OK so act_as if not sent is implicitly the requestor perhaps authenticated by the endpoint in the normal OAuth way.
If the if the requestor is acting like a proxy as in the Token Agent case the act_as would indicate the identity of the client making the request to the Token Agent so that the resulting token can include that identity as the AZA. I think that logic holds together. In that case, if the resulting token is PoP, then the party identified by the act_as's public key would go in the resulting token. That may actually be reversed from the WS-Trust usage, but that is something else to dig into in the WG. I think working on this along side of the PoP drafts will help prevent possible conflicts and confusions. We should accept Mikes draft or both of these as a starting point. John B. On Aug 8, 2014, at 1:55 PM, Brian Campbell <bcampb...@pingidentity.com> wrote: > Absolutely agree that some examples are needed. There's a [[ TODO ]] in there > for it. I just hadn't gotten to it yet and wanted to get the I-D up before > the Aug 10 date that Hannes put out there. The example you outlined is a good > start, I think. > > Yes, code and refresh tokens would/could be valid tokens. A previously issued > access token might also be. JWT & SAML too. The last paragraph of > http://tools.ietf.org/html/draft-campbell-oauth-sts-00#section-1 attempts to > state that the scope of the doc is only the framework for exchange and that > the "syntax, semantics and security characteristics of the tokens themselves > (both those presented to the are explicitly out of scope." What constitutes > a valid token will depend on the deployment or additional profiling. > > "So how might sending an act_as token to the token endpoint as part of the > request impact the result." -> in general I was thinking it'd result in an > azp claim or something like that in the returned token. > > "Do you see the act_as interacting with PoP to limit who can present the > resulting token. " -> Quite possibly. Though, honestly, I don't yet have a > complete concept of how PoP works in conjunction with all this. > > "Is act_as simply duplicating the authentication portion of the current > assertion profile?" -> there is potential for duplication in some cases, yes. > But the motivation for act_as was to give additional flexibility by allowing > an additional party to be represented. Also to try and align with > draft-jones-oauth-token-exchange to the extent possible. I had toyed with the > idea of only having one inbound token for the subject and having the client > (relying on client authentication) be the actor. Then maybe a flag to > indicate if delegation vs impersonation is deserted in the returned token. > But it seemed like there was a need (things you'd said among others) for more > than two parties to be represented. There's some refinement to be done for > sure though. > > "Not having concrete answers at this point is not a problem, but we do need > to think all of this through." -> agree > > "I think this document is also useful input." -> thanks >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
