Subject: [OAUTH-WG] JSON Web Token (JWT) Profile

From: Antonio Sanso <[email-masked]>
Date: Tue, 11 Mar 2014 14:13:41 +0000

hi *,

JSON Web Token (JWT) Profile section 3 [0] explicitely says

The JWT MUST contain a "sub" (subject) claim

Now IMHO there are cases where having the sub is either not needed or redundant (since it might overlap with the issuer).\

As far as I can see “even Google” currently violates this spec [1] ( I know that this doesn’t matter, just wanted to bring a real use case scenario).

WDYT might the “sub” be optional in some situation?

regards

antonio

[0] http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07#section-3
[1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount

---

From: "Manfred Steyer" <[email-masked]>
Date: Tue, 11 Mar 2014 15:26:54 +0100

Hi Antonio,

some time ago, I wrote about the same issue, but – unfortunately – didn’t
get an answer. I place my thoughts about this at the end of this mail.

Wishes,

Manfred

8<-------------------------------

Hi,

the draft about the

JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants [1]

says:

„The JWT MUST contain a "sub" (subject) claim identifying theprincipal that
is the subject of the JWT.  Two cases need to be differentiated:

        A.  For the authorization grant, the subject SHOULD identify an

            authorized accessor for whom the access token is being

            requested (typically the resource owner, or an authorized

            delegate).

        B.  For client authentication, the subject MUST be the

            "client_id" of the OAuth client.“

I’m not sure, if this makes sense, cause in an federation-scenario the
original jwt is issued in an other security-domain and the auth-server in
question does not necessarily know the users in thouse domain. Furthermore,
it is very likely that the auth-server is not interested in the subject
claim, but just in other incoming claims in view of mapping them to outgoing
ones. IMHO, all the auth-server can do with the subject-claim is to create a
protocol entry that says that some action was performed for this subject.

Do I see that right?

Wishes,

Manfred

[1] https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07

Von: OAuth [mailto:[email-masked]] Im Auftrag von Antonio Sanso
Gesendet: Dienstag, 11. März 2014 15:14
An: [email-masked]
Betreff: [OAUTH-WG] JSON Web Token (JWT) Profile

hi *,

Now IMHO there are cases where having the sub is either not needed or
redundant (since it might overlap with the issuer).\

As far as I can see “even Google” currently violates this spec [1] ( I know
that this doesn’t matter, just wanted to bring a real use case scenario).

regards

antonio

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 11 Mar 2014 15:36:34 +0100

Hi Manfred, Hi Antonio,

Note that there are two documents that talk about the JWT and you guys
might be looking at the wrong document.

The main JWT document (see
http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-18) defines
the subject claim as optional (see Section 4.1.2).

The JWT bearer assertion document (see
http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07) does indeed
define it as mandatory but that's intentional since the purpose of the
spec is to authenticate the client (or the resource owner for an
authorization grant).

The assertion documents are used for interworking with "legacy" identity
infrastructure (such as SAML federations).

So, are you sure you are indeed looking at the right document?

Ciao
Hannes

On 03/11/2014 03:13 PM, Antonio Sanso wrote:
> As far as I can see “even Google” currently violates this spec [1] ( I
> know that this doesn’t matter, just wanted to bring a real use case
> scenario).
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Antonio Sanso <[email-masked]>
Date: Tue, 11 Mar 2014 14:56:52 +0000

hi Hannes,

I am aware of the 2 documents,

I might be wrong but http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07 is also about Authorization Grant Processing (this is the part I do use in my implementation ) and not only Client Authentication Processing.

Just my 0.02 $ but this seems to be a place where different implementer have the same issue :)

regards

antonio

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 11 Mar 2014 15:53:02 +0100

Thanks for clarifying.

I took a quick look at the Google API and it seems that in their use
case the client creates the JWT and consequently the subject and the
issue would actually be the same. I suspect that this is the reason why
they omitted the subject.

Could you explain why you would like to omit the subject claim in the JWT?

Ciao
Hannes

