[Openid-specs-ab] Spec call notes 7-Jun-12
Nat Sakimura
sakimura at gmail.com
Thu Jun 14 00:05:34 UTC 2012
Thanks Justin.
Can we use a claim name that would not let the developers mistake as a
unique username?
For example, instead of "username", "username_hint".
Best,
Nat
On Wed, Jun 13, 2012 at 3:25 AM, Richer, Justin P. <jricher at mitre.org>wrote:
> After some off-list discussions with Nat and a few others, here's an
> updated proposed wording:
>
> username string Shorthand name that the End-User wishes to be
> referred to at the RP, such as "janedoe" or "j.doe". This value MAY
> be any valid JSON string including
> special characters such as "@", "/", or whitespace. This value MUST NOT
> be relied upon to be unique by the
> RP. (See § 2.3.2.2)
> email string The End-User's preferred email address. This
> value MUST NOT be relied upon to be unique by the RP. (See § 2.3.2.2)
>
> And add the following section:
>
>
> == 2.3.2.2 Claim Stability and Uniqueness
>
> The user_id claim is the only claim which a client can rely upon to be
> stable, since user_id claim MUST be locally unique and never reassigned
> within the Issuer for a particular End-User as described in § 2.1.1.
> Therefore, the only guaranteed unique identifier for a given End-User is a
> combination of the Issuer's identifier and the user_id claim, and other
> fields such as username and email MUST NOT be used as unique identifiers
> for a given End-User.
>
> All other claims carry no such guarantees across different issuers in
> terms of stability over time or uniqueness across users, and issuers are
> permitted to apply local restrictions and policies. For instance, an Issuer
> MAY re-use a given username or email address claim across different
> different End-Users at different points in time, and the claimed username
> or email address for a given End-User MAY change over time.
>
>
>
> On Jun 11, 2012, at 10:50 AM, Richer, Justin P. wrote:
>
> Here is my proposed language to be added to the table in Messages §
> 2.3.2 (would suggest just below nickname):
>
>
> username string Shorthand name that the user wishes to be
> referred to at the RP, such as "janedoe". This value MAY be any valid
> JSON string including special
> characters such as "@", "/", or whitespace. There are no length limitations
> to this field.
>
>
>
> Then I'd suggest adding a new section:
>
>
> == 2.3.2.2 Claim Stability and Uniqueness
>
> Since user_id claim MUST be locally unique and never reassigned within
> the Issuer for a particular End-User as described in § 2.1.1, it is the
> only claim which can be relied upon to be stable. Therefore, the only
> guaranteed unique identifier for for a given End-User is a combination of
> the Issuer's identifier and the user_id claim.
>
> All other claims carry no such guarantees across different issuers in
> terms of stability over time or uniqueness across users. For instance, an
> Issuer MAY re-use a given username or email address claim across different
> different End-Users at different points in time, and the claimed username
> or email address for a given End-User MAY change over time.
>
>
>
>
>
> -- Justin
> On Jun 9, 2012, at 1:11 AM, Mike Jones wrote:
>
> It would help to have the exact text that the working group is being
> asked to add to the specs for this potential claim. One of the recurring
> problems in the discussion of issue #584 is that different people have been
> reading very different meanings and intent into the request.****
> ** **
> Since you’re the advocate for this, Justin, do you want to take first
> crack at writing up the proposed language to be added to the spec? I think
> that would really help your case.****
> ** **
> Best wishes,*
> ***
> -- Mike****
> ** **
> *From:* Nat Sakimura [mailto:sakimura at gmail.com]
> *Sent:* Friday, June 08, 2012 8:13 PM
> *To:* Justin Richer
> *Cc:* Mike Jones; openid-specs-ab at lists.openid.net
> *Subject:* Re: [Openid-specs-ab] Spec call notes 7-Jun-12****
> ** **
> We are going to have a call at a separate time for the
> claims_in_id_token issue at 7am Pacific. I am going to send out a doodle
> poll for that. Perhaps we can do the same for this one.
>
> =nat****
>
>
> On 2012/06/08, at 22:57, Justin Richer <jricher at mitre.org> wrote:****
>
> I think that the resolution to issue #584 (Username claim) is a mistake.
> We're regressing from capability available and used in OpenID 2.0 via SREG
> and AX. We're ignoring what an existing IdP, Facebook, already does.
>
> Telling clients to parse out the email address and pull in a name there is
> a ludicrous suggestion. Why don't we also drop given_name and family_name
> since the RP could just try and parse those out of "name"? It's absurd to
> make something this simple so complicated.
>
> I'm sorry that I can't make the telephone calls for the WG (for several
> personal reasons), especially since that seems to be where decisions like
> this get made. I would be happy to grab some other time to discuss this
> with people if more discussion is warranted. I'll even gladly submit a pull
> request of the spec changes for the issue. It will be about five lines
> tops, including all the XML.
>
> I can also say that our IdP implementation *will* have a username claim,
> and our in-house RP's *will* rely on it. I imagine that it other IdPs in
> the wild will as well. We might as well just decide here and now to
> standardize on it.
>
> And yes, I do think this is important.
>
> -- Justin
>
> On 06/07/2012 08:07 PM, Mike Jones wrote:****
> Spec call notes 7-Jun-12****
> ****
> Nat Sakimura****
> Mike Jones****
> George Fletcher****
> Edmund Jay****
> John Bradley****
> ****
> Agenda:****
> Next Interop****
> claims_in_id_token Issue****
> Session Management****
> Edits and Release****
> Open Issues****
> ****
> Next Interop:****
> We agreed that we need to clone the OC3 interop to create
> OC4 before adding****
> We will need Pam's buy-in and time to do this****
> ****
> claims_in_id_token Issue:****
> We agreed that it is easier to reach consensus when you
> can hear one another's voices than via e-mail****
> We will try to resolve this issue soon
> that way****
> Nat will send out a Doodle poll for special call time to
> discuss this issue****
> We will schedule the call at a time that makes it
> convenient for Europeans****
> ****
> We discussed that at John's proposal to have 4 new scope
> elements makes the scope elements not stateful****
> profile_idt email_idt address_idt
> phone_idt****
> Developers are rejecting claims_in_id_token because it
> made the 4 scope definitions stateful****
> ****
> ****
> Session Management:****
> Nat began transcribing the Session Management notes****
> He sent out initial notes that he needs feedback on****
> He noted that this spec will be quite different than the
> others, as it contains local APIs****
> ****
> Edits and Release:****
> The self-issued edits may be ready for review tomorrow -
> issue #566****
> After that, we'll do a release with that functionality
> only****
> ****
> Open Issues:****
> We discussed some of the open issues. There were no new
> ones.****
> #576: Discovery - Monitor IETF discovery spec decisions**
> **
> We're seeing no movement on WebFinger****
> We will need to decide soon what to do***
> *
> We could:****
> Stay with SWD****
> Try to profile a subset
> of WebFinger****
> Profile host-meta****
> #257: Acknowledgements and other sections need review****
> Nat complied a proposed list of
> acknowledgements****
> #539 Messages - 0. Add scope for offline access****
> AOL's approach requires stateful session
> state, Google's is stateless****
> This issue needs an owner and a concrete
> proposal****
> Assigned to George, who
> will work with Breno****
> #584 Messages - Username claim****
> We discussed whether syntax restrictions
> should be imposed and if so, what****
> No one on the call was particularly
> enamored with the claim****
> Relying parties could just use the part
> of the e-mail address before the @ to achieve approximately the same thing
> ****
> The consensus on the call was that this
> field is adding more confusion than value****
> Resolved as WontFix****
> #593 Standard: redirect_uri registration & matching****
> George argued that requiring matching
> query parameters is overkill****
> We only got through the issues up to #593****
>
>
> ****
>
> _______________________________________________****
>
> Openid-specs-ab mailing list****
>
> Openid-specs-ab at lists.openid.net****
>
> http://lists.openid.net/mailman/listinfo/openid-specs-ab****
>
> ** **
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120614/dacd529e/attachment.html>
More information about the Openid-specs-ab
mailing list