[OpenID] About Facebook, MySpace and OpenID

[Deron Meranda]

On Sun, Apr 5, 2009 at 1:04 PM, Peter Williams <pwilliams at rapattoni.com> wrote:
> The context is one of an OP minting an openid assertion, which creates an RP session based on asking for n attributes. But, if I as RP ask for another assertion 59 minutes later, I don’t expect as an RP to be asking for more or less attributes at that point (just because some or other set was or was not requested/delivered last time). I just ask for another assertion, and indicate that I need the OP to (still) represent the n attributes as (then) accurate, etc.

Sure, that's valid.  But also as an RP you shouldn't expect that just because
you ask for an attribute that you'll get it back if the answer is still the same
as the last time you asked.  This is a protocol/bandwidth optimization thing
that Google is doing; but it doesn't fundamentally change the correctness
does it?  (other than requiring the RP maintain state between requests).


> Given Google may have suspended the user account in the last 59 minute, I want to know that fact before I grant the (former google) user access to stored RP-stored credit card information (for example). As a relying party, I am RELYING ON google (for example) legally. If they are not doing something at the level  of (pape) assurance or completeness that I need to rely, what's the point of working with them - beyond merely using their friendly assertion to auto-populate an account signup form?

Again, I'm not sure how this related to AX attributes.

If the account has been suspended, or whatever, then I would assume
you'd get a negative
assertion back. But as far as any of the AX attributes, you only get
those back if: 1) your
RP has never asked for and received this AX value for this id before,
OR 2) the value has
changed since your RP last received it.

So if you ask for an attribute, and you get back a positive assertion
but no value for
that attribute; then the value must still be the same as the last time
you asked.
Isn't that sufficient for what you're describing your need is?

The only non-obvious part is that the RP must know to store the attributes it
receives, so that it can tell what the "last" value was.  It's really
not that big
of a burden, as long as the RP *knows* they have to do it.  (And this is where
the AX spec is rather quiet on the issue and thus have been surprised by
Google's behavior).


> The biggest point is that I cannot build openid software that knows how users cooperate with Google's particular consent/release/UI/persistence assumptions. As OP, they either given me the RP an positive assertion back with all required attribute or they don’t. If they don’t, the RP switches to the next selected RP service in the user's XRDS... per the protocol. If none support the required attribute set representing they have the required level of assurance, the RP will request the user supply the attribute values directly - by typing then in the form, as usual. The RP will then rely (directly) on the user, vs the OP.

I'm not sure what you mean by you "cannot build".  I think perhaps
you're talking
about how Google treats "optional" attributes as the same thing as "required"
attributes; so that in practice there really is no such thing as an optional AX
attribute.  This of course appears to be one of the biggest issues raised in
this thread, and it's not clear yet who's right (although I think it
is clear that
people want the AX spec to say more about the expected behavior).
-- 
Deron Meranda