> On 7. Jun 2020, at 16:18, Nov Matake wrote:
>
> private_key_jwt and mTLS can be sender PoP method for code too.
Seems we need to distinguish certain “kinds” of PoP for code.
1) private_key_jwt, mTLS and other client secrets can be used to authenticate
the client and thus check the bindin
On Sun, Jun 7, 2020 at 10:18 AM Nov Matake wrote:
> private_key_jwt and mTLS can be sender PoP method for code too.
>
>
Yes,correct thanks for pointing this out: So we have
code :
-> sender : Client
-> consumer : AS
-> sender PoP :
--> confidential client: [code_verifier (PKCE) AND
private_key_jwt and mTLS can be sender PoP method for code too.
> 2020/06/07 23:00、Francis Pouatcha のメール:
>
> I am a little bit confused. Let me break it down:
>
> code :
> -> sender : Client
> -> consumer : AS
> -> sender PoP :
>--> confidential client: code_verifier (PKCE)
>
I am a little bit confused. Let me break it down:
code :
-> sender : Client
-> consumer : AS
-> sender PoP :
--> confidential client: code_verifier (PKCE)
--> public client: code_verifier (PKCE)?
refresh_token :
-> sender : Client
-> consumer : AS
-> sender PoP :
Hi all,
I was wondering if we should move towards introducing and (more
explicitly) recommending the iss parameter in the security BCP, for the
reasons laid out below and in the article (which is now at
https://danielfett.de/2020/05/04/mix-up-revisited/).
Any thoughts on this?
-Daniel
Am 04.05.2
* sender-constrained code, bearer access token and sender-constrained refresh
token, use DynReg or "PKCE + DPoP allowing access token remaining bearer".
* sender-constrained code, sender-constrained access token and
sender-constrained refresh token, use "DynReg + DPoP" or "PKCE + DPoP".
* bearer
Yeah, both PKCE and Client Credential provide sender-constrained code...
lots of choices
Sent from my iPhone
> On Jun 7, 2020, at 21:26, Neil Madden wrote:
>
>
> Answers inline:
>
>>> On 7 Jun 2020, at 13:07, Nov Matake wrote:
>>>
>> So, you mean…
>>
>> If a frontend client want to use
Answers inline:
> On 7 Jun 2020, at 13:07, Nov Matake wrote:
>
> So, you mean…
>
> If a frontend client want to use
> * sender-constrained code, bearer access token and sender-constrained refresh
> token, use DynReg.
I’m not really sure what a sender-constrained code would be, but I suspect
So, you mean…
If a frontend client want to use
* sender-constrained code, bearer access token and sender-constrained refresh
token, use DynReg.
* sender-constrained code, sender-constrained access token and
sender-constrained refresh token, use DynReg + DPoP.
* bearer code, sender-constrained ac
There are multiple issues with using dynamic client registration for this. If a
user uninstalls and later reinstalls an app then they can end up with multiple
registrations for the same client, which makes it harder for them to manage
access. Additionally, client registrations typically don’t ex
Confidential clients can also use DPoP.
> 2020/06/07 20:25、Torsten Lodderstedt のメール:
>
> If the client would register for every transaction.
>
> And don’t forget, DPoP also supports sender constrained access to resource
> servers, which dyn registration does not.
>
>> Am 07.06.2020 um 13:04 s
If the client would register for every transaction.
And don’t forget, DPoP also supports sender constrained access to resource
servers, which dyn registration does not.
> Am 07.06.2020 um 13:04 schrieb Nov Matake :
>
> Since each client instance has at least one key, those are same level of
>
Since each client instance has at least one key, those are same level of state
management.
> 2020/06/07 16:24、Torsten Lodderstedt のメール:
>
> There are similarities in this particular use case but I would argue DPoP is
> more light weight than dynamic client registration, less state management in
There are similarities in this particular use case but I would argue DPoP is
more light weight than dynamic client registration, less state management in
particular.
> Am 07.06.2020 um 05:41 schrieb Nov Matake :
>
> DPoP-bound refresh token seems feature duplication with dynamic client
> regi
That’s correct for confidential clients.
For a public client, the refresh token is just bound to the client id. DPoP
allows binding to an ephemeral key pair for this kind of clients.
> Am 07.06.2020 um 00:57 schrieb Francis Pouatcha
> :
>
>
>>
>> > Am 05.06.2020 um 22:17 schrieb George Flet
15 matches
Mail list logo
