+1 for adoption
Matt
On Mon, Jan 6, 2020 at 9:38 PM Rifaat Shekh-Yusef
wrote:
> All,
>
> This is a call for adoption for the *OAuth 2.0 Rich Authorization
> Requests* document.
> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/
>
> Please, let us know if you support or object to th
John, thanks, much appreciated!
On 11/01/2020 21:36, John Bradley wrote:
>
> Yes JAR is not prohibiting paramater replication in the header.
>
> I will see if i can add something in final edits to call that out.
>
> John B.
>
> On 1/11/2020 6:16 AM, Vladimir Dzhuvinov wrote:
>>
>> Thanks Mike for
Hi all,
at the Singapore IETF meeting we talked about setting time aside for discussing
proof-of-possession tokens.
To schedule a call we put a Doodle poll together:
https://doodle.com/poll/sqhbeeg6knp435ag
Please let us know by the end of the week what dates work for you.
Ciao
Hannes & Rifaat
To be clear, I’m not saying we suggest a particular form, and I agree that we
shouldn’t specify that “it’s a JWT” or something of that nature. But if we call
the result of PAR “thing X” and the target of request_uri “thing X” in JAR,
then we’re compatible without saying what “thing X” needs to b
+1
On Mon, Jan 13, 2020, 4:15 PM Richard Backman, Annabelle wrote:
> My original suggestion was to remove this requirement from cases where the
> AS originally provided the request_uri, because in these cases, the
> request_uri resolution becomes an internal implementation detail of the AS.
> I
Torsten / Justin / Brian
In my reading of the ID, it appears that there is a request for just one
access token, and the authorization_details array lists one or more
resources that the one access token will provide access to. Correct?
I have heard anecdotally that there is interest in granting ac
3/4 options are at the same time on the same day of the week. More options
would be nice!
On Mon, Jan 13, 2020 at 9:19 AM Hannes Tschofenig
wrote:
> Hi all,
>
>
>
> at the Singapore IETF meeting we talked about setting time aside for
> discussing proof-of-possession tokens.
>
>
>
> To schedule a
Please don’t use RAR as a pandora’s box to introduce unrelated new semantics,
including issuing multiple access tokens.
-- Mike
From: OAuth On Behalf Of Dick Hardt
Sent: Monday, January 13, 2020 5:32 PM
To: Torsten Lodderstedt ; Brian Campb
Multiple access tokens are outside the scope of RAR. The request is intended to
describe the access for a single returned access token. If semantics for
multiple access tokens are agreed upon, then it can use the RAR structure, the
Resources parameter, and the Scope parameter all in parallel aga
I would rather see extensions define a key ID than a new key set URI. Otherwise
what’s the point of having more than one key in the set, with unique
identifiers?
It would’ve been nice if JWK could’ve agreed on a URL-based addressing format
for individual keys within the set, but that ship’s sai
Right now, Okta publishes two keys at the jwks_uri in order to be able to
rotate keys periodically. During the token lifetime window during key
rotation, the RSs can still find both the old and new key IDs in the set.
RSs are looking for a specific key ID when they do this, so it would be
fine to
On Mon, Jan 13, 2020 at 12:32:41PM -0500, Justin Richer wrote:
> To be clear, I’m not saying we suggest a particular form, and I agree that we
> shouldn’t specify that “it’s a JWT” or something of that nature. But if we
> call the result of PAR “thing X” and the target of request_uri “thing X” in
That’s what I thought. Thanks for the clarification.
On Mon, Jan 13, 2020 at 6:20 PM Justin Richer wrote:
> Multiple access tokens are outside the scope of RAR. The request is
> intended to describe the access for a single returned access token. If
> semantics for multiple access tokens are agre
13 matches
Mail list logo
