Orie, many thanks for the dump on metadata, I understand now the motive.
If we keep it simple and just say a metadata Discover proposal for specific
technologies there can be different proposals or the WG can make the call on
which one is the one that they want to work on. We can also have an
(a few days later than promised) the name has been updated and the new
draft revision published
https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/01/. A
listing of other changes copied from
https://www.ietf.org/archive/id/draft-ietf-oauth-identity-chaining-01.html#appendix-D-2
is
It sounds like they are violating the spec then. On the other hand, the fact
that the scope can be "increased back to the original scope" maybe suggests the
effective scope of the refresh token is still the same? Either way, the spec is
pretty clear, regardless of what some vendor does.
--
Sachin,
Why does it matter what Curity does here? Is the question about what should
happen according to the specification or whether or not Curity is compliant
with the spec when it comes to refresh tokens?
- Warren
On Tue, Feb 20, 2024 at 8:27 PM Sachin Mamoru
wrote:
> Hi Neil,
>
> Thanks
Hi Neil,
Thanks for the clarification.
But Curity has a different approach and they implemented it according to
the concept of narrowing down the refresh token scopes.
"The scope was originally read openid profile and after refresh the access
was reduced to read profile (i.e., the access_token
Orie, that is a very helpful write up. I believe that the "metadata
discovery document" is something related to a key use case that pops up
over and over again, and that we should keep it in scope.
Mike Prorock
CTO, Founder
https://mesur.io/
On Tue, Feb 20, 2024 at 11:18 AM Orie Steele
Thank you for making this so clear, and easy to review.
I'd like to unpack some of the intention behind the "metadata discovery"
deliverable, and hopefully this commentary will help others chime in, on if
it should be cut from scope.
The original intention was to generalize this capability from
On 2024-02-20, at 17:19, Orie Steele wrote:
>
> application/vc+ld+json - https
> application/vp+ld+json - https
>
> application/vc+ld+json+jwt - ht
> application/vp+ld+json+jwt - ht
>
> application/vc+ld+json+sd-jwt -
> application/vp+ld+json+sd-jwt -
>
> application/vc+ld+json+cose - h
>
Introduction
Digital credentials are essential to identity, authorization, licenses,
certificates, and digitization use cases that are part of modernization efforts
targeting efficiency and transparency.
A digital credential expresses claims or attributes about a subject, such as
their name
On 20 Feb 2024, at 11:02, Sachin Mamoru wrote:Hi Neil,Does that mean it should be identical to the narrowed scope request or the original request scope?It says it has to be identical to the scope of the existing refresh token in the request, not the scope specified in the request. So effectively
See the following PR related to registrations of media types that rely on
multiple structured suffixes, for example:
application/foo+bar+cose would require `+bar+cose` , `+cose`
application/foo+bar+jwt would require `+bar+jwt`, `+bar+jwt`
application/foo+bar+sd-jwt would require `+bar+sd-jwt`,
Hi Neil,
Does that mean it should be identical to the narrowed scope request or the
original request scope?
On Tue, 20 Feb 2024 at 16:31, Sachin Mamoru wrote:
>
>
> On Tue, 20 Feb 2024 at 12:23, Neil Madden wrote:
>
>>
>> On 20 Feb 2024, at 06:44, Sachin Mamoru wrote:
>>
>>
>> Hi All,
>>
On Tue, 20 Feb 2024 at 12:23, Neil Madden wrote:
>
> On 20 Feb 2024, at 06:44, Sachin Mamoru wrote:
>
>
> Hi All,
>
> When we request an access token using 3 scopes (scope1, scope2, scope3).
>
> Then will receive a refresh token (refresh_token1) with the access token.
>
> After that will
Hi Sachin,
When the authorization server returns a new refresh token as part of refreshing
an access token, then the new refresh token MUST have the same scope as the
original “old” refresh token (independent from the value of the scope request
parameter, e.g. it does not matter whether the
14 matches
Mail list logo
