I’ve submitted my draft of XYZ as an ID:
https://tools.ietf.org/html/draft-richer-transactional-authz-00
— Justin
On May 6, 2019, at 3:43 PM, Justin Richer
mailto:jric...@mit.edu>> wrote:
In a vein related to Torsten’s recent thread and blog post, I’ve also been
working on a proposal around T
For what it’s worth, if we think of things a little bit differently, we can
support both types of key presentation and possession proofs in parallel. My
thinking was that in both the MTLS and DPoP cases, the client proves that it
has access to a key and then uses that key with the RS in the same
This is not an easy question to answer, as resource servers in OAuth have never
really had a strong identity (or identifier) within the OAuth ecosystem. The
Resource Identifiers draft [1] tries to address this somewhat. In practice,
many resource servers are registered and stored as “clients” at
I agree with separating these concerns, but not quite with the description of
the goal of scopes. What a scope really represents, in my mind, is a shorthand
for a set of capabilities available at an API. This shorthand is baked into the
API and so needs to be useful across multiple clients and r
On the surface this is fine, but it hides an important detail: you need to have
a client registered with the system in order to make a token request, meaning
that the “dcr” token was issued to a different client than the one making the
registration request. So that just means that the developer
