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.
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.
I'd therefore request that you withdraw the DISCUSS on that basis, Barry.
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.
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: [email protected] [mailto:[email protected]] On Behalf Of
Stephen Farrell
Sent: Sunday, February 17, 2013 11:25 AM
To: [email protected]
Cc: Barry Leiba; [email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
