Subject: [OAUTH-WG] WGLC for DPoP Document

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 28 Mar 2022 08:01:11 -0400

All,

As discussed during the IETF meeting in *Vienna* last week, this is a *WG
Last Call *for the *DPoP* document:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/

Please, provide your feedback on the mailing list by April 11th.

Regards,
 Rifaat & Hannes

---

From: Denis <[email-masked]>
Date: Mon, 28 Mar 2022 16:28:47 +0200

Rifaat & Hannes,

Hereafter are my comments:

The introduction states :

        Recipients of such tokens are then able to verify the binding of 
the token to the key pair thatthe client has demonstrated
        that it holds via the DPoP header, thereby providing some 
assurance that the client presenting the token also possesses the 
private key.

        In other words, the legitimate presenter of the token is 
constrained to be the sender that holds and can prove possession of the 
private part of the key pair.

The client presenting the token *does not necessarily possess the 
private key*. The client presenting the token has been able to use
the results of some cryptographic functions using the private part of 
the key pair.

These results may be communicated by one client to another client, if 
the two clients agree to collaborate. This statement will be added later on.

Proposed rewording:

        Recipients of such tokens are then able to verify the binding of 
the token to the key pair thatthe client has demonstrated
        that it holds via the DPoP header, thereby providing some 
assurance that the client presenting the token *either *also possesses
        the private key *or* has been able to use the result of 
cryptographic computations from another client that possesses the 
private key.

        In other words, the presenter of the token can prove that it has 
been able to use the results of cryptographic computations performed
        by using the private part of the key pair.

The objectives states

        The primary aim of DPoP is to prevent unauthorized or 
illegitimate parties from using leaked or stolen access tokens,
        by binding a token to a public key upon issuance and requiring 
that the client proves possession of the corresponding
        private key when using the token.

DPoP does not prevent unauthorized or illegitimate parties from using 
access tokens, as soon as two clients agree to collaborate.

Proposed rewording:

        The primary aim of DPoP is to bind a token to a public key upon 
issuance and requiring that the client proves possession
        of the corresponding private key when using the token.This does 
not demonstrate that the client presenting the token is
        necessarily the legitimate client. In the case of 
non-collaborating clients, DPoP prevents unauthorized or illegitimate 
parties
        from using leaked or stolen access tokens. In the case of 
collaborating clients, the security of DPoP is ineffective
        (see section 11.X).

Section 11 is about "Security Considerations" and addresses the 
following topics:

11.1.DPoP Proof Replay
11.2.DPoP Proof Pre-Generation
11.3.DPoP Nonce Downgrade
11.4.Untrusted Code in the Client Context
11.5.Signed JWT Swapping
11.6.Signature Algorithms
11.7.Message Integrity
11.8.Access Token and Public Key Binding
11.9.Authorization Code and Public Key Binding

The case of collaborative clients should be addressed within section 11.

Text proposal.

11.X. Collaborative clients

             DPoP demonstrates that the client presenting the token has 
been able to use the results of some cryptographic functions
using the private part of the key pair.

If a client agrees to collaborate with another client, the security of 
DPoP is no longer effective.When two clients agree to collaborate,
these results of the cryptographic computations performed by one client 
may be communicated to another client.

Even if the private key used for DPoP is stored in such a way that it 
cannot be exported, e.g., in a hardware or software security module,
the client can perform all the cryptographic computations needed by the 
other client to create DPoP proofs.

The client can easily create new DPoP proofs as long as the other client 
is online.

Note: There exist other techniques able to limit, in some cases, the use 
of a token transmitted voluntarily by a legitimate client
                       to an illegitimate client.

Denis

> All,
>
> As discussed during the IETF meeting in *Vienna* last week, this is a 
> *WG Last Call *for the *DPoP* document:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Steinar Noem <[email-masked]>
Date: Mon, 28 Mar 2022 19:04:22 +0200

Interesting, but won't two collaborating clients just pass any data they
want to each other? Why would these collaborating clients go through the
trouble of exchanging private keys, dpop proofs or tokens? Could you
elaborate some more on the scenario?

S

man. 28. mar. 2022 kl. 16:29 skrev Denis <[email-masked]>:

> the token to the key pair that  the client has demonstrated
>        that it holds via the DPoP header, thereby providing some assurance
> that the client presenting the token also possesses the private key.
>
> The client presenting the token *does not necessarily possess the private
> key*. The client presenting the token has been able to use
> the results of some cryptographic functions using the private part of the
> key pair.
>
> These results may be communicated by one client to another client, if the
> two clients agree to collaborate. This statement will be added later on.
>
> Proposed rewording:
>
> the token to the key pair that  the client has demonstrated
>        that it holds via the DPoP header, thereby providing some assurance
> that the client presenting the token *either *also possesses
> cryptographic computations from another client that possesses the private
> key.
>
>        The primary aim of DPoP is to prevent unauthorized or illegitimate
> parties from using leaked or stolen access tokens,
>        by binding a token to a public key upon issuance and requiring that
> the client proves possession of the corresponding
>        of the corresponding private key when using the token.  This does
>        necessarily the legitimate client. In the case of non-collaborating
> clients, DPoP prevents unauthorized or illegitimate parties
> Section 11 is about "Security Considerations" and addresses the following
> topics:
>
>      11.1.  DPoP Proof Replay
>      11.2.  DPoP Proof Pre-Generation
>      11.3.  DPoP Nonce Downgrade
>      11.4.  Untrusted Code in the Client Context
>      11.5.  Signed JWT Swapping
>      11.6.  Signature Algorithms
>      11.7.  Message Integrity
>      11.8.  Access Token and Public Key Binding
>      11.9.  Authorization Code and Public Key Binding
>
>             If a client agrees to collaborate with another client, the
> security of DPoP is no longer effective.  When two clients agree to
> collaborate,
>             these results of the cryptographic computations performed by
> one client may be communicated to another client.
>
>             Even if the private key used for DPoP is stored in such a way
> that it cannot be exported, e.g., in a hardware or software security
> module,
>             the client can perform all the cryptographic computations
> needed by the other client to create DPoP proofs.
>
>             The client can easily create new DPoP proofs as long as the
> other client is online.
>
>             Note: There exist other techniques able to limit, in some
> cases, the use of a token transmitted voluntarily by a legitimate client
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

