Subject: [OAUTH-WG] draft-ietf-oauth-jwt-bearer-08 & subject issue

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 23 Apr 2014 10:39:29 +0200

Hi all,

in preparing the shepherd write-up for draft-ietf-oauth-jwt-bearer-08 I
had to review our recent email conversations and the issue raised by
Antonio in
http://www.ietf.org/mail-archive/web/oauth/current/msg12520.html belong
to it.

The issue was that Section 3 of draft-ietf-oauth-jwt-bearer-08 says:
"
   2.   The JWT MUST contain a "sub" (subject) claim identifying the
        principal 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.
"

Antonio pointed to the current Google API to illustrate that the subject
is not always needed. Here is the Google API documentation:
https://developers.google.com/accounts/docs/OAuth2ServiceAccount

The Google API used the client authentication part (rather than the
authorization grant), in my understanding.

I still believe that the subject field has to be included for client
authentication but I am not so sure anymore about the authorization
grant since I could very well imagine cases where the subject is not
needed for authorization decisions but also for privacy reasons.

I would therefore suggest to change the text as follows:

"
   2.   The JWT contains a "sub" (subject) claim identifying the
        principal that is the subject of the JWT.  Two cases need to be
        differentiated:

        A.  For the authorization grant, the subject claim MAY
            be included. If it is included it MUST identify the
            authorized accessor for whom the access token is being
            requested (typically the resource owner, or an authorized
            delegate). Reasons for not including the subject claim
            in the JWT are identity hiding (i.e., privacy protection
            of the identifier of the subject) and cases where
            the identifier of the subject is irrelevant for making
            an authorization decision by the resource server.

        B.  For client authentication, the subject MUST be the
            included in the JWT and the value MUST be populated
            with the "client_id" of the OAuth client.
"

What do you guys think?

Ciao
Hannes

---

From: Brian Campbell <[email-masked]>
Date: Wed, 23 Apr 2014 16:37:29 -0600

