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
