> > "Dynamically declaring," in what sense? Where are those mechanisms > documented?**** > > ** ** > > Many of them are documented in draft-ietf-oauth-dyn-reg.**** > > ** ** > > One profile (an outer doll J) that enables fully interoperable > implementations is documented in draft-hardjono-oauth-umacore. > > ...
> Another related profile that enables fully interoperable implementations > is documented in http://openid.net/specs/openid-connect-messages-1_0.html. > > It's possible, then, that this isn't an issue of major changes needed in this document, but one of document ordering. It's possible (I'm still not sure, but maybe) that if some of these other documents came out before or at the same time as this one, they would all fit together and all would be clear. So maybe that's one way through this. In the end, all I'm saying is that if I hear that everyone is using oauth to peel bananas, and I want put my banana-peeling application on the market by adding oauth to it, I need to be able to read a set of specs that say how to do that, and that's all. And if I do that, my application will work when it's slotted into any oauth-based banana-peeling system. Barry
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
