On Fri, Oct 17, 2014 at 9:27 AM, Brian Campbell <bcampb...@pingidentity.com> wrote:
> > > On Thu, Oct 16, 2014 at 4:32 PM, Richard Barnes <r...@ipv.sx> wrote: > >> >> >> On Thu, Oct 16, 2014 at 1:44 PM, Brian Campbell < >> bcampb...@pingidentity.com> wrote: >> >>> Thanks for your review and feedback on this one too, Richard. Replies >>> are inline below... >>> >>> On Wed, Oct 15, 2014 at 10:01 PM, Richard Barnes <r...@ipv.sx> wrote: >>> >>>> Richard Barnes has entered the following ballot position for >>>> draft-ietf-oauth-jwt-bearer-10: Discuss >>>> >>>> When responding, please keep the subject line intact and reply to all >>>> email addresses included in the To and CC lines. (Feel free to cut this >>>> introductory paragraph, however.) >>>> >>>> >>>> Please refer to >>>> http://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>> >>>> As with draft-ietf-oauth-assertions, the requirement for an "aud" claim >>>> seems entirely unnecessary. Holding this DISCUSS point pending that >>>> discussion >>>> and its reflection in this document. >>>> >>>> "Assertions that do not identify the Authorization Server as an intended >>>> audience MUST be rejected." -- What does it mean for an assertion to >>>> "identify >>>> the Authorization Server"? Does the specified <Audience> need to match >>>> the >>>> entire URL of the relevant OAuth endpoint? Just the origin? Just the >>>> domain? >>>> Does the URL need to be canonicalized? >>>> >>>> >>> >>> No c14n, as it says, "... compare the audience values using the Simple >>> String Comparison method defined in Section 6.2.1 of RFC 3986." >>> >>> Basically the AS is at liberty to determine how it identifies itself. >>> Some guidance on using the token endpoint is provided but it's ultimately >>> up to the AS (or the larger deployment in which the AS exists). The >>> acceptable value is one of a few bits of information that must be exchanged >>> for this profile, which is discussed in the Interoperability Considerations >>> https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-10#section-5 >>> >> >> Sigh. "Negotiate it out of band" is a terrible, non-scalable, >> not-in-the-spirit-of-the-Internet answer. But I guess I might clear on >> this if you could add something like the following: >> "As noted in Section 5 of [I-D.ietf-oauth-jwt-bearer], the precise >> strings to be used as the Audience for a given Authorization Server must be >> configured out-of-band by the Authorization Server and the Issuer of the >> assertion." >> > > > > I'll add the suggested text. > Great. Let me know when the revised text is posted. --Richard > > > >> >> But is there seriously no answer that the WG could agree on? This seems >> like it should be a pretty simple question. Was it even discussed? >> >> > > > It was discussed but it's not simple for reasons I've tried to articulate > many times. > > Note that the specific profiling or usage of these specs can constrain or > dictate the values of this and other the things that needing out of band > negotiation and can be more in the spirit of the Internet to the extent > that they define dynamic exchange/discovery/registration/etc. of required > information. But these little documents need to fit into such larger > contexts not try and define them. > > > >> --Richard >> >> >> >>> Some more explanation/discussion of it is in the middle(ish) of this >>> reply to a similar comment from Stephen Farrell >>> http://www.ietf.org/mail-archive/web/oauth/current/msg13605.html >>> >>> >>> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> "keyed message digest" -> "MAC" >>>> >>> >>> Yep. >>> >>> >>>> >>>> Both this and the SAML document could save a lot of bits by just being >>>> subsections of the -assertions document. >>>> >>> >>> The structure and relationship of the documents was decided on by the WG >>> nearly three years ago. There is some duplication but it's believed to be >>> more approachable this way - particularly for those implementing just one >>> assertion type. >>> >> >> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
