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

Brian Campbell bcampbell at pingidentity.com
Fri Apr 12 14:16:28 UTC 2019

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> 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
> 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/d95bbaba/attachment.html>

More information about the Openid-specs-ab mailing list