Re: [OAUTH-WG] [DPoP] Order of validation for DPoP proofs and access tokens

[Dmitry Telegin]

Any updates on this one? As of -04 we have a clear distinction between
"error=invalid_token" and "error=invalid_dpop_proof", so the question could
be reworded like this:
- if DPoP proof is used in combination with access token, and both are
invalid, which one of the "invalid_token" and "invalid_dpop_proof" should
be signaled?

Regards,
Dmitry
Backbase

On Fri, Jul 30, 2021 at 6:37 PM Dmitry Telegin  wrote:

> Hello,
>
> When DPoP proof is used in conjunction with a token (protected resource
> access; token refresh), what should be the order of validation of those?
> The draft doesn't mention this, and it's hard to deduce logically which
> should come first, since validation is mutual ("ath" DPoP claim vs.
> "cnf/jkt" token claim) and there is a sort of circular dependency. Are we
> going to address that in the spec, or intentionally leave as unspecified?
>
> Background: a developer asked me if it's guaranteed that the protected
> resource return a 401 in the case of invalid access token; currently, the
> answer seems to be "implementation specific".
>
> Regards,
> Dmitry
>
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] DPoP - access token hash format

[Dmitry Telegin]

As of -03, the "ath" DPoP proof claim has been introduced:

ath: hash of the access token (REQUIRED). The value MUST be the result of a
> base64url encoding (with no padding) the SHA-256 hash of the ASCII encoding
> of the associated access token's value.
>

OpenID Connect has a similar concept used to bind ID token to access token:

at_hash OPTIONAL. Access Token hash value. Its value is the base64url
> encoding of the left-most half of the hash of the octets of the ASCII
> representation of the access_token value, where the hash algorithm used
> is the hash algorithm used in the alg Header Parameter of the ID Token's
> JOSE Header. For instance, if the alg is RS256, hash the access_token
> value with SHA-256, then take the left-most 128 bits and base64url encode
> them. The at_hash value is a case sensitive string.
>
>
OIDC derives the hashing algorithm from the token header, while DPoP uses
SHA-256 unconditionally. OIDC uses the left-most half of the hash, while
DPoP uses the whole hash. Would it make sense to be aligned with OIDC on
this?

Regards,
Dmitry
Backbase
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] DPoP and OAuth2 extensions

[Dmitry Telegin]

The draft currently focuses on DPoP support in Authorization endpoint and
Token endpoint (authorization code grant + refresh token grant). The
concept, however, could be extrapolated to several other endpoints, grant
types and OAuth2 extensions:
- ROPC (RFC 6749 section 1.3.3);
- OAuth 2.0 Token Exchange (RFC 8693);
- OAuth 2.0 Extension Grants (RFC 6749 section 4.5);
- OAuth 2.0 Token Revocation (RFC 7009);
- OpenID Connect

(As for the latter, the UserInfo endpoint is introduced, which is an OAuth
2.0 protected resource conforming to OAuth 2.0 Bearer Token Usage (RFC
6750). However, UserInfo is different from the traditional protected
resources in having no advance knowledge on whether DPoP should be enforced
or not (until the incoming token is processed), hence the need to advertise
both "Bearer" and "DPoP" schemes via WWW-Authenticate.)

Would it make sense to mention these relations in the spec?

Regards,
Dmitry
Backbase
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [DPoP] Order of validation for DPoP proofs and access tokens

[Brian Campbell]

It's really just an implementation choice, I think.

On Wed, Oct 27, 2021 at 7:17 AM Dmitry Telegin  wrote:

> Any updates on this one? As of -04 we have a clear distinction between
> "error=invalid_token" and "error=invalid_dpop_proof", so the question could
> be reworded like this:
> - if DPoP proof is used in combination with access token, and both are
> invalid, which one of the "invalid_token" and "invalid_dpop_proof" should
> be signaled?
>
> Regards,
> Dmitry
> Backbase
>
> On Fri, Jul 30, 2021 at 6:37 PM Dmitry Telegin 
> wrote:
>
>> Hello,
>>
>> When DPoP proof is used in conjunction with a token (protected resource
>> access; token refresh), what should be the order of validation of those?
>> The draft doesn't mention this, and it's hard to deduce logically which
>> should come first, since validation is mutual ("ath" DPoP claim vs.
>> "cnf/jkt" token claim) and there is a sort of circular dependency. Are we
>> going to address that in the spec, or intentionally leave as unspecified?
>>
>> Background: a developer asked me if it's guaranteed that the protected
>> resource return a 401 in the case of invalid access token; currently, the
>> answer seems to be "implementation specific".
>>
>> Regards,
>> Dmitry
>>
>>
>>
>> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_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._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [DPoP] Order of validation for DPoP proofs and access tokens

[Neil Madden]

I would express a mild preference for “invalid_token” taking priority in this 
case. It seems pointless for the client to generate a new DPoP proof (in 
response to invalid_dpop_proof) if they are then going to get an invalid_token 
on the next request anyway. If they get a new AT they will naturally generate a 
new proof too as the AT hash will no longer match.

— Neil

> On 27 Oct 2021, at 16:20, Brian Campbell 
>  wrote:
> 
> It's really just an implementation choice, I think. 
> 
> On Wed, Oct 27, 2021 at 7:17 AM Dmitry Telegin 
>  > wrote:
> Any updates on this one? As of -04 we have a clear distinction between 
> "error=invalid_token" and "error=invalid_dpop_proof", so the question could 
> be reworded like this:
> - if DPoP proof is used in combination with access token, and both are 
> invalid, which one of the "invalid_token" and "invalid_dpop_proof" should be 
> signaled?
> 
> Regards,
> Dmitry
> Backbase
> 
> On Fri, Jul 30, 2021 at 6:37 PM Dmitry Telegin  > wrote:
> Hello,
> 
> When DPoP proof is used in conjunction with a token (protected resource 
> access; token refresh), what should be the order of validation of those? The 
> draft doesn't mention this, and it's hard to deduce logically which should 
> come first, since validation is mutual ("ath" DPoP claim vs. "cnf/jkt" token 
> claim) and there is a sort of circular dependency. Are we going to address 
> that in the spec, or intentionally leave as unspecified?
> 
> Background: a developer asked me if it's guaranteed that the protected 
> resource return a 401 in the case of invalid access token; currently, the 
> answer seems to be "implementation specific".
> 
> Regards,
> Dmitry
> 
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth 
> 
> 
> 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.___
> 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

Re: [OAUTH-WG] DPoP - access token hash format

[Brian Campbell]

There's discussions around this in the mail and meeting archives, if you
want to dig into it. But generally the "at_hash" approach has proven to be
complicated while not really achieving the algorithm agility it aims for.
We opted for something more straightforward with "ath" in DPoP.

On Wed, Oct 27, 2021 at 7:25 AM Dmitry Telegin  wrote:

> As of -03, the "ath" DPoP proof claim has been introduced:
>
> ath: hash of the access token (REQUIRED). The value MUST be the result of
>> a base64url encoding (with no padding) the SHA-256 hash of the ASCII
>> encoding of the associated access token's value.
>>
>
> OpenID Connect has a similar concept used to bind ID token to access token:
>
> at_hash OPTIONAL. Access Token hash value. Its value is the base64url
>> encoding of the left-most half of the hash of the octets of the ASCII
>> representation of the access_token value, where the hash algorithm used
>> is the hash algorithm used in the alg Header Parameter of the ID Token's
>> JOSE Header. For instance, if the alg is RS256, hash the access_token
>> value with SHA-256, then take the left-most 128 bits and base64url encode
>> them. The at_hash value is a case sensitive string.
>>
>>
> OIDC derives the hashing algorithm from the token header, while DPoP uses
> SHA-256 unconditionally. OIDC uses the left-most half of the hash, while
> DPoP uses the whole hash. Would it make sense to be aligned with OIDC on
> this?
>
> Regards,
> Dmitry
> Backbase
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_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._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] DPoP and OAuth2 extensions

[Brian Campbell]

https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-04.html#name-dpop-access-token-request
is pretty clear (I think?) that DPoP is applicable with all token endpoint
requests of any grant type.

I don't know what would be said about Token Revocation.

I'm not seeing the UserInfo endpoint as being different enough to need any
special treatment or discussion. But maybe that's just because I'm not sure
what it would say.

On Wed, Oct 27, 2021 at 7:49 AM Dmitry Telegin  wrote:

> The draft currently focuses on DPoP support in Authorization endpoint and
> Token endpoint (authorization code grant + refresh token grant). The
> concept, however, could be extrapolated to several other endpoints, grant
> types and OAuth2 extensions:
> - ROPC (RFC 6749 section 1.3.3);
> - OAuth 2.0 Token Exchange (RFC 8693);
> - OAuth 2.0 Extension Grants (RFC 6749 section 4.5);
> - OAuth 2.0 Token Revocation (RFC 7009);
> - OpenID Connect
>
> (As for the latter, the UserInfo endpoint is introduced, which is an OAuth
> 2.0 protected resource conforming to OAuth 2.0 Bearer Token Usage (RFC
> 6750). However, UserInfo is different from the traditional protected
> resources in having no advance knowledge on whether DPoP should be enforced
> or not (until the incoming token is processed), hence the need to advertise
> both "Bearer" and "DPoP" schemes via WWW-Authenticate.)
>
> Would it make sense to mention these relations in the spec?
>
> Regards,
> Dmitry
> Backbase
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_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._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

[Dick Hardt]

