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

[John Bradley]

Subject would be consistent with SAML.   Principal is less common outside web services.

But I really don't care much.   There are more specs that need to be changed if it is changed to sub,  however I don't think that is insurmountable at this point.  
Once the JWT Assertions spec is done then it gets tough.

John B.

On 2012-12-19, at 6:45 PM, Justin Richer <jricher at mitre.org> wrote:

> 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> 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?
> 
> 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] 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
>> 
>> 
>> 
>> _______________________________________________
>> 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/60fc4e28/attachment.html>