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 <ve7...@ve7jtb.com> 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." <jric...@mitre.org> 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 <stephen.farr...@cs.tcd.ie> > > 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 > >>> 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 > > _______________________________________________ > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