PS: Your feedback on the  draft-ietf-oauth-jwt-bearer-07 spec is timely
since we are about to finish all three assertion specs.

---

From: Antonio Sanso <[email-masked]>
Date: Tue, 11 Mar 2014 15:08:36 +0000

> they omitted the subject.

agreed that is why in my mail I said the subject might overlap with the issuer.
The subject in the google case is still called with its obsolete name (prn) and it is actually listed as ‘additional claims’ hence not mandatory.

regards

antonio

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 11 Mar 2014 16:05:22 +0100

Maintaining both information in the JWT is IMHO valuable since it gives
you some information about the security properties. Needless to say that
there is a substantial difference between a self-created JWT and a JWT
from a third party the relying party has some confidence in.

Why Google has an old implementation and whether they are planning to
update their code remains to be seen.

More importantly, however, is why you argue that the subject claim has
to be optional.

Ciao
Hannes

Ps: I also noticed in the examples that all URIs have their URI scheme
missing. While that might be OK I am not entirely sure...

---

From: John Bradley <[email-masked]>
Date: Tue, 11 Mar 2014 12:25:05 -0300

The missing scheme especially on JWT issued by google is something I understand they are working on but need to be careful about breaking existing code, so will possibly need new endpoints that are spec compliant. 

While in this google case the subject and the issuer happen to be the same they may well not be even in the self signed case.   In WG discussions being consistent in providing the subject was considered to be better for interoperability than optimizing for the case where sub or issuer could be dropped.  

John B.

---

From: Antonio Sanso <[email-masked]>
Date: Tue, 11 Mar 2014 17:11:59 +0000

Ok this is my use case:

- I  am John Doe and going to AS to register my app named app1
- I then either upload my public key or download a private key
- at this point I am ready to build my assertion, the issuer claim is going to be app1 and should suffice.

is the subject really needed in this use case? 

regards

antonio

---

From: John Bradley <[email-masked]>
Date: Tue, 11 Mar 2014 16:12:42 -0300

The specification is intended to allow the interoperation of standard libraries.  

In some cases the subject and the iss may be the same, however the underlying OAuth library may be a general one and always require a subject for security processing.

It is possible that all libraries could have a special rule for when sub is not present and use the value of iss as sub.  This will save some bytes in the JWT but it is probably not worth creating an extra code path in libraries for the size optimization. 

I don't think your saying there is no subject just that it is redundant with iss in some cases.

John B.

---

From: "Manfred Steyer" <[email-masked]>
Date: Tue, 11 Mar 2014 20:28:03 +0100

Hi,

perhaps you can show that I'm wrong, but I still think, that there are
cases, where the subject is unknown cause it's not relevant. Let's consider
the following federation-scenario:

1. Bob has a Token T1 that says, that he works  for Company A on Project B.
The Subject of this token is "Bob".
2. Company X says, that everyone in Company A working for Project B gets
access to Accounting-Information.
3. Bob exchanges this Token T1 at Company X's AuthServer for another Token
T2. T2 contains a claim AccessLevel=Accouting. T2 could also get a copy of
the subj-claim, but Company X doesn't care about that, cause no one in
Company B knows Bob.

The only reason I can imagine, why the sub-claim should be copied into T2 is
because of tracing and finding out, that there is a correlation between T2
und T1. But this could be accomplished with other mechanisms too.

Did I oversee something? If there is another reason, why sub is mandatory, I
think, it would not hurt too much to copy the sub-claim from T1 to T2 (and
from T2 to T3 etc.)...

Wishes
Manfred

-----Ursprüngliche Nachricht-----
Von: OAuth [mailto:[email-masked]] Im Auftrag von Hannes Tschofenig
Gesendet: Dienstag, 11. März 2014 16:05
An: Antonio Sanso
Cc: [email-masked]
Betreff: Re: [OAUTH-WG] JSON Web Token (JWT) Profile

Maintaining both information in the JWT is IMHO valuable since it gives you
some information about the security properties. Needless to say that there
is a substantial difference between a self-created JWT and a JWT from a
third party the relying party has some confidence in.