That thread that Antonio started which you reference went on for some time (
http://www.ietf.org/mail-archive/web/oauth/current/threads.html#12520) and
seems to have reached consensus that the spec didn't need normative change
and that such privacy cases or other cases which didn't explicitly need a
subject identifier would be more appropriately dealt with in application
logic: http://www.ietf.org/mail-archive/web/oauth/current/msg12538.html

On Wed, Apr 23, 2014 at 2:39 AM, Hannes Tschofenig <
[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 24 Apr 2014 09:09:48 +0200

Hi Brian,

I read through the thread and the Google case is a bit different since
they are using the client authentication part of the JWT bearer spec.
There I don't see the privacy concerns either.

I am, however, focused on the authorization grant where the subject is
in most cases the resource owner.

It is possible to put garbage into the subject element when privacy
protection is needed for the resource owner case but that would need to
be described in the document; currently it is not there.

Ciao
Hannes

On 04/24/2014 12:37 AM, Brian Campbell wrote:
> That thread that Antonio started which you reference went on for some
> time
> (http://www.ietf.org/mail-archive/web/oauth/current/threads.html#12520)
> and seems to have reached consensus that the spec didn't need normative
> change and that such privacy cases or other cases which didn't
> explicitly need a subject identifier would be more appropriately dealt
> with in application logic:
> http://www.ietf.org/mail-archive/web/oauth/current/msg12538.html
> 
> 
> 
> 
> On Wed, Apr 23, 2014 at 2:39 AM, Hannes Tschofenig
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi all,
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 24 Apr 2014 06:30:49 -0600

There is some discussion of that case in the assertion framework document
at http://tools.ietf.org/html/draft-ietf-oauth-assertions-15#section-6.3.1

Do you feel that more is needed? If so, can you propose some text?

On Thu, Apr 24, 2014 at 1:09 AM, Hannes Tschofenig <
[email-masked]> wrote:

> >     http://www.ietf.org/mail-archive/web/oauth/current/msg12520.htmlbelong
> >     to it.
> >

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 24 Apr 2014 14:48:16 +0200

Hi Brian,

Thanks for pointing to the assertion framework document. Re-reading the
text it appears that we have listed the case that in Section 6.3.1 but
have forgotten to cover it elsewhere in the document.

In Section 6.3.1 we say:

"

6.3.1.  Client Acting on Behalf of an Anonymous User

   When a client is accessing resources on behalf of an anonymous user,
   the Subject indicates to the Authorization Server that the client is
   acting on-behalf of an anonymous user as defined by the Authorization
   Server.  It is implied that authorization is based upon additional
   criteria, such as additional attributes or claims provided in the
   assertion.  For example, a client may present an assertion from a
   trusted issuer asserting that the bearer is over 18 via an included
   claim.

*****
    In this case, no additional information about the user's
   identity is included, yet all the data needed to issue an access
   token is present.
*****
"
(I marked the relevant part with '***')

In Section 5.2, however, we say:

   o  The assertion MUST contain a Subject.  The Subject identifies an
      authorized accessor for which the access token is being requested
      (typically the resource owner, or an authorized delegate).  When
      the client is acting on behalf of itself, the Subject MUST be the
      value of the client's "client_id".

What we should have done in Section 5.2 is to expand the cases inline
with what we have written in Section 6.

Here is my proposed text:

"
o  The assertion MUST contain a Subject.  The Subject identifies an
authorized accessor for which the access token is being requested
(typically the resource owner, or an authorized delegate).

When the client is acting on behalf of itself, as described in Section
6.1 and Section 6.2, the Subject MUST be the value of the client's
"client_id".

When the client is acting on behalf of an user, as described in Section
6.3, the Subject element MUST be included in the assertion and
identifies an authorized accessor for which the access token is being
requested.

When the client is acting on behalf of an anonymous user, as described
in Section 6.3.1, the Subject element MUST NOT be included in the
assertion. Other elements within the assertion will, however, provide
enough information for the authorization server to make an authorization
decision.
"

Does this make sense to you?

Ciao
Hannes

On 04/24/2014 02:30 PM, Brian Campbell wrote:
> There is some discussion of that case in the assertion framework
> document at
> http://tools.ietf.org/html/draft-ietf-oauth-assertions-15#section-6.3.1
> 
> On Thu, Apr 24, 2014 at 1:09 AM, Hannes Tschofenig
>     > <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>     >
>     >     Hi all,
>     >
>     >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 25 Apr 2014 11:17:01 -0600

I believe, from the thread referenced earlier and prior discussion and
draft text, that the WG has reached (rough) consensus to require the
subject claim. So text that says "Subject element MUST NOT be included"
isn't workable.

It seems what's needed here is some better explanation of how, in cases
that need it, the value of the subject can be populated without using a PII
type value. A simple static value like "ANONYMOUS-SUBJECT" could be used.
Or, more likely, some kind of pairwise persistent pseudonymous identifier
would be utilized, which would not directly identify the subject but would
allow the relying party to recognize the same subject on subsequent
transactions. A transient pseudonym might also be appropriate in some
cases. And any of those approaches could be used with or without additional
claims (like age > 18 or membership in some group) that get used to make an
authorization decision.

I wasn't sure exactly how to articulate all that in text for the draft(s)
but that's more of what I was asking for when I asked if you could propose
some text.

On Thu, Apr 24, 2014 at 6:48 AM, Hannes Tschofenig <
[email-masked]> wrote:

> >     (
> http://www.ietf.org/mail-archive/web/oauth/current/threads.html#12520)

---

From: Mike Jones <[email-masked]>
Date: Fri, 25 Apr 2014 18:07:27 +0000

I agree.  We’d already discussed this pretty extensively and reached the conclusion that always requiring both an issuer and a subject both kept the specs simpler and was likely to improve interoperability.

It’s entirely up to the application profile what the contents of the issuer and the subject fields are and so I don’t think we need to further specify their contents beyond what’s already in the specs.

                                                            -- Mike

From: OAuth [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Friday, April 25, 2014 10:17 AM
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer-08 & subject issue

I believe, from the thread referenced earlier and prior discussion and draft text, that the WG has reached (rough) consensus to require the subject claim. So text that says "Subject element MUST NOT be included" isn't workable.
It seems what's needed here is some better explanation of how, in cases that need it, the value of the subject can be populated without using a PII type value. A simple static value like "ANONYMOUS-SUBJECT" could be used. Or, more likely, some kind of pairwise persistent pseudonymous identifier would be utilized, which would not directly identify the subject but would allow the relying party to recognize the same subject on subsequent transactions. A transient pseudonym might also be appropriate in some cases. And any of those approaches could be used with or without additional claims (like age > 18 or membership in some group) that get used to make an authorization decision.
I wasn't sure exactly how to articulate all that in text for the draft(s) but that's more of what I was asking for when I asked if you could propose some text.

On Thu, Apr 24, 2014 at 6:48 AM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi Brian,

In Section 6.3.1 we say:

"

*****

"

Ciao
Hannes

On 04/24/2014 02:30 PM, Brian Campbell wrote:
> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>     Hi Brian,
>
>     > <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>> wrote:
>     >
>     >     Hi all,
>     >
>     >     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>

---

From: John Bradley <[email-masked]>
Date: Fri, 25 Apr 2014 16:08:21 -0300

Agreed.

On Apr 25, 2014, at 3:07 PM, Mike Jones <[email-masked]> wrote:

> On Thu, Apr 24, 2014 at 6:48 AM, Hannes Tschofenig <[email-masked]> wrote:
> Hi Brian,
>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 25 Apr 2014 13:57:43 -0600

I absolutely agree with always requiring both issuer and subject and that
doing so keeps the specs simpler and is likely to improve interoperability.

However, without changing that, perhaps some of the text in the document(s)
could be improved a bit. Here's a rough proposal:

Change the text of the second bullet in
http://tools.ietf.org/html/draft-ietf-oauth-assertions-15#section-5.2 to

"The assertion MUST contain a Subject. The Subject typically identifies an
authorized accessor for which the access token is being requested (i.e. the
resource owner, or an authorized delegate) but, in some cases, may be a
pseudonym or other value denoting an anonymous user. When the client is
acting on behalf of itself, the Subject MUST be the value of the client's
client_id."

And also change
http://tools.ietf.org/html/draft-ietf-oauth-assertions-15#section-6.3.1 to

"When a client is accessing resources on behalf of an anonymous user, a
mutually agreed upon Subject identifier indicating anonymity is used. The
Subject value might be an agreed upon static value indicating an anonymous
user or an opaque persistent or transient pseudonym for the user may also
be utilized. The authorization may be based upon additional criteria, such
as additional attributes or claims provided in the assertion. For example,
a client may present an assertion from a trusted issuer asserting that the
bearer is over 18 via an included claim. In this case, no additional
information about the user's identity is included, yet all the data needed
to issue an access token is present."

And maybe also change the subject text in SAML and JWT (item #2 in
http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-08#section-3 and
http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-19#section-3) to
read a little more like the new proposed text above for section 5.2 of the
Assertion Framework draft.

Would that sit any better with you, Hannes? Thoughts from others in the WG?

On Fri, Apr 25, 2014 at 1:08 PM, John Bradley <[email-masked]> wrote:

> I agree.  We’d already discussed this pretty extensively and reached the
> conclusion that always requiring both an issuer and a subject both kept the
> specs simpler and was likely to improve interoperability.
>
> It’s entirely up to the application profile what the contents of the
> issuer and the subject fields are and so I don’t think we need to further
> specify their contents beyond what’s already in the specs.
>
>                                                             -- Mike
>
> *From:* OAuth [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Brian Campbell
> *Sent:* Friday, April 25, 2014 10:17 AM
> *To:* Hannes Tschofenig
> *Cc:* [email-masked]
> *Subject:* Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer-08 & subject issue
>
>

---

From: John Bradley <[email-masked]>
Date: Fri, 25 Apr 2014 17:11:26 -0300

I am OK with that.

On Apr 25, 2014, at 4:57 PM, Brian Campbell <[email-masked]> wrote:

> I absolutely agree with always requiring both issuer and subject and that doing so keeps the specs simpler and is likely to improve interoperability.
> 
> However, without changing that, perhaps some of the text in the document(s) could be improved a bit. Here's a rough proposal:
> 
> Change the text of the second bullet in http://tools.ietf.org/html/draft-ietf-oauth-assertions-15#section-5.2 to 
> 
> "The assertion MUST contain a Subject. The Subject typically identifies an authorized accessor for which the access token is being requested (i.e. the resource owner, or an authorized delegate) but, in some cases, may be a pseudonym or other value denoting an anonymous user. When the client is acting on behalf of itself, the Subject MUST be the value of the client's client_id."
> 
> And also change http://tools.ietf.org/html/draft-ietf-oauth-assertions-15#section-6.3.1 to 
> 
> "When a client is accessing resources on behalf of an anonymous user, a mutually agreed upon Subject identifier indicating anonymity is used. The Subject value might be an agreed upon static value indicating an anonymous user or an opaque persistent or transient pseudonym for the user may also be utilized. The authorization may be based upon additional criteria, such as additional attributes or claims provided in the assertion. For example, a client may present an assertion from a trusted issuer asserting that the bearer is over 18 via an included claim. In this case, no additional information about the user's identity is included, yet all the data needed to issue an access token is present."
> 
> And maybe also change the subject text in SAML and JWT (item #2 in http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-08#section-3 and http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-19#section-3) to read a little more like the new proposed text above for section 5.2 of the Assertion Framework draft.
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 27 Apr 2014 11:55:49 +0200

+1

(we actually use a sub value of "anonymous" in our id tokens in case age 
verification, if we do not want to disclose the user's identity to the RP)

Am 25.04.2014 22:11, schrieb John Bradley:
> I am OK with that.
>
> On Apr 25, 2014, at 4:57 PM, Brian Campbell 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>> I absolutely agree with always requiring both issuer and subject and 
>> that doing so keeps the specs simpler and is likely to improve 
>> interoperability.
>>
>> However, without changing that, perhaps some of the text in the 
>> document(s) could be improved a bit. Here's a rough proposal:
>>
>> "The assertion MUST contain a Subject. The Subject typically 
>> requested (i.e. the resource owner, or an authorized delegate) but, 
>> in some cases, may be a pseudonym or other value denoting an 
>> anonymous user. When the client is acting on behalf of itself, the 
>> Subject MUST be the value of the client's client_id."
>>
>> And also change 
>> to
>> "When a client is accessing resources on behalf of an anonymous user, 
>> a mutually agreed upon Subject identifier indicating anonymity is 
>> used. The Subject value might be an agreed upon static value 
>> indicating an anonymous user or an opaque persistent or transient 
>> pseudonym for the user may also be utilized. The authorization may be 
>> based upon additional criteria, such as additional attributes or 
>> claims provided in the assertion. For example, a client may present 
>> an assertion from a trusted issuer asserting that the bearer is over 
>> 18 via an included claim. In this case, no additional information 
>> about the user's identity is included, yet all the data needed to 
>> issue an access token is present."
>>
>> read a little more like the new proposed text above for section 5.2 
>> of the Assertion Framework draft.
>>
>> On Fri, Apr 25, 2014 at 1:08 PM, John Bradley <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>     Agreed.
>>
>>     On Apr 25, 2014, at 3:07 PM, Mike Jones
>>     <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>>     I agree.  We'd already discussed this pretty extensively and
>>>     reached the conclusion that always requiring both an issuer and
>>>     a subject both kept the specs simpler and was likely to improve
>>>     interoperability.
>>>     It's entirely up to the application profile what the contents of
>>>     the issuer and the subject fields are and so I don't think we
>>>     need to further specify their contents beyond what's already in
>>>     the specs.
>>>     -- Mike
>>>     *From:*OAuth [mailto:[email-masked]]*On Behalf Of*Brian
>>>     Campbell
>>>     *Sent:*Friday, April 25, 2014 10:17 AM
>>>     *To:*Hannes Tschofenig
>>>     *Cc:[email-masked] <mailto:[email-masked]>
>>>     *Subject:*Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer-08 &
>>>     subject issue
>>>
>>>     I believe, from the thread referenced earlier and prior
>>>     discussion and draft text, that the WG has reached (rough)
>>>     consensus to require the subject claim. So text that says
>>>     "Subject element MUST NOT be included" isn't workable.
>>>
>>>     It seems what's needed here is some better explanation of how,
>>>     in cases that need it, the value of the subject can be populated
>>>     without using a PII type value. A simple static value like
>>>     "ANONYMOUS-SUBJECT" could be used. Or, more likely, some kind of
>>>     pairwise persistent pseudonymous identifier would be utilized,
>>>     which would not directly identify the subject but would allow
>>>     the relying party to recognize the same subject on subsequent
>>>     transactions. A transient pseudonym might also be appropriate in
>>>     some cases. And any of those approaches could be used with or
>>>     without additional claims (like age > 18 or membership in some
>>>     group) that get used to make an authorization decision.
>>>
>>>     I wasn't sure exactly how to articulate all that in text for the
>>>     draft(s) but that's more of what I was asking for when I asked
>>>     if you could propose some text.
>>>
>>>
>>>
>>>
>>>     On Thu, Apr 24, 2014 at 6:48 AM, Hannes Tschofenig
>>>      When
>>>     > <[email-masked]
>>>     <mailto:[email-masked]><mailto:[email-masked]
>>>     >     > and seems to have reached consensus that the spec didn't
>>>     need
>>>     >     normative
>>>     >     > <[email-masked]
>>>     <mailto:[email-masked]><mailto:[email-masked]
>>>     <mailto:[email-masked]>>
>>>     <mailto:[email-masked]>
>>>     <mailto:[email-masked]>>>> wrote:
>>>     >     >
>>>     >     >     Hi all,
>>>     >     >
>>>     >     >     had to review our recent email conversations and the
>>>     issue
>>>     >     raised by
>>>     >     >     Antonio in
>>>     >     >
>>>     >
>>>     >     >     The issue was that Section 3 of
>>>     draft-ietf-oauth-jwt-bearer-08
>>>     >     says:
>>>     >     >     "
>>>     >     >             A.  For the authorization grant, the subject
>>>     SHOULD
>>>     >     identify an
>>>     >     >     Antonio pointed to the current Google API to
>>>     illustrate that
>>>     >     the subject
>>>     >     >     The Google API used the client authentication part
>>>     (rather
>>>     >     than the
>>>     >     >     I still believe that the subject field has to be
>>>     included for
>>>     >     client
>>>     >     >     grant since I could very well imagine cases where
>>>     the subject
>>>     >     is not
>>>     <mailto:[email-masked]><mailto:[email-masked]
>>>     <mailto:[email-masked]>> <mailto:[email-masked]
>>>     <mailto:[email-masked]>
>>>     >     <mailto:[email-masked] <mailto:[email-masked]>>>

---

From: "Manger, James" <[email-masked]>
Date: Mon, 28 Apr 2014 10:34:40 +1000

Saying “sub” MUST be present might simplify a spec, but only at the cost of compromising the meaning of messages.

“sub” sometimes holds an identifier for a subject that is unambiguous in the context of the issuer. That is, an account needs to be identified by the tuple {iss, sub}.

“sub” sometimes holds an identifier for a subject that is globally unambiguous. That is, “sub” alone is sufficient to identify an account. An unstated assumption is that all “sub” values that might be compared need to come from the same (unidentified) namespace.

“sub” sometimes holds an ephemeral pseudonym (eg random garbage).

“sub” sometimes holds a fixed string such as “anonymous” (with different issuers choosing different strings). Assuming the tuple {iss, sub} identifies an account would be positively dangerous in this case.

“sub” sometimes holds a fingerprint of a public key. “sub” is then redundant as it can be recalculated from the key. That introduces the chance that some component uses “sub” without confirming it matches the key that is likely to introduce security vulnerabilities.

A “sub” value is sometimes “unique” in its context [draft-ietf-oauth-json-web-token-19#section-4.1.2 ], which I interpret as meaning it is the subject’s one and only identifier. I suspect in practice “sub” will often be “unambiguous”, but not necessarily “unique”. That is, an account might have multiple “sub” values associated with it (due to account merges, key changes, system redesigns, aliases…).

Making “sub” mandatory seems to make this mess worse.
We would be better with distinct "isub", "gsub", "psub", "asub":null, "ksub", and "unique":true elements so the semantics are clear.

--
James Manger

From: OAuth [mailto:[email-masked]] On Behalf Of Torsten Lodderstedt
Sent: Sunday, 27 April 2014 7:56 PM
To: John Bradley; Brian Campbell
Cc: [email-masked]
Subject: Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer-08 & subject issue

+1

(we actually use a sub value of "anonymous" in our id tokens in case age verification, if we do not want to disclose the user's identity to the RP)
Am 25.04.2014 22:11, schrieb John Bradley:
I am OK with that.

On Apr 25, 2014, at 4:57 PM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, Apr 25, 2014 at 1:08 PM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
Agreed.

On Apr 25, 2014, at 3:07 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

                                                            -- Mike

From: OAuth [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Friday, April 25, 2014 10:17 AM
To: Hannes Tschofenig
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer-08 & subject issue

In Section 6.3.1 we say:

"

*****

"

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 28 Apr 2014 10:49:18 +0200

Hi all,

your text proposal sounds reasonable and it might, as suggested,
indicate what value to put in there for the anonymous user (such as
'anonymous'). Saying explicitly what implementers should be doing helps
interoperability.

Mentioning the pseudonym is also a good idea since in some cases
anonymity can be too strong and pseudonymity is what is desired. For the
terminology you could reference RFC 6973.

Ciao
Hannes

PS: A note to various folks in this email thread: We have not discussed
this issue before. As I mentioned in my original email we had only
discussed a related issue regarding client authentication. Antonio's
email lead me to think about the authorization grant, which is obviously
a different story (which only happens to be in the same document because
of the document structure we came up with).

On 04/25/2014 09:57 PM, Brian Campbell wrote:
> "The assertion MUST contain a Subject. The Subject typically identifies
> an authorized accessor for which the access token is being requested
> (i.e. the resource owner, or an authorized delegate) but, in some cases,
> may be a pseudonym or other value denoting an anonymous user. When the
> client is acting on behalf of itself, the Subject MUST be the value of
> the client's client_id."
> 
> And also change
> mutually agreed upon Subject identifier indicating anonymity is used.
> The Subject value might be an agreed upon static value indicating an
> anonymous user or an opaque persistent or transient pseudonym for the
> user may also be utilized. The authorization may be based upon
> additional criteria, such as additional attributes or claims provided in
> the assertion. For example, a client may present an assertion from a
> claim. In this case, no additional information about the user's identity
> is included, yet all the data needed to issue an access token is present."
> 
> http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-19#section-3)
> to read a little more like the new proposed text above for section 5.2
>     On Apr 25, 2014, at 3:07 PM, Mike Jones <[email-masked]
>>     I agree.  We’d already discussed this pretty extensively and
>>     reached the conclusion that always requiring both an issuer and a
>>     subject both kept the specs simpler and was likely to improve
>>     interoperability.____
>>      
>>     It’s entirely up to the application profile what the contents of
>>     the issuer and the subject fields are and so I don’t think we need
>>     to further specify their contents beyond what’s already in the
>>     specs.____
>>      
>>                                                                 --
>>     Mike____
>>      
>>     *From:* OAuth [mailto:[email-masked]] *On Behalf Of *Brian
>>     Campbell
>>     *Cc:* [email-masked] <mailto:[email-masked]>
>>     *Subject:* Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer-08 & subject
>>     issue____
>>     __ __
>>
>>     I believe, from the thread referenced earlier and prior discussion
>>     and draft text, that the WG has reached (rough) consensus to
>>     require the subject claim. So text that says "Subject element MUST
>>     NOT be included" isn't workable.____
>>
>>     It seems what's needed here is some better explanation of how, in
>>     cases that need it, the value of the subject can be populated
>>     which would not directly identify the subject but would allow the
>>     relying party to recognize the same subject on subsequent
>>     group) that get used to make an authorization decision. ____
>>
>>     draft(s) but that's more of what I was asking for when I asked if
>>     you could propose some text.____
>>
>>
>>
>>
>>     ____
>>
>>     __ __
>>
>>     <[email-masked] <mailto:[email-masked]>>
>>     wrote:____
>>     Hi Brian,
>>
>>     authorized accessor for which the access token is being requested____
>>
>>     ____
>>     Hannes____
>>     > On Thu, Apr 24, 2014 at 1:09 AM, Hannes Tschofenig____
>>     <mailto:[email-masked]> <mailto:[email-masked]
>>     <mailto:[email-masked]> <mailto:[email-masked]
>>     <mailto:[email-masked]>>____
>>     <mailto:[email-masked]>____
>>     >     >             principal that is the subject of the JWT.  Two
>>     cases
>>     >     need to be
>>     >     >             differentiated:
>>     >     >
>>     >     >     grant since I could very well imagine cases where the
>>     subject
>>     >     is not
>>     >     >             principal that is the subject of the JWT.  Two
>>     cases
>>     >     need to be
>>     >     >             differentiated:
>>     >     >
>>     claim MAY
>>     >     >     OAuth mailing list____
>>     <mailto:[email-masked]> <mailto:[email-masked]
>>     >____
>>     __ __

---

From: Brian Campbell <[email-masked]>
Date: Mon, 28 Apr 2014 12:41:07 -0600

Thanks Hannes,

I'll update that text to reference RFC 6973 and also to indicate a specific
value which could be used for the anonymous user. And I'll publish new
drafts here soon(ish).

On Mon, Apr 28, 2014 at 2:49 AM, Hannes Tschofenig <
[email-masked]> wrote:

> > http://tools.ietf.org/html/draft-ietf-oauth-assertions-15#section-6.3.1to
> >
> >>     >     >                 requested (typically the resource owner, or
> an
> >>     >     authorized
> >>     >     >                 delegate).
> >>     >     >
> >>     >     >                 requested (typically the resource owner, or
> an
> >>     >     authorized
> >>     >     >                 in the JWT are identity hiding (i.e.,
> privacy
> >>     >     protection

---

From: Brian Campbell <[email-masked]>
Date: Mon, 28 Apr 2014 16:01:52 -0600

And those new drafts have now been published:

http://tools.ietf.org/html/draft-ietf-oauth-assertions-16
http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-09
http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-20

On Mon, Apr 28, 2014 at 12:41 PM, Brian Campbell <[email-masked]
> wrote:

> Thanks Hannes,
>
> I'll update that text to reference RFC 6973 and also to indicate a
> specific value which could be used for the anonymous user. And I'll publish
> new drafts here soon(ish).
>
>
>
>
>
>
>> > http://tools.ietf.org/html/draft-ietf-oauth-assertions-15#section-5.2to
>> >
>> >>     >     >                 requested (typically the resource owner,
>> or an
>> >>     >     authorized
>> >>     >     >                 delegate).
>> >>     >     >
>> >>     >     >                 requested (typically the resource owner,
>> or an
>> >>     >     authorized