On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig <hannes.tschofe...@gmx.net> wrote > Item #2: You wrote: > > " > Section 2.5.1.4 of Assertions and Protocols for the OASIS > Security Assertion Markup Language [OASIS.saml-core-2.0-os] > defines the <AudienceRestriction> and <Audience> elements and, > in addition to the URI references discussed there, the token > endpoint URL of the authorization server MAY be used as a URI > that identifies the authorization server as an intended > audience. Assertions that do not identify the Authorization > Server as an intended audience MUST be rejected. > " > > The 'MAY' is extremely weak here. If you make it a MUST that there has to be > the endpoint URL of the authorization server in there then that would > provide so much more interoperability. As a reader I wouldn't know what > other options I have and systems that provision necessary databases / tables > to ensure that the comparison takes place will also struggle.
The "MAY" is intended to be weak and is only a suggestion for deployments which don't already have a suitable identifier (like a SAML 2 entity ID) for an audience value. I understand that you'd like this to be tighter but the suggestion is not viable and it wouldn't provide the perceived interoperability panacea anyway. Some information needs to be agreed upon for this to work. How is out of scope here. The audience is one such value. Even if mandating one specific thing for audience was feasible, it wouldn't add to interoperability because there is other information that has to be agreed on anyway. > Then, there is again this SHOULD regarding the comparison operation, see > " > Audience > values SHOULD be compared using the Simple String Comparison > method defined in Section 6.2.1 of RFC 3986 [RFC3986], unless > otherwise specified by the application. > " > > I would replace it with a MUST, as I argued in > draft-ietf-oauth-jwt-bearer-06. As I said there [1], I think I'm okay with that but would like to hear from others in the WG. [1] http://www.ietf.org/mail-archive/web/oauth/current/msg12251.html _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
