[Openid-specs-ab] Inconsistency between user_id and prn claims - notice of upcoming breaking change

[Justin Richer]

On 12/19/2012 03:07 PM, Breno de Medeiros wrote:
>
>
>
> On Wed, Dec 19, 2012 at 11:09 AM, Mike Jones 
> <Michael.Jones at microsoft.com <mailto:Michael.Jones at microsoft.com>> wrote:
>
>     While of course you're right that "prn" isn't highly intuitive,
>     neither are the contents of this particular claim.  It will
>     contain values not intended for consumption by humans, such as
>     24400320 or AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4 -- not values
>     intended for human consumption such as ben at livefyre.com
>     <mailto:ben at livefyre.com>.
>
>     UID (or for that matter user_id) don't work in the general case
>     because the principal/subject may not be a user.  It could be an
>     OAuth client, a service, etc.
>
>     FYI, "sbj" was discussed and rejected during the call because it's
>     really not any more intuitive than "prn" and if we use anything
>     other than "prn" we'd have to change two IETF specs as well (JWT
>     and the OAuth JWT Assertion Profile).
>
>
> But neither of these other specs are final, right?

Correct, and I think that Mike's claim is a little bit of a red herring. 
Making a change will have some friction, but not enough for it to be 
impossible. I would rather us have something that is intuitive to the 
intended audience -- developers. "sub", to me, is more common and 
understandable than "prn". But I'm also not coming from a SAML or even a 
general Security Nerd background, where "principal" is used more often.

  -- Justin

>     -- Mike
>
>     *From:*openid-connect-interop at googlegroups.com
>     <mailto:openid-connect-interop at googlegroups.com>
>     [mailto:openid-connect-interop at googlegroups.com
>     <mailto:openid-connect-interop at googlegroups.com>] *On Behalf Of
>     *Benjamin Goering
>     *Sent:* Tuesday, December 18, 2012 9:37 PM
>     *To:* openid-connect-interop at googlegroups.com
>     <mailto:openid-connect-interop at googlegroups.com>
>     *Cc:* openid-specs-ab at lists.openid.net
>     <mailto:openid-specs-ab at lists.openid.net>
>     *Subject:* Re: Inconsistency between user_id and prn claims -
>     notice of upcoming breaking change
>
>     `prn` doesn't map to anything intuitive to most non-expert hackers
>     in the industry (IMHO), and `subj` would be better than `sub`
>     (subscription). Is `uid` an option given knowledge of these other
>     specs? Just my naive opinion.
>
>
>
>     On Monday, December 17, 2012 5:05:26 PM UTC-8, Mike Jones wrote:
>
>     Mitre and Microsoft implementers have both recently independently
>     pointed out that an ID Token is not currently usable as an OAuth
>     JWT Assertion because it uses the "user_id" claim to identify the
>     subject of the token, rather than the "prn" (principal) claim, as
>     specified in the OAuth JWT Assertion spec.  This inconsistency is
>     already causing real problems/limitations for implementations. 
>     See http://hg.openid.net/connect/issue/687 for more background on
>     the issue.
>
>     This was discussed on the working group call today and it was
>     decided that while changing the "user_id" claim name now would be
>     painful, it would be more painful over time to keep having
>     implementer's try to work around this inconsistency when they need
>     to use an ID Token as an OAuth JWT assertion. Therefore, we
>     decided that the specs should be changed so that an ID Token is a
>     legal OAuth JWT Assertion.  The simplest way to do this would be
>     to change all uses of the claim name "user_id" to "prn". Only the
>     syntax would change -- not the meaning of the claim.
>
>     The other potential solution that was discussed was to change both
>     the names "user_id" and "prn" to "sub" (subject).  While being a
>     (somewhat) more meaningful name, using "prn" was preferred because
>     it will involve a change only to the Connect specs -- not also to
>     the JWT and OAuth JWT Assertion specs.
>
>     The participants in the working group call decided that we should
>     make this change, but we wanted to give clear notice to the
>     working group and interop participants of this upcoming breaking
>     change.  If you would like to propose an alternative solution to
>     the inconsistency, please do so before the Thursday OpenID Connect
>     call.  We plan to include this change in the upcoming
>     implementer's drafts.
>
>     -- Mike
>
>
>     _______________________________________________
>     Openid-specs-ab mailing list
>     Openid-specs-ab at lists.openid.net
>     <mailto:Openid-specs-ab at lists.openid.net>
>     http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
>
> -- 
> --Breno
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20121219/3b9a86a3/attachment.html>