[OpenID] SREG 1.x attributes

Peter Williams pwilliams at rapattoni.com
Tue Dec 2 03:47:31 UTC 2008


From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Dick Hardt

Sent: Monday, December 01, 2008 4:57 PM

To: Martin Atkins

Cc: general at openid.net

Subject: Re: [OpenID] SREG 1.x attributes





AX works as you think it works Martin.



Peter's comments are confusing to me.



-- Dick





Let's look at the text::-



>From "Overview":

This service extension defines two message types for transferring attributes: fetch (see Section 5 (Fetch Message)<http://openid.net/specs/openid-attribute-exchange-1_0.html#fetch>) and store (see Section 6 (Store Message)<http://openid.net/specs/openid-attribute-exchange-1_0.html#store>). Fetch retrieves attribute information from an OpenID Provider, while store saves or updates attribute information on the OpenID Provider. Both messages originate from the Relying Party and are passed to the OpenID Provider via the user agent as per the OpenID Authentication protocol specification.



>From "Section 5":
Fetch Message
The fetch message is used to retrieve personal identity attributes from an OpenID Provider.





Given I (really do!) come from way down in the class ranking, I read  all that plainly ( but incorrectly).



There really is very little in the AX standard that indicates what I now understand - that the AX extension  is _supposed_ to be used only as a message extension of an actual, classical, openid authN request/response run.  Unlike my state machine's assumption (for the last year), AX is NOT supposed to be used while merely leveraging an existing openid association between RP and OP, where the request's openid.cliamed_id AND openid.identity are both absent.

"openid.claimed_id" and "openid.identity" SHALL be either both present or both absent. If neither value is present, the assertion is not about an identifier, and will contain other information in its payload, using extensions (Extensions)<http://openid.net/specs/openid-authentication-2_0.html#extensions>.



Now I know the  right model (claimed_id = identity = not null where typeof(identity) isa URI/XRI) , if I carefully read section3.1,  I __can__ (and now _do_) comprehend from the very structure  of the section that the fetch request (of attributes)  MUST accompany an identity/authentication request. That is,  unlike a SAML attribute request (which need not be associated with any previous run of the authentication protocol), an AX fetch req extension must only be used as an extension of a classical openid authN req. It MUST not be used where identity=claimed_id=null.



I think I also understand, that an unsolicited AuthN response MUST NOT be extended with the AX response fields defined in 5.2 unless the OP is performing the update procedures described in the field "openid.ax.update_url". The async issuance by the OP of one or more fetch response messages (given the receipt of an sponsoring update request, earlier) MAY or MAY NOT make an assertion about the claimed_id



(I still not sure on the last bit, to be truthful.)





Rather than just specify message elements, it would be much easier to understand if ALL the states and ALL the procedures per state were listed! Then, one can just write a typical protocol state machine, rather than hoping that the _assumed_ state table is complete.



To be fair, the phrasing of 3.1 (In other words...) DOES imply what Dick says, (now I know the right answer). But, in 10 readings...I missed its significance.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081201/58fd6382/attachment-0001.htm>


More information about the general mailing list