One take away I had from the meeting today, and form the mail list, is the
concern of doing asymmetric crypto on API calls. How about if we use the
Client's public key to encrypt a symmetric key and pass that back to the
Client in the token request response?
EG:
In response to the token request,
There seems two prevailing approaches:
1. The AS generates a symmetric key and encrypts it to a specific audience as
part of/associated with the access token (KDC-type model).
2. The client attempts asymmetric use, and the resource server negotiates a
symmetric key specific to it.
The first mod
Dear all,
I have a few comments about the leakage of access tokens and the
underlying assumptions:
Section 2, A5 should be clarified:
"a resource server can be compromised by an attacker": Is the assumption
that the attacker cannot get access to the resources stored at the
compromised RS (o
At the end of my previous email I mentioned that you can achieve some of the
same aims as DPoP without needing a PoP mechanism at all. This email is that
follow-up.
OAuth is agnostic about the format of access tokens and many vendors support
either random string database tokens or JWTs. But the
Macaroons are built on proof of possession. In order to add a caveat to a
macaroon, the sender has to have the HMAC of the macaroon without their caveat.
The distinctive property of macaroons as I see it is that they eliminate the
need for key negotiation with the bearer. How much value this has
On 22 Nov 2019, at 01:42, Richard Backman, Annabelle
wrote:
>
>
> Macaroons are built on proof of possession. In order to add a caveat to a
> macaroon, the sender has to have the HMAC of the macaroon without their
> caveat.
Yes of course. But this is the HMAC *tag* not the original key. The
On Fri, Nov 22, 2019 at 3:08 PM Neil Madden
wrote:
> On 22 Nov 2019, at 01:42, Richard Backman, Annabelle
> wrote:
>
> There are key distribution challenges with that if you are doing
> validation at the RS, but validation at the RS using either approach means
> you’ve lost protection against re
I’m going to +1 Dick and Annabelle’s question about the scope here. That was
the one major thing that struck me during the DPoP discussions in Singapore
yesterday: we don’t seem to agree on what DPoP is for. Some (including the
authors, it seems) see it as a quick point-solution to a specific us
Hi everyone
I'd agree with this. I'm looking at DPOP as an alternative and
ultimately simpler way to accomplish what we can already do with MTLS-bound
Access Tokens, for use cases such as the ones we address in Open Banking;
these are API transactions that demand a high level of assurance and as
s
> On 22. Nov 2019, at 15:24, Justin Richer wrote:
>
> I’m going to +1 Dick and Annabelle’s question about the scope here. That was
> the one major thing that struck me during the DPoP discussions in Singapore
> yesterday: we don’t seem to agree on what DPoP is for. Some (including the
> auth
Hi Rob,
> On 22. Nov 2019, at 15:52, Rob Otto
> wrote:
>
> Hi everyone
>
> I'd agree with this. I'm looking at DPOP as an alternative and ultimately
> simpler way to accomplish what we can already do with MTLS-bound Access
> Tokens, for use cases such as the ones we address in Open Banking;
11 matches
Mail list logo
