Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today
When can we get the IESG to review the SAML Assertions draft? It would be good to get the Assertions draft and the SAML Assertions draft back in sync, from a schedule and process perspective, as comments on one may also reflect on the other. -- Mike -Original Message- From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] Sent: Saturday, January 19, 2013 8:19 AM To: Mike Jones Cc: Hannes Tschofenig; Stephen Farrell; Tschofenig, Hannes (NSN - FI/Espoo); oauth@ietf.org Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today Hi Mike, Hi all, Thanks for the feedback. I see that a couple of you have decided to go with option 2. Regarding the comments below. On Jan 19, 2013, at 12:30 AM, Mike Jones wrote: > I can't agree with proceeding with Hannes' rewrite of the interoperability > text, as editorially, it reads like it is apologizing for a defect in the > specification, whereas it is an intentional feature of the specification that > the syntax and verification rules of some fields is intentionally left open > for profiles to specify (even while the semantics of them is defined by the > Assertions spec). I propose that instead, we go with the revised version at > the end of this message, which I believe incorporates Hannes' ideas while > keeping the editorial tone positive. I tried to provide an honest assessment of the situation with my writeup. > > Second, I believe that we should proceed with the non-normative terminology > change of "Principal" to "Subject", which was proposed in > http://www.ietf.org/mail-archive/web/oauth/current/msg10530.html and > supported by Justin and Torsten, with no one opposed. This should go into > the version being discussed on the telechat (as well as the interoperability > text). It would certainly make sense to re-submit a new version with this change and then we see how it reads. Now, since we have a bit more time that should not be an issue at all. > > Finally, I believe that it would be beneficial to all to have the > Assertions and SAML Profile specs be discussed on the same telechat, > as both are useful for understanding the other. Frankly, I think they > should go to the IETF Editor together as "related specifications", > with the goal being consecutively numbered RFCs referencing one > another. Is there any reason we can't schedule both for the February > 7th telechat? (I don't actually understand how they failed to proceed > in lock-step in the first place. Chairs - any insights?) It might be beneficial to have the two discussed together but the IESG has not done the reviews of the SAML assertion draft yet and therefore it is not on the agenda yet. Ciao Hannes > > > > Interoperability Considerations > > This specification defines a framework for using assertions with OAuth 2.0. > However, as an abstract framework in which the data formats used for > representing many values are not defined, on its own, this specification is > not sufficient to produce interoperable implementations. > > Two other specifications that profile this framework for specific assertion > have been developed: one ([I-D.ietf-oauth-saml2-bearer]) uses SAML 2.0-based > assertions and the other ([I-D.ietf-oauth-jwt-bearer]) uses JSON Web Tokens > (JWTs). These two instantiations of this framework specify additional > details about the assertion encoding and processing rules for using those > kinds of assertions with OAuth 2.0. > > However, even when profiled for specific assertion types, additional > profiling for specific use cases will be required to achieve full > interoperability. Deployments for particular trust frameworks, circles of > trust, or other uses cases will need to agree among the participants on the > kinds of values to be used for some abstract fields defined by this > specification. For example the values of Issuer, Subject, and Audience > fields might be URLs, URIs, fully qualified domain names, OAuth client IDs, > IP addresses, or other values, depending upon the requirements of the > particular use case. The verification rules for some values will also be use > case specific. > > This framework was designed with the clear expectation that additional > specifications will define prescriptive profiles and extensions necessary to > achieve full web-scale interoperability for particular use cases. > > > > Thanks all, > -- Mike > > -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Stephen Farrell > Sent: Friday, January 18, 2013 9:47 AM > To: Tscho
Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today
Hi Hannes, On 01/19/2013 04:19 PM, Hannes Tschofenig wrote: > > Thanks for the feedback. I see that a couple of you have decided to go with > option 2. Yep, looks like it. I've moved this back to Feb 7 so the discussion doesn't need to be rushed. S. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today
Hi Mike, Hi all, Thanks for the feedback. I see that a couple of you have decided to go with option 2. Regarding the comments below. On Jan 19, 2013, at 12:30 AM, Mike Jones wrote: > I can't agree with proceeding with Hannes' rewrite of the interoperability > text, as editorially, it reads like it is apologizing for a defect in the > specification, whereas it is an intentional feature of the specification that > the syntax and verification rules of some fields is intentionally left open > for profiles to specify (even while the semantics of them is defined by the > Assertions spec). I propose that instead, we go with the revised version at > the end of this message, which I believe incorporates Hannes' ideas while > keeping the editorial tone positive. I tried to provide an honest assessment of the situation with my writeup. > > Second, I believe that we should proceed with the non-normative terminology > change of "Principal" to "Subject", which was proposed in > http://www.ietf.org/mail-archive/web/oauth/current/msg10530.html and > supported by Justin and Torsten, with no one opposed. This should go into > the version being discussed on the telechat (as well as the interoperability > text). It would certainly make sense to re-submit a new version with this change and then we see how it reads. Now, since we have a bit more time that should not be an issue at all. > > Finally, I believe that it would be beneficial to all to have the Assertions > and SAML Profile specs be discussed on the same telechat, as both are useful > for understanding the other. Frankly, I think they should go to the IETF > Editor together as "related specifications", with the goal being > consecutively numbered RFCs referencing one another. Is there any reason we > can't schedule both for the February 7th telechat? (I don't actually > understand how they failed to proceed in lock-step in the first place. > Chairs - any insights?) It might be beneficial to have the two discussed together but the IESG has not done the reviews of the SAML assertion draft yet and therefore it is not on the agenda yet. Ciao Hannes > > > > Interoperability Considerations > > This specification defines a framework for using assertions with OAuth 2.0. > However, as an abstract framework in which the data formats used for > representing many values are not defined, on its own, this specification is > not sufficient to produce interoperable implementations. > > Two other specifications that profile this framework for specific assertion > have been developed: one ([I-D.ietf-oauth-saml2-bearer]) uses SAML 2.0-based > assertions and the other ([I-D.ietf-oauth-jwt-bearer]) uses JSON Web Tokens > (JWTs). These two instantiations of this framework specify additional > details about the assertion encoding and processing rules for using those > kinds of assertions with OAuth 2.0. > > However, even when profiled for specific assertion types, additional > profiling for specific use cases will be required to achieve full > interoperability. Deployments for particular trust frameworks, circles of > trust, or other uses cases will need to agree among the participants on the > kinds of values to be used for some abstract fields defined by this > specification. For example the values of Issuer, Subject, and Audience > fields might be URLs, URIs, fully qualified domain names, OAuth client IDs, > IP addresses, or other values, depending upon the requirements of the > particular use case. The verification rules for some values will also be use > case specific. > > This framework was designed with the clear expectation that additional > specifications will define prescriptive profiles and extensions necessary to > achieve full web-scale interoperability for particular use cases. > > > > Thanks all, > -- Mike > > -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > Stephen Farrell > Sent: Friday, January 18, 2013 9:47 AM > To: Tschofenig, Hannes (NSN - FI/Espoo) > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today > > > Hiya, > > So I'll take the lack of further discussion about this an meaning that the wg > want this to shoot ahead. I'll put this in as an RFC editor note for the > draft. > > Cheers, > S. > > On 01/18/2013 12:04 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> Hi all, >> >> As you have seen on the list (see >> http://www.ietf.org/mail-archive/web/oauth/current/msg10526.
Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today
I prefer Mike's wording over Hannes's rewrite. This is a design feature to leave it to specs like openID Connect to profile what the values are. We did that in the context of what made sense for the spec using the assertion profile. I thought I also supported changing Principal to Subject on this list but it could have been one of the other places, that I agreed to the change:) John B. On 2013-01-18, at 3:30 PM, Mike Jones wrote: > I can't agree with proceeding with Hannes' rewrite of the interoperability > text, as editorially, it reads like it is apologizing for a defect in the > specification, whereas it is an intentional feature of the specification that > the syntax and verification rules of some fields is intentionally left open > for profiles to specify (even while the semantics of them is defined by the > Assertions spec). I propose that instead, we go with the revised version at > the end of this message, which I believe incorporates Hannes' ideas while > keeping the editorial tone positive. > > Second, I believe that we should proceed with the non-normative terminology > change of "Principal" to "Subject", which was proposed in > http://www.ietf.org/mail-archive/web/oauth/current/msg10530.html and > supported by Justin and Torsten, with no one opposed. This should go into > the version being discussed on the telechat (as well as the interoperability > text). > > Finally, I believe that it would be beneficial to all to have the Assertions > and SAML Profile specs be discussed on the same telechat, as both are useful > for understanding the other. Frankly, I think they should go to the IETF > Editor together as "related specifications", with the goal being > consecutively numbered RFCs referencing one another. Is there any reason we > can't schedule both for the February 7th telechat? (I don't actually > understand how they failed to proceed in lock-step in the first place. > Chairs - any insights?) > > > > Interoperability Considerations > > This specification defines a framework for using assertions with OAuth 2.0. > However, as an abstract framework in which the data formats used for > representing many values are not defined, on its own, this specification is > not sufficient to produce interoperable implementations. > > Two other specifications that profile this framework for specific assertion > have been developed: one ([I-D.ietf-oauth-saml2-bearer]) uses SAML 2.0-based > assertions and the other ([I-D.ietf-oauth-jwt-bearer]) uses JSON Web Tokens > (JWTs). These two instantiations of this framework specify additional > details about the assertion encoding and processing rules for using those > kinds of assertions with OAuth 2.0. > > However, even when profiled for specific assertion types, additional > profiling for specific use cases will be required to achieve full > interoperability. Deployments for particular trust frameworks, circles of > trust, or other uses cases will need to agree among the participants on the > kinds of values to be used for some abstract fields defined by this > specification. For example the values of Issuer, Subject, and Audience > fields might be URLs, URIs, fully qualified domain names, OAuth client IDs, > IP addresses, or other values, depending upon the requirements of the > particular use case. The verification rules for some values will also be use > case specific. > > This framework was designed with the clear expectation that additional > specifications will define prescriptive profiles and extensions necessary to > achieve full web-scale interoperability for particular use cases. > > > > Thanks all, > -- Mike > > -Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > Stephen Farrell > Sent: Friday, January 18, 2013 9:47 AM > To: Tschofenig, Hannes (NSN - FI/Espoo) > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today > > > Hiya, > > So I'll take the lack of further discussion about this an meaning that the wg > want this to shoot ahead. I'll put this in as an RFC editor note for the > draft. > > Cheers, > S. > > On 01/18/2013 12:04 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> Hi all, >> >> As you have seen on the list (see >> http://www.ietf.org/mail-archive/web/oauth/current/msg10526.html) I >> had a chat with Mike about how to address my comment for the assertion >> draft and Mike kindly provided his text proposal (see >> http://www.ietf.org/mail-arc
Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today
Same comment as Brian.I support Mike's proposed text. -cmort On Jan 18, 2013, at 3:32 PM, Brian Campbell wrote: I apologize for not participating in much of the discussion around this - I've been otherwise occupied this week with a myriad of other priorities at work. I would, however, like to voice my support in favor of the version of the text that Mike proposed. On Fri, Jan 18, 2013 at 3:59 PM, Mike Jones mailto:michael.jo...@microsoft.com>> wrote: To make the proposed changes concrete, I've made them in a proposed draft 10 (attached). This contains no normative changes from draft 9. People should look at Section 1.1 (Interoperability Considerations) and review the new text there. The only other change was renaming "Principal" to "Subject" to align terminology with the SAML and JWT specs, as discussed on the list. I will wait for OK from one of the chairs or Stephen before checking this in. -- Mike -Original Message- From: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On Behalf Of Mike Jones Sent: Friday, January 18, 2013 2:31 PM To: Stephen Farrell; Tschofenig, Hannes (NSN - FI/Espoo) Cc: oauth@ietf.org<mailto:oauth@ietf.org> Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today I can't agree with proceeding with Hannes' rewrite of the interoperability text, as editorially, it reads like it is apologizing for a defect in the specification, whereas it is an intentional feature of the specification that the syntax and verification rules of some fields is intentionally left open for profiles to specify (even while the semantics of them is defined by the Assertions spec). I propose that instead, we go with the revised version at the end of this message, which I believe incorporates Hannes' ideas while keeping the editorial tone positive. Second, I believe that we should proceed with the non-normative terminology change of "Principal" to "Subject", which was proposed in http://www.ietf.org/mail-archive/web/oauth/current/msg10530.html and supported by Justin and Torsten, with no one opposed. This should go into the version being discussed on the telechat (as well as the interoperability text). Finally, I believe that it would be beneficial to all to have the Assertions and SAML Profile specs be discussed on the same telechat, as both are useful for understanding the other. Frankly, I think they should go to the IETF Editor together as "related specifications", with the goal being consecutively numbered RFCs referencing one another. Is there any reason we can't schedule both for the February 7th telechat? (I don't actually understand how they failed to proceed in lock-step in the first place. Chairs - any insights?) Interoperability Considerations This specification defines a framework for using assertions with OAuth 2.0. However, as an abstract framework in which the data formats used for representing many values are not defined, on its own, this specification is not sufficient to produce interoperable implementations. Two other specifications that profile this framework for specific assertion have been developed: one ([I-D.ietf-oauth-saml2-bearer]) uses SAML 2.0-based assertions and the other ([I-D.ietf-oauth-jwt-bearer]) uses JSON Web Tokens (JWTs). These two instantiations of this framework specify additional details about the assertion encoding and processing rules for using those kinds of assertions with OAuth 2.0. However, even when profiled for specific assertion types, additional profiling for specific use cases will be required to achieve full interoperability. Deployments for particular trust frameworks, circles of trust, or other uses cases will need to agree among the participants on the kinds of values to be used for some abstract fields defined by this specification. For example the values of Issuer, Subject, and Audience fields might be URLs, URIs, fully qualified domain names, OAuth client IDs, IP addresses, or other values, depending upon the requirements of the particular use case. The verification rules for some values will also be use case specific. This framework was designed with the clear expectation that additional specifications will define prescriptive profiles and extensions necessary to achieve full web-scale interoperability for particular use cases. Thanks all, -- Mike -Original Message- From: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On Behalf Of Stephen Farrell Sent: Friday, January 18, 2013 9:47 AM To: Tschofenig, Hannes (NSN - FI/Espoo) Cc: oauth@ietf.org<mailto:oauth@
Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today
I apologize for not participating in much of the discussion around this - I've been otherwise occupied this week with a myriad of other priorities at work. I would, however, like to voice my support in favor of the version of the text that Mike proposed. On Fri, Jan 18, 2013 at 3:59 PM, Mike Jones wrote: > To make the proposed changes concrete, I've made them in a proposed draft > 10 (attached). This contains no normative changes from draft 9. People > should look at Section 1.1 (Interoperability Considerations) and review the > new text there. The only other change was renaming "Principal" to > "Subject" to align terminology with the SAML and JWT specs, as discussed on > the list. > > I will wait for OK from one of the chairs or Stephen before checking this > in. > > -- Mike > > -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > Mike Jones > Sent: Friday, January 18, 2013 2:31 PM > To: Stephen Farrell; Tschofenig, Hannes (NSN - FI/Espoo) > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- > Today > > I can't agree with proceeding with Hannes' rewrite of the interoperability > text, as editorially, it reads like it is apologizing for a defect in the > specification, whereas it is an intentional feature of the specification > that the syntax and verification rules of some fields is intentionally left > open for profiles to specify (even while the semantics of them is defined > by the Assertions spec). I propose that instead, we go with the revised > version at the end of this message, which I believe incorporates Hannes' > ideas while keeping the editorial tone positive. > > Second, I believe that we should proceed with the non-normative > terminology change of "Principal" to "Subject", which was proposed in > http://www.ietf.org/mail-archive/web/oauth/current/msg10530.html and > supported by Justin and Torsten, with no one opposed. This should go into > the version being discussed on the telechat (as well as the > interoperability text). > > Finally, I believe that it would be beneficial to all to have the > Assertions and SAML Profile specs be discussed on the same telechat, as > both are useful for understanding the other. Frankly, I think they should > go to the IETF Editor together as "related specifications", with the goal > being consecutively numbered RFCs referencing one another. Is there any > reason we can't schedule both for the February 7th telechat? (I don't > actually understand how they failed to proceed in lock-step in the first > place. Chairs - any insights?) > > > > Interoperability Considerations > > This specification defines a framework for using assertions with OAuth > 2.0. However, as an abstract framework in which the data formats used for > representing many values are not defined, on its own, this specification is > not sufficient to produce interoperable implementations. > > Two other specifications that profile this framework for specific > assertion have been developed: one ([I-D.ietf-oauth-saml2-bearer]) uses > SAML 2.0-based assertions and the other ([I-D.ietf-oauth-jwt-bearer]) uses > JSON Web Tokens (JWTs). These two instantiations of this framework specify > additional details about the assertion encoding and processing rules for > using those kinds of assertions with OAuth 2.0. > > However, even when profiled for specific assertion types, additional > profiling for specific use cases will be required to achieve full > interoperability. Deployments for particular trust frameworks, circles of > trust, or other uses cases will need to agree among the participants on the > kinds of values to be used for some abstract fields defined by this > specification. For example the values of Issuer, Subject, and Audience > fields might be URLs, URIs, fully qualified domain names, OAuth client IDs, > IP addresses, or other values, depending upon the requirements of the > particular use case. The verification rules for some values will also be > use case specific. > > This framework was designed with the clear expectation that additional > specifications will define prescriptive profiles and extensions necessary > to achieve full web-scale interoperability for particular use cases. > > > > Thanks all, > -- Mike > > -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > Stephen Farrell > Sent: Friday, January 18, 2013 9:47 AM > To: Tschofenig, Hannes (NSN - FI/Espoo) > Cc: oauth
Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today
I can't agree with proceeding with Hannes' rewrite of the interoperability text, as editorially, it reads like it is apologizing for a defect in the specification, whereas it is an intentional feature of the specification that the syntax and verification rules of some fields is intentionally left open for profiles to specify (even while the semantics of them is defined by the Assertions spec). I propose that instead, we go with the revised version at the end of this message, which I believe incorporates Hannes' ideas while keeping the editorial tone positive. Second, I believe that we should proceed with the non-normative terminology change of "Principal" to "Subject", which was proposed in http://www.ietf.org/mail-archive/web/oauth/current/msg10530.html and supported by Justin and Torsten, with no one opposed. This should go into the version being discussed on the telechat (as well as the interoperability text). Finally, I believe that it would be beneficial to all to have the Assertions and SAML Profile specs be discussed on the same telechat, as both are useful for understanding the other. Frankly, I think they should go to the IETF Editor together as "related specifications", with the goal being consecutively numbered RFCs referencing one another. Is there any reason we can't schedule both for the February 7th telechat? (I don't actually understand how they failed to proceed in lock-step in the first place. Chairs - any insights?) Interoperability Considerations This specification defines a framework for using assertions with OAuth 2.0. However, as an abstract framework in which the data formats used for representing many values are not defined, on its own, this specification is not sufficient to produce interoperable implementations. Two other specifications that profile this framework for specific assertion have been developed: one ([I-D.ietf-oauth-saml2-bearer]) uses SAML 2.0-based assertions and the other ([I-D.ietf-oauth-jwt-bearer]) uses JSON Web Tokens (JWTs). These two instantiations of this framework specify additional details about the assertion encoding and processing rules for using those kinds of assertions with OAuth 2.0. However, even when profiled for specific assertion types, additional profiling for specific use cases will be required to achieve full interoperability. Deployments for particular trust frameworks, circles of trust, or other uses cases will need to agree among the participants on the kinds of values to be used for some abstract fields defined by this specification. For example the values of Issuer, Subject, and Audience fields might be URLs, URIs, fully qualified domain names, OAuth client IDs, IP addresses, or other values, depending upon the requirements of the particular use case. The verification rules for some values will also be use case specific. This framework was designed with the clear expectation that additional specifications will define prescriptive profiles and extensions necessary to achieve full web-scale interoperability for particular use cases. Thanks all, -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Stephen Farrell Sent: Friday, January 18, 2013 9:47 AM To: Tschofenig, Hannes (NSN - FI/Espoo) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today Hiya, So I'll take the lack of further discussion about this an meaning that the wg want this to shoot ahead. I'll put this in as an RFC editor note for the draft. Cheers, S. On 01/18/2013 12:04 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi all, > > As you have seen on the list (see > http://www.ietf.org/mail-archive/web/oauth/current/msg10526.html) I > had a chat with Mike about how to address my comment for the assertion > draft and Mike kindly provided his text proposal (see > http://www.ietf.org/mail-archive/web/oauth/current/msg10529.html). I > have used his text as input and extended it a bit. Here is the updated > text. > > > > Operational Considerations and Interoperability Expectations > > This specification defines a framework for using assertions with OAuth > 2.0. However, as an abstract framework on its own, this specification > is not sufficient to produce interoperable implementations. Two other > specifications that instantiate this framework have been developed, > one uses SAML 2.0-based assertions and is described in > [I-D.ietf-oauth-saml2-bearer] and the second builds on JSON Web Tokens > (JWTs) and can be found in [I-D.ietf-oauth-jwt-bearer]. These two > instantiations provide additional details about the assertion encoding > and processing rules for those interested to implement and de
Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today
Hiya, So I'll take the lack of further discussion about this an meaning that the wg want this to shoot ahead. I'll put this in as an RFC editor note for the draft. Cheers, S. On 01/18/2013 12:04 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi all, > > As you have seen on the list (see > http://www.ietf.org/mail-archive/web/oauth/current/msg10526.html) I had > a chat with Mike about how to address my comment for the assertion draft > and Mike kindly provided his text proposal (see > http://www.ietf.org/mail-archive/web/oauth/current/msg10529.html). I > have used his text as input and extended it a bit. Here is the updated > text. > > > > Operational Considerations and Interoperability Expectations > > This specification defines a framework for using assertions with OAuth > 2.0. However, as an abstract framework on its own, this specification is > not sufficient to produce interoperable implementations. Two other > specifications that instantiate this framework have been developed, one > uses SAML 2.0-based assertions and is described in > [I-D.ietf-oauth-saml2-bearer] and the second builds on JSON Web Tokens > (JWTs) and can be found in [I-D.ietf-oauth-jwt-bearer]. These two > instantiations provide additional details about the assertion encoding > and processing rules for those interested to implement and deploy > assertions with OAuth 2.0. > > However, even with these instance documents an interoperable > implementation is not possible since for a specific deployment > environment (within a trust framework or circle of trust, as it is > sometimes called) agreements about acceptable values for various fields > in the specification have to be agreed upon. For example, the audience > field needs to be populated by the entity that generates the assertion > with a specific value and that value may hold identifiers of different > types (for example, a URL, an IP address, an FQDN) and the entity > receiving and verifying the assertion must compare the value in the > audience field with other information it may obtain from the request > and/or with locally available information. Since the abstract framework > nor the instance documents provide sufficient information about the > syntax, the semantic and the comparison operation of the audience field > additional profiling in further specifications is needed for an > interoperable implementation. This additional profiling is not only > needed for the audience field but also for other fields as well. > > This framework was designed with the expectation that additional > specifications will fill this gap for deployment-specific environments. > > > > You have the choice: > > 1. take this as-is if you want the assertion draft > (draft-ietf-oauth-assertions ) on the Jan 24 IESG telechat. There is no > normative text in the writeup; it is rather a clarification. > > 2. discuss it if need be, and draft-ietf-oauth-assertions will be on the > Feb 7 >telechat (if the discussion is done by Feb 1) > > 1 or 2 needs to be chosen today. > > > Ciao > Hannes > > PS: FYI - draft-ietf-oauth-saml2-bearer and draft-ietf-oauth-jwt-bearer > are not yet on the telechat agenda. > > ___ > 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-WG] Assertion Draft: Text about Interoperability -- Today
Hi all, As you have seen on the list (see http://www.ietf.org/mail-archive/web/oauth/current/msg10526.html) I had a chat with Mike about how to address my comment for the assertion draft and Mike kindly provided his text proposal (see http://www.ietf.org/mail-archive/web/oauth/current/msg10529.html). I have used his text as input and extended it a bit. Here is the updated text. Operational Considerations and Interoperability Expectations This specification defines a framework for using assertions with OAuth 2.0. However, as an abstract framework on its own, this specification is not sufficient to produce interoperable implementations. Two other specifications that instantiate this framework have been developed, one uses SAML 2.0-based assertions and is described in [I-D.ietf-oauth-saml2-bearer] and the second builds on JSON Web Tokens (JWTs) and can be found in [I-D.ietf-oauth-jwt-bearer]. These two instantiations provide additional details about the assertion encoding and processing rules for those interested to implement and deploy assertions with OAuth 2.0. However, even with these instance documents an interoperable implementation is not possible since for a specific deployment environment (within a trust framework or circle of trust, as it is sometimes called) agreements about acceptable values for various fields in the specification have to be agreed upon. For example, the audience field needs to be populated by the entity that generates the assertion with a specific value and that value may hold identifiers of different types (for example, a URL, an IP address, an FQDN) and the entity receiving and verifying the assertion must compare the value in the audience field with other information it may obtain from the request and/or with locally available information. Since the abstract framework nor the instance documents provide sufficient information about the syntax, the semantic and the comparison operation of the audience field additional profiling in further specifications is needed for an interoperable implementation. This additional profiling is not only needed for the audience field but also for other fields as well. This framework was designed with the expectation that additional specifications will fill this gap for deployment-specific environments. You have the choice: 1. take this as-is if you want the assertion draft (draft-ietf-oauth-assertions ) on the Jan 24 IESG telechat. There is no normative text in the writeup; it is rather a clarification. 2. discuss it if need be, and draft-ietf-oauth-assertions will be on the Feb 7 telechat (if the discussion is done by Feb 1) 1 or 2 needs to be chosen today. Ciao Hannes PS: FYI - draft-ietf-oauth-saml2-bearer and draft-ietf-oauth-jwt-bearer are not yet on the telechat agenda. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
