On Apr 25, 2014, at 4:57 PM, = Brian Campbell <bcampbell@pingidentity.com&= gt; 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.

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 = <ve7jtb@ve7jtb.com> wrote:

Agreed.

On Apr 25, 2014, at 3:07 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I agree. We=92d 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=92s entirely up to the application profile what the contents of = the issuer and the subject fields are and so I don=92t think we need to = further specify their contents beyond what=92s already in the = specs.

            = ;            &= nbsp;           &nb= sp;            = ;           -- = Mike

From: = OAuth [mailto:oauth-bounces@ietf.org] = On Behalf Of Brian Campbell
Sent: Friday, April 25, 2014 10:17 = AM
To: Hannes = Tschofenig
Cc: oauth@ietf.org
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 <hannes.tschofenig@gmx.net> = wrote:

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-1= 5#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
> <hannes.tschofenig@gmx.net <mail= to:hannes.tschofenig@gmx.net>> wrote:
>
> 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/threa= ds.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/msg12= 538.html
> >
> >
> = >
> >
> > On Wed, Apr = 23, 2014 at 2:39 AM, Hannes Tschofenig
> > <hannes.tschofenig@gmx.net <mail= to:hannes.tschofenig@gmx.net>

> = <mailto:hannes.tschofenig@gmx.net

> = <mailto:hannes.tschofenig@gmx.net>>> wrote:
> >
> > 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/msg12= 520.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/OAuth2Servic= eAccount
> >
> > 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
> = >
> >
> > = _______________________________________________
> > OAuth mailing = list
> = >   OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org
> <mailto:OAuth@ietf.org>>
> > =   https://www.ietf.org/mailman/listinfo/oauth
> >
> = >
>
>

______________________= _________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth