[OpenID] SREG 1.x attributes

[Martin Atkins]

Shane B Weeden wrote:
> 
> Andrew - understand your points, but that can be argued both ways. If I 
> *want* to use SREG, and *want* to advertise my headphone preference and 
> cannot extend the spec, I am forced to overload an existing attribute 
> name rather than advertise a more meaningful alternative. This is 
> exactly what happened in many early deployments of LDAP. And you're 
> right - no one will care that my implementation doesn't enforce that 
> element of the spec, and it won't. It's a shame though that some others 
> might, when that could simply be a deployment-time decision.
> 

Just to complete this thought, what would be the reason not to use AX 
for this use-case? (of avertising your "headphone preference")

It seems to me that whether you add an additional attribute to SREG or 
encode it using the designed-in extensibility of AX you need to alter 
both the Consumer and Server to support that attribute anyway, so at 
that point you can alter Consumer and Server to use AX at the same time.

Since AX is has decentralized extensibility designed in, I'm still 
wondering what the motivation is to allow ad-hoc extensibility in SREG. 
What use-cases does an ad-hoc SREG extension attribute satisfy that a 
custom AX attribute does not?

(The sort of use-case I'm looking for is something like "I want to 
automatically discover the headphone preference of the user."; "I want 
to send custom attributes using SREG" is not really a use-case, it's one 
of a number of solutions that satisfy the use-case.)