[Openid-specs-ab] OAuth JAR's final improvements

Mike Jones Michael.Jones at microsoft.com
Fri Apr 12 19:30:21 UTC 2019


I agree that the audience should be the issuer value.

-- Mike
________________________________
From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> on behalf of Brian Campbell via Openid-specs-ab <openid-specs-ab at lists.openid.net>
Sent: Friday, April 12, 2019 7:16:28 AM
To: Artifact Binding/Connect Working Group
Cc: Brian Campbell; John Bradley
Subject: Re: [Openid-specs-ab] OAuth JAR's final improvements

I recall the general conclusion from the discussion regarding the value for "aud" somewhat differently. The consensus was that the JWT's "aud" (audience) should contain the AS's issuer value from RFC8414. Using the value of the authorization_endpoint would be a further departure from how it works in OIDC Core and make supporting both or transitioning from the OIDC request to the JAR request more cumbersome.

There was also the suggestion to just make "aud" required (i.e. a MUST vs. a SHOULD) in JAR while having to make the aforementioned change anyway, which Folks seemed in favor of.


On Thu, Apr 11, 2019 at 8:53 PM Nat Sakimura via Openid-specs-ab <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>> wrote:
As noted in the last meeting note, we had a discussion on OAuth JAR
draft at the OAuth Security Workshop 2019. The draft has gone through
the telechat but needs one fix pointed out by Ekr.

That is

a) to add an explanatory text to what `aud` shall be.

In OIDC Core 1.0, `aud` here is defined as

The aud value SHOULD be or include the OP's Issuer Identifier URL.

In -17 of the OAuth JAR draft, it is saying:

   the Authorization Request
   Object SHOULD contain the Claims "iss" (issuer) and "aud" (audience)
   as members, with their semantics being the same as defined in the JWT
   [RFC7519] specification.

Apparently, it is less specific than OIDC.

We discussed this a bit in the OAuth Security Workshop 2019 and what
the room concluded was that it should be a value in the OAuth Server
Metadata.
There are two candidates for this.

* issuer
* authorization_endpoint

The discussion there concluded that since the request really should be
going to the authorization_endpoint and not the token endpoint, the
value of `aud` should be the value of `authorization_endpoint` as in
RFC8414.

Then, there were a bunch of other features that people wanted were discussed.

They were:

b) Additional AS metadata, e.g,
* authorization_endpoint_jar_signing_alg_values_supported
* authorization_endpoint_jar_encryption_alg_values_supported

c) Client registration parameter to indicate always sign, and always encrypt.

d) Take 7.5 from FAPI Part 2.

It was agreed that pushing b), c) and d) above would mean pushing the
draft back to WG and as FAPI wants to have the spec published ASAP, it
was agreed just to do a) for this document and leave b) - d) in
another spec or bi OAuth JAR bis.

--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190412/0e12462c/attachment.html>


More information about the Openid-specs-ab mailing list