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

[[e-mail]]

Thanks Dick,

I understand. If the protocol flow is closed within our system, there is little
value in standardization.

Maybe what I really need is not exactly a standard about self-issued access
tokens. Rather, I look for recommendations, best practice documents or
implementations about it. If it were such things, we could just reuse that and
apply to our system.


Toshio Ito

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

Toshio, unless your system needs to interoperate with third party systems, I don't see the value in a standardized JWT. The JWT standard provides a standard token format. What you put in the payload is application specific.

You can do a separation of concerns behind your API endpoint for validating the JWT. If it were me, I would not set up an AS. You won't have to set up the endpoint and the extra call in your client.

On Sun, Oct 3, 2021 at 7:26 PM <[e-mail]<mailto:[e-mail]>> wrote:
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]<mailto:[e-mail]>>
Sent: Saturday, October 2, 2021 6:04 AM
To: Dick Hardt <[e-mail]<mailto:[e-mail]>>
Cc: ito toshio(伊藤 俊夫 ○ＲＤＣ□ＩＴ研○ＣＮＬ) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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

[イメージは差出人によって削除されました。]ᐧ