| [email-masked] | [email-masked]  | +47 955 21 620 | www.udelt.no |

---

From: Denis <[email-masked]>
Date: Mon, 28 Mar 2022 19:26:55 +0200

Steinar,

As you have guessed, no data (except the token and some crypto 
checksums) is passing through the clients.

Once the legitimate client has allowed the illegitimate client to use 
the token, the illegitimate client can do anything it wants with it.
The legitimate client can be kept fully ignorant of what illegitimate 
client is doing.

The data flow is minimum: if the token allows to view a 4 Gb movie, that 
data flow does not flow between the clients.

Furthermore, the content of the token may allow the illegitimate client 
to use it during days or months.
Suppose that the token indicates "over 18". If the user is over 18 now, 
he will certainly be "over 18" the next days, months or years.
There is no need to refresh the token as it would be the case if the 
token included a home address.

Denis

> Interesting, but won't two collaborating clients just pass any data 
> they want to each other? Why would these collaborating clients go 
> through the trouble of exchanging private keys, dpop proofs or tokens? 
> Could you elaborate some more on the scenario?
>
> S
>
>     constrained to be the sender that holds and can prove possession
>     of the private part of the key pair.
>
>     the results of some cryptographic functions using the private part
>     of the key pair.
>
>     These results may be communicated by one client to another client,
>     if the two clients agree to collaborate. This statement will be
>     added later on.
>
>     Proposed rewording:
>
>            Recipients of such tokens are then able to verify the
>     binding of the token to the key pair thatthe client has demonstrated
>            In other words, the presenter of the token can prove that
>     it has been able to use the results of cryptographic computations
>     performed
>            by binding a token to a public key upon issuance and
>     requiring that the client proves possession of the corresponding
>     DPoP does not prevent unauthorized or illegitimate parties from
>     using access tokens, as soon as two clients agree to collaborate.
>
>     Proposed rewording:
>
>            The primary aim of DPoP is to bind a token to a public key
>     upon issuance and requiring that the client proves possession
>            of the corresponding private key when using the token.This
>     does not demonstrate that the client presenting the token is
>     non-collaborating clients, DPoP prevents unauthorized or
>     illegitimate parties
>                 DPoP demonstrates that the client presenting the token
>     has been able to use the results of some cryptographic functions
>     security of DPoP is no longer effective.When two clients agree to
>     collaborate,
>     these results of the cryptographic computations performed by one
>     client may be communicated to another client.
>
>     Even if the private key used for DPoP is stored in such a way that
>     it cannot be exported, e.g., in a hardware or software security
>     module,
>     the client can perform all the cryptographic computations needed
>     by the other client to create DPoP proofs.
>
>     The client can easily create new DPoP proofs as long as the other
>     client is online.
>
>     Note: There exist other techniques able to limit, in some cases,
>     the use of a token transmitted voluntarily by a legitimate client
>>     As discussed during the IETF meeting in *Vienna* last week, this
>>     is a *WG Last Call *for the *DPoP* document:
> | [email-masked] <mailto:[email-masked]> | [email-masked]  | +47 955 
> 21 620 | www.udelt.no <http://www.udelt.no/> |

---

From: David Waite <[email-masked]>
Date: Mon, 28 Mar 2022 15:32:08 -0600

> On Mar 28, 2022, at 8:28 AM, Denis <[email-masked]> wrote:

<snip>
>        The primary aim of DPoP is to bind a token to a public key upon issuance and requiring that the client proves possession 
>        of the corresponding private key when using the token.  This does not demonstrate that the client presenting the token is 
>        necessarily the legitimate client. In the case of non-collaborating clients, DPoP prevents unauthorized or illegitimate parties 
>        from using leaked or stolen access tokens. In the case of collaborating clients, the security of DPoP is ineffective 
>        (see section 11.X).
> 

<snip>
>             If a client agrees to collaborate with another client, the security of DPoP is no longer effective.  When two clients agree to collaborate, 
>             these results of the cryptographic computations performed by one client may be communicated to another client. 
> 
> 
If a system has shared its tokens and/or credentials with another system, they are both operating as part of a single client. Neither DPoP nor OAuth define how two clients can share access, such as by applying scopes issued against the client with identifier “foo” to the client with id “bar”. 

From an AS or user perspective, multiple parties could collaborate beyond the expectations and limitations they intended the client to have. However, sharing across parties or underlying systems could be entirely within expectations - such as multiple services which together use information from the resource server to fulfill a request.

One could have text such as:

DPoP does not prevent sharing of data or access by a client with additional parties which are not authorized by the AS. In particular, a client may voluntarily share either private keys or constructed DPoP proofs.

But this is somewhat matter-of-factly stating that the AS should continue to have the same evaluation process of what parties should be given access as clients - that DPoP is not a DRM or DLP scheme.

<snip>
>             Even if the private key used for DPoP is stored in such a way that it cannot be exported, e.g., in a hardware or software security module, 
>             the client can perform all the cryptographic computations needed by the other client to create DPoP proofs. 
> 
This seems unneeded with the text above. In addition, DPoP does not define a way for an AS to ensure it only issues access tokens against PoP keys which are non-exportable.

-DW

---

From: Justin Richer <[email-masked]>
Date: Tue, 29 Mar 2022 09:10:17 -0400

