[OAUTH-WG] Protocol Action: 'The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)' to Proposed Standard (draft-ietf-oauth-jwsreq-28.txt)

2020-08-21 Thread The IESG
The IESG has approved the following document:
- 'The OAuth 2.0 Authorization Framework: JWT Secured Authorization
   Request (JAR)'
  (draft-ietf-oauth-jwsreq-28.txt) as Proposed Standard

This document is the product of the Web Authorization Protocol Working Group.

The IESG contact persons are Benjamin Kaduk and Roman Danyliw.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/





Technical Summary

   The authorization request in OAuth 2.0 [RFC6749] utilizes query
   parameter serialization, which means that Authorization Request
   parameters are encoded in the URI of the request and sent through
   user agents such as web browsers.  While it is easy to implement, it
   means that (a) the communication through the user agents are not
   integrity protected and thus the parameters can be tainted, and (b)
   the source of the communication is not authenticated.  Because of
   these weaknesses, several attacks to the protocol have now been put
   forward.

   This document introduces the ability to send request parameters in a
   JSON Web Token (JWT) instead, which allows the request to be JWS
   signed and/or JWE encrypted so that the integrity, source
   authentication and confidentiality property of the Authorization
   Request is attained.  The request can be sent by value or by
   reference.

Working Group Summary

  The document changes the encoding of the parameters in the 
  authorization request to a JSON-based encoding.

Document Quality

   There are a number of implementations, both vendor and
   open source and there was good support in the working group.

Personnel

 Hannes Tschofenig is the document shepherd and the responsible area 
director is Roman Danyliw. 
 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


Re: [OAUTH-WG] ECDH-1PU encryption algorithm

2020-08-21 Thread Thibault Normand
Hello,

Id' like to add that I've made a Gist with a one file implementation in Go
to try to make it simple to understand.
https://gist.github.com/Zenithar/cf58b003fcf341a3b1593c30b50b0820

I hope it helps new users
Regards,

Le lun. 10 août 2020 à 19:34, Mike Jones  a écrit :

> I’m likewise supportive of the work.  Note that COSE working group is
> currently open whereas JOSE is closed, so if you want working group review,
> I’d submit specs to COSE soon.
>
>
>
> As background, I worked the spec
> https://tools.ietf.org/html/draft-ietf-cose-webauthn-algorithms-08 in
> COSE which also performs JOSE registrations.  So that’s definitely a viable
> path forward.  (This document is currently in AUTH48 status, and so is
> about to become an RFC.)
>
>
>
> Filip, the JOSE working group closed after RFCs 7515-7518 and 7520 were
> completed.  Note that it’s possible to register algorithms, etc. in the
> IANA JOSE registries https://www.iana.org/assignments/jose/jose.xhtml
> without the spec coming from a working group – and indeed, without coming
> from a working group at all.
>
>
>
>   -- Mike
>
>
>
> *From:* OAuth  *On Behalf Of * Dick Hardt
> *Sent:* Monday, August 10, 2020 10:27 AM
> *To:* Filip Skokan 
> *Cc:* oauth 
> *Subject:* Re: [OAUTH-WG] ECDH-1PU encryption algorithm
>
>
>
> I'm supportive of this work.
>
>
>
> It is not clear that it is in the charter of the OAuth WG.
>
>
>
>
>
> On Mon, Aug 10, 2020 at 9:01 AM Filip Skokan  wrote:
>
> Hi Neil,
>
>
>
> I'm interested in seeing both AES SIV and ECDH-1PU for JOSE. Not sure how
> to go about it tho since JOSE is a concluded WG.
>
>
>
> Out of curiosity, why is it a concluded WG? Did IETF/JOSE WG not consider
> the need to further maintain/expand the JOSE algorithms as time goes on?
>
>
> S pozdravem,
> *Filip Skokan*
>
>
>
>
>
> On Mon, 10 Aug 2020 at 10:29, Neil Madden 
> wrote:
>
> Thanks Vladimir,
>
> Responses below
>
> > On 8 Aug 2020, at 10:40, Vladimir Dzhuvinov 
> wrote:
> >
> > Hi Neil,
> >
> > I definitely like the elegance of the proposed alg for JOSE, it provides
> > something that isn't currently available in the various classes of algs
> > made standard in JOSE.
> >
> > I also wanted to ask what's happening with AES SIV for JOSE, if there's
> > traction / feedback / support there as well?
> >
> > https://tools.ietf.org/html/draft-madden-jose-siv-mode-02
>
> Thanks for bringing this up. I’ve not received much feedback about this
> one, and I haven’t been very good at pushing it. If there is interest then
> I’d certainly be interested in bringing this forward too.
>
> That draft might be a better fit for eg the COSE WG though, which could
> then also register identifiers for JOSE. What do you think?
>
> >
> > Vladimir
> >
> >
> >>> On 05/08/2020 13:01, Neil Madden wrote:
> >> Hi all,
> >> You may remember me from such I-Ds
> >> as https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03, which
> >> proposes adding a new encryption algorithm to JOSE. I’d like to
> >> reserve a bit of time to discuss it at one of the upcoming interim
> >> meetings.
> >> The basic idea is that in many cases in OAuth and OIDC you want to
> >> ensure both confidentiality and authenticity of some token - for
> >> example when transferring an ID token containing PII to the client
> >> through the front channel, or for access tokens intended to be handled
> >> by a specific RS without online token introspection (such as the JWT
> >> access token draft). If you have a shared secret key between the AS
> >> and the client/RS then you can use symmetric authenticated encryption
> >> (alg=dir or alg=A128KW etc). But if you need to use public key
> >> cryptography then currently you are limited to a nested
> >> signed-then-encrypted JOSE structure, which produces much larger token
> >> sizes.
> >> The draft adds a new “public key authenticated encryption” mode based
> >> on ECDH in the NIST standard “one-pass unified” model. The primary
> >> advantage for OAuth usage is that the tokens produced are more compact
> >> compared to signing+encryption (~30% smaller for typical access/ID
> >> token sizes in compact serialization). Performance-wise, it’s roughly
> >> equivalent. I know that size concerns are often a limiting factor in
> >> choosing whether to encrypt tokens, so this should help.
> >> In terms of implementation, it’s essentially just a few extra lines of
> >> code compared to an ECDH-ES implementation. (Some JOSE library APIs
> >> might need an adjustment to accommodate the extra private key needed
> >> for encryption/public key for decryption).
> >> I’ve received a few emails off-list from people interested in using it
> >> for non-OAuth use-cases such as secure messaging applications. I think
> >> these use-cases can be accommodated without significant changes, so I
> >> think the OAuth WG would be a good venue for advancing this.
> >> I’d be interested to hear thoughts and discussion on the list prior to

[OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

2020-08-21 Thread The IESG


The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'JWT Response for OAuth Token
Introspection'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2020-09-04. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   This specification proposes an additional JSON Web Token (JWT)
   secured response for OAuth 2.0 Token Introspection.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/



No IPR declarations have been submitted directly on this I-D.





___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


[OAUTH-WG] AD Review of draft-ietf-oauth-jwt-introspection-response-09

2020-08-21 Thread Roman Danyliw
Hi!

I conducted an another AD review of 
draft-ietf-oauth-jwt-introspection-response-09.  As background, -07 of this 
document went to IESG Review and the document was brought back to the WG to 
address the DISCUSS points.  

Below is my feedback which can be addressed concurrently with IETF LC.

** Section 5.  I want to clarify what are the permissible members of 
token_introspection.  The two relevant text snippets seem to be:

(a) "token_introspection  A JSON object containing the members of the
   token introspection response, as specified in the "OAuth
   Token Introspection Response" registry established by
   [RFC7662] as well as other members."

(b) "Claims from the "JSON Web Token Claims" registry that are
   commonly used in [OpenID.Core] and can be applied to the
   resource owner MAY be included as members in the
   "token_introspection" claim."

-- Per (a), Recommend citing the IANA sub-registry directly -- 
https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-introspection-response
 (and not the "as specified in the "OAuth Token Introspection Response" 
registry established by [RFC7662]")

-- Per (a), "... as well as other members", what members is this referencing?  
Is that (b)?  Recommend being clear upfront on which exact registries are the 
sources of valid members.

-- Per (b), "... commonly used in [OpenId.Core]", what are those specifically?  
Is that claims registered in 
https://www.iana.org/assignments/jwt/jwt.xhtml#claims whose reference is 
[OpenID Connect Core 1.0]?  Recommend being unambiguous in which claims are 
permitted by pointing the IANA registry.

-- If I'm understanding right that the source comes either from 
oauth-parameters.xhtml#token-introspection-response or jwt.xhtml#claims, what 
happens if it isn't one of those?

** Section 5.  Per " The AS MUST ensure the release of any privacy-sensitive 
data is legally based", recommend also including a forward reference to Section 
9

Regards,
Roman

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-rar-02.txt

2020-08-21 Thread Torsten Lodderstedt
Hi all, 

the new RAR revision clarifies the “type” parameter processing. 

best regards,
Torsten. 

> On 21. Aug 2020, at 16:16, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Web Authorization Protocol WG of the IETF.
> 
>Title   : OAuth 2.0 Rich Authorization Requests
>Authors : Torsten Lodderstedt
>  Justin Richer
>  Brian Campbell
>   Filename: draft-ietf-oauth-rar-02.txt
>   Pages   : 31
>   Date: 2020-08-21
> 
> Abstract:
>   This document specifies a new parameter "authorization_details" that
>   is used to carry fine grained authorization data in the OAuth
>   authorization request.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-rar-02
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar-02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-rar-02
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


[OAUTH-WG] I-D Action: draft-ietf-oauth-rar-02.txt

2020-08-21 Thread internet-drafts


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

Title   : OAuth 2.0 Rich Authorization Requests
Authors : Torsten Lodderstedt
  Justin Richer
  Brian Campbell
Filename: draft-ietf-oauth-rar-02.txt
Pages   : 31
Date: 2020-08-21

Abstract:
   This document specifies a new parameter "authorization_details" that
   is used to carry fine grained authorization data in the OAuth
   authorization request.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-rar-02
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-rar-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth