Subject: [OAUTH-WG] oauth assertions plan

From: Stephen Farrell <[email-masked]>
Date: Sun, 17 Feb 2013 19:24:40 +0000

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/.

---

From: Mike Jones <[email-masked]>
Date: Sun, 17 Feb 2013 20:41:29 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Sunday, February 17, 2013 11:25 AM
To: [email-masked]
Cc: Barry Leiba; [email-masked]
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.

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 17 Feb 2013 21:25:25 +0000

Hi Mike,

> 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 sh…

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.

> 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…

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.

---

From: Mike Jones <[email-masked]>
Date: Sun, 17 Feb 2013 21:56:28 +0000

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:[email-masked]] 
Sent: Sunday, February 17, 2013 1:25 PM
To: Mike Jones
Cc: [email-masked]; Barry Leiba; [email-masked]
Subject: Re: [OAUTH-WG] oauth assertions plan

Hi Mike,

> 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 sh…

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.

> 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…

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.

> 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
> 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.)
> 
> 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.
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 18 Feb 2013 00:23:11 +0000

In some off-list mail between Mike and I, he said:

>> Was TCP a bad idea because it didn't have MTI port numbers?  Would
>> it have improved TCP to add an MTI port or two?

To which I responded:

> Ports are MTI for TCP. [1] They are 16 bit values
> with a well-defined test for equality and a little bit
> more structure/IANA stuff.

We agreed it'd be useful to bring this to the list since it
maybe captures the disconnect.

I'm not sure I quite get it but I think Mike means that no
particular port number (or the associated protocol) needs to
be listened for by all TCP stacks. That's correct, but nothing
to do with TCP interop.

Port numbers do need to be specified by all TCP packets or
those are malformed and all TCP stacks need to know how to
compare those and probably more subtleties but support for
port numbers is definitely not optional - its mandatory.

Cheers,
S.

[1] http://tools.ietf.org/html/rfc793#section-2.7

---

From: John Bradley <[email-masked]>
Date: Sun, 17 Feb 2013 22:19:43 -0300

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.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 18 Feb 2013 00:38:25 -0500

OK, I have some time to respond to this on a real computer.

Let's look at the general mechanism that oauth provides, using one use case:
A client asks an authorization server for authorization to do something.
The authorization server responds with an authorization token, which
the client is required to understand.

We have talked about three kinds of tokens: bearer tokens, MAC tokens,
and assertion tokens.
How does a client know what kind of token it will get from a
particular authorization server?
How does a server that supports multiple token types know what kind of
token it should give to a particular client?

Now, suppose that the server decides to give back an assertion:
How does the server know whether to give a SAML assertion or a JWT
assertion?  How does the client know which it's going to get?

And now you're saying that even if everyone knows they're going to get
an assertion token, and specifically a JWT assertion, the semantics of
particular fields in those tokens are undefined.  If you have
different meanings ("different kinds of things", as you've said) for
the Audience field, how is the server supposed to communicate which
meaning *it* is using?  How is there any assurance that a client will
understand it in the same way?

These are the sorts of things I'm concerned about, and this is what I
mean by saying that it's like a Ukrainian doll: you open the oauth
doll and find the token doll; you open the token doll and find the
assertions doll; you open the assertions doll and find the JWT doll;
you open the JWT doll and find the Audience field doll... at what
point do the dolls end and interoperablity begins?

I understand that you want certain things to be handled differently by
different applications, and I'm fine with that in principle.  But the
other part of the principle is that I have to be able to write an
application that interoperates with yours *purely by reading the
specs*.

If you do this by profiling, we need to get to a point where two
things are true: (1) the profile chain has ended, and what's left is
well defined, and (2) I have to be able to, *from the specs and the
protocol alone*, determine what profile will be used.  I don't see how
this protocol gives me any way to determine what to send or what to
expect to receive.  And if an out-of-band understanding is required
for that, that doesn't interoperate.

Now, the way we usually handle the need for "different kinds of
things" is to have different fields for each, or to have one field
tagged so that it's self-defining (as URIs have a scheme that says
what to do with them).  If the Audience field might look like this in
one application:
   urn:ietf:params:banana
...and like this in another
   abra:cadabra
...where the first is understood to be a URI and the second is
something else, then please explain how you and I can each write
applications to that?

