[OpenID] SREG 1.x attributes

[Peter Williams]

Here is a compromise: make it clear that both solicited and unsolicited responses to an auth can bear a ax etension ... alongside the sreg).

Ax comes across as: ask for auth, get assertion (with sreg), now go back and ask for ax, get ax response (over association keys).

Then, ax is nothing more than the sreg attributes you wanted but don't have in the std...now encoded as ibm extra attribute schema in the companion ax extension.

This does address a rp form filing asking for more than the limited sreg attr set...but at least allows more to go back than requested (under the idp-sp trust model)



-----Original Message-----
From: Martin Atkins <mart at degeneration.co.uk>
Sent: Monday, December 01, 2008 4:07 PM
To: general at openid.net <general at openid.net>
Subject: Re: [OpenID] SREG 1.x attributes


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

_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general