If that's the case then I would omit the RFC 2119 language and say that the details have to be provided by the respective documents.
On Jan 11, 2013, at 4:37 PM, Richer, Justin P. 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