And this is exactly the problem with the “collaborating clients” attack, as has been pointed out any number of times it’s been brought up before. If two clients are willingly collaborating in this way, they do not need to share any cryptographic material and impersonate each other.

You don’t need to steal my license if I’m willing to just go buy you beer.

The DPoP draft does address signed request re-use, which some see as a feature to be carefully applied.

 — Justin

> On Mar 28, 2022, at 1:04 PM, Steinar Noem <[email-masked]> wrote:
> 
> Interesting, but won't two collaborating clients just pass any data they want to each other? Why would these collaborating clients go through the trouble of exchanging private keys, dpop proofs or tokens? Could you elaborate some more on the scenario? 
> 
> S
> 
> man. 28. mar. 2022 kl. 16:29 skrev Denis <[email-masked] <mailto:[email-masked]>>:
> Rifaat & Hannes,
>        Recipients of such tokens are then able to verify the binding of the token to the key pair that  the client has demonstrated 
>        that it holds via the DPoP header, thereby providing some assurance that the client presenting the token also possesses the private key. 
> 
>        In other words, the legitimate presenter of the token is constrained to be the sender that holds and can prove possession of the private part of the key pair.
> 
> The client presenting the token does not necessarily possess the private key. The client presenting the token has been able to use 
> the results of some cryptographic functions using the private part of the key pair. 
> 
> These results may be communicated by one client to another client, if the two clients agree to collaborate. This statement will be added later on.
> 
> Proposed rewording:
> 
>        Recipients of such tokens are then able to verify the binding of the token to the key pair that  the client has demonstrated 
>        that it holds via the DPoP header, thereby providing some assurance that the client presenting the token either also possesses 
>        the private key or has been able to use the result of cryptographic computations from another client that possesses the private key. 
> 
>        In other words, the presenter of the token can prove that it has been able to use the results of cryptographic computations performed 
>        The primary aim of DPoP is to prevent unauthorized or illegitimate parties from using leaked or stolen access tokens, 
>        by binding a token to a public key upon issuance and requiring that the client proves possession of the corresponding 
> DPoP does not prevent unauthorized or illegitimate parties from using access tokens, as soon as two clients agree to collaborate.
> 
> Proposed rewording:
> 
> Section 11 is about "Security Considerations" and addresses the following topics:
> 
>      11.1.  DPoP Proof Replay
>             DPoP demonstrates that the client presenting the token has been able to use the results of some cryptographic functions
>             The client can easily create new DPoP proofs as long as the other client is online.
> 
>             Note: There exist other techniques able to limit, in some cases, the use of a token transmitted voluntarily by a legitimate client 
>> As discussed during the IETF meeting in Vienna last week, this is a WG Last Call for the DPoP document:
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ <https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/>
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> 
> -- 
> Vennlig hilsen
> 
> Steinar Noem
> Partner Udelt AS
> Systemutvikler
>  
> | [email-masked] <mailto:[email-masked]> | [email-masked] <mailto:[email-masked]>  | +47 955 21 620 <> | www.udelt.no <http://www.udelt.no/> |

---

From: Daniel Fett <[email-masked]>
Date: Tue, 29 Mar 2022 15:13:35 +0200

+1

Am 29.03.22 um 15:10 schrieb Justin Richer:
> And this is exactly the problem with the “collaborating clients” 
> attack, as has been pointed out any number of times it’s been brought 
> up before. If two clients are willingly collaborating in this way, 
> they do not need to share any cryptographic material and impersonate 
> each other.
>
>> through the trouble of exchanging private keys, dpop proofs or 
>> tokens? Could you elaborate some more on the scenario?
>>
>> S
>>
>>     These results may be communicated by one client to another
>>     client, if the two clients agree to collaborate. This statement
>>     will be added later on.
>>
>>     Proposed rewording:
>>
>>                 DPoP demonstrates that the client presenting the
>>     token has been able to use the results of some cryptographic
>>     functions
>>     that it cannot be exported, e.g., in a hardware or software
>>     security module,
>> | [email-masked] <mailto:[email-masked]> | [email-masked]  | +47 
>> 955 21 620 | www.udelt.no <http://www.udelt.no/> |

-- 
https://danielfett.de

---

From: Denis <[email-masked]>
Date: Tue, 29 Mar 2022 15:19:09 +0200

Hi  Justin,

You broke the thread since you have not re-used the last message which was:

    Steinar,

    Once the legitimate client has allowed the illegitimate client to
    use the token, the illegitimate client can do anything it wants with it.
    The legitimate client can be kept fully ignorant of what
    illegitimate client is doing.

    The data flow is minimum: if the token allows to view a 4 Gb movie,
    that data flow does not flow between the clients.

    Furthermore, the content of the token may allow the illegitimate
    client to use it during days or months.
    Suppose that the token indicates "over 18". If the user is over 18
    now, he will certainly be "over 18" the next days, months or years.
    There is no need to refresh the token as it would be the case if the
    token included a home address.

This message explains why this collaborative attack is very different 
from simply forwarding messages between clients.

The illegitimate client can do anything it wants without disclosing what 
it is doing to the legitimate client.
The traffic between the clients is kept to the very minimum.

Denis

>>>     assurance that the client presenting the token also possesses
>>>     the private key.
>>>
>>>     The client presenting the token *does not necessarily possess
>>>     the private key*. The client presenting the token has been able
>>>     to use
>>>     cryptographic computations from another client that possesses
>>>     the private key.
>>>
>>>     it has been able to use the results of cryptographic
>>>     computations performed
>>>            The primary aim of DPoP is to bind a token to a public
>>>     key upon issuance and requiring that the client proves possession
>>>            of the corresponding private key when using the
>>>     token.This does not demonstrate that the client presenting the
>>>     token is
>>>     security of DPoP is no longer effective.When two clients agree
>>>     to collaborate,
>>>>     As discussed during the IETF meeting in *Vienna* last week,
>>>>     this is a *WG Last Call *for the *DPoP* document:

