Hi Mike, I am sure the rest of the working group is interested to see how difficult it is to arrange a conference call when one person is in Espoo/Finland and the other person in the West Coast. In any case, I am online and ready to chat.
In any case I will let the group know what conclusions we reached. Ciao Hannes PS: For some reason your SMS arrived one day later... On Jan 15, 2013, at 7:20 PM, Mike Jones wrote: > Hi Hannes, > > Can you please either give me a call for us to talk about the changes you > have in mind or write down the specific changes you want? I'd like us to > reach a mutual understanding of what you're trying to achieve in time for > Stephen to proceed with the telechat on schedule. > > Thank you, > -- Mike > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Mike Jones > Sent: Sunday, January 13, 2013 11:03 PM > To: Hannes Tschofenig > Cc: [email protected] WG > Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 > > I'm thinking it would be useful for us to talk on the phone or Skype > tomorrow, Hannes, because I'm pretty sure I don't know what specific changes > you're asking for in which specs. Are you, for instance, asking for language > saying that audience values are to be compared for equality as case-sensitive > strings in the SAML bearer and JWT bearer specs? (They're not just URIs, as > they can be OAuth Client IDs.) Or maybe you can propose specific language > changes, so it's clear what you're asking for. > > Thanks, > -- Mike > > -----Original Message----- > From: Hannes Tschofenig [mailto:[email protected]] > Sent: Sunday, January 13, 2013 2:49 AM > To: Mike Jones > Cc: Hannes Tschofenig; Brian Campbell; Stephen Farrell; [email protected] WG > Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 > > Hi Mike, > > it is fine to support different identifiers and to even allow the set of > supported identifiers to get extended over time. > > Just omitting a description is, however, not an option. We are in the lucky > position where others have done the work for us already (as mentioned in the > two cited references). For the IAB document there is even the chance to > provide feedback (see > https://www.iab.org/2013/01/09/call-for-comment-issues-in-identifier-comparison-for-security-purposes/) > in case you believe the author is misguided. We just need to make use of > them. > > Ciao > Hannes > > On Jan 13, 2013, at 12:09 PM, Mike Jones wrote: > >> We already know of use cases where the audience is an abstract identifier >> and use cases where the audience is the URL of the token endpoint. Both are >> legitimate. We should foreclose neither. >> >> Like many things OAuth, interoperability can be achieved, but it may require >> a profile further specifying the behaviors appropriate to that use case. >> This is not a bug - it is a feature, as it increases the applicability of >> the OAuth specifications. >> >> The Assertion, JWT Profile, and SAML Profile are striking an appropriate >> balance by providing guidance on likely audience values for many use cases, >> but not precluding other values where necessary for those use cases. >> >> Best wishes, >> -- Mike >> >> -----Original Message----- >> From: Hannes Tschofenig [mailto:[email protected]] >> Sent: Sunday, January 13, 2013 1:56 AM >> To: Mike Jones >> Cc: Hannes Tschofenig; Brian Campbell; Stephen Farrell; [email protected] >> WG >> Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 >> >> Hi Mike, >> >> I understand your reasoning: you want to keep all options open in the >> framework specification and you want to be more specific in >> draft-ietf-oauth-jwt-bearer and in draft-ietf-oauth-saml2-bearer. >> >> The RFC 2119 language does not add anything but it does not hurt either. It >> just says that there could essentially be anything in there, including the >> URL of the Token Endpoint. >> >> You can of course post-pone dealing with the issue to the more specific >> documents. For example, draft-ietf-oauth-jwt-bearer at the moment does not >> allow an interoperable deployment since it just repeats the abstract >> framework text by saying "The token endpoint URL of the authorization server >> MAY be used as an acceptable value for an "aud" element." >> >> Ciao >> Hannes >> >> On Jan 12, 2013, at 10:42 PM, Mike Jones wrote: >> >>> Hi Hannes, >>> >>> For the reasons that Justin and Brian state, I believe that the MAY is >>> appropriate. In some use cases, a good representation of an appropriate >>> audience value is URL of the Token Endpoint. That's there in the >>> Assertions specification as guidance to writers token-type specific specs >>> using the Assertions spec, as I believe it should be. That being the case, >>> as Brian describes, sometimes audience values are more abstract identifiers >>> or identifiers for groups of services, and we don't want to inadvertently >>> preclude those actual use cases. >>> >>> Thus, I believe that the language is appropriate as-is. Thus, I believe >>> that we should proceed with the currently scheduled telechat discussion of >>> the spec. >>> >>> Thanks all, >>> -- Mike >>> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On >>> Behalf Of Hannes Tschofenig >>> Sent: Saturday, January 12, 2013 11:50 AM >>> To: Brian Campbell >>> Cc: [email protected] WG >>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 >>> >>> Hi Brian, >>> >>> I understand that this is challenging. >>> >>> Nevertheless it would make sense to describe the desired behavior in >>> draft-ietf-oauth-jwt-bearer and in draft-ietf-oauth-saml2-bearer in such a >>> way that two versions developed by different groups would interoperate >>> without causing security problems or failures. >>> >>> To move forward with draft-ietf-oauth-assertions I suggest to follow the >>> recommendation in >>> http://www.ietf.org/mail-archive/web/oauth/current/msg10507.html and to >>> address the details in draft-ietf-oauth-jwt-bearer and in >>> draft-ietf-oauth-saml2-bearer as soon as possible to get these documents >>> moving forward and completed soon. >>> >>> Ciao >>> Hannes >>> >>> On Jan 11, 2013, at 7:51 PM, Brian Campbell wrote: >>> >>>> That text around audience in the framework spec changed from a SHOULD to a >>>> MAY in -09 so that it would be more consistent with the the SAML and JWT >>>> versions, which were already using a MAY in that context. >>>> >>>> Your concern is valid Hannes and your point is taken. But reality is >>>> rather messy and I don't believe it can addressed as easily as you >>>> suggest. >>>> >>>> In SAML, for example, an entity identifier is often used as a value for >>>> the audience (per spec and in practice). But an AS may not necessarily >>>> identify itself with a full blown SAML entity, in which case the token >>>> endpoint URI is more appropriate. The whole issue is also somewhat >>>> complicated in SAML too by it having both audience and recipient that are >>>> similar but not the same. I've tried to account for all of this in the >>>> SAML doc but it's admittedly somewhat awkward and complex and not as >>>> simple as saying the value has to be X and must be validated in exactly >>>> such a way. >>>> >>>> JWT doesn't have the same history and baggage of SAML but is subject to >>>> many of the same real world deployment variations. >>>> >>>> I'm definitely open to improvements with respect to the handling of >>>> audience values but I believe anything that is done needs to reflect >>>> the realities of current implementations and deployments as well as >>>> related specifications., >>>> >>>> >>>> >>>> On Fri, Jan 11, 2013 at 8:55 AM, John Bradley <[email protected]> wrote: >>>> Yes in assertions it needs to be general. It is the JWT and SAML profiles >>>> that need to nail down what the format of the audience is. They should >>>> probably both be the URI of the token endpoint. In both SAML and JWT >>>> there can be multiple audiences for the token. >>>> >>>> John >>>> On 2013-01-11, at 11:37 AM, "Richer, Justin P." <[email protected]> wrote: >>>> >>>>> It's my understanding that the general assertions claim is more of a >>>>> conceptual mapping than it is a concrete encoding, so anything more >>>>> specific here would be out of place. I would like the authors to either >>>>> confirm or correct my assumptions, though. >> >>> >>>>> >>>>> -- Justin >>>>> >>>>> >>>>> On Jan 11, 2013, at 6:30 AM, Stephen Farrell >>>>> <[email protected]> >>>>> wrote: >>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> Since we thought we were done with it, I put this document on the >>>>>> IESG telechat agenda for Jan 24. Hannes' question however looks >>>>>> like its a real one that needs an answer. >>>>>> >>>>>> I'd appreciate it if the WG could figure out if there's any change >>>>>> needed and either make that change in the next week, or else tell >>>>>> me to take the draft off the telechat agenda for now. >>>>>> >>>>>> If discussion doesn't happen, or happens but doesn't reach a >>>>>> conclusion, then I'll take the draft off the agenda in a week's >>>>>> time and we can sort out if any changes are needed later. >>>>>> >>>>>> The reason why now+1-week matters, is that that's when IESG >>>>>> members tend to do their reviews and having 'em all review a >>>>>> moving target isn't a good plan. >>>>>> >>>>>> Thanks, >>>>>> S. >>>>>> >>>>>> On 01/11/2013 08:18 AM, Hannes Tschofenig wrote: >>>>>>> Hi guys, >>>>>>> >>>>>>> Thanks for updating the assertion document and for incorporating the >>>>>>> comments received on the mailing list. >>>>>>> >>>>>>> There is only one issue that caught my attention. You changed the >>>>>>> description of the audience element to the following text (in version >>>>>>> -09 of http://tools.ietf.org/html/draft-ietf-oauth-assertions-09): >>>>>>> " >>>>>>> Audience A value that identifies the parties intended to process the >>>>>>> assertion. An audience value MAY be the URL of the Token Endpoint >>>>>>> as defined in Section 3.2 of OAuth 2.0 [RFC6749]. >>>>>>> " >>>>>>> >>>>>>> Since the value in the audience field is used to by the authorization >>>>>>> server in a comparison operation (see Section 5.2) I believe the >>>>>>> current text will lead to interoperability problems. Not only is the >>>>>>> comparision operation unspecified but even the value that is contained >>>>>>> in the field is left open. The RFC 2119 MAY does not really give a lot >>>>>>> of hints of what should be put in there. >>>>>>> >>>>>>> Without having a clear description of what identifier is contained in >>>>>>> this field and how the comparison works it is either possible that a >>>>>>> legitimate client is rejected by the authorization server (which is >>>>>>> annoying) or an assertion with an incorrect assertion is accepted >>>>>>> (which is a security problem). >>>>>>> >>>>>>> Btw, the same issue can also be seen in >>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04, >>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-15 and in a >>>>>>> more generic form also in the JWT (Section 4.1.3 of >>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06; "aud" >>>>>>> claim). From the description in the JWT document I was not quite sure >>>>>>> whether the ability to carry an array of case sensitive strings for >>>>>>> that field is also allowed in any of the assertion documents. >>>>>>> >>>>>>> Note that there are two documents that provide input to this problem >>>>>>> space, namely: >>>>>>> http://tools.ietf.org/html/rfc6125 >>>>>>> http://tools.ietf.org/html/draft-iab-identifier-comparison-07 >>>>>>> >>>>>>> So, I would suggest to decide what type of identifier goes into this >>>>>>> field and then to point to a document that illustrates how the >>>>>>> comparison operation would look like. Possible identifiers are domain >>>>>>> names, IP addresses, URIs, etc. Just as an example from RFC 6125 would >>>>>>> you allow a wildcard match (like "*.example.com") or only an equality >>>>>>> match? Would "www.example.com" be the same as "example.com" if they >>>>>>> resolve to the same IP address(es)? >>>>>>> >>>>>>> Ciao >>>>>>> Hannes >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> [email protected] >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
