FYI, this is exactly what we are doing in [1] to manage Verifiable Credentials using OAuth2.0. The AS issues a verifiable credential that stays (for long time) in the client. The client uses DPoP to prove ownership of the credential. We just started a new project funded by essif [2] that will further develop this idea and provide implementations.
Best, Nikos [1] N. Fotiou, V.A. Siris, G.C. Polyzos, "Capability-based access control for multi-tenant systems using Oauth 2.0 and Verifiable Credentials," Proc. 30th International Conference on Computer Communications and Networks (ICCCN), Athens, Greece, July 2021 (https://mm.aueb.gr/publications/0a8b37c5-c814-4056-88a7-19556221728c.pdf) [2]https://essif-lab.eu -- Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou Researcher - Mobile Multimedia Laboratory Athens University of Economics and Business https://mm.aueb.gr > On 29 Sep 2021, at 6:42 PM, Daniel Fett <[email protected]> wrote: > > That very much sounds like a static string as the access token plus DPoP. > > -Daniel > > Am 29.09.21 um 03:54 schrieb [email protected]: >> Hi OAuth folks, >> >> I have a question. Is there (or was there) any standardizing effort for >> "self-issued access tokens"? >> >> Self-issued access tokens are mentioned in a blog post by P. Siriwardena in >> 2014 >> [*1]. It's an Access Token issued by the Client and sent to the Resource >> Server. >> The token is basically a signed document (e.g. JWT) by the private key of the >> Client. The Resource Server verifies the token with the public key, which is >> provisioned in the RS in advance. >> >> I think self-issued access tokens are handy replacement for Client >> Credentials >> Grant flow in simple deployments, where it's not so necessary to separate AS >> and >> RS. In fact, Google supports this type of authentication for some services >> [*2][*3]. I'm wondering if there are any other services supporting >> self-signed >> access tokens. >> >> Any comments are welcome. >> >> [*1]: >> https://wso2.com/library/blog-post/2014/10/blog-post-self-issued-access-tokens/ >> >> [*2]: >> https://developers.google.com/identity/protocols/oauth2/service-account#jwt-auth >> >> [*3]: >> https://google.aip.dev/auth/4111 >> >> >> ------------- >> Toshio Ito >> Research and Development Center >> Toshiba Corporation >> >> >> >> _______________________________________________ >> OAuth mailing list >> >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > > > -- > > https://danielfett.de > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
