I'd be okay with that as a way forward. Frankly, of course, I'd prefer to see draft-campbell-oauth-sts as the starting point with Mike and the other draft-jones-oauth-token-exchange authors added as co-authors. Regardless, there are elements from both that likely need to end up in the final work so a consolidation of authors and concepts makes sense.
And yes, there are lots of details that the working group will need to decide on going forward that we shouldn't get hung up on right now. Though I believe that deciding if the token endpoint is used for general token exchange is an important philosophical question that should be answered first. If the token endpoint is to be used, I strongly belie that this token exchange should leverage and work within the constructs provided and defined by OAuth. That's the direction I took with draft-campbell-oauth-sts and yes that involves overloading the access_token response parameter with something that's not always strictly an access token. The existing token endpoint request/response are already rather close to what one might expect in an STS type exchange. I find there's a nice elegant simplicity to it but I also see where that discomfort might come from. If there's consensus to not use/overload the existing stuff, I think it'd be much more appropriate to define a new endpoint. A lot of syntactic stuff likely falls out from that decision.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
