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

[Breno de Medeiros]

On Wed, Dec 19, 2012 at 11:09 AM, Mike Jones <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.****
>
> ** **
>
> 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?


> ****
>
> ** **
>
>                                                                 -- Mike***
> *
>
> ** **
>
> *From:* 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
> *Cc:* 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
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>


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