I largely agree with Mike, that assertions are going to be used in a number of places that have different naming conventions.
Is what Barry looking for a specific profile for how it would be used with the token endpoint to authenticate a OAuth confidential client to a token endpoint in the OAuth Code flow? I can see having specifics for particular protocols using assertions for them to accede interop. The debate on that is if that should be in the assertions spec , the JWT assertions spec, the SAML assertions spec or some other document. Unless we get down to some specifics I feed we will talk this in circles. In Connect we did profile it for the code flow use-case. To do that interoperable algorithms and some other things needed to be specified. It may be useful to look at several ways people intend to use these profiles to add perspective to the discussion. John B. On 2013-02-17, at 6:56 PM, Mike Jones <michael.jo...@microsoft.com> wrote: > Hi Stephen, > > I disagree with you that I didn't discuss address interop in my note below. > I stated that applications built with these specifications can and should be > interoperable, but that profiling is (and should be) required to achieve > completely interoperable implementations of these specifications. > > The contents of an assertion used for different applications will, of > necessity, have some differences between them, because they're specific to > the needs of the application. If we mandate an MTI profile that meets the > needs of one application of assertions, we will have rendered the > specifications less useful (or unusable) to other applications. Otherwise > (while you may not find analogies useful), it's like declaring that TFTP be > an MTI application for all UDP implementations, in order to achieve > interoperability. > > I think it would be useful if we focused the discussion on the merits and > downsides of specific possible changes to increase interop. For instance, > the Audience field (by design) can contain different kinds of things when > used by different applications. > > Barry, are you proposing that we require that the Audience contain a specific > data format tailored to a particular application of assertions? If so, what > format are you proposing, and for which application of assertions? Likewise, > are you proposing that the Subject field contain a particular data format > tailored to a particular application? And also the Issuer field? > > To be clear, the Subject, Issuer, and Audience fields are those that require > profiling to achieve full interop. Is there a concrete proposal that the > specs limit the values of those fields in a particular way? (That would > achieve interop without profiling, but would severely limit the applicability > of the specs.) > > Is there some third way that I'm missing? > > -- Mike > > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] > Sent: Sunday, February 17, 2013 1:25 PM > To: Mike Jones > Cc: oauth@ietf.org; Barry Leiba; oauth-cha...@tools.ietf.org > Subject: Re: [OAUTH-WG] oauth assertions plan > > > Hi Mike, > > On 02/17/2013 08:41 PM, Mike Jones wrote: >> I've been thinking about Barry's DISCUSS for a bit. No one else has >> responded yet, so I guess I'll jump in and share my perspective. >> >> As I see it, the OAuth Assertions spec, the SAML Assertion Profile, and the >> JWT Assertion Profile are tools used for building applications - not >> applications themselves. As such, there will and should be fields whose >> precise syntax and interpretation is left up to the applications building >> built with them. Applications can and should be interoperable. Tools >> require profiling to achieve interoperability. This isn't a bug. It's a >> feature, as it means that the tool can be used in many different >> applications. > > Declaring something a feature or bug may be in the eye of the beholder. But > the discuss is about interop and you don't address that. > > Please bear in mind that being able to interop (the goal here) does not mean > that field foo MUST have value type bar but that implementations MUST have > the code for handing value type bar. > I see no argument in your mail addressing that. > > These specs might also be useful tools in a toolbox but that is beside the > point of this DISCUSSion. > >> Let's consider the Audience field as an illustrative example. For some >> applications, the Audience field will be the Client ID of an OAuth Client. >> For some applications, the Audience field will be the URI of an endpoint >> that the flow is redirected to. For some applications, the Audience field >> will be an abstract identifier associated with a group of participating >> parties, for instance, it might be a URN such as >> urn:incommon:federation-members. All of these are valid uses of the >> Audience field. If any of them were made mandatory values, it would break >> all the other applications, because those values aren't applicable or useful >> in the other applications. >> >> I'll close with an analogy. The UDP protocol is a tool. The TCP protocol >> is a tool. They were standardized as RFCs 768 and 793 without MTI port >> values or applications. They could have required that TFTP and Telnet also >> be implemented to ensure interoperable implementations of UDP and TCP, but >> they did not. Just like the situation with the OAuth Assertions specs, this >> wasn't a bug - it was a feature. > > One cannot draw any conclusion from analogies and I don't think they help > this discussion. > >> I'd therefore request that you withdraw the DISCUSS on that basis, Barry. > > I'd be surprised, but Barry's able to speak for himself. I think the WG need > to address the topic of the discuss and not try to say that interop isn't > important. In this venue, it is. > >> I'd be glad to talk with you more about this either via e-mail or by phone. >> I'm looking forward to a useful and productive discussion. > > Email discussion on this list is where this should mostly happen I think now > that the draft is back with the WG. > > Cheers, > S. > > >> Cheers, >> -- Mike >> >> P.S. RFC 768 is amazingly short! Have a look at it again, if you haven't >> read it in a while. Good things really can come in small packages! >> >> -----Original Message----- >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >> Of Stephen Farrell >> Sent: Sunday, February 17, 2013 11:25 AM >> To: oauth@ietf.org >> Cc: Barry Leiba; oauth-cha...@tools.ietf.org >> Subject: [OAUTH-WG] oauth assertions plan >> >> >> Hi all, >> >> The OAuth assertion document has received DISCUSSes as you can see from the >> data tracker at [1]. I've been chatting with the chairs and the ADs with >> those DISCUSSes in the last few days. >> >> The main concern is that these documents do not sufficiently specify >> the functionality that is needed (MTI) in order to develop an >> interoperable implementation. This concern is, unfortunately, also >> applicable to the two assertion instance documents, the JWT >> (draft-ietf-oauth-jwt-bearer) and the SAML >> (draft-ietf-oauth-saml2-bearer) documents. >> >> I've therefore decided to send the assertion document back to the >> working group and to recommend to the group to resubmit them for >> publication once these blocking DISCUSSes have been addressed >> satisfactory. I think this will need some consideration of both the >> assertions framework and the saml/jwt drafts. (Probably submitting two >> or three of those at once makes better sense >> anyway.) >> >> To help resolve this we're planning to meet at lunch time on the Monday of >> the IETF just before the oauth session. The goal of that chat is to try to >> figure out what'll need doing to get these documents ready, so that that >> plan can be presented as a semi-worked out proposal at the oauth session >> later that day. >> I'd like to have the document editors/authors, chairs and discussing ADs >> there if possible. (I'll send details.) If someone else really needs to be >> there, let me know but I think starting with the smaller group will be more >> tractable. If everyone thinks we need to just work it out at the WG session >> that's fine and we can skip the lunchtime meeting, but I'd say we're likely >> to end up in the same place but take longer. >> >> However, if this can be sorted on the list beforehand that's much >> better of course, so please do try to do that starting now. (That is, >> let's not start by quibbling about process and lunchtime meetings but >> by discussing the DISCUSSes:-) >> >> Regards, >> Stephen. >> >> [1] http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ballot/. >> >> _______________________________________________ >> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