Thanks for pointing out the Oblivious draft Justin. It is interesting, but
looks to be focussed on privacy rather than non-repudiation. Was I missing
non-repudiation aspects?
ᐧ

On Sat, Oct 23, 2021 at 4:55 PM Justin Richer  wrote:

> Dick, you would probably be interested in the Oblivious HTTP effort that
> has recently been chartered to solve similar encapsulation problems in
> HTTP.
>
> - Justin
> 
> From: OAuth [oauth-boun...@ietf.org] on behalf of Dick Hardt [
> dick.ha...@gmail.com]
> Sent: Friday, October 22, 2021 6:08 PM
> To: Richard Backman, Annabelle
> Cc: David Waite; oauth
> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adoption - OAuth
> Proof of Possession Tokens with HTTP Message Signature
>
> I have a use case for a self contained request that can be independently
> verified by multiple parties. IE, not just have PoP at HTTP endpoint, but
> by components doing processing further down the line. It also provides
> non-repudiation.
>
> For example, a JWT that is sent as an HTTP payload includes the request
> and the access token.
>
> mTLS, DPoP, and HTTP signing don't provide this functionality
>
> It is not clear if others have similar requirements, or if there is value
> in standardization effort, but I wanted to call out a use case not solved
> by the current efforts.
>
> /Dick
>
> On Wed, Oct 13, 2021 at 2:55 PM Richard Backman, Annabelle  40amazon@dmarc.ietf.org> wrote:
> If keeping DPoP simple means we have to have come up with 10 different
> variants to handle all the different cases that it doesn't support, then it
> isn't keeping it simple, it is just pushing the problem forward to the
> implementers to figure out which set of RFCs to implement.
>
> I'm hoping we can stop at 3: mTLS, DPoP, and Justin's draft. If someone
> has use cases that aren't covered by one or more of those, they should
> bring those up so we can discuss them and decide what changes are
> warranted. (Either here, or in HTTPbis if changes should be made to Message
> Signatures) My preference would've been to stop at 2, but the consensus has
> not been in favor of expanding the scope of use cases served by DPoP.
>
> [
> https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=593dd17a-bb93-449b-8126-3b72052d76b2]ᐧ
> 
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] DPoP Interim Meeting Minutes

[Rifaat Shekh-Yusef]

All,

Thanks to *Hannes* and *Dick* for taking the following notes during the
DPoP Interim meeting today.
https://notes.ietf.org/s/notes-ietf-interim-2021-oauth-14-oauth

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

[OAUTH-WG] AD review of draft-ietf-oauth-iss-auth-resp-02

[Roman Danyliw]

Hi!

I performed an AD review of draft-ietf-oauth-iss-auth-resp-02.  Thanks for 
documenting this mitigation.  

The document is in good shape so I am advancing it to IETF LC.  Please treat 
these minor comments as part of that feedback:

** Section 2.4.  Editorial.

   The decision of whether to accept such
   responses is individual for every scenario and it is not in the scope
   of this specification.

Would it be more clear to say:

"Local policy or configuration can determine whether to accept such responses 
and specific guidance is out of scope for this specification."

There is also similar language in the next paragraph.

** Section 5.1 and 5.2.  Per the "Change Control" field, please s/IESG/IETF/

Thanks,
Roman

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

Re: [OAUTH-WG] AD review of draft-ietf-oauth-iss-auth-resp-02

[Warren Parad]

Would making it even simpler also work? (and is more consistent with the
6749 language)
>
> The decision of whether to accept such responses is beyond the scope of
> this specification.


Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress .


On Wed, Oct 27, 2021 at 9:41 PM Roman Danyliw  wrote:

> Hi!
>
> I performed an AD review of draft-ietf-oauth-iss-auth-resp-02.  Thanks for
> documenting this mitigation.
>
> The document is in good shape so I am advancing it to IETF LC.  Please
> treat these minor comments as part of that feedback:
>
> ** Section 2.4.  Editorial.
>
>The decision of whether to accept such
>responses is individual for every scenario and it is not in the scope
>of this specification.
>
> Would it be more clear to say:
>
> "Local policy or configuration can determine whether to accept such
> responses and specific guidance is out of scope for this specification."
>
> There is also similar language in the next paragraph.
>
> ** Section 5.1 and 5.2.  Per the "Change Control" field, please
> s/IESG/IETF/
>
> Thanks,
> Roman
>
> ___
> 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] Last Call: (OAuth 2.0 Authorization Server Issuer Identification) to Proposed Standard

[The IESG]

The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'OAuth 2.0 Authorization Server
Issuer Identification'
   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 2021-11-17. 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 document specifies a new parameter iss that is used to
   explicitly include the issuer identifier of the authorization server
   in the authorization response of an OAuth authorization flow.  The
   iss parameter serves as an effective countermeasure to "mix-up
   attacks".




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/



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





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