For your specific questions:

> 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?

I am proposing that there must be a way for someone writing an
application to know what to use in these fields that will work with
your application (or will work with a server in the same way as your
application does, or whatever) *without* having to go to the
documentation of your application to figure it out.

That's why I say that as I see it, it's not an issue of MTI.  I'm not
saying that I want you to require that any particular thing be
implemented.  I'm saying that both sides need to be able to know which
variations *are* implemented.  How else do you get interoperability?

Your TCP/ports example is a perfect one to show how this works: the
assignments for port numbers are *exactly* to create the
interoperability I'm talking about here.  TCP doesn't say anything
about the protocol ("profile", perhaps) that's used over it.  But
we've defined that port 110 is used for POP and 143 is used for IMAP
and 25 is used for SMTP, and so on.  So I know that if my IMAP
application wants to talk with your IMAP server, I can accomplish that
by using port 143.  If you decide to run your IMAP server on port 142
instead, or if you run your POP server on port 143, we will not
interoperate.

But all I need to know is (1) how to do IMAP, (2) how to do it over
TCP, and (3) what port to use... and I can build an IMAP client that
will work with any IMAP server that follows the same specs.

Can you do that here?  Please explain how.

Barry

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 18 Feb 2013 09:44:03 +0000

Hi Barry,

I agree with you generally, but just on one point...

On 02/18/2013 05:38 AM, Barry Leiba wrote:
> That's why I say that as I see it, it's not an issue of MTI.  

I do think there is an issue related to MTI that's affecting
the discussion. Clearing up that issue won't by itself solve
the interop problem but is, I think, needed as a part of doing
that.

The issue is that it seems to me that not everyone is clear
that MTI != MUST-use.

If some field with some syntax is MTI that means that everyone
writing code has to be able to handle that field properly.

It does not mean that everyone has to use that syntax.

But if everyone's code supports handling that syntax, then
we do enable better interoperability.

So as you address Barry's good point, please do not
conflate MTI with MUST-use since they are not the same.

S.

PS: Just in case: MTI == "mandatory to implement"

---

From: John Bradley <[email-masked]>
Date: Mon, 18 Feb 2013 12:17:37 -0300

Barry,

I will point out that in RFC 6749 the Client is specificity not required to understand the access token, it is required to understand the token_type in the response from the authorization server in order to know how to present the token to the RS.

Perhaps you were speaking metaphorically though.

It seems like the scope of your criticism has more to do with RFC 6749 & RFC 6750 overall, than the assertions drafts themselves.

In OpenID Connect we implemented a discovery and registration layer for clients to discover what the Authorization server supports.  

Things like:
token_endpoint_auth_methods_supported  OPTIONAL.  JSON array
      containing a list of authentication types supported by this Token
      Endpoint.  The options are "client_secret_post",
      "client_secret_basic", "client_secret_jwt", and "private_key_jwt",
      as described in Section 2.2.1 of OpenID Connect Messages 1.0
      [OpenID.Messages].  Other authentication types may be defined by
      extension.  If unspecified or omitted, the default is
      "client_secret_basic" -- the HTTP Basic Authentication Scheme as
      specified in Section 2.3.1 of OAuth 2.0 [RFC6749].

token_endpoint_auth_signing_alg_values_supported  OPTIONAL.  JSON
      array containing a list of the JWS signing algorithms ("alg"
      values) supported by the Token Endpoint for the "private_key_jwt"
      and "client_secret_jwt" methods to encode the JWT [JWT].  Servers
      SHOULD support "RS256".

The client can then set in registration what auth method it intends to use to prevent downgrade attacks.
token_endpoint_auth_method  OPTIONAL.  Requested authentication
      method for the Token Endpoint.  The options are
      "client_secret_post", "client_secret_basic", "client_secret_jwt",
      and "private_key_jwt", as described in Section 2.2.1 of OpenID
      Connect Messages 1.0 [OpenID.Messages].  Other Authentication
      methods may be defined by extension.  If unspecified or omitted,
      the default is "client_secret_basic" HTTP Basic Authentication
      Scheme as specified in Section 2.3.1 of OAuth 2.0 [RFC6749].

To acceve real interoperability these things need to be profiled or you need a negotiation mechanism.

