Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today

[John Bradley]

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

[OAUTH-WG] Missed comments on the assertion framework

[Brian Campbell]

There were some comments on the document made by Shawn Emery as part of a
security directorate's review
http://www.ietf.org/mail-archive/web/secdir/current/msg03679.html that seem
to have gotten lost in the shuffle.

His editorial comments are spot on and I believe the changes he suggests
should all be made. I'm not sure if a new draft or a RFC editor's note is
more appropriate at this stage?

The question about providing more guidance on the Assertion ID is a little
less straightforward. The JWT and SAML instances of the framework both
inherit some guidance from their respective token format definitions -
http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06#section-4.1.7and
§1.3.4 ID and ID Reference Values of saml-core-2.0-os. Perhaps that is
sufficient. If we were to add something to draft-ietf-oauth-assertions, I'd
probably look to borrow some text from one or both of those locations.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today

[Chuck Mortimore]

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] 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@ietf.org
Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today


Hiya,

So I'll take the lack of further discussion

Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today

[Brian Campbell]

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

Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today

[Mike Jones]

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 deploy 
> assertions with OAuth 2.0.
> 
> However, even with these instance documents an interoperable 
> implementation is not possible sinc

Re: [OAUTH-WG] OAuth Digest, Vol 51, Issue 58

[naz ahmed]

Sent from BlackBerry® on Airtel

-Original Message-
From: oauth-requ...@ietf.org
Date: Fri, 18 Jan 2013 17:47:23 
To: 
Subject: OAuth Digest, Vol 51, Issue 58


If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/oauth

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.



Send OAuth mailing list submissions to
    oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
    https://www.ietf.org/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
    oauth-requ...@ietf.org

You can reach the person managing the list at
    oauth-ow...@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today

[Stephen Farrell]

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

Re: [OAUTH-WG] error_description USASCII-encoded - is this a difficulty?

[Todd W Lainhart]

Hi  Hannes -

Providing localization support indirectly via the error_uri was the 
conclusion that we were coming to, so thanks for responding and confirming 
that.

Best wishes -- Todd




Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainh...@us.ibm.com




From:   Hannes Tschofenig 
To: Todd W Lainhart/Lexington/IBM@IBMUS, 
Cc: Hannes Tschofenig , oauth@ietf.org, 
oauth-boun...@ietf.org
Date:   01/18/2013 04:42 AM
Subject:Re: [OAUTH-WG] error_description USASCII-encoded - is this 
a difficulty?



Hi Todd, 

it is important to note that the error_description is not meant to be 
shown to the end users.
That was the reason for not introducing internationalization support. 

If you want to provide some additional information about the error 
description in other languages I would suggest to use the error_uri to 
point the developer to that information. 

Ciao
Hannes

On Jan 17, 2013, at 8:09 PM, Todd W Lainhart wrote:

> We're working on an OAuth 2.0 AS, with extensions defined for session 
mgmt.  We're trying to adopt uniformly the error reporting mechanism in 
6749. 
> 
> I'm now realizing that the error_description response in specified to be 
USASCII.  I was assuming that the error message could be UTF-8 encoded, 
such that I could return error messages in the client's locale.  E.G. 
consider the client credentials grant.  The store on the AS holding the 
registration is down, so I'd like to return a 500 with an error message 
from the store, from a catalog mapped to the client's language. 
> 
> I've wondered about adding an additional response parameter, something 
like error_description_locale, but thought that there might be better 
practices out there.  I'm also wondering about the USASCII constraint on 
error_description.  I'm a long-time reader of this list, but I'm not 
recalling the background on this.
> 
> 
> 
> 
> Todd Lainhart
> Rational software
> IBM Corporation
> 550 King Street, Littleton, MA 01460-1250
> 1-978-899-4705
> 2-276-4705 (T/L)
> lainh...@us.ibm.com
> 
> ___
> 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

[Tschofenig, Hannes (NSN - FI/Espoo)]

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

Re: [OAUTH-WG] error_description USASCII-encoded - is this a difficulty?

[Hannes Tschofenig]

Hi Todd, 

it is important to note that the error_description is not meant to be shown to 
the end users.
That was the reason for not introducing internationalization support. 

If you want to provide some additional information about the error description 
in other languages I would suggest to use the error_uri to point the developer 
to that information. 

Ciao
Hannes

On Jan 17, 2013, at 8:09 PM, Todd W Lainhart wrote:

> We're working on an OAuth 2.0 AS, with extensions defined for session mgmt.  
> We're trying to adopt uniformly the error reporting mechanism in 6749. 
> 
> I'm now realizing that the error_description response in specified to be 
> USASCII.  I was assuming that the error message could be UTF-8 encoded, such 
> that I could return error messages in the client's locale.  E.G. consider the 
> client credentials grant.  The store on the AS holding the registration is 
> down, so I'd like to return a 500 with an error message from the store, from 
> a catalog mapped to the client's language. 
> 
> I've wondered about adding an additional response parameter, something like 
> error_description_locale, but thought that there might be better practices 
> out there.  I'm also wondering about the USASCII constraint on 
> error_description.  I'm a long-time reader of this list, but I'm not 
> recalling the background on this.
> 
> 
> 
> 
> Todd Lainhart
> Rational software
> IBM Corporation
> 550 King Street, Littleton, MA 01460-1250
> 1-978-899-4705
> 2-276-4705 (T/L)
> lainh...@us.ibm.com
> 
> ___
> 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] Reminder: OAuth WG Conference Call, 21st January 2013, 1pm EST

[zhou . sujing]

I have some questions concerning the oauth-security document.
1. collusion 
Only collusion between resource servers are considered, 
 however, collusion between resource server and client could happen.
2. AS-to-RS relationship anonymity
   if "the Client must not provide information about the Resource Server 
in the access token request." 
  then how AS can encrypt access token using the key shared between AS　
and RS?
  I feel this requirement is unclear and conflict with some security 
measures that might be taken in OAuth 2.0.
3. Compromise of client， RS have been considered (separately)
   But the result of their compromise may not be limited to "client 
accessing more resources ",
it could be compromised client/RS  redirect RO to a manipulated AS 
phishing RO's credential, for example. 



 



oauth-boun...@ietf.org 写于 2013-01-17 21:43:26:

> Hi all, 
> 
> We will have our next OAuth conference call on the 21st January 
> 2013, 1pm EST (for roughly one hour).
> 
> John & Nat kindly offered their conference bridge. It is the same 
> bridge we used before.
> https://www3.gotomeeting.com/join/695548174
> 
> We will continue where we stopped last time, namely we stopped our 
> discussions at the crypto agility requirement 
> (first requirement in http://tools.ietf.org/html/draft-tschofenig-
> oauth-security-01#section-5). 
> 
> Here is the slide set I used last time:
> http://www.tschofenig.priv.at/OAuth2-Security-11Jan2013.ppt
> (We stopped at slide #2.)
> 
> We also did not manage to get to discuss the use case Justin raised 
> at the first conference call. He distributed a writeup on the list:
> http://www.ietf.org/mail-archive/web/oauth/current/msg10407.html
> 
> Ciao
> Hannes & Derek
> 
> PS: I will try to distribute my meeting minute notes from the 
> previous call by tomorrow. 
> 
> ___
> 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