Kristoffer,
I assume you mean an interface between the authorization server and the
resource server. If so, I believe it definitely merits a serious
discussion, and I support the idea in principle.
On this subject, I think we need even more work defining the token and
linking it to the resource owner. Today's discussion between Eran and
Phil once again made me think of insufficiency of the "opaque tokens."
Indeed, anything that comes with the OAuth flow is an OAuth token. (From
the security point of view, of course, that also means that anything
that can be INSERTED into an OAuth flow will be an OAuth token...) I am
not criticizing the design decisions--I have agreed with all of them.
But going forward, I would like the resource owner, the end user (both
human and virtual) to 1) issue tokens or 2) outsource this work it it
wishes. In the latter case, the resource owner must at least understand
what the token has rather than just pass the token.
Ideally, I would like this to be an OAuth work item: OAuth WG works very
well, and it has gathered the best people to judge the task. I
understand though that token specification is not presently in the
charter, and therefore it can be discussed only in the context of
changing the charter. And so I first wrote this in response to the item
that you proposed, which I think is one step toward what I thought
should be done.
Igor
Kristoffer Gronowski wrote:
...
IMO there is one item missing and that is to create an optional formal
interface between the authorization server and the protected resource.
It could increase the productivity of creating the oauth protected web
services when the auth server can be treated as an off the shelf piece
of code.
Then it would be up to the auth server to also provide an number of
other extension like the discovery, token revocation and other.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
