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
