Thanks for doing that. I think that this is clearer and extends Mike's draft to be more specific about input and output token types.
It is going to be hard for people to get their heads around this without at-least having some example use-cases and example token input and outputs. In following this proposed model would code and refresh tokens be considered valid on_behalf_of tokens? I am guessing that a JWT or SAML 2 assertion clearly can be. So if for example I wanted a JWT/id_token to use in the assertion flow at a SaaS I would send. aud = "an identifyer for the SaaS AS (perhaps the token endpoint or issuer uri) requested_security_token_type = urn:ietf:params:oauth:token-type:jwt (perhaps something more specific?) on_behalf_of = (refresh token?) on_behalf_of_token_type = urn:ietf:params:oauth:token-type:refresh (yes I just made that up) So how might sending an act_as token to the token endpoint as part of the request impact the result. Do you see the act_as interacting with PoP to limit who can present the resulting token. Is act_as simply duplicating the authentication portion of the current assertion profile? Not having concrete answers at this point is not a problem, but we do need to think all of this through. I think this document is also useful input. John B. On Aug 8, 2014, at 10:27 AM, Brian Campbell <bcampb...@pingidentity.com> wrote: > I am very much in favor of the WG pursuing the general concept of an OAuth > Token Exchange. However, I don't believe this document, in its current form > anyway, is the necessarily the most appropriate starting point as a WG work > item. > > I wrote up an I-D, which I'd ask to be considered as alternative or > additional input into the process: > https://datatracker.ietf.org/doc/draft-campbell-oauth-sts/ > > I don't intend this to be confrontational or "this is better than that" kind > of thing. Producing a draft just seemed like the most straightforward way to > document some initial thoughts on it. I'm more than open to collaborating on > it going forward. > > > > On Mon, Jul 28, 2014 at 11:33 AM, Hannes Tschofenig > <hannes.tschofe...@gmx.net> wrote: > Hi all, > > during the IETF #90 OAuth WG meeting, there was strong consensus in > adopting the "OAuth 2.0 Token Exchange" > (draft-jones-oauth-token-exchange-01.txt) specification as an OAuth WG > work item. > > We would now like to verify the outcome of this call for adoption on the > OAuth WG mailing list. Here is the link to the document: > http://datatracker.ietf.org/doc/draft-jones-oauth-token-exchange/ > > If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion > as to the suitability of adopting this document as a WG work item, > please send mail to the OAuth WG list indicating your opinion (Yes/No). > > The confirmation call for adoption will last until August 10, 2014. If > you have issues/edits/comments on the document, please send these > comments along to the list in your response to this Call for Adoption. > > Ciao > Hannes & Derek > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > > Brian Campbell > Distinquished Engineer > @ bcampb...@pingidentity.com > +1 720.317.2061 > Connect with us… > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
