>> When using secure elements with specific properties, it is possible to
>> counter the Alice & Bob Collusion attack.
You don’t just need the Secure Element’s properties (key-pair generated on SE;
non-exportable private key; high-entropy key-id generated on SE; conformance
cert; special
Okay, I'll look at adding a refresh example and some additional explanation.
There are client authentication methods that use asymmetric cryptography so
sender-constraining a refresh token with an asymmetric key pair (indirectly
via the client's credentials) is already possible and happening in
Hey Brian
A refresh example would make it more clear, and would also assist in
communicating that DPoP could be used just for refresh.
I see in the updated text that using DPoP with confidential clients is
discouraged. I understand the RT is sender constrained -- but
asymmetric cryptography is
I'm currently working on the draft and hope to have a new revision
published relatively soon. Just the other day I made some changes to the
text around RTs with
https://github.com/danielfett/draft-dpop/commit/11d90264bffa0325461e7f8d96311fac44986974
that maybe/hopefully makes some of it more
Hello
I was reviewing the latest DPoP draft[1] and saw numerous mentions of using
a DPoP proof for refreshing an access token, but no explicit description of
how to do that, nor an example. Was this intentional?
Perhaps a new section "Refreshing an Access Token"?
Additionally, I can imagine
excusme hello all itu error kok gak selesai2 ya
On 28 Okt 2020 23.56 +0700, Aaron Parecki , wrote:
> Hi Roberto,
>
> The authors are keeping track of open discussions on this GitHub repo
> https://github.com/aaronpk/oauth-v2-1
>
> If you'd like to provide feedback on the record, then this email
Hi Roberto,
The authors are keeping track of open discussions on this GitHub repo
https://github.com/aaronpk/oauth-v2-1
If you'd like to provide feedback on the record, then this email list is
the best place for that. You're also welcome to open issues on the GitHub
repo, but that is an
Hi everybody,
I'd like to provide some feedback to draft-ietf-oauth-v2-1. Is there a repo
(eg. like https://github.com/httpwg/http-core) where I can see the open
issues,
catch up with the discussion and discuss PRs?
Thanks for your hard work and have a nice day,
R:
Am 28.10.20 um 12:00 schrieb Warren Parad:
> I would likewise assume that issuer validation is always required. But
> maybe I hadn't been thinking about this enough. Is there an
> alternative to validating it, and implicitly trusting it? Because as
> you pointed out either demonstrated control
I would likewise assume that issuer validation is always required. But
maybe I hadn't been thinking about this enough. Is there an alternative to
validating it, and implicitly trusting it? Because as you pointed out
either demonstrated control over valid redirect URIs or really any other
secondary
Hi all,
during my work to update the Security BCP, I stumbled upon a problem in
our current recommendations against mix-up attacks.
Until now, our understanding was that adding an "iss" parameter in the
authorization response and using a distinct redirect URI for each
configured issuer provided
11 matches
Mail list logo