---

From: Roberto Polli <[email-masked]>
Date: Tue, 29 Mar 2022 15:27:27 +0200

Dear all,

thanks for this interesting work! I think that there's some editorial work
that should be done
on terminology (e.g. a consistent use of JOSE header parameter, HTTP header
field, ...)
and some simplification will really make the spec more easy to read.

For example, once defined that the syntax of DPOP is a JWS, it is redundant
to
further state that DPOP value MUST be a JWS.
Moreover there are security considerations all throughout the document,
that should probably
be moved to the #Security section.

I will provide further feedback in the next few days.

I'm providing some PRs on the repo: feel free to comment there.

- https://github.com/danielfett/draft-dpop/pulls/ioggstream

Kind regards,
R.

---

From: Justin Richer <[email-masked]>
Date: Tue, 29 Mar 2022 11:21:05 -0400

If the “legitimate” client willingly gives away its secrets and tokens to the “illegitimate” client, then the latter isn’t actually “illegitimate” anymore.

What I was saying is that the “attack" is not even necessary if the clients are in fact working together. If the “legitimate” client knowing gives away its credentials, it is accepting that the receiver of those credentials can do anything it wants with those credentials. That’s why they are credentials.

 — Justin

PS: I did not “break” the thread, I replied to a message in the thread. That’s how email lists work.

> On Mar 29, 2022, at 9:19 AM, Denis <[email-masked]> wrote:
> 
> Hi  Justin,
> 
> As you have guessed, no data (except the token and some crypto checksums) is passing through the clients. 
> 
> Once the legitimate client has allowed the illegitimate client to use the token, the illegitimate client can do anything it wants with it.
> The legitimate client can be kept fully ignorant of what illegitimate client is doing.
> 
> The data flow is minimum: if the token allows to view a 4 Gb movie, that data flow does not flow between the clients.
> 
> Furthermore, the content of the token may allow the illegitimate client to use it during days or months.
> Suppose that the token indicates "over 18". If the user is over 18 now, he will certainly be "over 18" the next days, months or years.  
> There is no need to refresh the token as it would be the case if the token included a home address.
> This message explains why this collaborative attack is very different from simply forwarding messages between clients.
> 
> The illegitimate client can do anything it wants without disclosing what it is doing to the legitimate client.
>>>> On Mar 28, 2022, at 1:04 PM, Steinar Noem <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>> https://danielfett.de <https://danielfett.de/>
>>

---

From: Denis <[email-masked]>
Date: Tue, 29 Mar 2022 17:39:34 +0200

Hi  Justin,

