[OpenID] SREG 1.x attributes

[Martin Atkins]

Peter Williams wrote:
> 
> 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
> 

It's been a while since I reviewed the AX specification, but unless the 
AX specification specifically forbids it it ought to be acceptable to 
send an unsolicited positive assertion (which is what the Auth spec 
calls your "unsolicited AuthN response") with AX extension fields. I 
don't see any reason why it would.

The Authentication spec doesn't give any special requirements about 
unsolicited positive assertions except to give RPs permission (via the 
opposite of a SHOULD) to reject them. Therefore I think the default, 
unless an extension spec explicitly says otherwise, is that the 
extension fields may be used in both solicited and unsolicited positive 
assertions.

> 
> 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.
> 

I'm not sure that a state machine for AX would be very interesting. It's 
really just a request-response protocol like HTTP: you can send a 
request for attributes and recieve a response, and you can send a 
request to update attributes and recieve a response. Just as with HTTP, 
the protocol itself is stateless. (the attribute values themselves are 
not, of course.)

If you've got a general idea of what you imagine a state machine diagram 
for AX would look like (even if it's a little vaugue in some places) 
then I'd be interested to see/hear about it; perhaps it can be included 
in a future version of the protocol.