Why Google has an old implementation and whether they are planning to update
their code remains to be seen.

More importantly, however, is why you argue that the subject claim has to be
optional.

Ciao
Hannes

On 03/11/2014 04:08 PM, Antonio Sanso wrote:
>> issue would actually be the same. I suspect that this is the reason 
>> why they omitted the subject.
> 
> The subject in the google case is still called with its obsolete name
(prn) and it is actually listed as ‘additional claims’ hence not mandatory.
>> PS: Your feedback on the  draft-ietf-oauth-jwt-bearer-07 spec is 
>> timely since we are about to finish all three assertion specs.
>>
>>
>>> I might be wrong but
http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07 is also about
Authorization Grant Processing (this is the part I do use in my
implementation ) and not only Client Authentication Processing.
>>>> Note that there are two documents that talk about the JWT and you 
>>>> guys might be looking at the wrong document.
>>>>
>>>> http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-18) 
>>>> defines the subject claim as optional (see Section 4.1.2).
>>>>
>>>> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07) does 
>>>> indeed define it as mandatory but that's intentional since the 
>>>> purpose of the spec is to authenticate the client (or the resource 
>>>> owner for an authorization grant).
>>>>
>>>> The assertion documents are used for interworking with "legacy" 
>>>> identity infrastructure (such as SAML federations).
>>>>
>>>>> Now IMHO there are cases where having the sub is either not needed 
>>>>> or redundant (since it might overlap with the issuer).\
>>>>>
>>>>> As far as I can see “even Google” currently violates this spec [1] 
>>>>> ( I know that this doesn’t matter, just wanted to bring a real use 
>>>>> case scenario).
>>>>>
>>>>> [0] 
>>>>> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07#section-
>>>>> 3 [1] 
>>>>> https://developers.google.com/accounts/docs/OAuth2ServiceAccount
>>>>>
>>>>>

---

From: John Bradley <[email-masked]>
Date: Tue, 11 Mar 2014 16:49:27 -0300

Company X will likely care about the subject being asserted by company A for auditing and possible revocation.

It may be that the extension claim accessLevel=Accounting is sufficient to grant the access token.  

By Policy A could make sub itself, or an identifier for the user of the client in it's namespace.  

Yes there are some cases where it may be redundant or not disclosed for a privacy reason, but the current decision is to keep the library consistent and push that decision to the application logic.

You can make the case the decision was wrong.  

The other reason for it is that the JWT and SAML assertions are parallel and in SAML subject is required.   That was the other consistency reason for making it mandatory.  

John B.

---

From: Antonio Sanso <[email-masked]>
Date: Tue, 11 Mar 2014 20:43:54 +0000

agree, but in some cases the subject is not only same as the issuer but simply it doesn’t matter.

In my example below all it matters is that the assertion signed by app1 is valid…. 

Continue in my probably not relevant “Google example” if I set the prn same as the issuer it would not work (keeping only the issuer without any subject gives me back a correct access token instead).

Again this is not relevant spec wise. AFIU there is consensus in the working group to keep the subject mandatory. Would it make sense at least to add a little not that in some situations the issuer and the subject are the same?
This might clarify at least something to people that do wonder...

regards

antonio

---

From: Phil Hunt <[email-masked]>
Date: Tue, 11 Mar 2014 15:04:15 -0700

I think that's the wrong perspective. If you intend the issuer to be the subject, you need to declare it.

I wouldn't worry that it duplicates issuer. The fields have different meaning.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 12 Mar 2014 07:44:32 +0900

+1. Saving a few bytes in exchange to interoperability and security
possible downgrade does not seem to be a good strategy for me.

Nat

2014-03-12 7:04 GMT+09:00 Phil Hunt <[email-masked]>:

> > agree, but in some cases the subject is not only same as the issuer but
> simply it doesn't matter.
> >
> > In my example below all it matters is that the assertion signed by app1
> is valid....
> >
> > Continue in my probably not relevant "Google example" if I set the prn
> same as the issuer it would not work (keeping only the issuer without any
> subject gives me back a correct access token instead).
> >
> > Again this is not relevant spec wise. AFIU there is consensus in the
> working group to keep the subject mandatory. Would it make sense at least
> to add a little not that in some situations the issuer and the subject are
> the same?
> >> In some cases the subject and the iss may be the same, however the
> underlying OAuth library may be a general one and always require a subject
> for security processing.
> >>
> >> It is possible that all libraries could have a special rule for when
> sub is not present and use the value of iss as sub.  This will save some
> bytes in the JWT but it is probably not worth creating an extra code path
> in libraries for the size optimization.
> >>
> >>>> The missing scheme especially on JWT issued by google is something I
> understand they are working on but need to be careful about breaking
> existing code, so will possibly need new endpoints that are spec compliant.
> >>>>
> >>>> While in this google case the subject and the issuer happen to be the
> same they may well not be even in the self signed case.   In WG discussions
> being consistent in providing the subject was considered to be better for
> interoperability than optimizing for the case where sub or issuer could be
> dropped.
> >>>>
> >>>> John B.
> >>>>
> >>>>>> The subject in the google case is still called with its obsolete
> name (prn) and it is actually listed as 'additional claims' hence not
> mandatory.
> >>>>>>
> >>>>>> regards
> >>>>>>
> >>>>>> antonio
> >>>>>>
> >>>>>>>
> timely
> defines
> indeed
> identity
> >>>>>>>>>> As far as I can see "even Google" currently violates this spec
> [1] ( I
> >>>>>>>>>> know that this doesn't matter, just wanted to bring a real use
> case
> >>>>>>>>>> scenario).
> >>>>>>>>>>
> >>>>>>>>>> WDYT might the "sub" be optional in some situation?
> >>>>>>>>>>
> >>>>>>>>>> regards
> >>>>>>>>>>
> >>>>>>>>>> antonio
> >>>>>>>>>>
> >>>>>>>>>> [0]
> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07#section-3
> >>>>>>>>>> [1]

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: "Manfred Steyer" <[email-masked]>
Date: Wed, 12 Mar 2014 08:08:59 +0100

Hi John,

thx for this explanation. It helps me to see, why this decision has been
made.

Wishes,
Manfred

-----Ursprüngliche Nachricht-----
Von: John Bradley [mailto:[email-masked]] 
Gesendet: Dienstag, 11. März 2014 20:49
An: Manfred Steyer
Cc: Hannes Tschofenig; Antonio Sanso; [email-masked]
Betreff: Re: [OAUTH-WG] JSON Web Token (JWT) Profile

Company X will likely care about the subject being asserted by company A for
auditing and possible revocation.

It may be that the extension claim accessLevel=Accounting is sufficient to
grant the access token.  

By Policy A could make sub itself, or an identifier for the user of the
client in it's namespace.  

Yes there are some cases where it may be redundant or not disclosed for a
privacy reason, but the current decision is to keep the library consistent
and push that decision to the application logic.

The other reason for it is that the JWT and SAML assertions are parallel and
in SAML subject is required.   That was the other consistency reason for
making it mandatory.  

John B.

> Maintaining both information in the JWT is IMHO valuable since it gives
you
> Why Google has an old implementation and whether they are planning to
update
>> On Mar 11, 2014, at 3:53 PM, Hannes Tschofenig
<[email-masked]>
> wrote:

---

From: Antonio Sanso <[email-masked]>
Date: Wed, 12 Mar 2014 09:44:29 +0000

+1

thanks

antonio

On Mar 12, 2014, at 8:08 AM, Manfred Steyer <[email-masked]> wrote:

>> (prn) and it is actually listed as 'additional claims' hence not
> mandatory.
>>> 
>>> regards
>>> 
>>> antonio
>>> 
>>>> 
>>>>>>> As far as I can see "even Google" currently violates this spec [1] 
>>>>>>> ( I know that this doesn't matter, just wanted to bring a real use 
>>>>>>> case scenario).
>>>>>>>