In this scenario, the “legitimate” client _never_ gives away its secrets 
(if it is using a secure platform, it can't). It never give away its 
credentials either.

When using key bound access tokens, a RS can't know whether the access 
token is presented by the “legitimate” client  or by an“illegitimate” 
client.

One of the goals is also to prevent a client to monetize the selling of 
"key bound access tokens" to other end-users.

As I have already indicated, there exists a solution able to prevent 
such scenario in some specific cases (i.e. in the case of RS long-term 
user accounts).

Denis

> If the “legitimate” client willingly gives away its secrets and tokens 
> to the “illegitimate” client, then the latter isn’t actually 
> “illegitimate” anymore.
>
> What I was saying is that the “attack" is not even necessary if the 
> clients are in fact working together.
> If the “legitimate” client knowing gives away its credentials, it is 
> accepting that the receiver of those credentials can do anything it 
> wants with those credentials. That’s why they are credentials.
>
>  — Justin
>
>>     The data flow is minimum: if the token allows to view a 4 Gb
>>     movie, that data flow does not flow between the clients.
>>
>>     Suppose that the token indicates "over 18". If the user is over
>>     18 now, he will certainly be "over 18" the next days, months or
>>     years.
>> The illegitimate client can do anything it wants without disclosing 
>> what it is doing to the legitimate client.
>>>> attack, as has been pointed out any number of times it’s been 
>>>> brought up before. If two clients are willingly collaborating in 
>>>> this way, they do not need to share any cryptographic material and 
>>>> impersonate each other.
>>>>
>>>>> Interesting, but won't two collaborating clients just pass any 
>>>>> data they want to each other? Why would these collaborating 
>>>>> clients go through the trouble of exchanging private keys, dpop 
>>>>> proofs or tokens? Could you elaborate some more on the scenario?
>>>>>
>>>>> S
>>>>>
>>>>>     Recipients of such tokens are then able to verify the binding
>>>>>     of the token to the key pair thatthe client has demonstrated
>>>>>            that it holds via the DPoP header, thereby providing
>>>>>     some assurance that the client presenting the token also
>>>>>     possesses the private key.
>>>>>
>>>>>            In other words, the legitimate presenter of the token
>>>>>     is constrained to be the sender that holds and can prove
>>>>>     possession of the private part of the key pair.
>>>>>
>>>>>     the private key*. The client presenting the token has been
>>>>>     able to use
>>>>>     client, if the two clients agree to collaborate. This
>>>>>     statement will be added later on.
>>>>>
>>>>>     Proposed rewording:
>>>>>
>>>>>            that it holds via the DPoP header, thereby providing
>>>>>     some assurance that the client presenting the token *either
>>>>>     *also possesses
>>>>>            In other words, the presenter of the token can prove
>>>>>     that it has been able to use the results of cryptographic
>>>>>     computations performed
>>>>>     DPoP does not prevent unauthorized or illegitimate parties
>>>>>     from using access tokens, as soon as two clients agree to
>>>>>     collaborate.
>>>>>
>>>>>     Proposed rewording:
>>>>>
>>>>>            from using leaked or stolen access tokens. In the case
>>>>>     of collaborating clients, the security of DPoP is ineffective
>>>>>            (see section 11.X).
>>>>>

---

From: Justin Richer <[email-masked]>
Date: Tue, 29 Mar 2022 13:55:11 -0400

Denis,

This is why the use of “iat” and “nonce” are recommended, to prevent this kind of replay, and these are already discussed in the draft. Having a highly targeted request with narrow presentation window is desirable in most cases, but some applications of DPoP do want to have a pre-generated proof that can be re-used on multiple requests. In this case, it becomes kind of bearer token in its own right, since it’s not strictly tied to a single HTTP request. This isn’t an attack, it’s an artifact of DPoP’s limited attachment to the HTTP message. If a client pre-generates a generic proof and gives it to another client, then that’s exactly the same as the client handing over its access token (which it would also need to do). 

The proof and the token are credentials, by definition.

Subject identifiers within the token do not prevent this kind of collusion, as has been previously discussed at length. Nothing stops Alice from giving her token that says “This is Alice” to Bob and having Bob use it. The RS will know it’s Alice’s token, but it’s still valid and Bob can act as Alice. If Alice is over 18 then Bob will get access to the things that Alice can get because she’s over 18. The call still works. Please stop pretending that adding a user identifier to the token solves the problem you are describing, it simply does not.

 — Justin

> On Mar 29, 2022, at 11:39 AM, Denis <[email-masked]> wrote:
> 
> Hi  Justin,
> 
> In this scenario, the “legitimate” client never gives away its secrets (if it is using a secure platform, it can't). It never give away its credentials either.
> 
> When using key bound access tokens, a RS can't know whether the access token is presented by the “legitimate” client  or by an“illegitimate” client.
> 
> One of the goals is also to prevent a client to monetize the selling of "key bound access tokens" to other end-users. 
> 
> As I have already indicated, there exists a solution able to prevent such scenario in some specific cases (i.e. in the case of RS long-term user accounts).
> 
> Denis
> 
> 
>> What I was saying is that the “attack" is not even necessary if the clients are in fact working together. 
>> If the “legitimate” client knowing gives away its credentials, it is accepting that the receiver of those credentials can do anything it wants with those credentials. That’s why they are credentials.
>> 
>>  — Justin
>> 
>>> On Mar 29, 2022, at 9:19 AM, Denis <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi  Justin,
>>>

---

From: Denis <[email-masked]>
Date: Tue, 29 Mar 2022 21:53:58 +0200

Justin,

> Denis,
>
> This is why the use of “iat” and “nonce” are recommended, to prevent 
> this kind of replay, and these are already discussed in the draft.
> Having a highly targeted request with narrow presentation window is 
> desirable in most cases, but some applications of DPoP do want to have 
> a pre-generated proof that can be re-used on multiple requests. In 
> this case, it becomes kind of bearer token in its own right, since 
> it’s not strictly tied to a single HTTP request. This isn’t an attack, 
> it’s an artifact of DPoP’s limited attachment to the HTTP message. If 
> a client pre-generates a generic proof and gives it to another client, 
> then that’s exactly the same as the client handing over its access 
> token (which it would also need to do).

The topic I am discussing has nothing to do with replay. The legitimate 
client gives away a token that it will never use.

> The proof and the token are credentials, by definition.

Well, the term "credentials" is being used with many different semantics 
in different documents. This is why I prefer not to use it.

> Subject identifiers within the token do not prevent this kind of 
> collusion, as has been previously discussed at length.

As it has been presented several times, this other technique provides a 
solution (only) in the context of long term user accounts,
but this is very common case.

> Nothing stops Alice from giving her token that says “This is Alice” to 
> Bob and having Bob use it.

Such scenario does not exist in the context of long term user accounts. 
However, it is important first to understand the concept
of long term user accounts.

> The RS will know it’s Alice’s token, but it’s still valid and Bob can 
> act as Alice.

When the AS delivers the access token, it includes into that access 
token an identifier that the client cannot choose which is 
representative of either Bob or Alice.

Alice cannot act on a long term user account that has been previously 
successfully opened by Bob, because she will get an identifier specific 
to herself.

On the contrary, when using DPoP, the sentence "/*not identified, not 
catch*/" applies.  Bob can sell such key bound tokens to an unlimited 
number of users.

> If Alice is over 18 then Bob will get access to the things that Alice 
> can get because she’s over 18.
> The call still works.
>
> Please stop pretending that adding a user identifier to the token 
> solves the problem you are describing, it simply does not.

I would agree that the scenario of mixing user identifiers to the token 
and giving away access tokens between collaborative clients
has not yet been fully explored. If you are willing to discuss long term 
user accounts in such a context, please open a different thread.

However, we should not mix topics since *this current thread is about 
DPoP*.

The key  point is not the existence of an alternative technique at the 
moment, but the fact that DPoP is currently giving *a false sense of 
security*.

Currently DPoP allows clients to monetize the selling of "key bound 
access tokens" to other end-users, and this should be advertised
in the Security Considerations section.

The next question is the following: being informed of that threat, will 
the community really use DPoP ? I let you answer that question.
However, if the community is not informed, it is more likely that it 
will use it. Ignoring the danger will not stop the threat.

Denis

>> In this scenario, the “legitimate” client _never_ gives away its 
>> secrets (if it is using a secure platform, it can't). It never give 
>> away its credentials either.
>>
>> When using key bound access tokens, a RS can't know whether the 
>> access token is presented by the “legitimate” client  or by 
>> an“illegitimate” client.
>>
>> One of the goals is also to prevent a client to monetize the selling 
>> of "key bound access tokens" to other end-users.
>>
>> such scenario in some specific cases (i.e. in the case of RS 
>> long-term user accounts).
>>
>> Denis
>>
>>
>>> If the “legitimate” client willingly gives away its secrets and 
>>> tokens to the “illegitimate” client, then the latter isn’t actually 
>>> “illegitimate” anymore.
>>>
>>>>     Once the legitimate client has allowed the illegitimate client
>>>>     to use the token, the illegitimate client can do anything it
>>>>     wants with it.
>>>>     Furthermore, the content of the token may allow the
>>>>     illegitimate client to use it during days or months.
>>>> This message explains why this collaborative attack is very 
>>>> different from simply forwarding messages between clients.
>>>>
>>>>>> this way, they do not need to share any cryptographic material 
>>>>>> and impersonate each other.
>>>>>>
>>>>>>>     The client presenting the token *does not necessarily
>>>>>>>     possess the private key*. The client presenting the token
>>>>>>>     has been able to use
>>>>>>>            the private key *or* has been able to use the result
>>>>>>>     of cryptographic computations from another client that
>>>>>>>            The primary aim of DPoP is to bind a token to a
>>>>>>>     public key upon issuance and requiring that the client
>>>>>>>     proves possession
>>>>>>>     token.This does not demonstrate that the client presenting
>>>>>>>     the token is
>>>>>>>            from using leaked or stolen access tokens. In the
>>>>>>>     case of collaborating clients, the security of DPoP is
>>>>>>>     ineffective
>>>>>>>            (see section 11.X).
>>>>>>>
>>>>>>>     security of DPoP is no longer effective.When two clients
>>>>>>>     agree to collaborate,
>>>>>>>     Even if the private key used for DPoP is stored in such a
>>>>>>>     way that it cannot be exported, e.g., in a hardware or
>>>>>>>     software security module,
>>>>>>> | [email-masked] <mailto:[email-masked]> | [email-masked]  | 
>>>>>>> +47 955 21 620 | www.udelt.no <http://www.udelt.no/> |

---

From: Hans Zandbelt <[email-masked]>
Date: Tue, 29 Mar 2022 22:07:13 +0200

On Tue, Mar 29, 2022 at 9:54 PM Denis <[email-masked]> wrote:

> Nothing stops Alice from giving her token that says “This is Alice” to Bob
> and having Bob use it.
>
nothing stops Alice from logging in on Bob's device, obtaining tokens for
access and then leave Bob with the device, even in long term user accounts

Hans.

-- 
[email-masked]
ZmartZone IAM - www.zmartzone.eu

---

From: Denis <[email-masked]>
Date: Tue, 29 Mar 2022 22:19:00 +0200

Hans,

Please do not mix topics. I have changed the title of that thread, for 
not polluting the original one.

>>     Nothing stops Alice from giving her token that says “This is
>>     Alice” to Bob and having Bob use it.
>
>     Such scenario does not exist in the context of long term user
>     accounts. However, it is important first to understand the concept
> nothing stops Alice from logging in on Bob's device, obtaining tokens 
> for access and then leave Bob with the device, even in long term user 
> accounts

Even so, Alice will be unable to use that long term user account that 
has been just opened the next time an access token will be requested by 
the RS,
unless she asks again to Bob to use again Bob's device. In such a case, 
she has better to live very close to Bob. :-)

Denis

> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu>

---

From: Hans Zandbelt <[email-masked]>
Date: Tue, 29 Mar 2022 23:09:38 +0200

Hi Denis,

thanks for correcting the thread topic:

On Tue, Mar 29, 2022 at 10:19 PM Denis <[email-masked]> wrote:

> Even so, Alice will be unable to use that long term user account that has
> been just opened the next time an access token will be requested by the RS,
so I conclude that the security considerations of the spec on subject
identifiers should stipulate that colluding clients must not live close to
each other then... (or better, that the spec does not try to address this
type of attack, same for DPoP)

Hans.

---

From: Mike Jones <[email-masked]>
Date: Tue, 29 Mar 2022 21:12:38 +0000

I support publication of the specification.

                                                       -- Mike

From: OAuth <[email-masked]> On Behalf Of Rifaat Shekh-Yusef
Sent: Monday, March 28, 2022 5:01 AM
To: oauth <[email-masked]>
Subject: [OAUTH-WG] WGLC for DPoP Document

All,

Regards,
 Rifaat & Hannes

---

From: Denis <[email-masked]>
Date: Tue, 29 Mar 2022 23:16:10 +0200

Hi Hans,

>>     nothing stops Alice from logging in on Bob's device, obtaining
>>     tokens for access and then leave Bob with the device, even in
>>     long term user accounts
>
>     Even so, Alice will be unable to use that long term user account
>     that has been just opened the next time an access token will be
>     requested by the RS,
>     unless she asks again to Bob to use again Bob's device. In such a
>     case, she has better to live very close to Bob. :-)
>
> identifiers should stipulate that colluding clients must not live 
> close to each other then...
> (or better, that the spec does not try to address this type of attack, 
> same for DPoP)

I see that you have a good sense of humour. :-)

