[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-0001.html>


More information about the Openid-specs-ab mailing list