Re: [OAUTH-WG] self-issued access tokens

[[e-mail]]

Thanks Dick,

Our use case is basically the option 2. There is only one RS. So, to simplify
the architecture, we want to omit the round-trip of getting an access token from
AS.

I agree with your idea of using JWTs to convey client's signature. So my
original question was if there was a standardized profile of a JWT for that
purpose. From the responses to this thread so far, I think the answer is no.


Thanks for comment, David,

Yeah, maybe it's wise to have AS anyway for better extensibility.


Toshio Ito

From: David Waite <[e-mail]>
Sent: Saturday, October 2, 2021 6:04 AM
To: Dick Hardt <[e-mail]>
Cc: ito toshio(伊藤 俊夫 ○ＲＤＣ□ＩＴ研○ＣＮＬ) <[e-mail]>; [e-mail]
Subject: Re: [OAUTH-WG] self-issued access tokens




On Oct 1, 2021, at 11:06 AM, Dick Hardt <[e-mail]<mailto:[e-mail]>> wrote:
<snip>

If there is really only one service, then there is little value in an AS. I would have the client post a JWT that has the request payload in it, or a detached signature if it is a large payload. Personally, I like sending the request as a JWT as it allows services further down the processing pipeline to independently verify the request from the client.

This assumes sufficient computing power on the IoT device, and reasonably low call volume.
[イメージは差出人によって削除されました。]ᐧ

One interpretation of the purpose in the AS is to create tokens based on its authorization decisions, while direct submission of client-authored JWTs would be more in line with having the RS make those decisions directly.

Even if they were hosted on the same hardware, I’d still push to use an AS-role component in order to optimize the decision making process and to not have to refactor (or risk duplication) of that logic later.

-DW