The reality is that the mechanism protects the case when the users are 
spread all over the world in different locations.

Now, I will never allow Alice to use my own device.

This has nothing to do with what DPoP can offer. So it is not the same 
for DPoP.

Denis

---

From: David Waite <[email-masked]>
Date: Tue, 29 Mar 2022 15:20:29 -0600

I also support publication of this specification

-DW

> On Mar 29, 2022, at 3:12 PM, Mike Jones <Michael.Jones=[email-masked]> wrote:
>

---

From: Steinar Noem <[email-masked]>
Date: Wed, 30 Mar 2022 07:23:33 +0200

I would like to un-ask my question. Is there a «retract mail» option
somewhere?

PS! This is written by my wife, with whom I have colluded many times. She
even knows the PIN code on my bank cards.

tir. 29. mar. 2022 kl. 22:08 skrev Hans Zandbelt <[email-masked]
>:

>> However, it is important first to  the concept
-- 
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

---

From: Daniel Fett <[email-masked]>
Date: Wed, 30 Mar 2022 08:54:40 +0200

I also support publication.

-Daniel

Am 29.03.22 um 23:20 schrieb David Waite:
>> On Mar 29, 2022, at 3:12 PM, Mike Jones 
>> <Michael.Jones=[email-masked]> wrote:
>>
>> *From:*OAuth <[email-masked]>*On Behalf Of*Rifaat Shekh-Yusef
>> *Sent:*Monday, March 28, 2022 5:01 AM
>> *To:*oauth <[email-masked]>
>> *Subject:*[OAUTH-WG] WGLC for DPoP Document
>> All,
>>
>> As discussed during the IETF meeting in*Vienna*last week, this is 
>> a*WG Last Call*for the *DPoP*document:

