Hi Mike, I guess we are on the same page with regard to discovery/negotiation. I do not care so much how it is implemented as long it is there.
While certain libraries may implement everything I don't think it is reasonable to assume that every deployment will have every functionality implemented. I would be super surprised. Even on a server with enough storage this is not a viable option. On constrained devices this is certainly not possible and our story cannot be built on such an assumption. Ciao hannes On Dec 8, 2011, at 5:08 PM, Michael Thomas wrote: > On 12/08/2011 06:18 AM, Hannes Tschofenig wrote: >> 3) We want the ability for algorithm negotiation/discovery, at least up to a >> certain degree. For example, it would would nice if a client talks to a >> server and they both implement TLS 1.2 then they actually use it. The >> requirement for crypto-agility fits in here as well. >> > > I don't think that certain degree even needs to be all that > complicated. Suppose that in the future there exists a kitchen > sink liboauth which is widely available. As a service provider, > all I really care is that the client can interoperate with > me. So suppose I just generate a sdk that looks like this: > > client--->MyServiceShim->liboauth ---------- liboauth->MyserviceShim--->server > > No need for discovery or anything like that: it's baked into the > shim which I make available for all the usual suspect language > bindings. And it's still a better situation for the service provider > because they don't have to maintain liboauth... the shim becomes > nothing more than a the set of policy decisions that turn the > right knobs in the underlying library. > > So did the MTI buy us anything in this -- rather likely -- scenario? > No. Whoever builds liboauth is almost by definition going to be > silent about winners and losers -- it's job is to implement everything, > not take sides. > > Mike _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