Are you saying that Assertions needs a low level mechanism to negotiate capabilities?   
Many will argue that specs at a higher level like like Dynamic Client Registration https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/ are better places to address these capability negotiations because as you point out there is more to be negotiated than just assertions.

In your message you are asking about how the server knows what format of assertion the client needs, I think you meant that to be how will a client know what format of assertion a token endpoint can accept.   It is the client that creates the assertion in the spec under discussion.   Signed SAML or JWS assertions from the AS to the RS are a whole separate issue.

It has been stated by one of the WG chairs that some of us are anti interoperability, so some of us may be a touch sensitive, around this, as it is not the case.

I am in-favour of interoperability, but not interoperability theatre. 

If there are specific improvements we can make to assertions then lets discuss them, without downloading all of OAuth's perceived interoperability issues on them.

I am also happy to engage in the broader discussion of how OAuth can use things like Discovery and dynamic registration to address some of the wider interop issues. 

I am happy to make time for that in Orlando if that works for people.

Regards
John B.

---

From: Mike Jones <[email-masked]>
Date: Mon, 18 Feb 2013 18:06:32 +0000

Hi Barry.  Thanks for your response.  I believe we share the same goals here (the "what").  Where I think we need to focus the discussion then is on the mechanisms to achieve that (the "how").  Let me fill in the details, as I see them, by responding to a few things you wrote:

If you do this by profiling, we need to get to a point where two things are true: (1) the profile chain has ended, and what's left is well defined, and (2) I have to be able to, *from the specs and the protocol alone*, determine what profile will be used.  I don't see how this protocol gives me any way to determine what to send or what to expect to receive.  And if an out-of-band understanding is required for that, that doesn't interoperate.

I completely agree with you that the profile chain has to end, with what's left being well-defined and that from the protocol specs alone, one can determine how to interoperate.

Now, the way we usually handle the need for "different kinds of things" is to have different fields for each, or to have one field tagged so that it's self-defining (as URIs have a scheme that says what to do with them).  If the Audience field might look like this in one application:

   urn:ietf:params:banana

   abra:cadabra

...where the first is understood to be a URI and the second is something else, then please explain how you and I can each write applications to that?

You can write applications to that by having the profile chain end, and with the contents of the Audience field being completely specified somewhere in the profile chain being used.  Also, I'll observe that we are using the "tagged field" approach that you mention in the assertions specs, using the defined tag values urn:ietf:params:oauth:grant-type:saml2-bearer, urn:ietf:params:oauth:client-assertion-type:saml2-bearer, urn:ietf:params:oauth:grant-type:jwt-bearer, and urn:ietf:params:oauth:client-assertion-type:jwt-bearer to declare the token type and use of that token type.  (The OpenID Connect profile also uses a "tagged field" which is an OAuth scope value of "openid" to dynamically declare to the OAuth implementation that the OpenID Connect profile is being used.  Other profiles may similarly indicate their usage through different scope values.)

I am proposing that there must be a way for someone writing an application to know what to use in these fields that will work with your application (or will work with a server in the same way as your application does, or whatever) *without* having to go to the documentation of your application to figure it out.

I agree with what I think you mean, but possibly not with how you're saying it.  Using the TCP analogy again, in fact, to understand the contents of the TCP stream for port 25, one has to go to the documentation of the application communicating on port 25.  In this case, that documentation is RFC 821 and its successors.  SMTP is a profile of TCP that further specifies the contents of the data being exchanged.  An analogous situation exists when using OAuth Assertions.

I'll also observe that the working group is also working on a specification that enables an OAuth client to dynamically register itself with the Authorization Server (draft-ietf-oauth-dyn-reg) and that that registration does declare information about what profile is being used, as John Bradley pointed out in his response.  That's a key piece of the whole solution to enable interoperable implementations.

So using your Ukrainian dolls analogy, yes, the OAuth Assertions spec and the OAuth SAML2 Profile and OAuth JWT Profile specs are dolls inside other dolls - not the outer doll.  That's by design, and not a spec defect, at least as I see it.  We already do have mechanisms for dynamically declaring what profile is being used, and we are using them.