-- 
https://danielfett.de

---

From: Dave Tonge <[email-masked]>
Date: Wed, 30 Mar 2022 08:55:55 +0200

I support publication of the specification

On Wed, 30 Mar 2022 at 08:55, Daniel Fett <[email-masked]> wrote:

> On Mar 29, 2022, at 3:12 PM, Mike Jones <
> Michael.Jones=[email-masked]> wrote:
>
> *From:* OAuth <[email-masked]> *On Behalf Of *Rifaat Shekh-Yusef
> *Sent:* Monday, March 28, 2022 5:01 AM
> *To:* oauth <[email-masked]>
> *Subject:* [OAUTH-WG] WGLC for DPoP Document
>
> All,
>
> -- https://danielfett.de

-- 
Dave Tonge
CTO
<http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
t: +44 (0)117 280 5120

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
Limited which is authorised and regulated by the Financial Conduct
Authority ("FCA"). Moneyhub Financial Technology is entered on the
Financial Services Register (FRN 809360) at fca.org.uk/register.
Moneyhub Financial
Technology is registered in England & Wales, company registration number
06909772 .
Moneyhub Financial Technology Limited 2018 ©

DISCLAIMER: This email (including any attachments) is subject to copyright,
and the information in it is confidential. Use of this email or of any
information in it other than by the addressee is unauthorised and unlawful.
Whilst reasonable efforts are made to ensure that any attachments are
virus-free, it is the recipient's sole responsibility to scan all
attachments for viruses. All calls and emails to and from this company may
be monitored and recorded for legitimate purposes relating to this
company's business. Any opinions expressed in this email (or in any
attachments) are those of the author and do not necessarily represent the
opinions of Moneyhub Financial Technology Limited or of any other group
company.

-- 

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology 
Limited which is authorised and regulated by the Financial Conduct 
Authority ("FCA"). Moneyhub Financial Technology is entered on the 
Financial Services Register (FRN 809360) at https://register.fca.org.uk/ 
<https://register.fca.org.uk/>. Moneyhub Financial Technology is registered 
in England & Wales, company registration number 06909772. Moneyhub 
Financial Technology Limited 2022 © Moneyhub Enterprise, 

DISCLAIMER: This 
email (including any attachments) is subject to copyright, and the 
information in it is confidential. Use of this email or of any information 
in it other than by the addressee is unauthorised and unlawful. Whilst 
reasonable efforts are made to ensure that any attachments are virus-free, 
it is the recipient's sole responsibility to scan all attachments for 
viruses. All calls and emails to and from this company may be monitored and 
recorded for legitimate purposes relating to this company's business. Any 
opinions expressed in this email (or in any attachments) are those of the 
author and do not necessarily represent the opinions of Moneyhub Financial 
Technology Limited or of any other group company.

---

From: Steinar Noem <[email-masked]>
Date: Wed, 30 Mar 2022 09:18:53 +0200

ons. 30. mar. 2022 kl. 08:56 skrev Dave Tonge <[email-masked]>:

> Financial Services Register (FRN 809360) at fca.org.uk/register. Moneyhub Financial
> DISCLAIMER: This email (including any attachments) is subject to
> copyright, and the information in it is confidential. Use of this email or
> of any information in it other than by the addressee is unauthorised and
> unlawful. Whilst reasonable efforts are made to ensure that any attachments
> are virus-free, it is the recipient's sole responsibility to scan all
> Financial Services Register (FRN 809360) at https://register.fca.org.uk/.
> Moneyhub Financial Technology is registered in England & Wales, company
> registration number 06909772. Moneyhub Financial Technology Limited 2022 ©
> Moneyhub Enterprise,
>
> DISCLAIMER: This email (including any attachments) is subject to
> copyright, and the information in it is confidential. Use of this email or
> of any information in it other than by the addressee is unauthorised and
> unlawful. Whilst reasonable efforts are made to ensure that any attachments
> are virus-free, it is the recipient's sole responsibility to scan all

-- 
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 30 Mar 2022 14:07:57 +0200

I support publication of this specification. 

> Am 30.03.2022 um 09:18 schrieb Steinar Noem <[email-masked]>:
> 
> ons. 30. mar. 2022 kl. 08:56 skrev Dave Tonge <[email-masked] <mailto:[email-masked]>>:
> On Wed, 30 Mar 2022 at 08:55, Daniel Fett <[email-masked] <mailto:[email-masked]>> wrote:
>>> On Mar 29, 2022, at 3:12 PM, Mike Jones <Michael.Jones=[email-masked] <mailto:Michael.Jones=[email-masked]>> wrote:
>>> 
>>> From: OAuth <[email-masked] <mailto:[email-masked]>> On Behalf Of Rifaat Shekh-Yusef
>>> To: oauth <[email-masked] <mailto:[email-masked]>>
> https://danielfett.de <https://danielfett.de/>_______________________________________________
> OAuth mailing list
> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at fca.org.uk/register <http://fca.org.uk/register>. Moneyhub Financial Technology is registered in England & Wales, company registration number  06909772 .
> DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.
> 
> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/ <https://register.fca.org.uk/>. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2022 © Moneyhub Enterprise, 
> 
> DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.
> 
>

