Subject: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-jwt-bearer-10: (with DISCUSS and COMMENT)

From: "Richard Barnes" <[email-masked]>
Date: Wed, 15 Oct 2014 21:01:22 -0700

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?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

"keyed message digest" -> "MAC"

Both this and the SAML document could save a lot of bits by just being
subsections of the -assertions document.

---

From: Brian Campbell <[email-masked]>
Date: Thu, 16 Oct 2014 14:44:16 -0600

Thanks for your review and feedback on this one too, Richard. Replies are
inline below...

> http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/

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

Yep.

> 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.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 16 Oct 2014 15:32:04 -0700

> 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

---

From: John Bradley <[email-masked]>
Date: Thu, 16 Oct 2014 22:12:24 -0300

It was discussed.   As I recall it was decided that like SAML it is the responsibility of the protocol using OAuth to define it's naming convention for entities.

In Connect Section 9. we chose to use the URI of the token_endpoint, but we debated using the logical "iss" identifier for the Authorization server. 

There is a argument for using Named vs locations tying a logical name to a protocol endpoint URI may not always make sense.  

SAML typically uses entityID as a logical name allowing for endpoints to be reconfigured without breaking deployments in mysterious ways.

Saying that it must always be the uri of the token endpoint may be to inflexible,  though that is the easy answer most of the time.

John B.

On Oct 16, 2014, at 7:32 PM, Richard Barnes <[email-masked]> wrote:

> 
> 
> On Thu, Oct 16, 2014 at 1:44 PM, Brian Campbell <[email-masked]> wrote:
> Thanks for your review and feedback on this one too, Richard. Replies are inline below...
> 
> 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 Farrellhttp://www.ietf.org/mail-archive/web/oauth/current/msg13605.html 
> 
> 
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Campbell <[email-masked]>
Date: Fri, 17 Oct 2014 10:27:07 -0600

On Thu, Oct 16, 2014 at 4:32 PM, Richard Barnes <[email-masked]> wrote:

>> 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

I'll add the suggested text.

> 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

---

From: Richard Barnes <[email-masked]>
Date: Fri, 17 Oct 2014 11:10:23 -0700

On Fri, Oct 17, 2014 at 9:27 AM, Brian Campbell <[email-masked]>
wrote:

>>>> Please refer to
>>>> http://www.ietf.org/iesg/statement/discuss-criteria.html
>> "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

Great.  Let me know when the revised text is posted.

--Richard