On Mon, Nov 4, 2013 at 11:58 AM, Brian Campbell
<[email protected]>wrote:

> On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig
> <[email protected]> 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.
>

I'm ok with that as well.



>
> [1] http://www.ietf.org/mail-archive/web/oauth/current/msg12251.html
> _______________________________________________
> OAuth mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to