Re: [OAUTH-WG] Listing OAuth Access Token Metadata

Thank you all for the quick replies and I really appreciate the
suggestions.

One thing that I want to clarify is that, in this use case, the requirement
is to list all the access tokens (metadata) (that belong to a single owner)
issued for the custom grant but in the introspection specification only
metadata can be listed for a given access token.

Here, we need PATs rather than a standard OAuth grant type because the
token should be issued to a user (not a client) and the user will use this
token to access certain APIs through another third-party application (which
could be a simple automation script). And also, there are some attributes
like alias and description that should be stored with the PAT as they are
required for token identification purposes (Those attributes are not common
with other standard OAuth grant types).  Furthermore, the user should be
able to revoke any of his PATs at any time.

In the ID token suggestion, it is mentioned to look into OIDC ID token
specification. Does it imply that an ID token should be used as a Personal
Access Token, instead of an OAuth2 access token, or is it proposed to
extract user information?

Thank You.
Kind Regards,

Dhaura Pathirana

On Mon, 4 Apr 2022 at 00:13, Warren Parad <wparad@rhosys.ch> wrote:

> I'm tempted to say user created PATs are incompatible with OAuth, and
> OAuth already has a solution which avoids the user having to manually
> create these sorts of tokens. Is there a reason OAuth wouldn't be able to
> handle the specific use case.
>
> Warren Parad
>
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement
> Authress <https://authress.io/>.
>
>
> On Sun, Apr 3, 2022 at 7:56 PM Takahiko Kawasaki <taka@authlete.com>
> wrote:
>
>> Dear Dhaura,
>>
>> My recommendation to you (undergraduate? LinkedIn says so) is to
>> investigate the following as the first step.
>>
>>
>>    - ID Token (OpenID Connect Core 1.0, Section 2)
>>    - UserInfo Endpoint (OpenID Connect Core 1.0, Section 5.3)
>>
>>
>> In general, inventing a new grant type should be the last resort.
>>
>> Best Regards,
>> Takahiko Kawasaki
>>
>>
>> On Sun, Apr 3, 2022 at 3:35 PM David Waite <david=
>> 40alkaline-solutions.com@dmarc.ietf.org> wrote:
>>
>>>
>>> On Apr 1, 2022, at 3:24 AM, Dhaura Pathirana <dhaurapathirana@gmail.com>
>>> wrote:
>>>
>>> I would like to know if anyone has seen this (listing token metadata) as
>>> a common use case in OAuth2 and a standard way of doing it had been
>>> proposed before?
>>>
>>>
>>> OAuth Token Introspection (RFC 7662) defines a way to query for active
>>> state and meta-info.
>>>
>>> However, its use is defined only for protected resources, and not the
>>> resource owner or the client the token was issued to.
>>>
>>> -DW
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>