I agree with Stephen that we should let this conversation run for a while to make sure everyone comes to a common understanding, but ultimately, I hope that you'll withdraw your DISCUSS, because, in fact, interoperable implementations can be written by reading the specs used alone.

                                                            Best wishes,

                                                            -- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Sunday, February 17, 2013 9:38 PM
To: Mike Jones
Cc: Stephen Farrell; [email-masked]; [email-masked]
Subject: Re: [OAUTH-WG] oauth assertions plan

The authorization server responds with an authorization token, which the client is required to understand.

We have talked about three kinds of tokens: bearer tokens, MAC tokens, and assertion tokens.

How does a client know what kind of token it will get from a particular authorization server?

How does a server that supports multiple token types know what kind of token it should give to a particular client?

How does the server know whether to give a SAML assertion or a JWT assertion?  How does the client know which it's going to get?

And now you're saying that even if everyone knows they're going to get an assertion token, and specifically a JWT assertion, the semantics of particular fields in those tokens are undefined.  If you have different meanings ("different kinds of things", as you've said) for the Audience field, how is the server supposed to communicate which meaning *it* is using?  How is there any assurance that a client will understand it in the same way?

These are the sorts of things I'm concerned about, and this is what I mean by saying that it's like a Ukrainian doll: you open the oauth doll and find the token doll; you open the token doll and find the assertions doll; you open the assertions doll and find the JWT doll; you open the JWT doll and find the Audience field doll... at what point do the dolls end and interoperablity begins?

I understand that you want certain things to be handled differently by different applications, and I'm fine with that in principle.  But the other part of the principle is that I have to be able to write an application that interoperates with yours *purely by reading the specs*.

If you do this by profiling, we need to get to a point where two things are true: (1) the profile chain has ended, and what's left is well defined, and (2) I have to be able to, *from the specs and the protocol alone*, determine what profile will be used.  I don't see how this protocol gives me any way to determine what to send or what to expect to receive.  And if an out-of-band understanding is required for that, that doesn't interoperate.

Now, the way we usually handle the need for "different kinds of things" is to have different fields for each, or to have one field tagged so that it's self-defining (as URIs have a scheme that says what to do with them).  If the Audience field might look like this in one application:

   urn:ietf:params:banana

   abra:cadabra

...where the first is understood to be a URI and the second is something else, then please explain how you and I can each write applications to that?

For your specific questions:

> 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?

I am proposing that there must be a way for someone writing an application to know what to use in these fields that will work with your application (or will work with a server in the same way as your application does, or whatever) *without* having to go to the documentation of your application to figure it out.

That's why I say that as I see it, it's not an issue of MTI.  I'm not saying that I want you to require that any particular thing be implemented.  I'm saying that both sides need to be able to know which variations *are* implemented.  How else do you get interoperability?

Your TCP/ports example is a perfect one to show how this works: the assignments for port numbers are *exactly* to create the interoperability I'm talking about here.  TCP doesn't say anything about the protocol ("profile", perhaps) that's used over it.  But we've defined that port 110 is used for POP and 143 is used for IMAP and 25 is used for SMTP, and so on.  So I know that if my IMAP application wants to talk with your IMAP server, I can accomplish that by using port 143.  If you decide to run your IMAP server on port 142 instead, or if you run your POP server on port 143, we will not interoperate.

But all I need to know is (1) how to do IMAP, (2) how to do it over TCP, and (3) what port to use... and I can build an IMAP client that will work with any IMAP server that follows the same specs.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Mon, 18 Feb 2013 13:37:09 -0500

I'll get to John's message later, after I digest it more.  I can reply to
this one now.

please explain how you and I can each write applications to that?
>
> **
>
> ** **
>
> You can write applications to that by having the profile chain end, and
> with the contents of the Audience field being completely specified
> somewhere in the profile chain being used.
>
>
In order for that to work, we have to know ("we" being both sides of the
protocol, and also "we" being different implementors of similar
applications) what profile to use.

> I am proposing that there must be a way for someone writing an application
> to know what to use in these fields that will work with your application
> (or will work with a server in the same way as your application does, or
> whatever) *without* having to go to the documentation of your application
> to figure it out.****
>
> ** **
>
> I agree with what I think you mean, but possibly not with how you’re
> saying it.  Using the TCP analogy again, in fact, to understand the
> contents of the TCP stream for port 25, one has to go to the documentation
> of the application communicating on port 25.  In this case, that
> documentation is RFC 821 and its successors.
>
> Yeh, here's where we're disconnected.  One does NOT have to go to the
documentation of the application at all.  One has to go to the
specification of SMTP.  But one needn't know *anything* about any other
implementations of SMTP: everything you need is in the SMTP spec (including
that it runs on port 25).

If there were a similar thing here, I'd be happy.  But if there's a similar
thing here, I don't see it.

I’ll also observe that the working group is also working on a specification
> that enables an OAuth client to dynamically register itself with the
> Authorization Server (draft-ietf-oauth-dyn-reg) *and that that
> registration does declare information about what profile is being used*,
> as John Bradley pointed out in his response.  That’s a key piece of the
> whole solution to enable interoperable implementations.****
>
>
It sounds like it is a key piece, and in that case I think that document
needs to come forward along with (or before) the ones that depend on it for
interoperability.  Absent something like that, we can't evaluate whether
it's possible to write interoperable implementations of this spec.

>  We already do have mechanisms for dynamically declaring what profile is
> being used, and we are using them.****
>
>
"Dynamically declaring," in what sense?  Where are those mechanisms
documented?

> I agree with Stephen that we should let this conversation run for a while
> to make sure everyone comes to a common understanding, but ultimately, I
> hope that you’ll withdraw your DISCUSS, because, in fact, interoperable
> implementations can be written by reading the specs used alone.
>
>
I still don't see that that's true (how did those interoperable
implementations resolve the incompletely specified bits?), but, in any
case, don't obsess over the DISCUSS ballot, because it no longer matters:
Stephen has returned the document to the working group, and when it comes
back to IESG Evaluation again I'm sure Stephen will issue a new ballot and
we'll start the process from a clean slate.

Barry

---

From: Mike Jones <[email-masked]>
Date: Mon, 18 Feb 2013 19:02:11 +0000

"Dynamically declaring," in what sense?  Where are those mechanisms documented?

Many of them are documented in draft-ietf-oauth-dyn-reg.

One profile (an outer doll :)) that enables fully interoperable implementations is documented in draft-hardjono-oauth-umacore.  It uses the "http://docs.kantarainitiative.org/uma/scopes/prot.json" scope value as its "tagged field" value.  Another related profile that enables fully interoperable implementations is documented in http://openid.net/specs/openid-connect-messages-1_0.html.  It uses the "openid" scope value as its "tagged field" value, per http://openid.net/specs/openid-connect-messages-1_0.html#scopes.  I know that Dick Hardt has another profile that's using the JWT Assertion Profile for a BC Government identity project.  I know of ones used inside of enterprises and at cloud services as well.

                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Monday, February 18, 2013 10:37 AM
To: Mike Jones
Cc: Barry Leiba; [email-masked]; [email-masked]
Subject: Re: [OAUTH-WG] oauth assertions plan

I'll get to John's message later, after I digest it more.  I can reply to this one now.

You can write applications to that by having the profile chain end, and with the contents of the Audience field being completely specified somewhere in the profile chain being used.

In order for that to work, we have to know ("we" being both sides of the protocol, and also "we" being different implementors of similar applications) what profile to use.

I agree with what I think you mean, but possibly not with how you're saying it.  Using the TCP analogy again, in fact, to understand the contents of the TCP stream for port 25, one has to go to the documentation of the application communicating on port 25.  In this case, that documentation is RFC 821 and its successors.
Yeh, here's where we're disconnected.  One does NOT have to go to the documentation of the application at all.  One has to go to the specification of SMTP.  But one needn't know *anything* about any other implementations of SMTP: everything you need is in the SMTP spec (including that it runs on port 25).

If there were a similar thing here, I'd be happy.  But if there's a similar thing here, I don't see it.

It sounds like it is a key piece, and in that case I think that document needs to come forward along with (or before) the ones that depend on it for interoperability.  Absent something like that, we can't evaluate whether it's possible to write interoperable implementations of this spec.

 We already do have mechanisms for dynamically declaring what profile is being used, and we are using them.

"Dynamically declaring," in what sense?  Where are those mechanisms documented?

