[Openid-specs-ab] Spec call notes 7-Jun-12

Justin Richer jricher at mitre.org
Thu Jun 14 16:51:53 UTC 2012


"display_name" sounds too much like the displayed value of the user's 
full name, which is what "name" is for. The motivation for using 
"username" was largely copying from Facebook, which is where the rest of 
the UserInfo schema is copied from. If we're not going to keep copying 
Facebook, then I would rather to see "preferred_username", which is 
taken from the PoCo "preferredUsername" field. (I'll here interject that 
SCIM is using "userName", but their version of "userName" conflates the 
functionality of our user_id and username, which is something I very 
much want to avoid, so I don't think there's much use in tracking SCIM 
here, unfortunately.)

If we change the text to the following, does this address everyone's 
concerns?

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


    == 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 preferred_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 preferred_username or email
    address claim across different different End-Users at different
    points in time, and the claimed preferred_username or email address
    for a given End-User MAY change over time.



I believe that this language allows IdPs that want to do so to tie 
preferred_username directly and uniquely to user_id (since some will), 
but it doesn't force them to and it cautions RPs away from relying on 
that across IdPs.

  -- Justin

On 06/14/2012 01:56 AM, Roland Hedberg wrote:
> In the LDAP community we have displayName as the name of a similar attribute.
> In this community that would translate to display_name :-)
>
> -- Roland
>
> 14 jun 2012 kl. 02:19 skrev Mike Jones:
>
>> I’d be *MUCH* happier with that.  Changing the claim name in this manner would likely change my position from being opposed to the claim to not opposing it.
>>
>>                                                                  -- Mike
>>
>> From: Nat Sakimura [mailto:sakimura at gmail.com]
>> Sent: Wednesday, June 13, 2012 5:06 PM
>> To: Richer, Justin P.
>> Cc: Mike Jones; openid-specs-ab at lists.openid.net
>> Subject: Re: [Openid-specs-ab] Spec call notes 7-Jun-12
>>
>> 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
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> -- Roland
> ------------------------------------------------------
> Roland Hedberg
> IT Architect/Senior Researcher
> ICT Services and System Development (ITS)
> Umeå University
> SE-901 87 Umeå, Sweden	
> Phone +46 90 786 68 44
> Mobile +46 70 696 68 44
> www.its.umu.se
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120614/6b2243b6/attachment-0001.html>


More information about the Openid-specs-ab mailing list