OTTO – Open.Trust.Taxonomy.Operators – For Federation
Open Trust Taxonomy Operators
Thursday 4F Convener: Mike Schwartz
Notes-taker(s): Paul Hethmon
Tags for the session - technology discussed/ideas considered:
technology discussed/ideas considered: oauth token federation
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
https://github.com/token-7/token7-specs/blob/master/draft-token7-oauth-token-based-federation-01.txt
Review of “draft-token7-oauth-token-based-federation-01.txt”
Some possible issues with binding a token to the TLS session (and reusing elsewhere)
Feedback given to draft author:
one concern is that this proposed draft is trying to overload the access token, i.e. pass the authorization grant to RS2. One of the advantages of the grant is that you have authenticated the client. And in your diagram, RS2 is not authenticated if you were binding the token (AT1) to a TLS session, AS1 would not accept the token from RS1
In general shipping around the bearer token is problematic. Maybe the policy should simply give access to RS1 to call the API of RS2.
We discussed: https://github.com/token-7/token7-specs/blob/master/draft-token7-oauth-token-based-federation-01.txt
Here was the feedback we sent back to Igor:
- One concern is that this proposed draft is trying to overload the access token, i.e. pass the authorization grant to RS2.
- One of the advantages of the grant is that you have authenticated the client. And in your diagram, RS2 is not authenticated.
- If you were binding the token (AT1) to a TLS session, AS1 would not be accept the token from RS1.
In general, shipping around the bearer token is problematic.
Maybe the policy should just simply give access to RS1 to call the API of RS2.
Igor's response, why not use:
https://tools.ietf.org/html/draft-richer-oauth-chain-00
https://tools.ietf.org/html/draft-hunt-oauth-chain-01
"Yes, I’ve read both of these drafts. They presume that your resource server is registered/authenticated at your own AS and at all federated ASs. From a purely practical point of view, this is improper for token-based dynamic/automatic federation. I tried to avoid cross domain resource server and client registration/authentication."
