On 02/19/2013 02:58 PM, John Bradley wrote: > Yes but that contradicts what Barry is appearing to ask for which is run time > interoperability, by profile or configuration.
I can tell you that I don't think Barry and I are asking for contradictory things. They are different, but not contradictory, and have the same goal (interop). I believe Barry would agree with that. Saying that field X is MTI can be entirely consistent with defining a protocol that allow for negotiating whether or not to use field X for example. So you seem to be starting from a false dichotomy. S. > > While having code available in libraries is generally a good thing, I agree. > That is likely not going to address all of Barry's issues. > > A number of us recommended that Assertions , JWT-assertions and SAML > assertions go ahead together because they are interrelated. The chairs > decided to send assertions on on it's own and it has been pushed back. > That is not especialy surprising, because it is not intended to be complete > and interoperable in a end to end system on its own. > > The question remains where to make what MTI. While it may be logical to > make SAML support MTI in SAML assertions should every library supporting > assertions have full SAML support even if the applications are only using JWT > assertions? > > Where I think Barry and I agree is that we need to look at a group of > documents that are intended to be used together for MTI rather than trying to > overload Assertions which is only a small part of the whole. > > So where we may disagree is if requiring libraries to have code that systems > don't use and is effectively dead, helps with overall interoperability or is > mostly theatre. > > I suspect it is a continuum in that having the RS256 algorithm available in > all the JWT assertion libraries lets applications using assertions choose to > use it, but that doesn't guarantee all applications will, or allow a client > to figure out if that algorithm is available for use. > > Hence my position that MTI without additional profiles/Discovery/negotiation > is interoperability theatre if you are pretending it will make arbitrary > OAuth deployments automatically work together. > > Regards > John B. > > On 2013-02-19, at 4:22 AM, SM <s...@resistor.net> wrote: > >> Hi John, >> At 12:54 18-02-2013, John Bradley wrote: >>> That is where we get into the area Stephen Farrell has been raising about >>> MTI not being required to deploy. >> >> The topic of mandatory to implement has been discussed previously in the >> working group. >> Stephen Farrell explained [1] what it meant. Barry Leiba explained what it >> meant. >> >> In my humble opinion a mandatory to implement feature is about having the >> code for the feature. If the code is out there it is easier to get what you >> want. >> >> Regards, >> -sm > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
