Re: [OAUTH-WG] draft-ietf-oauth-assertions-09
+1 Ursprüngliche Nachricht Von: Phil Hunt phil.h...@oracle.com Datum: An: Mike Jones michael.jo...@microsoft.com Cc: oauth@ietf.org Betreff: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 +1. This makes good sense. Phil Sent from my phone. On 2013-01-15, at 18:26, Mike Jones michael.jo...@microsoft.com wrote: Hannes and I spoke and went through the issues. He was trying to maximize interoperability of implementations which is obviously a good goal. However, after discussing the particulars, we also agreed that, for some features and use cases, specific profiles of the assertions will be needed to achieve complete interoperability (just like profiles of OAuth are required to achieve interoperability). Therefore, we propose to add an explanatory paragraph to the assertions document explaining that profiling will be required to achieve interoperability in some cases. This would be in exactly the same spirit as http://tools.ietf.org/html/rfc6749#section-1.8, which supplies the same kinds of caveats to implementer's of OAuth Core. I'll work on proposed specific wording shortly. I'll note that adding this text will not change the meaning of the document in any way - it will simply provide additional guidance to implementers on how to think about using the assertion framework. Best wishes, -- Mike -Original Message- From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] Sent: Tuesday, January 15, 2013 10:34 AM To: Mike Jones Cc: Hannes Tschofenig; oauth@ietf.org WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 Hi Mike, I am sure the rest of the working group is interested to see how difficult it is to arrange a conference call when one person is in Espoo/Finland and the other person in the West Coast. In any case, I am online and ready to chat. In any case I will let the group know what conclusions we reached. Ciao Hannes PS: For some reason your SMS arrived one day later... On Jan 15, 2013, at 7:20 PM, Mike Jones wrote: Hi Hannes, Can you please either give me a call for us to talk about the changes you have in mind or write down the specific changes you want? I'd like us to reach a mutual understanding of what you're trying to achieve in time for Stephen to proceed with the telechat on schedule. Thank you, -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Sunday, January 13, 2013 11:03 PM To: Hannes Tschofenig Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 I'm thinking it would be useful for us to talk on the phone or Skype tomorrow, Hannes, because I'm pretty sure I don't know what specific changes you're asking for in which specs. Are you, for instance, asking for language saying that audience values are to be compared for equality as case-sensitive strings in the SAML bearer and JWT bearer specs? (They're not just URIs, as they can be OAuth Client IDs.) Or maybe you can propose specific language changes, so it's clear what you're asking for. Thanks, -- Mike -Original Message- From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] Sent: Sunday, January 13, 2013 2:49 AM To: Mike Jones Cc: Hannes Tschofenig; Brian Campbell; Stephen Farrell; oauth@ietf.org WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 Hi Mike, it is fine to support different identifiers and to even allow the set of supported identifiers to get extended over time. Just omitting a description is, however, not an option. We are in the lucky position where others have done the work for us already (as mentioned in the two cited references). For the IAB document there is even the chance to provide feedback (see https://www.iab.org/2013/01/09/call-for-comment-issues-in-identifier-comparison-for-security-purposes/) in case you believe the author is misguided. We just need to make use of them. Ciao Hannes On Jan 13, 2013, at 12:09 PM, Mike Jones wrote: We already know of use cases where the audience is an abstract identifier and use cases where the audience is the URL of the token endpoint. Both are legitimate. We should foreclose neither. Like many things OAuth, interoperability can be achieved, but it may require a profile further specifying the behaviors appropriate to that use case. This is not a bug - it is a feature, as it increases the applicability of the OAuth specifications. The Assertion, JWT Profile, and SAML Profile are striking an appropriate balance by providing guidance on likely audience values for many use cases, but not precluding other values where necessary for those use cases. Best wishes, -- Mike -Original Message- From: Hannes
Re: [OAUTH-WG] draft-ietf-oauth-assertions-09
Hi Hannes, Can you please either give me a call for us to talk about the changes you have in mind or write down the specific changes you want? I'd like us to reach a mutual understanding of what you're trying to achieve in time for Stephen to proceed with the telechat on schedule. Thank you, -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Sunday, January 13, 2013 11:03 PM To: Hannes Tschofenig Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 I'm thinking it would be useful for us to talk on the phone or Skype tomorrow, Hannes, because I'm pretty sure I don't know what specific changes you're asking for in which specs. Are you, for instance, asking for language saying that audience values are to be compared for equality as case-sensitive strings in the SAML bearer and JWT bearer specs? (They're not just URIs, as they can be OAuth Client IDs.) Or maybe you can propose specific language changes, so it's clear what you're asking for. Thanks, -- Mike -Original Message- From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] Sent: Sunday, January 13, 2013 2:49 AM To: Mike Jones Cc: Hannes Tschofenig; Brian Campbell; Stephen Farrell; oauth@ietf.org WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 Hi Mike, it is fine to support different identifiers and to even allow the set of supported identifiers to get extended over time. Just omitting a description is, however, not an option. We are in the lucky position where others have done the work for us already (as mentioned in the two cited references). For the IAB document there is even the chance to provide feedback (see https://www.iab.org/2013/01/09/call-for-comment-issues-in-identifier-comparison-for-security-purposes/) in case you believe the author is misguided. We just need to make use of them. Ciao Hannes On Jan 13, 2013, at 12:09 PM, Mike Jones wrote: We already know of use cases where the audience is an abstract identifier and use cases where the audience is the URL of the token endpoint. Both are legitimate. We should foreclose neither. Like many things OAuth, interoperability can be achieved, but it may require a profile further specifying the behaviors appropriate to that use case. This is not a bug - it is a feature, as it increases the applicability of the OAuth specifications. The Assertion, JWT Profile, and SAML Profile are striking an appropriate balance by providing guidance on likely audience values for many use cases, but not precluding other values where necessary for those use cases. Best wishes, -- Mike -Original Message- From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] Sent: Sunday, January 13, 2013 1:56 AM To: Mike Jones Cc: Hannes Tschofenig; Brian Campbell; Stephen Farrell; oauth@ietf.org WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 Hi Mike, I understand your reasoning: you want to keep all options open in the framework specification and you want to be more specific in draft-ietf-oauth-jwt-bearer and in draft-ietf-oauth-saml2-bearer. The RFC 2119 language does not add anything but it does not hurt either. It just says that there could essentially be anything in there, including the URL of the Token Endpoint. You can of course post-pone dealing with the issue to the more specific documents. For example, draft-ietf-oauth-jwt-bearer at the moment does not allow an interoperable deployment since it just repeats the abstract framework text by saying The token endpoint URL of the authorization server MAY be used as an acceptable value for an aud element. Ciao Hannes On Jan 12, 2013, at 10:42 PM, Mike Jones wrote: Hi Hannes, For the reasons that Justin and Brian state, I believe that the MAY is appropriate. In some use cases, a good representation of an appropriate audience value is URL of the Token Endpoint. That's there in the Assertions specification as guidance to writers token-type specific specs using the Assertions spec, as I believe it should be. That being the case, as Brian describes, sometimes audience values are more abstract identifiers or identifiers for groups of services, and we don't want to inadvertently preclude those actual use cases. Thus, I believe that the language is appropriate as-is. Thus, I believe that we should proceed with the currently scheduled telechat discussion of the spec. Thanks all, -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes
Re: [OAUTH-WG] draft-ietf-oauth-assertions-09
Hi Mike, I am sure the rest of the working group is interested to see how difficult it is to arrange a conference call when one person is in Espoo/Finland and the other person in the West Coast. In any case, I am online and ready to chat. In any case I will let the group know what conclusions we reached. Ciao Hannes PS: For some reason your SMS arrived one day later... On Jan 15, 2013, at 7:20 PM, Mike Jones wrote: Hi Hannes, Can you please either give me a call for us to talk about the changes you have in mind or write down the specific changes you want? I'd like us to reach a mutual understanding of what you're trying to achieve in time for Stephen to proceed with the telechat on schedule. Thank you, -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Sunday, January 13, 2013 11:03 PM To: Hannes Tschofenig Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 I'm thinking it would be useful for us to talk on the phone or Skype tomorrow, Hannes, because I'm pretty sure I don't know what specific changes you're asking for in which specs. Are you, for instance, asking for language saying that audience values are to be compared for equality as case-sensitive strings in the SAML bearer and JWT bearer specs? (They're not just URIs, as they can be OAuth Client IDs.) Or maybe you can propose specific language changes, so it's clear what you're asking for. Thanks, -- Mike -Original Message- From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] Sent: Sunday, January 13, 2013 2:49 AM To: Mike Jones Cc: Hannes Tschofenig; Brian Campbell; Stephen Farrell; oauth@ietf.org WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 Hi Mike, it is fine to support different identifiers and to even allow the set of supported identifiers to get extended over time. Just omitting a description is, however, not an option. We are in the lucky position where others have done the work for us already (as mentioned in the two cited references). For the IAB document there is even the chance to provide feedback (see https://www.iab.org/2013/01/09/call-for-comment-issues-in-identifier-comparison-for-security-purposes/) in case you believe the author is misguided. We just need to make use of them. Ciao Hannes On Jan 13, 2013, at 12:09 PM, Mike Jones wrote: We already know of use cases where the audience is an abstract identifier and use cases where the audience is the URL of the token endpoint. Both are legitimate. We should foreclose neither. Like many things OAuth, interoperability can be achieved, but it may require a profile further specifying the behaviors appropriate to that use case. This is not a bug - it is a feature, as it increases the applicability of the OAuth specifications. The Assertion, JWT Profile, and SAML Profile are striking an appropriate balance by providing guidance on likely audience values for many use cases, but not precluding other values where necessary for those use cases. Best wishes, -- Mike -Original Message- From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] Sent: Sunday, January 13, 2013 1:56 AM To: Mike Jones Cc: Hannes Tschofenig; Brian Campbell; Stephen Farrell; oauth@ietf.org WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 Hi Mike, I understand your reasoning: you want to keep all options open in the framework specification and you want to be more specific in draft-ietf-oauth-jwt-bearer and in draft-ietf-oauth-saml2-bearer. The RFC 2119 language does not add anything but it does not hurt either. It just says that there could essentially be anything in there, including the URL of the Token Endpoint. You can of course post-pone dealing with the issue to the more specific documents. For example, draft-ietf-oauth-jwt-bearer at the moment does not allow an interoperable deployment since it just repeats the abstract framework text by saying The token endpoint URL of the authorization server MAY be used as an acceptable value for an aud element. Ciao Hannes On Jan 12, 2013, at 10:42 PM, Mike Jones wrote: Hi Hannes, For the reasons that Justin and Brian state, I believe that the MAY is appropriate. In some use cases, a good representation of an appropriate audience value is URL of the Token Endpoint. That's there in the Assertions specification as guidance to writers token-type specific specs using the Assertions spec, as I believe it should be. That being the case, as Brian describes, sometimes audience values are more abstract identifiers or identifiers for groups of services, and we don't want
Re: [OAUTH-WG] draft-ietf-oauth-assertions-09
+1. This makes good sense. Phil Sent from my phone. On 2013-01-15, at 18:26, Mike Jones michael.jo...@microsoft.com wrote: Hannes and I spoke and went through the issues. He was trying to maximize interoperability of implementations which is obviously a good goal. However, after discussing the particulars, we also agreed that, for some features and use cases, specific profiles of the assertions will be needed to achieve complete interoperability (just like profiles of OAuth are required to achieve interoperability). Therefore, we propose to add an explanatory paragraph to the assertions document explaining that profiling will be required to achieve interoperability in some cases. This would be in exactly the same spirit as http://tools.ietf.org/html/rfc6749#section-1.8, which supplies the same kinds of caveats to implementer's of OAuth Core. I'll work on proposed specific wording shortly. I'll note that adding this text will not change the meaning of the document in any way - it will simply provide additional guidance to implementers on how to think about using the assertion framework. Best wishes, -- Mike -Original Message- From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] Sent: Tuesday, January 15, 2013 10:34 AM To: Mike Jones Cc: Hannes Tschofenig; oauth@ietf.org WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 Hi Mike, I am sure the rest of the working group is interested to see how difficult it is to arrange a conference call when one person is in Espoo/Finland and the other person in the West Coast. In any case, I am online and ready to chat. In any case I will let the group know what conclusions we reached. Ciao Hannes PS: For some reason your SMS arrived one day later... On Jan 15, 2013, at 7:20 PM, Mike Jones wrote: Hi Hannes, Can you please either give me a call for us to talk about the changes you have in mind or write down the specific changes you want? I'd like us to reach a mutual understanding of what you're trying to achieve in time for Stephen to proceed with the telechat on schedule. Thank you, -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Sunday, January 13, 2013 11:03 PM To: Hannes Tschofenig Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 I'm thinking it would be useful for us to talk on the phone or Skype tomorrow, Hannes, because I'm pretty sure I don't know what specific changes you're asking for in which specs. Are you, for instance, asking for language saying that audience values are to be compared for equality as case-sensitive strings in the SAML bearer and JWT bearer specs? (They're not just URIs, as they can be OAuth Client IDs.) Or maybe you can propose specific language changes, so it's clear what you're asking for. Thanks, -- Mike -Original Message- From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] Sent: Sunday, January 13, 2013 2:49 AM To: Mike Jones Cc: Hannes Tschofenig; Brian Campbell; Stephen Farrell; oauth@ietf.org WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 Hi Mike, it is fine to support different identifiers and to even allow the set of supported identifiers to get extended over time. Just omitting a description is, however, not an option. We are in the lucky position where others have done the work for us already (as mentioned in the two cited references). For the IAB document there is even the chance to provide feedback (see https://www.iab.org/2013/01/09/call-for-comment-issues-in-identifier-comparison-for-security-purposes/) in case you believe the author is misguided. We just need to make use of them. Ciao Hannes On Jan 13, 2013, at 12:09 PM, Mike Jones wrote: We already know of use cases where the audience is an abstract identifier and use cases where the audience is the URL of the token endpoint. Both are legitimate. We should foreclose neither. Like many things OAuth, interoperability can be achieved, but it may require a profile further specifying the behaviors appropriate to that use case. This is not a bug - it is a feature, as it increases the applicability of the OAuth specifications. The Assertion, JWT Profile, and SAML Profile are striking an appropriate balance by providing guidance on likely audience values for many use cases, but not precluding other values where necessary for those use cases. Best wishes, -- Mike -Original Message- From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] Sent: Sunday, January 13, 2013 1:56 AM To: Mike Jones Cc: Hannes Tschofenig; Brian Campbell; Stephen Farrell; oauth@ietf.org WG Subject: Re: [OAUTH-WG] draft-ietf
Re: [OAUTH-WG] draft-ietf-oauth-assertions-09
We already know of use cases where the audience is an abstract identifier and use cases where the audience is the URL of the token endpoint. Both are legitimate. We should foreclose neither. Like many things OAuth, interoperability can be achieved, but it may require a profile further specifying the behaviors appropriate to that use case. This is not a bug - it is a feature, as it increases the applicability of the OAuth specifications. The Assertion, JWT Profile, and SAML Profile are striking an appropriate balance by providing guidance on likely audience values for many use cases, but not precluding other values where necessary for those use cases. Best wishes, -- Mike -Original Message- From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] Sent: Sunday, January 13, 2013 1:56 AM To: Mike Jones Cc: Hannes Tschofenig; Brian Campbell; Stephen Farrell; oauth@ietf.org WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 Hi Mike, I understand your reasoning: you want to keep all options open in the framework specification and you want to be more specific in draft-ietf-oauth-jwt-bearer and in draft-ietf-oauth-saml2-bearer. The RFC 2119 language does not add anything but it does not hurt either. It just says that there could essentially be anything in there, including the URL of the Token Endpoint. You can of course post-pone dealing with the issue to the more specific documents. For example, draft-ietf-oauth-jwt-bearer at the moment does not allow an interoperable deployment since it just repeats the abstract framework text by saying The token endpoint URL of the authorization server MAY be used as an acceptable value for an aud element. Ciao Hannes On Jan 12, 2013, at 10:42 PM, Mike Jones wrote: Hi Hannes, For the reasons that Justin and Brian state, I believe that the MAY is appropriate. In some use cases, a good representation of an appropriate audience value is URL of the Token Endpoint. That's there in the Assertions specification as guidance to writers token-type specific specs using the Assertions spec, as I believe it should be. That being the case, as Brian describes, sometimes audience values are more abstract identifiers or identifiers for groups of services, and we don't want to inadvertently preclude those actual use cases. Thus, I believe that the language is appropriate as-is. Thus, I believe that we should proceed with the currently scheduled telechat discussion of the spec. Thanks all, -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Saturday, January 12, 2013 11:50 AM To: Brian Campbell Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 Hi Brian, I understand that this is challenging. Nevertheless it would make sense to describe the desired behavior in draft-ietf-oauth-jwt-bearer and in draft-ietf-oauth-saml2-bearer in such a way that two versions developed by different groups would interoperate without causing security problems or failures. To move forward with draft-ietf-oauth-assertions I suggest to follow the recommendation in http://www.ietf.org/mail-archive/web/oauth/current/msg10507.html and to address the details in draft-ietf-oauth-jwt-bearer and in draft-ietf-oauth-saml2-bearer as soon as possible to get these documents moving forward and completed soon. Ciao Hannes On Jan 11, 2013, at 7:51 PM, Brian Campbell wrote: That text around audience in the framework spec changed from a SHOULD to a MAY in -09 so that it would be more consistent with the the SAML and JWT versions, which were already using a MAY in that context. Your concern is valid Hannes and your point is taken. But reality is rather messy and I don't believe it can addressed as easily as you suggest. In SAML, for example, an entity identifier is often used as a value for the audience (per spec and in practice). But an AS may not necessarily identify itself with a full blown SAML entity, in which case the token endpoint URI is more appropriate. The whole issue is also somewhat complicated in SAML too by it having both audience and recipient that are similar but not the same. I've tried to account for all of this in the SAML doc but it's admittedly somewhat awkward and complex and not as simple as saying the value has to be X and must be validated in exactly such a way. JWT doesn't have the same history and baggage of SAML but is subject to many of the same real world deployment variations. I'm definitely open to improvements with respect to the handling of audience values but I believe anything that is done needs to reflect the realities of current
Re: [OAUTH-WG] draft-ietf-oauth-assertions-09
Hi Mike, it is fine to support different identifiers and to even allow the set of supported identifiers to get extended over time. Just omitting a description is, however, not an option. We are in the lucky position where others have done the work for us already (as mentioned in the two cited references). For the IAB document there is even the chance to provide feedback (see https://www.iab.org/2013/01/09/call-for-comment-issues-in-identifier-comparison-for-security-purposes/) in case you believe the author is misguided. We just need to make use of them. Ciao Hannes On Jan 13, 2013, at 12:09 PM, Mike Jones wrote: We already know of use cases where the audience is an abstract identifier and use cases where the audience is the URL of the token endpoint. Both are legitimate. We should foreclose neither. Like many things OAuth, interoperability can be achieved, but it may require a profile further specifying the behaviors appropriate to that use case. This is not a bug - it is a feature, as it increases the applicability of the OAuth specifications. The Assertion, JWT Profile, and SAML Profile are striking an appropriate balance by providing guidance on likely audience values for many use cases, but not precluding other values where necessary for those use cases. Best wishes, -- Mike -Original Message- From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] Sent: Sunday, January 13, 2013 1:56 AM To: Mike Jones Cc: Hannes Tschofenig; Brian Campbell; Stephen Farrell; oauth@ietf.org WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 Hi Mike, I understand your reasoning: you want to keep all options open in the framework specification and you want to be more specific in draft-ietf-oauth-jwt-bearer and in draft-ietf-oauth-saml2-bearer. The RFC 2119 language does not add anything but it does not hurt either. It just says that there could essentially be anything in there, including the URL of the Token Endpoint. You can of course post-pone dealing with the issue to the more specific documents. For example, draft-ietf-oauth-jwt-bearer at the moment does not allow an interoperable deployment since it just repeats the abstract framework text by saying The token endpoint URL of the authorization server MAY be used as an acceptable value for an aud element. Ciao Hannes On Jan 12, 2013, at 10:42 PM, Mike Jones wrote: Hi Hannes, For the reasons that Justin and Brian state, I believe that the MAY is appropriate. In some use cases, a good representation of an appropriate audience value is URL of the Token Endpoint. That's there in the Assertions specification as guidance to writers token-type specific specs using the Assertions spec, as I believe it should be. That being the case, as Brian describes, sometimes audience values are more abstract identifiers or identifiers for groups of services, and we don't want to inadvertently preclude those actual use cases. Thus, I believe that the language is appropriate as-is. Thus, I believe that we should proceed with the currently scheduled telechat discussion of the spec. Thanks all, -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Saturday, January 12, 2013 11:50 AM To: Brian Campbell Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 Hi Brian, I understand that this is challenging. Nevertheless it would make sense to describe the desired behavior in draft-ietf-oauth-jwt-bearer and in draft-ietf-oauth-saml2-bearer in such a way that two versions developed by different groups would interoperate without causing security problems or failures. To move forward with draft-ietf-oauth-assertions I suggest to follow the recommendation in http://www.ietf.org/mail-archive/web/oauth/current/msg10507.html and to address the details in draft-ietf-oauth-jwt-bearer and in draft-ietf-oauth-saml2-bearer as soon as possible to get these documents moving forward and completed soon. Ciao Hannes On Jan 11, 2013, at 7:51 PM, Brian Campbell wrote: That text around audience in the framework spec changed from a SHOULD to a MAY in -09 so that it would be more consistent with the the SAML and JWT versions, which were already using a MAY in that context. Your concern is valid Hannes and your point is taken. But reality is rather messy and I don't believe it can addressed as easily as you suggest. In SAML, for example, an entity identifier is often used as a value for the audience (per spec and in practice). But an AS may not necessarily identify itself with a full blown SAML entity, in which case the token
Re: [OAUTH-WG] draft-ietf-oauth-assertions-09
I'm thinking it would be useful for us to talk on the phone or Skype tomorrow, Hannes, because I'm pretty sure I don't know what specific changes you're asking for in which specs. Are you, for instance, asking for language saying that audience values are to be compared for equality as case-sensitive strings in the SAML bearer and JWT bearer specs? (They're not just URIs, as they can be OAuth Client IDs.) Or maybe you can propose specific language changes, so it's clear what you're asking for. Thanks, -- Mike -Original Message- From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] Sent: Sunday, January 13, 2013 2:49 AM To: Mike Jones Cc: Hannes Tschofenig; Brian Campbell; Stephen Farrell; oauth@ietf.org WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 Hi Mike, it is fine to support different identifiers and to even allow the set of supported identifiers to get extended over time. Just omitting a description is, however, not an option. We are in the lucky position where others have done the work for us already (as mentioned in the two cited references). For the IAB document there is even the chance to provide feedback (see https://www.iab.org/2013/01/09/call-for-comment-issues-in-identifier-comparison-for-security-purposes/) in case you believe the author is misguided. We just need to make use of them. Ciao Hannes On Jan 13, 2013, at 12:09 PM, Mike Jones wrote: We already know of use cases where the audience is an abstract identifier and use cases where the audience is the URL of the token endpoint. Both are legitimate. We should foreclose neither. Like many things OAuth, interoperability can be achieved, but it may require a profile further specifying the behaviors appropriate to that use case. This is not a bug - it is a feature, as it increases the applicability of the OAuth specifications. The Assertion, JWT Profile, and SAML Profile are striking an appropriate balance by providing guidance on likely audience values for many use cases, but not precluding other values where necessary for those use cases. Best wishes, -- Mike -Original Message- From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] Sent: Sunday, January 13, 2013 1:56 AM To: Mike Jones Cc: Hannes Tschofenig; Brian Campbell; Stephen Farrell; oauth@ietf.org WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 Hi Mike, I understand your reasoning: you want to keep all options open in the framework specification and you want to be more specific in draft-ietf-oauth-jwt-bearer and in draft-ietf-oauth-saml2-bearer. The RFC 2119 language does not add anything but it does not hurt either. It just says that there could essentially be anything in there, including the URL of the Token Endpoint. You can of course post-pone dealing with the issue to the more specific documents. For example, draft-ietf-oauth-jwt-bearer at the moment does not allow an interoperable deployment since it just repeats the abstract framework text by saying The token endpoint URL of the authorization server MAY be used as an acceptable value for an aud element. Ciao Hannes On Jan 12, 2013, at 10:42 PM, Mike Jones wrote: Hi Hannes, For the reasons that Justin and Brian state, I believe that the MAY is appropriate. In some use cases, a good representation of an appropriate audience value is URL of the Token Endpoint. That's there in the Assertions specification as guidance to writers token-type specific specs using the Assertions spec, as I believe it should be. That being the case, as Brian describes, sometimes audience values are more abstract identifiers or identifiers for groups of services, and we don't want to inadvertently preclude those actual use cases. Thus, I believe that the language is appropriate as-is. Thus, I believe that we should proceed with the currently scheduled telechat discussion of the spec. Thanks all, -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Saturday, January 12, 2013 11:50 AM To: Brian Campbell Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09 Hi Brian, I understand that this is challenging. Nevertheless it would make sense to describe the desired behavior in draft-ietf-oauth-jwt-bearer and in draft-ietf-oauth-saml2-bearer in such a way that two versions developed by different groups would interoperate without causing security problems or failures. To move forward with draft-ietf-oauth-assertions I suggest to follow the recommendation in http://www.ietf.org/mail-archive/web/oauth/current
[OAUTH-WG] draft-ietf-oauth-assertions-09
Hi guys, Thanks for updating the assertion document and for incorporating the comments received on the mailing list. There is only one issue that caught my attention. You changed the description of the audience element to the following text (in version -09 of http://tools.ietf.org/html/draft-ietf-oauth-assertions-09): Audience A value that identifies the parties intended to process the assertion. An audience value MAY be the URL of the Token Endpoint as defined in Section 3.2 of OAuth 2.0 [RFC6749]. Since the value in the audience field is used to by the authorization server in a comparison operation (see Section 5.2) I believe the current text will lead to interoperability problems. Not only is the comparision operation unspecified but even the value that is contained in the field is left open. The RFC 2119 MAY does not really give a lot of hints of what should be put in there. Without having a clear description of what identifier is contained in this field and how the comparison works it is either possible that a legitimate client is rejected by the authorization server (which is annoying) or an assertion with an incorrect assertion is accepted (which is a security problem). Btw, the same issue can also be seen in http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04, http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-15 and in a more generic form also in the JWT (Section 4.1.3 of http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06; aud claim). From the description in the JWT document I was not quite sure whether the ability to carry an array of case sensitive strings for that field is also allowed in any of the assertion documents. Note that there are two documents that provide input to this problem space, namely: http://tools.ietf.org/html/rfc6125 http://tools.ietf.org/html/draft-iab-identifier-comparison-07 So, I would suggest to decide what type of identifier goes into this field and then to point to a document that illustrates how the comparison operation would look like. Possible identifiers are domain names, IP addresses, URIs, etc. Just as an example from RFC 6125 would you allow a wildcard match (like *.example.com) or only an equality match? Would www.example.com be the same as example.com if they resolve to the same IP address(es)? Ciao Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] draft-ietf-oauth-assertions-09
Hi, Since we thought we were done with it, I put this document on the IESG telechat agenda for Jan 24. Hannes' question however looks like its a real one that needs an answer. I'd appreciate it if the WG could figure out if there's any change needed and either make that change in the next week, or else tell me to take the draft off the telechat agenda for now. If discussion doesn't happen, or happens but doesn't reach a conclusion, then I'll take the draft off the agenda in a week's time and we can sort out if any changes are needed later. The reason why now+1-week matters, is that that's when IESG members tend to do their reviews and having 'em all review a moving target isn't a good plan. Thanks, S. On 01/11/2013 08:18 AM, Hannes Tschofenig wrote: Hi guys, Thanks for updating the assertion document and for incorporating the comments received on the mailing list. There is only one issue that caught my attention. You changed the description of the audience element to the following text (in version -09 of http://tools.ietf.org/html/draft-ietf-oauth-assertions-09): Audience A value that identifies the parties intended to process the assertion. An audience value MAY be the URL of the Token Endpoint as defined in Section 3.2 of OAuth 2.0 [RFC6749]. Since the value in the audience field is used to by the authorization server in a comparison operation (see Section 5.2) I believe the current text will lead to interoperability problems. Not only is the comparision operation unspecified but even the value that is contained in the field is left open. The RFC 2119 MAY does not really give a lot of hints of what should be put in there. Without having a clear description of what identifier is contained in this field and how the comparison works it is either possible that a legitimate client is rejected by the authorization server (which is annoying) or an assertion with an incorrect assertion is accepted (which is a security problem). Btw, the same issue can also be seen in http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04, http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-15 and in a more generic form also in the JWT (Section 4.1.3 of http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06; aud claim). From the description in the JWT document I was not quite sure whether the ability to carry an array of case sensitive strings for that field is also allowed in any of the assertion documents. Note that there are two documents that provide input to this problem space, namely: http://tools.ietf.org/html/rfc6125 http://tools.ietf.org/html/draft-iab-identifier-comparison-07 So, I would suggest to decide what type of identifier goes into this field and then to point to a document that illustrates how the comparison operation would look like. Possible identifiers are domain names, IP addresses, URIs, etc. Just as an example from RFC 6125 would you allow a wildcard match (like *.example.com) or only an equality match? Would www.example.com be the same as example.com if they resolve to the same IP address(es)? Ciao Hannes ___ 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
Re: [OAUTH-WG] draft-ietf-oauth-assertions-09
It's my understanding that the general assertions claim is more of a conceptual mapping than it is a concrete encoding, so anything more specific here would be out of place. I would like the authors to either confirm or correct my assumptions, though. -- Justin On Jan 11, 2013, at 6:30 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: Hi, Since we thought we were done with it, I put this document on the IESG telechat agenda for Jan 24. Hannes' question however looks like its a real one that needs an answer. I'd appreciate it if the WG could figure out if there's any change needed and either make that change in the next week, or else tell me to take the draft off the telechat agenda for now. If discussion doesn't happen, or happens but doesn't reach a conclusion, then I'll take the draft off the agenda in a week's time and we can sort out if any changes are needed later. The reason why now+1-week matters, is that that's when IESG members tend to do their reviews and having 'em all review a moving target isn't a good plan. Thanks, S. On 01/11/2013 08:18 AM, Hannes Tschofenig wrote: Hi guys, Thanks for updating the assertion document and for incorporating the comments received on the mailing list. There is only one issue that caught my attention. You changed the description of the audience element to the following text (in version -09 of http://tools.ietf.org/html/draft-ietf-oauth-assertions-09): Audience A value that identifies the parties intended to process the assertion. An audience value MAY be the URL of the Token Endpoint as defined in Section 3.2 of OAuth 2.0 [RFC6749]. Since the value in the audience field is used to by the authorization server in a comparison operation (see Section 5.2) I believe the current text will lead to interoperability problems. Not only is the comparision operation unspecified but even the value that is contained in the field is left open. The RFC 2119 MAY does not really give a lot of hints of what should be put in there. Without having a clear description of what identifier is contained in this field and how the comparison works it is either possible that a legitimate client is rejected by the authorization server (which is annoying) or an assertion with an incorrect assertion is accepted (which is a security problem). Btw, the same issue can also be seen in http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04, http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-15 and in a more generic form also in the JWT (Section 4.1.3 of http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06; aud claim). From the description in the JWT document I was not quite sure whether the ability to carry an array of case sensitive strings for that field is also allowed in any of the assertion documents. Note that there are two documents that provide input to this problem space, namely: http://tools.ietf.org/html/rfc6125 http://tools.ietf.org/html/draft-iab-identifier-comparison-07 So, I would suggest to decide what type of identifier goes into this field and then to point to a document that illustrates how the comparison operation would look like. Possible identifiers are domain names, IP addresses, URIs, etc. Just as an example from RFC 6125 would you allow a wildcard match (like *.example.com) or only an equality match? Would www.example.com be the same as example.com if they resolve to the same IP address(es)? Ciao Hannes ___ 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] draft-ietf-oauth-assertions-09
If that's the case then I would omit the RFC 2119 language and say that the details have to be provided by the respective documents. On Jan 11, 2013, at 4:37 PM, Richer, Justin P. wrote: It's my understanding that the general assertions claim is more of a conceptual mapping than it is a concrete encoding, so anything more specific here would be out of place. I would like the authors to either confirm or correct my assumptions, though. -- Justin On Jan 11, 2013, at 6:30 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: Hi, Since we thought we were done with it, I put this document on the IESG telechat agenda for Jan 24. Hannes' question however looks like its a real one that needs an answer. I'd appreciate it if the WG could figure out if there's any change needed and either make that change in the next week, or else tell me to take the draft off the telechat agenda for now. If discussion doesn't happen, or happens but doesn't reach a conclusion, then I'll take the draft off the agenda in a week's time and we can sort out if any changes are needed later. The reason why now+1-week matters, is that that's when IESG members tend to do their reviews and having 'em all review a moving target isn't a good plan. Thanks, S. On 01/11/2013 08:18 AM, Hannes Tschofenig wrote: Hi guys, Thanks for updating the assertion document and for incorporating the comments received on the mailing list. There is only one issue that caught my attention. You changed the description of the audience element to the following text (in version -09 of http://tools.ietf.org/html/draft-ietf-oauth-assertions-09): Audience A value that identifies the parties intended to process the assertion. An audience value MAY be the URL of the Token Endpoint as defined in Section 3.2 of OAuth 2.0 [RFC6749]. Since the value in the audience field is used to by the authorization server in a comparison operation (see Section 5.2) I believe the current text will lead to interoperability problems. Not only is the comparision operation unspecified but even the value that is contained in the field is left open. The RFC 2119 MAY does not really give a lot of hints of what should be put in there. Without having a clear description of what identifier is contained in this field and how the comparison works it is either possible that a legitimate client is rejected by the authorization server (which is annoying) or an assertion with an incorrect assertion is accepted (which is a security problem). Btw, the same issue can also be seen in http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04, http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-15 and in a more generic form also in the JWT (Section 4.1.3 of http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06; aud claim). From the description in the JWT document I was not quite sure whether the ability to carry an array of case sensitive strings for that field is also allowed in any of the assertion documents. Note that there are two documents that provide input to this problem space, namely: http://tools.ietf.org/html/rfc6125 http://tools.ietf.org/html/draft-iab-identifier-comparison-07 So, I would suggest to decide what type of identifier goes into this field and then to point to a document that illustrates how the comparison operation would look like. Possible identifiers are domain names, IP addresses, URIs, etc. Just as an example from RFC 6125 would you allow a wildcard match (like *.example.com) or only an equality match? Would www.example.com be the same as example.com if they resolve to the same IP address(es)? Ciao Hannes ___ 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] draft-ietf-oauth-assertions-09
Yes in assertions it needs to be general. It is the JWT and SAML profiles that need to nail down what the format of the audience is.They should probably both be the URI of the token endpoint. In both SAML and JWT there can be multiple audiences for the token. John On 2013-01-11, at 11:37 AM, Richer, Justin P. jric...@mitre.org wrote: It's my understanding that the general assertions claim is more of a conceptual mapping than it is a concrete encoding, so anything more specific here would be out of place. I would like the authors to either confirm or correct my assumptions, though. -- Justin On Jan 11, 2013, at 6:30 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: Hi, Since we thought we were done with it, I put this document on the IESG telechat agenda for Jan 24. Hannes' question however looks like its a real one that needs an answer. I'd appreciate it if the WG could figure out if there's any change needed and either make that change in the next week, or else tell me to take the draft off the telechat agenda for now. If discussion doesn't happen, or happens but doesn't reach a conclusion, then I'll take the draft off the agenda in a week's time and we can sort out if any changes are needed later. The reason why now+1-week matters, is that that's when IESG members tend to do their reviews and having 'em all review a moving target isn't a good plan. Thanks, S. On 01/11/2013 08:18 AM, Hannes Tschofenig wrote: Hi guys, Thanks for updating the assertion document and for incorporating the comments received on the mailing list. There is only one issue that caught my attention. You changed the description of the audience element to the following text (in version -09 of http://tools.ietf.org/html/draft-ietf-oauth-assertions-09): Audience A value that identifies the parties intended to process the assertion. An audience value MAY be the URL of the Token Endpoint as defined in Section 3.2 of OAuth 2.0 [RFC6749]. Since the value in the audience field is used to by the authorization server in a comparison operation (see Section 5.2) I believe the current text will lead to interoperability problems. Not only is the comparision operation unspecified but even the value that is contained in the field is left open. The RFC 2119 MAY does not really give a lot of hints of what should be put in there. Without having a clear description of what identifier is contained in this field and how the comparison works it is either possible that a legitimate client is rejected by the authorization server (which is annoying) or an assertion with an incorrect assertion is accepted (which is a security problem). Btw, the same issue can also be seen in http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04, http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-15 and in a more generic form also in the JWT (Section 4.1.3 of http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06; aud claim). From the description in the JWT document I was not quite sure whether the ability to carry an array of case sensitive strings for that field is also allowed in any of the assertion documents. Note that there are two documents that provide input to this problem space, namely: http://tools.ietf.org/html/rfc6125 http://tools.ietf.org/html/draft-iab-identifier-comparison-07 So, I would suggest to decide what type of identifier goes into this field and then to point to a document that illustrates how the comparison operation would look like. Possible identifiers are domain names, IP addresses, URIs, etc. Just as an example from RFC 6125 would you allow a wildcard match (like *.example.com) or only an equality match? Would www.example.com be the same as example.com if they resolve to the same IP address(es)? Ciao Hannes ___ 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 ___ 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
Re: [OAUTH-WG] draft-ietf-oauth-assertions-09
That text around audience in the framework spec changed from a SHOULD to a MAY in -09 so that it would be more consistent with the the SAML and JWT versions, which were already using a MAY in that context. Your concern is valid Hannes and your point is taken. But reality is rather messy and I don't believe it can addressed as easily as you suggest. In SAML, for example, an entity identifier is often used as a value for the audience (per spec and in practice). But an AS may not necessarily identify itself with a full blown SAML entity, in which case the token endpoint URI is more appropriate. The whole issue is also somewhat complicated in SAML too by it having both audience and recipient that are similar but not the same. I've tried to account for all of this in the SAML doc but it's admittedly somewhat awkward and complex and not as simple as saying the value has to be X and must be validated in exactly such a way. JWT doesn't have the same history and baggage of SAML but is subject to many of the same real world deployment variations. I'm definitely open to improvements with respect to the handling of audience values but I believe anything that is done needs to reflect the realities of current implementations and deployments as well as related specifications., On Fri, Jan 11, 2013 at 8:55 AM, John Bradley ve7...@ve7jtb.com wrote: Yes in assertions it needs to be general. It is the JWT and SAML profiles that need to nail down what the format of the audience is.They should probably both be the URI of the token endpoint. In both SAML and JWT there can be multiple audiences for the token. John On 2013-01-11, at 11:37 AM, Richer, Justin P. jric...@mitre.org wrote: It's my understanding that the general assertions claim is more of a conceptual mapping than it is a concrete encoding, so anything more specific here would be out of place. I would like the authors to either confirm or correct my assumptions, though. -- Justin On Jan 11, 2013, at 6:30 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: Hi, Since we thought we were done with it, I put this document on the IESG telechat agenda for Jan 24. Hannes' question however looks like its a real one that needs an answer. I'd appreciate it if the WG could figure out if there's any change needed and either make that change in the next week, or else tell me to take the draft off the telechat agenda for now. If discussion doesn't happen, or happens but doesn't reach a conclusion, then I'll take the draft off the agenda in a week's time and we can sort out if any changes are needed later. The reason why now+1-week matters, is that that's when IESG members tend to do their reviews and having 'em all review a moving target isn't a good plan. Thanks, S. On 01/11/2013 08:18 AM, Hannes Tschofenig wrote: Hi guys, Thanks for updating the assertion document and for incorporating the comments received on the mailing list. There is only one issue that caught my attention. You changed the description of the audience element to the following text (in version -09 of http://tools.ietf.org/html/draft-ietf-oauth-assertions-09): Audience A value that identifies the parties intended to process the assertion. An audience value MAY be the URL of the Token Endpoint as defined in Section 3.2 of OAuth 2.0 [RFC6749]. Since the value in the audience field is used to by the authorization server in a comparison operation (see Section 5.2) I believe the current text will lead to interoperability problems. Not only is the comparision operation unspecified but even the value that is contained in the field is left open. The RFC 2119 MAY does not really give a lot of hints of what should be put in there. Without having a clear description of what identifier is contained in this field and how the comparison works it is either possible that a legitimate client is rejected by the authorization server (which is annoying) or an assertion with an incorrect assertion is accepted (which is a security problem). Btw, the same issue can also be seen in http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04, http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-15 and in a more generic form also in the JWT (Section 4.1.3 of http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06; aud claim). From the description in the JWT document I was not quite sure whether the ability to carry an array of case sensitive strings for that field is also allowed in any of the assertion documents. Note that there are two documents that provide input to this problem space, namely: http://tools.ietf.org/html/rfc6125 http://tools.ietf.org/html/draft-iab-identifier-comparison-07 So, I would suggest to decide what type of identifier goes into this field and then to point to a document that illustrates how the comparison operation would look like.
