+1. This makes good sense. Phil
Sent from my phone. On 2013-01-15, at 18:26, Mike Jones <[email protected]> wrote: > Hannes and I spoke and went through the issues. He was trying to maximize > interoperability of implementations which is obviously a good goal. However, > after discussing the particulars, we also agreed that, for some features and > use cases, specific profiles of the assertions will be needed to achieve > complete interoperability (just like profiles of OAuth are required to > achieve interoperability). > > Therefore, we propose to add an explanatory paragraph to the assertions > document explaining that profiling will be required to achieve > interoperability in some cases. This would be in exactly the same spirit as > http://tools.ietf.org/html/rfc6749#section-1.8, which supplies the same kinds > of caveats to implementer's of OAuth Core. > > I'll work on proposed specific wording shortly. I'll note that adding this > text will not change the meaning of the document in any way - it will simply > provide additional guidance to implementers on how to think about using the > assertion framework. > > Best wishes, > -- Mike > > -----Original Message----- > From: Hannes Tschofenig [mailto:[email protected]] > Sent: Tuesday, January 15, 2013 10:34 AM > To: Mike Jones > Cc: Hannes Tschofenig; [email protected] WG > Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 > > 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 _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
