I would support that too but only if the way it's calculated would get aligned
as well. If it remains being a fixed sha256 of the whole token rather than what
at_hash does, using a new claim makes sense.
Odesláno z iPhonu
> 9. 4. 2021 v 5:38, Mike Jones <Michael.Jones=40microsoft....@dmarc.ietf.org>:
>
>
> I had expected that we would use the existing member name “at_hash” for the
> access token hash value, rather than the new name “ath”, since there’s
> already precedent for using it. Could we change to the standard name for
> this when we publish the next version?
>
> Thanks,
> -- Mike
>
> From: OAuth <oauth-boun...@ietf.org> On Behalf Of Brian Campbell
> Sent: Wednesday, April 7, 2021 1:30 PM
> To: oauth <oauth@ietf.org>
> Subject: [OAUTH-WG] Fwd: New Version Notification for
> draft-ietf-oauth-dpop-03.txt
>
> A new revision of DPoP has been published. The doc history snippet is copied
> below. The main change here is the addition of an access token hash claim.
>
> -03
>
> * Add an access token hash ("ath") claim to the DPoP proof when used
> in conjunction with the presentation of an access token for
> protected resource access
>
> * add Untrusted Code in the Client Context section to security
> considerations
>
> * Editorial updates and fixes
>
> ---------- Forwarded message ---------
> From: <internet-dra...@ietf.org>
> Date: Wed, Apr 7, 2021 at 2:16 PM
> Subject: New Version Notification for draft-ietf-oauth-dpop-03.txt
>
>
> A new version of I-D, draft-ietf-oauth-dpop-03.txt
> has been successfully submitted by Brian Campbell and posted to the
> IETF repository.
>
> Name: draft-ietf-oauth-dpop
> Revision: 03
> Title: OAuth 2.0 Demonstrating Proof-of-Possession at the
> Application Layer (DPoP)
> Document date: 2021-04-07
> Group: oauth
> Pages: 32
> URL: https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.txt
> Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
> Html: https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.html
> Htmlized: https://tools.ietf.org/html/draft-ietf-oauth-dpop-03
> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dpop-03
>
> Abstract:
> This document describes a mechanism for sender-constraining OAuth 2.0
> tokens via a proof-of-possession mechanism on the application level.
> This mechanism allows for the detection of replay attacks with access
> and refresh tokens.
>
>
>
>
> 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.
>
> The IETF Secretariat
>
>
>
> 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
