I am OK with that. On Apr 25, 2014, at 4:57 PM, Brian Campbell <bcampb...@pingidentity.com> 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 <ve7...@ve7jtb.com> wrote: > Agreed. > > On Apr 25, 2014, at 3:07 PM, Mike Jones <michael.jo...@microsoft.com> 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:oauth-boun...@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.tschofe...@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-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 >> > <hannes.tschofe...@gmx.net <mailto:hannes.tschofe...@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/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 >> > > <hannes.tschofe...@gmx.net <mailto:hannes.tschofe...@gmx.net> >> > <mailto:hannes.tschofe...@gmx.net >> > <mailto:hannes.tschofe...@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/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 >> > > >> > > >> > > _______________________________________________ >> > > 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 > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
