Hi Brian, we should definitely take your work into account and I recall some other drafts on the same subject being published some time ago as well.
Adding more co-authors to this working group item makes a lot of sense to me. Ciao Hannes On 08/11/2014 04:42 PM, Brian Campbell wrote: > 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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth