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

Richer, Justin P. jricher at mitre.org
Mon Jun 11 15:30:51 UTC 2012

If we put a length limit on this claim's data, we must limit all others as well. It won't be an infinite stream because JSON can't do that and this all MUST be valid JSON.

What I was attempting to convey with this language is that it might not be 8 characters long or whatever other arbitrary limitation an RP might impose, and that it's up to the RP to deal with values outside of its storage capabilities, much like it must do already with name and other fields.

 -- Justin

On Jun 11, 2012, at 11:26 AM, Sascha Preibisch wrote:

Whenever I read “there are no length limitations to this field” alarm bells start ringing. I would always prefer to have a limit even if it is big. Potentially an unlimited text field could be an endless stream of data which could cause severe issues on the RP.
I would suggest to set a max. length for this (and any other) field.


From: openid-specs-ab-bounces at lists.openid.net<mailto:openid-specs-ab-bounces at lists.openid.net> [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Richer, Justin P.
Sent: Monday, June 11, 2012 7:50 AM
To: Mike Jones
Cc: openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>
Subject: Re: [Openid-specs-ab] Spec call notes 7-Jun-12

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:

== 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<mailto: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.


On 2012/06/08, at 22:57, Justin Richer <jricher at mitre.org<mailto: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

                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<mailto:Openid-specs-ab at lists.openid.net>


Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>

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

More information about the Openid-specs-ab mailing list