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

Nat Sakimura sakimura at gmail.com
Fri Apr 12 22:31:43 UTC 2019


Thanks Brian,

Actually that may very well be. In fact I also remembered like that but my memo was saying otherwise, so...

Nat Sakimura
On Apr 12, 2019, 11:16 PM +0900, Brian Campbell <bcampbell at pingidentity.com>, wrote:
> 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/20190413/4047bc4f/attachment-0001.html>


More information about the Openid-specs-ab mailing list