Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-jwt-bearer-10: (with DISCUSS and COMMENT)
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. 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
Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-jwt-bearer-10: (with DISCUSS and COMMENT)
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
Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-jwt-bearer-10: (with DISCUSS and COMMENT)
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 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
Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-jwt-bearer-10: (with DISCUSS and COMMENT)
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. 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? --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