---

From: Warren Parad <[email-masked]>
Date: Wed, 30 Mar 2022 14:12:01 +0200

I support publication.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.

On Wed, Mar 30, 2022 at 2:08 PM Torsten Lodderstedt <torsten=
[email-masked]> wrote:

> ons. 30. mar. 2022 kl. 08:56 skrev Dave Tonge <[email-masked]
> >:
>

---

From: Pieter Kasselman <[email-masked]>
Date: Wed, 30 Mar 2022 13:00:47 +0000

I support publication

From: OAuth <[email-masked]> On Behalf Of Warren Parad
Sent: Wednesday 30 March 2022 13:12
To: Torsten Lodderstedt <torsten=[email-masked]>
Cc: oauth <[email-masked]>
Subject: Re: [OAUTH-WG] WGLC for DPoP Document

I support publication.

[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement Authress<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0f5d914774c543d33bb608da124691a7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637842391592114157%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=OmFLKCEoC%2B1GdmXgbrupe%2Bjh0alg19lyCAz3GS%2FWDlg%3D&reserved=0>.

On Wed, Mar 30, 2022 at 2:08 PM Torsten Lodderstedt <torsten=[email-masked]<mailto:[email-masked]>> wrote:
I support publication of this specification.

Am 30.03.2022 um 09:18 schrieb Steinar Noem <[email-masked]<mailto:[email-masked]>>:

ons. 30. mar. 2022 kl. 08:56 skrev Dave Tonge <[email-masked]<mailto:[email-masked]>>:
I support publication of the specification

On Wed, 30 Mar 2022 at 08:55, Daniel Fett <[email-masked]<mailto:[email-masked]>> wrote:

-Daniel

-DW

On Mar 29, 2022, at 3:12 PM, Mike Jones <Michael.Jones=[email-masked]<mailto:Michael.Jones=[email-masked]>> wrote:

                                                       -- Mike

From: OAuth <[email-masked]<mailto:[email-masked]>> On Behalf Of Rifaat Shekh-Yusef
Sent: Monday, March 28, 2022 5:01 AM
To: oauth <[email-masked]<mailto:[email-masked]>>
Subject: [OAUTH-WG] WGLC for DPoP Document

All,

As discussed during the IETF meeting in Vienna last week, this is a WG Last Call for the DPoP document:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-oauth-dpop%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0f5d914774c543d33bb608da124691a7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637842391592114157%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3UV7OEQHo2JtM%2F89ocby6KzBQ6VhcfexHQH0gojnKUQ%3D&reserved=0>

Regards,
 Rifaat & Hannes

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0f5d914774c543d33bb608da124691a7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637842391592114157%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tlMe8RGJLA1AltaaR%2Bi0tl%2FMEotkdbmS%2Bkz%2BRAMmor0%3D&reserved=0>

OAuth mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0f5d914774c543d33bb608da124691a7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637842391592114157%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tlMe8RGJLA1AltaaR%2Bi0tl%2FMEotkdbmS%2Bkz%2BRAMmor0%3D&reserved=0>

--

https://danielfett.de<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdanielfett.de%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0f5d914774c543d33bb608da124691a7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637842391592164606%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=zfOMKw9sYBbMkfIWzEsLPF0Mo3pX66Zr5hU4XjrxbVI%3D&reserved=0>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0f5d914774c543d33bb608da124691a7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637842391592164606%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=K4jzdn2T1kbc7a%2BQFOP3mssF8%2FvgEHJwnAisLZhaPhU%3D&reserved=0>

--
Dave Tonge
CTO
[Moneyhub Enterprise]<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.google.com%2Furl%3Fq%3Dhttp%253A%252F%252Fmoneyhubenterprise.com%252F%26sa%3DD%26sntz%3D1%26usg%3DAFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0f5d914774c543d33bb608da124691a7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637842391592164606%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MIGh%2BNQlVkRDAVdnW1gV2GgmuP9vn%2F7qpzf1v9xtEso%3D&reserved=0>
t: +44 (0)117 280 5120

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at fca.org.uk/register<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Ffca.org.uk%2Fregister&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0f5d914774c543d33bb608da124691a7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637842391592164606%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=SN2ew7gP6jx%2FLf6psbf%2F6UpxcVCckYCj9tdUuG38nQg%3D&reserved=0>. Moneyhub Financial Technology is registered in England & Wales, company registration number  06909772 .
Moneyhub Financial Technology Limited 2018 (c)

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fregister.fca.org.uk%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0f5d914774c543d33bb608da124691a7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637842391592164606%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Iz8vqhg9aOfsnKWG0kxiebUj%2Bzk48sUNnpnWOhr29T8%3D&reserved=0>. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2022 (c) Moneyhub Enterprise,

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0f5d914774c543d33bb608da124691a7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637842391592164606%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=K4jzdn2T1kbc7a%2BQFOP3mssF8%2FvgEHJwnAisLZhaPhU%3D&reserved=0>

--
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

| [email-masked]<mailto:[email-masked]> | [email-masked]<mailto:[email-masked]>  | +47 955 21 620 | www.udelt.no<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.udelt.no%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0f5d914774c543d33bb608da124691a7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637842391592164606%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=FEVm7hyLAMQl2Zq9H0LSoe1T%2Fiiw6AzZwL7o%2BJTFmIk%3D&reserved=0> |
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0f5d914774c543d33bb608da124691a7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637842391592214127%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=r0LcTSu5xIkk2d%2FA%2BrmbOBzbj7gSmRvci%2BoyNCrd%2FDk%3D&reserved=0>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0f5d914774c543d33bb608da124691a7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637842391592214127%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=r0LcTSu5xIkk2d%2FA%2BrmbOBzbj7gSmRvci%2BoyNCrd%2FDk%3D&reserved=0>