All - Inconsistency between user_id and prn claims

[Former user]

In an on-list discussion, I suggested using the JWT Assertion grant as a method of id token renewal:

http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20121105/002506.html

In order to fulfil the parsing requirements of the JWT Bearer Assertion, the id_token would need a 'prn' field representing the user. Right now, this is a role being fulfilled by the 'user_id' field, and adding a 'prn' field (which I've done in my testing environment) with the same information would be needlessly redundant. However, it's the only field missing from the id_token being usable in a JWT Bearer Assertion, and it would be useful to be able to treat the id_token like a generic JWT in many circumstances.

Alternatively, this begs the question of why does the id_token need a 'user_id' field if JWT already defines something for this? I believe the answer is that the id_token definition predates JWT having the 'prn' field, but I'm not positive. I also believe that 'user_id' reads much better than 'prn' (unless you're a SAML nerd). I've never been a fan of JWT's short names, either, but that's besides the point.

Note that this is a distinct request from #636.

[Brian Campbell]

FWIW, I've also wondered why "user_id" was used in the id_token rather than "prn".

[John Bradley]

The reason was we were trying to match what Facebook was using in signedrequest.

The other thing is the prn field is global like a upn as opposed to user_id which is scoped to the issuer.

There were debates at the time about concatenating them together in the prn requiring more parsing on the client. If you use prn and iss then you need to compare the two unless you scope prn by isa .

One option would be to change to prn but that would send the domain twice which is a waste of space.

Mike can comment on if prn could be allowed to be scoped to the iss. They are semantically different.

[Former user]

I was unaware of the scoping differences between the fields, thanks for that clarification. Then how about this: the 'prn' in OIDC should be defined as iss + user_id, but still keep the separate fields as well. This would prevent clients having to do string parsing but let the id_token be compliant with JWT assertions.

[Michael Jones]

I agree that it would be a shame, architecturally, if we can't use an ID Token as a assertion in a way that complies with the OAuth JWT Assertion Profile. I believe we need to address this.

There are few ways to do this, as I see it:

1. Add "prn" to the ID Token. Upside: Simple. Downsides: Wastes space through duplication of data; potential interop problem where not everyone duplicates or uses the information in the same way.

2. Replace "user_id" with "prn" in the ID Token. Downside: Less mnemonic than user_id. Upside: simple.

3. Modify the OAuth JWT Assertion Profile to allow the subject to be identified by a claim other than "prn" - possibly explicitly calling out "user_id". Upside: would work. Downside: Codifies inconsistency.

4. Replace both "user_id" and "prn" with a different claim in both specs. Candidates include "id" and "sub".

Let's make this a topic for Monday's call.

[Michael Jones]

Other possible claim names to replace "user_id" and "prn" include "sbj" and "who".

[Nat Sakimura]

BTW, you should define what is "subject" in JWT as well.

[Michael Jones]

Changed issue title

[Michael Jones]

Fixed #687 - All - Inconsistency between user_id and prn claims

→ <<cset b53fb67e5efc>>