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