I still don't see that that's true (how did those interoperable implementations resolve the incompletely specified bits?), but, in any case, don't obsess over the DISCUSS ballot, because it no longer matters: Stephen has returned the document to the working group, and when it comes back to IESG Evaluation again I'm sure Stephen will issue a new ballot and we'll start the process from a clean slate.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Mon, 18 Feb 2013 14:03:03 -0500

>
> It seems like the scope of your criticism has more to do with RFC 6749 &
> RFC 6750 overall, than the assertions drafts themselves.
>

No, and I'm sorry if it came across that way.  I mentioned the token-type
issue only by way of background.  As it happens, I do think it was a
mistake to publish the oauth framework spec without a mechanism for
discovery/negotiation/communication of token types, but I'm not holding
that against this document at all.

> In OpenID Connect we implemented a discovery and registration layer for
> clients to discover what the Authorization server supports.
>

Great!  I think that each use of the protocol shouldn't have to roll this
on its own, but it's good that OIDC did it.

> need a negotiation mechanism.

We do agree on that; cool.

> Many will argue that specs at a higher level like like Dynamic Client
> Registration https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/are better places to address these capability negotiations because as you
> point out there is more to be negotiated than just assertions.
>

I would be happy to have it done that way, but then I think that needs to
happen first, and this needs to refer to that (normatively) as the (or a)
mechanism that helps this interoperate.

> It has been stated by one of the WG chairs that some of us are anti
> interoperability, so some of us may be a touch sensitive, around this, as
> it is not the case.
>

Yeh, we very much need to keep that kind of rhetoric and questioning of
motives out of the discussion.  You won't hear it from me, certainly.
 Quite the opposite: I'm quite confident that we all share the goal of
developing good specs from which interoperable implementations can be
built.  It's not a question of anti-anything, but of disagreement about how
to accomplish that.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Mon, 18 Feb 2013 14:09:50 -0500

> documented?****
> Many of them are documented in draft-ietf-oauth-dyn-reg.****
>
> ** **
>
> One profile (an outer doll J) that enables fully interoperable
> implementations is documented in draft-hardjono-oauth-umacore.
>
> ...

> Another related profile that enables fully interoperable implementations
> is documented in http://openid.net/specs/openid-connect-messages-1_0.html.
>
>
It's possible, then, that this isn't an issue of major changes needed in
this document, but one of document ordering.  It's possible (I'm still not
sure, but maybe) that if some of these other documents came out before or
at the same time as this one, they would all fit together and all would be
clear.

So maybe that's one way through this.

In the end, all I'm saying is that if I hear that everyone is using oauth
to peel bananas, and I want put my banana-peeling application on the market
by adding oauth to it, I need to be able to read a set of specs that say
how to do that, and that's all.  And if I do that, my application will work
when it's slotted into any oauth-based banana-peeling system.

Barry

---

From: Brian Campbell <[email-masked]>
Date: Mon, 18 Feb 2013 12:34:13 -0700

I do believe some face to face discussion amongst a smallerish group might
be valuable on this. I'll be in Orlando and plan on contributing to that as
much as I can. Thanks for organizing the lunch discussion Stephen.

I do feel that this conversation has strayed a bit and I'd like to clear up
one important misconception. The three assertion documents do not define an
access token type at all. The questions and concerns around bearer tokens
and MAC tokens and other token types may well be very legitimate but are
completely orthogonal to the scope and intent of the assertion documents.
The assertions drafts define how to trade an assertion for a an access
token at the token endpoint via the extension grant type mechanism provided
by RFC 6749. The assertions drafts also define an alternative means of
client authentication but its scope is very limited and only applies to a
client authenticating to the AS's token endpoint. I believe the documents
are pretty clear on what they seek to accomplish (and what they do not) but
this is definitely not the first time this has come up and that likely
points to the need for some more clarification in docs themselves.

It seems to me that much of the recent discussion here is largely unrelated
to that actual intent and scope of the documents in question. It may well
be valuable discussion but, even if we can find some common ground on it,
these assertion drafts probably aren't the right place to address these
issues.

On Mon, Feb 18, 2013 at 12:09 PM, Barry Leiba <[email-masked]>wrote:

>>  Another related profile that enables fully interoperable
>> implementations is documented in
>> http://openid.net/specs/openid-connect-messages-1_0.html.
>>
>>

---

From: John Bradley <[email-masked]>
Date: Mon, 18 Feb 2013 17:54:40 -0300

Thanks Barry,

We had to partially roll our own registration spec because there was no common one at the time.  We did however partially base ours on the UMA one and now we have sever groups working on https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/ based on implementation experience to produce a common way to do it.

I don't think this is the first spec to develop that way.

It is a interesting discussion to have on how much negotiation should happen at each level.

In some ways this contrasts the approach taken by GSSAPI vs SAML where in GSSAPI things are negotiated a a low lever and in SAML they are generally preconfigured in some out of band way.  In part it may be the difference between something that is session oriented vs OAuth/SAML SSO that are using REST like bindings.

Now in SAML as part of the spec there is saml-meta-data that is supported in some (not enough) implementations because it is not MTI (sone of us would like to change that).

Part of the driving forces between the approaches is that when things are federated there needs to be some sort of trust model and that is hard to anticipate in the lower levels.  

I don't think it has to be completely one way or the other, but there will be resistance to duplicating things in lower elves that are likely to be duplicated anyway as part of the higher level trust model.

In Connect we have the problem that the protocol needs to support simple social networks all the way to three letter agencies.
Those have very different trust models and even preferred algorithms.

We have struggled with the Mandatory to Deploy features for interoperability,  Mandatory to Implement is not useful if it is not also mandatory to deploy.   So in the case of token endpoint authentication by HTTP basic it is reasonable to say a OAuth library needs to support http basic, it is not reasonable to say that a deployer that needs SAML assertions signed with EC keys cross certified with the federal bridge has to deploy it. 

That is where we get into the area Stephen Farrell has been raising about MTI not being required to deploy.

That is fine if we are trying to specify library functionality, however it may not help real interoperability for applications.

We likely need to have both.  I can see saying that MTI for a library calling itself compliant with the specs needs to implement a minimum number of algorithms and token types.   That is probably an easy agreement to come to.

Agreeing on what features can or should be negotiated at the lower level vs pushed down from the configuration of the application using them is the harder part.

I look forward to the discussion.

John B.

On 2013-02-18, at 4:03 PM, Barry Leiba <[email-masked]> wrote:

> No, and I'm sorry if it came across that way.  I mentioned the token-type issue only by way of background.  As it happens, I do think it was a mistake to publish the oauth framework spec without a mechanism for discovery/negotiation/communication of token types, but I'm not holding that against this document at all.
>  
> Great!  I think that each use of the protocol shouldn't have to roll this on its own, but it's good that OIDC did it.
>  
> I would be happy to have it done that way, but then I think that needs to happen first, and this needs to refer to that (normatively) as the (or a) mechanism that helps this interoperate.
>  
> Yeh, we very much need to keep that kind of rhetoric and questioning of motives out of the discussion.  You won't hear it from me, certainly.  Quite the opposite: I'm quite confident that we all share the goal of developing good specs from which interoperable implementations can be built.  It's not a question of anti-anything, but of disagreement about how to accomplish that.
> 
> Barry
>

---

From: SM <[email-masked]>
Date: Mon, 18 Feb 2013 23:22:50 -0800

Hi John,
>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

---

From: John Bradley <[email-masked]>
Date: Tue, 19 Feb 2013 11:58:01 -0300

Yes but that contradicts what Barry is appearing to ask for which is run time interoperability, by profile or configuration.

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 <[email-masked]> wrote:

> 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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 19 Feb 2013 15:15:25 +0000

> 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.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 19 Feb 2013 14:10:25 -0500

> not to use field X for example.

He would, indeed agree with that -- with all of it.

Barry

---

From: Mike Jones <[email-masked]>
Date: Tue, 19 Feb 2013 19:15:56 +0000

All of this discussion is occurring at a pretty abstract level.  I hope we can soon make it concrete, because then it would be actionable.

Do any of you who felt that changes might be needed to the Assertions spec or related specs have specific textual changes to propose to any of the specs, which we could then consider the merits of together?

				Thanks,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Tuesday, February 19, 2013 11:10 AM
To: Stephen Farrell
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Mandatory to implement

> 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.

Barry

---

From: John Bradley <[email-masked]>
Date: Tue, 19 Feb 2013 16:26:37 -0300

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.