Support of different types of tokens is not clear

[alextok]

We need to define how different type of credentials will be delivered to the servers. The current spec defines "authorization" as , but what should we send if it is an "id_token", or "access token", or custom token. What is a plan to support other credential types?

Plan A: "authorization" : <authorization_code | id_token | access_token|custom_token >

Plan B: "authorization" : "id_token": "access_token": "custom_token":

[arnar]

I think the particular type or semantics of those tokens don't need to be relevant to dbsc.

We could clarify that this should not be confused with authorization tokens in eg OAuth2 - the only meaning of the authorization parameter is that the browser will set it as an Authorization: Bearer ... header on the registration call to the endpoint.

The motivation for this was twofold:

1. It allows passing a bearer token for the server to link registration with some preceding sign in flow without relying on cookies.

2. It may fit some existing oauth-modeled infrastructure, where a one time authz token can be used here, a refresh token as the session id, and access tokens as the short term cookies.

But if a website wants to use other tokens (including bespoke non-standard ones), as long as they accept them in the Authorization header, they should be able to just do so.

[kmonsen]

Updated the explainer with Arnar's explanation here: https://github.com/WICG/dbsc/commit/d23e52de33089ec027906c3007202e749886ebae

[alextok]

In OAuth RFC there is a term "authorization code" but there is no term "authorization token". Hence, I would remove:

The authorization code is not an authorization token

I would change this one:

a one time authz token to: a one-time authorization code

I would remove refresh token, as it may be an arguable statement (depends upon background):

a refresh token as the session id

My version:

The authorization code is optional and will be sent in the registration JWT if present. The authorization parameter is that the browser will set it in the JWT on the registration call to the endpoint. This allows passing a bearer token for the server to link registration with some preceding sign in flow without relying on cookies, or it may fit some existing OAuth-modeled infrastructure, where a one-time authorization code, an access token or id token can be used here for authentication. If a website wants to use other tokens (including bespoke non-standard ones), as long as they accept them in the Authorization header, they should be able to just do so.

[kmonsen]

Updated here: https://github.com/WICG/dbsc/commit/6b39658120b6c55edbb6eead702140a262f7f67f

[arnar]

I added the value back as the authorization header in 00141ce, as this is the main point that can help integrate with existing infra. I agree it should be included in the JWT as well though for integrity, hence it appears in both places now.

I also changed some of the language to clarify.

Please reopen this issue if you have comments on that change.