Sorry I did not intend to imply that what Barry is asking for is contradictory to MTI, only that it is different enough that it may require more than MTI of the existing features. As stated in the second line of the message.
I think we need to get down to discussing specific changes. John B. On 2013-02-19, at 12:15 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > > 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 >>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
