Completing the SREG 1.1 specification
Hi all,
It recently became apparent that version 1.1 of the Simple Registration
Extension (SREG), which updates the protocol to work as an OpenID
Authentication 2.0 extension, was never finished and published.
Furthermore, it has been noted that the latest draft contains
ambiguities about how SREG is to be used in 1.1 vs. 2.0 messages, and
that in some cases it does not describe how SREG is used by popular
implementations today.
I'd like to form a working group to get version 1.1 completed, with a
focus on simply writing down what current implementations do to aid
interoperability rather than making any changes.
I have a draft of a more formal working group proposal prepared, but
first I'd like to see who is interested in working on this. The minimum
membership for an OpenID Foundation working group is five members. I
anticipate that this group's work will be done relatively quickly, since
we'd merely be documenting established practice.
Please reply here if you'd be interested in joining this working group,
and in particular whether you are willing to be listed as a proposer in
the working group proposal.
I have included below my current draft working group proposal. I welcome
any comments on it.
Thanks,
Martin
OpenID Authentication 2.0 was finalized this past December and since
has started to see quite reasonable adoption. Many implementations
of Authentication 2.0 have made use of the Simple Registration
Extension that was popularized as an ad-hoc OpenID 1.1 extension.
While SREG is compatible with and has been deployed using the more
formal extension mechanism described in OpenID Authentication 2.0,
a 2.0-compatible version of SREG was never published. A draft
revised version is available [1], but it was never approved as
a specification and contains some ambiguities about how SREG
is used in 2.0 vs 1.1 messages.
This proposal is to form a working group to finish and publish
a version of SREG that is compatible with OpenID Authentication 2.0,
describing how SREG is used in existing popular implementations.
== Background information ==
Many implementors have extrapolated how SREG 1.0 can be used within
the extension mechanism defined in OpenID Authentication 2.0, but
this has actually never been documented in a specification. A draft
of "SREG 1.1" was produced[1], but it was not published and has been
found to contain some ambiguities and deviations from established
practice.
== Working Group Name ==
OpenID Simple Registration Extension 1.1
== Purpose ==
To complete and publish the SREG 1.1 specification, documenting
how SREG is used by popular implementations today.
== Scope ==
The proposed work is as follows:
* Update the SREG specification to describe how it can be used as
an OpenID 2.0 extension as well as an OpenID 1.1 ad-hoc extension.
* Update the SREG specification to correct any deviations between
the specification and established implementation practice.
Note that this charter does not include adding new features to
Simple Registration; ideally, the specification produced by this
working group will merely be documenting existing implementation
practice, and will require no changes to existing implementations
as far as possible. Where implementations differ, an approach
will be chosen on the basis of number of deployments and on
consensus within the working group.
== Anticipated Contributions ==
* Feedback from library authors and other implementors about
how they have adapted SREG 1.0 to work within OpenID 2.0's
extension mechanism.
* Specification text to achieve the the goals described in
the above scope.
== Proposed List of Specifications ==
* OpenID Simple Registration Extension 1.1 ("SREG 1.1")
== Anticipated audience or users of the work ==
Implementers of OpenID Providers and Relying Parties.
== Language in which the WG will conduct business ==
English.
== Method of work ==
Work will take place primarily on the working group mailing list,
with the possibility of conference calls and face-to-face meetings
if deemed necessary by the working group.
== Basis for determining when the work of the WG is completed ==
Proposed changes will be evaluated on the basis of whether they
increase or decrease consensus within the working group. The work
will be completed once it is apparent that maximal consensus on the
draft has been achieved, consistent with the purpose and scope.
Proposers:
* Martin Atkins, Six Apart ([EMAIL PROTECTED])
* David Recordon, Six Apart ([EMAIL PROTECTED])
* ...
Initial Editors:
* Martin Atkins, Six Apart ([EMAIL PROTECTED])
* David Recordon, Six Apart ([EMAIL PROTECTED])
[1]http://openid.net/specs/openid-simple-registration-extension-1_1-01.html
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
Re: Completing the SREG 1.1 specification
A related topic.
Wondering what the community thinks of having two specifications for
moving around profile data: we have SREG and AX: do we need both?
-- Dick
On 28-Nov-08, at 2:33 PM, Martin Atkins wrote:
>
> Hi all,
>
> It recently became apparent that version 1.1 of the Simple
> Registration
> Extension (SREG), which updates the protocol to work as an OpenID
> Authentication 2.0 extension, was never finished and published.
>
> Furthermore, it has been noted that the latest draft contains
> ambiguities about how SREG is to be used in 1.1 vs. 2.0 messages, and
> that in some cases it does not describe how SREG is used by popular
> implementations today.
>
> I'd like to form a working group to get version 1.1 completed, with a
> focus on simply writing down what current implementations do to aid
> interoperability rather than making any changes.
>
> I have a draft of a more formal working group proposal prepared, but
> first I'd like to see who is interested in working on this. The
> minimum
> membership for an OpenID Foundation working group is five members. I
> anticipate that this group's work will be done relatively quickly,
> since
> we'd merely be documenting established practice.
>
> Please reply here if you'd be interested in joining this working
> group,
> and in particular whether you are willing to be listed as a proposer
> in
> the working group proposal.
>
> I have included below my current draft working group proposal. I
> welcome
> any comments on it.
>
> Thanks,
> Martin
>
>
>
> OpenID Authentication 2.0 was finalized this past December and since
> has started to see quite reasonable adoption. Many implementations
> of Authentication 2.0 have made use of the Simple Registration
> Extension that was popularized as an ad-hoc OpenID 1.1 extension.
>
> While SREG is compatible with and has been deployed using the more
> formal extension mechanism described in OpenID Authentication 2.0,
> a 2.0-compatible version of SREG was never published. A draft
> revised version is available [1], but it was never approved as
> a specification and contains some ambiguities about how SREG
> is used in 2.0 vs 1.1 messages.
>
> This proposal is to form a working group to finish and publish
> a version of SREG that is compatible with OpenID Authentication 2.0,
> describing how SREG is used in existing popular implementations.
>
>
>
> == Background information ==
> Many implementors have extrapolated how SREG 1.0 can be used within
> the extension mechanism defined in OpenID Authentication 2.0, but
> this has actually never been documented in a specification. A draft
> of "SREG 1.1" was produced[1], but it was not published and has been
> found to contain some ambiguities and deviations from established
> practice.
>
> == Working Group Name ==
> OpenID Simple Registration Extension 1.1
>
> == Purpose ==
> To complete and publish the SREG 1.1 specification, documenting
> how SREG is used by popular implementations today.
>
> == Scope ==
> The proposed work is as follows:
> * Update the SREG specification to describe how it can be used as
> an OpenID 2.0 extension as well as an OpenID 1.1 ad-hoc extension.
> * Update the SREG specification to correct any deviations between
> the specification and established implementation practice.
>
> Note that this charter does not include adding new features to
> Simple Registration; ideally, the specification produced by this
> working group will merely be documenting existing implementation
> practice, and will require no changes to existing implementations
> as far as possible. Where implementations differ, an approach
> will be chosen on the basis of number of deployments and on
> consensus within the working group.
>
> == Anticipated Contributions ==
> * Feedback from library authors and other implementors about
> how they have adapted SREG 1.0 to work within OpenID 2.0's
> extension mechanism.
> * Specification text to achieve the the goals described in
> the above scope.
>
> == Proposed List of Specifications ==
> * OpenID Simple Registration Extension 1.1 ("SREG 1.1")
>
> == Anticipated audience or users of the work ==
> Implementers of OpenID Providers and Relying Parties.
>
> == Language in which the WG will conduct business ==
> English.
>
> == Method of work ==
> Work will take place primarily on the working group mailing list,
> with the possibility of conference calls and face-to-face meetings
> if deemed necessary by the working group.
>
> == Basis for determining when the work of the WG is completed ==
> Proposed changes will be evaluated on the basis of whether they
> increase or decrease consensus within the working group. The work
> will be completed once it is apparent that maximal consensus on the
> draft has been achieved, consistent with the purpose and scope.
>
> Proposers:
> * Martin Atkins, Six Apart ([EMAIL PROTECTED])
> * David Recordon, Six Apart ([EMAIL PR
Re: Completing the SREG 1.1 specification
I agree that it's not ideal to have both, and in an ideal world everyone would use AX, but currently SREG seems to be more widely deployed than AX. This working group proposal was motivated not by some desire to needlessly perpetuate SREG but rather by actual real-world interop problems I've had to deal with as an implementer. As long as folks still want to implement SREG, I think it's beneficial to have a specification that actually works in practice, which the current draft does not. Dick Hardt wrote: > A related topic. > > Wondering what the community thinks of having two specifications for > moving around profile data: we have SREG and AX: do we need both? > ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Completing the SREG 1.1 specification
On 28-Nov-08, at 11:28 PM, Martin Atkins wrote: > > I agree that it's not ideal to have both, and in an ideal world > everyone > would use AX, but currently SREG seems to be more widely deployed than > AX. This working group proposal was motivated not by some desire to > needlessly perpetuate SREG but rather by actual real-world interop > problems I've had to deal with as an implementer. > > As long as folks still want to implement SREG, I think it's beneficial > to have a specification that actually works in practice, which the > current draft does not. Agreed. I was checking to see what people want to implement! If the community is ready to move to AX, then you don't need to do the work. If the community wants both, then it does need to get cleaned up. > > Dick Hardt wrote: >> A related topic. >> >> Wondering what the community thinks of having two specifications for >> moving around profile data: we have SREG and AX: do we need both? >> > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Completing the SREG 1.1 specification
I certainly want to see us push the world to implementing AX instead of SREG, though agree with Mart that there are existing interoperability problems with SREG that would be nice to fix given that large OPs are still implementing it in a broken fashion. I'd see no issue with including in the SREG spec that people really should go use AX instead. --David On Nov 29, 2008, at 12:40 AM, Dick Hardt wrote: > > On 28-Nov-08, at 11:28 PM, Martin Atkins wrote: > >> >> I agree that it's not ideal to have both, and in an ideal world >> everyone >> would use AX, but currently SREG seems to be more widely deployed >> than >> AX. This working group proposal was motivated not by some desire to >> needlessly perpetuate SREG but rather by actual real-world interop >> problems I've had to deal with as an implementer. >> >> As long as folks still want to implement SREG, I think it's >> beneficial >> to have a specification that actually works in practice, which the >> current draft does not. > > Agreed. I was checking to see what people want to implement! > > If the community is ready to move to AX, then you don't need to do the > work. > > If the community wants both, then it does need to get cleaned up. > >> >> Dick Hardt wrote: >>> A related topic. >>> >>> Wondering what the community thinks of having two specifications for >>> moving around profile data: we have SREG and AX: do we need both? >>> >> ___ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs > > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Completing the SREG 1.1 specification
Yahoo is currently testing SREG, and we'd like to see the 1.1 SREG draft updated to clarify any ambiguities before we're done testing. We'd also like to see the schema updated to include the user's profile pic. We decided to build support for SREG before AX because SREG seems to be more widely used, and also because SREG allows the RP to pass the url to its privacy policy in the request. Strangely, AX does not have an interface for the RP to pass its privacy policy to the OP. We have a mandatory requirement from our legal and privacy teams to be able to link to the RP's privacy policy on our OpenID approval page before sharing any user data with an RP. We'd like SREG to be updated to enable the profile pic to be in the schema, and also any other cleanup that's needed for OpenID 2.0 OPs to support it. Moving forward, we'd also like to support both SREG and AX, if AX is updated to allow the privacy policy url to be included in the request. Alternatively, OPs which support the OpenID/OAuth hybrid protocol can just tie the privacy policy to an OAuth consumer key, assuming that the OP requires pre-registered consumer keys. I'd be happy to help contribute to SREG and AX specs if the owners of the spec would like me to. Allen David Recordon wrote: > I certainly want to see us push the world to implementing AX instead > of SREG, though agree with Mart that there are existing > interoperability problems with SREG that would be nice to fix given > that large OPs are still implementing it in a broken fashion. I'd see > no issue with including in the SREG spec that people really should go > use AX instead. > > > >> On 28-Nov-08, at 11:28 PM, Martin Atkins wrote: >> >> >>> >>> As long as folks still want to implement SREG, I think it's >>> beneficial >>> to have a specification that actually works in practice, which the >>> current draft does not. >>> ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Completing the SREG 1.1 specification
On 2-Dec-08, at 3:41 PM, Allen Tom wrote: > > We decided to build support for SREG before AX because SREG seems to > be > more widely used, and also because SREG allows the RP to pass the > url to > its privacy policy in the request. Strangely, AX does not have an > interface for the RP to pass its privacy policy to the OP. Not sure how we missed that feature in SREG. Our bad. > Moving forward, we'd also like to support both SREG and AX, if AX is > updated to allow the privacy policy url to be included in the request. Looking at what needs to be addressed in AX. Good suggestion. Ties in with suggestions from Nat where the response with the privacy policy is returned all signed by the OP. > > > I'd be happy to help contribute to SREG and AX specs if the owners of > the spec would like me to. please! ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Completing the SREG 1.1 specification
there would appear to be an opportunity here for some drop-dead simple cross-protocol harmonization by the larger community agreeing on the definition of these sort of privacy policy identifiers by which a requestor indicates its privacy commitments and the authority any obligations. Define the various URIs and the associated semantics, and leave it to the particular protocols or metadata formats to define bindings. Liberty took a first stab [1] a while back, but had/has no expectation that the work would be meaningful if used only for Liberty/SAML protocols. [1] - http://www.projectliberty.org/liberty/content/download/4323/28921/file/draft-liberty-igf-privacy-constraints-v1.0-04.pdf paul Dick Hardt wrote: On 2-Dec-08, at 3:41 PM, Allen Tom wrote: We decided to build support for SREG before AX because SREG seems to be more widely used, and also because SREG allows the RP to pass the url to its privacy policy in the request. Strangely, AX does not have an interface for the RP to pass its privacy policy to the OP. Not sure how we missed that feature in SREG. Our bad. Moving forward, we'd also like to support both SREG and AX, if AX is updated to allow the privacy policy url to be included in the request. Looking at what needs to be addressed in AX. Good suggestion. Ties in with suggestions from Nat where the response with the privacy policy is returned all signed by the OP. I'd be happy to help contribute to SREG and AX specs if the owners of the spec would like me to. please! ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Completing the SREG 1.1 specification
Yes, the idea is to pass an URL to the the user's profile pic. I'm not sure if the resolution/aspect ratio needs to be communicated. Also, is the RP expected to download and cache the profile pic, or should it link directly to it? This needs to be clarified in the spec. +1 for adding additional URLs which are associated with the user. This could be helpful for identity consolidation. Allen Sam Alexander wrote: > +1 for adding a profile pic to the SREG 1.1 spec. > > Allen, I'm assuming you mean including a URI to the profile pic as > opposed to something like a base64 encoded jpeg or something else > totally awesome like that :) > > Also, having a "homepage" or "website" URI would be another great > field addition. This would be a URI that pointed to a blog, homepage, > additional OpenID or other URI that the user would like to provide. > > I agree that the strength of SREG is its constrained fields. These > two additions would allow ALOT of value to the spec, however, if they > were to be considered. > > -Sam > > On Dec 2, 2008, at 3:41 PM, Allen Tom wrote: > >> Yahoo is currently testing SREG, and we'd like to see the 1.1 SREG draft >> updated to clarify any ambiguities before we're done testing. We'd also >> like to see the schema updated to include the user's profile pic. >> >> We decided to build support for SREG before AX because SREG seems to be >> more widely used, and also because SREG allows the RP to pass the url to >> its privacy policy in the request. Strangely, AX does not have an >> interface for the RP to pass its privacy policy to the OP. We have a >> mandatory requirement from our legal and privacy teams to be able to >> link to the RP's privacy policy on our OpenID approval page before >> sharing any user data with an RP. >> >> We'd like SREG to be updated to enable the profile pic to be in the >> schema, and also any other cleanup that's needed for OpenID 2.0 OPs to >> support it. >> >> Moving forward, we'd also like to support both SREG and AX, if AX is >> updated to allow the privacy policy url to be included in the request. >> Alternatively, OPs which support the OpenID/OAuth hybrid protocol can >> just tie the privacy policy to an OAuth consumer key, assuming that the >> OP requires pre-registered consumer keys. >> >> I'd be happy to help contribute to SREG and AX specs if the owners of >> the spec would like me to. >> >> Allen >> >> >> David Recordon wrote: >>> I certainly want to see us push the world to implementing AX instead >>> of SREG, though agree with Mart that there are existing >>> interoperability problems with SREG that would be nice to fix given >>> that large OPs are still implementing it in a broken fashion. I'd see >>> no issue with including in the SREG spec that people really should go >>> use AX instead. >>> >>> >>> On 28-Nov-08, at 11:28 PM, Martin Atkins wrote: > > As long as folks still want to implement SREG, I think it's > beneficial > to have a specification that actually works in practice, which the > current draft does not. > >> >> ___ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs > ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
