An RS is not considered an OAuth 2 client, though there’s enough overlap in the structure that I know several implementations that store RS records in the same table as the client records with a special flag set on them to differentiate.
The RS <-> AS communication channel has never really gotten a formal definition in OAuth 2. The closest we’ve come is Token Introspection, which is RFC7662, and even there we didn’t define a set of authentication and discovery mechanisms. Instead, we piggybacked off of the token endpoint. This has proven to be problematic in practice and has lead to an explosion of the kind of additional metadata fields like you list below. — Justin > On Jul 20, 2020, at 4:23 PM, Tangui Le Pense > <[email protected]> wrote: > > Hello, > > A few late remarks and questions about this version of the draft. Sorry if it > was already answered, but I haven't found answers in the previous emails. > > Section 2.1: in case the JWT is signed then encrypted, which jwt should > include the "typ" parameter with the "at+jwt" value? The outer encrypted JWT > (JWE), the inner signed JWT (JWS) or both? > > Section 3: the example is missing the "iat" and "jti" fields that are > mandatory per section 2.2: > > {"typ":"at+JWT","alg":"RS256","kid":"RjEwOwOA"} > { > "iss": "https://authorization-server.example.com/";, > "sub": " 5ba552d67", > "aud": "https://rs.example.com/";, > "exp": 1544645174, > "client_id": "s6BhdRkqt3_", > "scope": "openid profile reademail" > } > > Section 4 "Validating JWT Access Tokens": > > o If the JWT access token is encrypted, decrypt it using the keys > and algorithms that the resource server specified during > registration. If encryption was negotiated with the authorization > server at registration time and the incoming JWT access token is > not encrypted, the resource server SHOULD reject it. > > The registration details are not documented. As an RS seems to be a special > case of an OAuth2 client (without any grant type granted, except, possibily, > "client_credentials") I was expecting registration of dynamic client > registration metadata similar to those for ID tokens (something like > "access_token_signed_response_alg", "access_token_encrypted_response_alg" and > "access_token_encrypted_response_enc"), and same for discovery metadata. > > Is the rationale for the absence of the registration of these fields that > RSes are not considered as OAuth2 clients? > > Also, in the same section, nothing is said about the validation of "iat" and > "jti". > > Regards, > > -- > > Tangui > > > 27.04.2020 21:27, [email protected] пишет: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Web Authorization Protocol WG of the IETF. >> >> Title : JSON Web Token (JWT) Profile for OAuth 2.0 Access >> Tokens >> Author : Vittorio Bertocci >> Filename : draft-ietf-oauth-access-token-jwt-07.txt >> Pages : 19 >> Date : 2020-04-27 >> >> Abstract: >> This specification defines a profile for issuing OAuth 2.0 access >> tokens in JSON web token (JWT) format. Authorization servers and >> resource servers from different vendors can leverage this profile to >> issue and consume access tokens in interoperable manner. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-07 >> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-07 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-access-token-jwt-07 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
