JSON Web Token (JWT) Bearer Token = Profiles for OAuth 2.0

<internet-drafts@ietf.org> · Wed, 6 Feb 2013 11:24:20 -0800

___________________=
____________________________
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
_______________________________________________
O=
Auth mailing list
OAu=
th@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<=
/pre>
______=
_________________________________________
OAuth =
mailing list
OAuth@ietf.org
https://www.ietf.org=
/mailman/listinfo/oauth
"scope": ["read", "write",
"dolphin"],

  scope = scope-token *( SP scope-token )

     scope-token = 1*( %x21 / %x23-5B / %x5D-7E )
_______________________________________________

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

"scope": ["read", "write", =
"dolphin"],

 scope =3D scope-token *( SP scope-token )

    scope-token =3D 1*( %x21 / %x23-5B / %x5D-7E )
_______________________________________________

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

"scope": =
["read", "write", "dolphin"],
 scope =3D scope-token *( SP scope-token =
)
    scope-token =3D 1*( %x21 / %x23-5B / %x5D-7E =
)
______________________________________________=
_
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
Only if it's
optional, and informational from the client's behalf. Would you define
"access" and "refresh" values here, with a means for
other specs (like OIDC) to put in their own values (like "id_token")?

On Feb 3, 2013, at 8:01 AM, Torsten Lodderstedt <torsten@lodderstedt.net>
wrote:

> Hi all,

> 

> before I publish a new revision of the draft, I would like to sort
out the following issues and would like to ask you for your feedback.

> 

> - Authorization vs. access grant vs. authorization grant: I propose
to use "authorization grant".

+1 to authorization grant

> - invalid_token error code: I propose to use the new error code "invalid_parameter"
(as suggested by Peter and George). I don't see the need to register it
(see 
http://www.ietf.org/mail-archive/web/oauth/current/msg10604.html
)
but would like to get your advice.

something more like "invalid_token_parameter" would maybe make
sense, since it's not just *any* parameter, it's the special "token"
parameter that we're talking about, but it's distinct from the invalid_token
response. The introspection endpoint uses the same pattern of a token=
parameter, but since the whole point of the introspection endpoint is determining
token validity it doesn't actually throw an error here. 

I agree that it doesn't need to be registered (since it's on a different
endpoint).

> - Donald F. Coffin raised the need for a token_type parameter to the
revocation request. Shall we re-consider this topic?

> 

Only if it's optional, and informational from the client's behalf. Would
you define "access" and "refresh" values here, with
a means for other specs (like OIDC) to put in their own values (like "id_token")?

 -- Justin

> best regards,

> Torsten.

> _______________________________________________

> 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

_______________________________________________=0AOAuth mailing =
list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth=0A
_______________________________________________
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

Could it do
something with invalid_parameter that it couldn't do with invalid_token_parameter
(among others), or vice versa? 

On Feb 4, 2013, at 3:57 PM, George Fletcher <gffletch@aol.com>

 wrote:

> 

> On 2/4/13 3:41 PM, Richer, Justin P. wrote:

>> On Feb 3, 2013, at 8:01 AM, Torsten Lodderstedt <torsten@lodderstedt.net>
wrote:

>> 

>> 

>>> - invalid_token error code: I propose to use the new error
code "invalid_parameter" (as suggested by Peter and George).
I don't see the need to register it (see 
http://www.ietf.org/mail-archive/web/oauth/current/msg10604.html
)
but would like to get your advice.

>> something more like "invalid_token_parameter" would
maybe make sense, since it's not just *any* parameter, it's the special
"token" parameter that we're talking about, but it's distinct
from the invalid_token response. The introspection endpoint uses the same
pattern of a token= parameter, but since the whole point of the introspection
endpoint is determining token validity it doesn't actually throw an error
here.

>> 

>> I agree that it doesn't need to be registered (since it's on a
different endpoint).

> For what it's worth my thinking was that if we have an 'invalid_parameter'
error, then the description can define which parameter is invalid. I don't
think we should create a bunch of specific error values that are endpoint
specific and could overlap which is where the whole error return value
started.

> 

Hm, I see what you're saying, but the error response is already endpoint
specific. Though there is value in not having conflicting and/or confusing
responses from different endpoints that use the same error code for different
things. 

What it really comes down to is: what can the client do with this error?
Could it do something with invalid_parameter that it couldn't do with invalid_token_parameter
(among others), or vice versa? As I'm writing this out, I'm not convinced
that it could, really, so this may be a bike shedding argument.

 -- Justin

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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

Could it do
something with invalid_parameter that it couldn't do with invalid_token_parameter
(among others), or vice versa? 

On Feb 4, 2013, at 3:57 PM, George Fletcher <gffletch@aol.com>

 wrote:

> 

> On 2/4/13 3:41 PM, Richer, Justin P. wrote:

>> On Feb 3, 2013, at 8:01 AM, Torsten Lodderstedt <torsten@lodderstedt.net>
wrote:

>> 

>> 

>>> - invalid_token error code: I propose to use the new error
code "invalid_parameter" (as suggested by Peter and George).
I don't see the need to register it (see 
http://www.ietf.org/mail-archive/web/oauth/current/msg10604.html
)
but would like to get your advice.

>> something more like "invalid_token_parameter" would
maybe make sense, since it's not just *any* parameter, it's the special
"token" parameter that we're talking about, but it's distinct
from the invalid_token response. The introspection endpoint uses the same
pattern of a token= parameter, but since the whole point of the introspection
endpoint is determining token validity it doesn't actually throw an error
here.

>> 

>> I agree that it doesn't need to be registered (since it's on a
different endpoint).

> For what it's worth my thinking was that if we have an 'invalid_parameter'
error, then the description can define which parameter is invalid. I don't
think we should create a bunch of specific error values that are endpoint
specific and could overlap which is where the whole error return value
started.

> 

Hm, I see what you're saying, but the error response is already endpoint
specific. Though there is value in not having conflicting and/or confusing
responses from different endpoints that use the same error code for different
things. 

What it really comes down to is: what can the client do with this error?
Could it do something with invalid_parameter that it couldn't do with invalid_token_parameter
(among others), or vice versa? As I'm writing this out, I'm not convinced
that it could, really, so this may be a bike shedding argument.

 -- Justin

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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

Could it do
              something with invalid_parameter that it couldn't do with
              invalid_token_parameter
              (among others), or vice versa? 

              On Feb 4, 2013, at 3:57 PM, George Fletcher <gffletch@aol.com>

              wrote:

              > 

              > On 2/4/13 3:41 PM, Richer, Justin P. wrote:

              >> On Feb 3, 2013, at 8:01 AM, Torsten Lodderstedt
              <torsten@lodderstedt.net>
              wrote:

              >> 

              >> 

              >>> - invalid_token error code: I propose to use
              the new error
              code "invalid_parameter" (as suggested by Peter and
              George).
              I don't see the need to register it (see 
http://www.ietf.org/mail-archive/web/oauth/current/msg10604.html
)
              but would like to get your advice.

              >> something more like "invalid_token_parameter"
              would
              maybe make sense, since it's not just *any* parameter,
              it's the special
              "token" parameter that we're talking about, but it's
              distinct
              from the invalid_token response. The introspection
              endpoint uses the same
              pattern of a token= parameter, but since the whole point
              of the introspection
              endpoint is determining token validity it doesn't actually
              throw an error
              here.

              >> 

              >> I agree that it doesn't need to be registered
              (since it's on a
              different endpoint).

              > For what it's worth my thinking was that if we have
              an 'invalid_parameter'
              error, then the description can define which parameter is
              invalid. I don't
              think we should create a bunch of specific error values
              that are endpoint
              specific and could overlap which is where the whole error
              return value
              started.

              > 

              Hm, I see what you're saying, but the error response is
              already endpoint
              specific. Though there is value in not having conflicting
              and/or confusing
              responses from different endpoints that use the same error
              code for different
              things. 

              What it really comes down to is: what can the client do
              with this error?
              Could it do something with invalid_parameter that it
              couldn't do with invalid_token_parameter
              (among others), or vice versa? As I'm writing this out,
              I'm not convinced
              that it could, really, so this may be a bike shedding
              argument.

              -- Justin

              _______________________________________________

              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

Could it do
              something with invalid_parameter that it couldn't do with
              invalid_token_parameter
              (among others), or vice versa? 

              On Feb 4, 2013, at 3:57 PM, George Fletcher <gffletch@aol.com>

              wrote:

              > 

              > On 2/4/13 3:41 PM, Richer, Justin P. wrote:

              >> On Feb 3, 2013, at 8:01 AM, Torsten Lodderstedt
              <torsten@lodderstedt.net>
              wrote:

              >> 

              >> 

              >>> - invalid_token error code: I propose to use
              the new error
              code "invalid_parameter" (as suggested by Peter and
              George).
              I don't see the need to register it (see 
http://www.ietf.org/mail-archive/web/oauth/current/msg10604.html
)
              but would like to get your advice.

              >> something more like "invalid_token_parameter"
              would
              maybe make sense, since it's not just *any* parameter,
              it's the special
              "token" parameter that we're talking about, but it's
              distinct
              from the invalid_token response. The introspection
              endpoint uses the same
              pattern of a token= parameter, but since the whole point
              of the introspection
              endpoint is determining token validity it doesn't actually
              throw an error
              here.

              >> 

              >> I agree that it doesn't need to be registered
              (since it's on a
              different endpoint).

              > For what it's worth my thinking was that if we have
              an 'invalid_parameter'
              error, then the description can define which parameter is
              invalid. I don't
              think we should create a bunch of specific error values
              that are endpoint
              specific and could overlap which is where the whole error
              return value
              started.

              > 

              Hm, I see what you're saying, but the error response is
              already endpoint
              specific. Though there is value in not having conflicting
              and/or confusing
              responses from different endpoints that use the same error
              code for different
              things. 

              What it really comes down to is: what can the client do
              with this error?
              Could it do something with invalid_parameter that it
              couldn't do with invalid_token_parameter
              (among others), or vice versa? As I'm writing this out,
              I'm not convinced
              that it could, really, so this may be a bike shedding
              argument.

              -- Justin

              _______________________________________________

              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

_______=
________________________________________=0AOAuth mailing list=0AOAuth@ietf.=
org=0Ahttps=
://www.ietf.org/mailman/listinfo/oauth=0A
_______________________________________________
OAuth mailing list
OAuth@=
ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Could it do something with
                    invalid_parameter that it couldn't do with
                    invalid_token_parameter (among others), or vice
                    versa? 

                    On Feb 4, 2013, at 3:57 PM, George Fletcher <gffletch@aol.com>

                    wrote:

                    > 

                    > On 2/4/13 3:41 PM, Richer, Justin P. wrote:

                    >> On Feb 3, 2013, at 8:01 AM, Torsten
                    Lodderstedt <torsten@lodderstedt.net>

                    wrote:

                    >> 

                    >> 

                    >>> - invalid_token error code: I propose
                    to use the new error code "invalid_parameter" (as
                    suggested by Peter and George). I don't see the need
                    to register it (see 
http://www.ietf.org/mail-archive/web/oauth/current/msg10604.html
) but would like to get your advice.

                    >> something more like
                    "invalid_token_parameter" would maybe make sense,
                    since it's not just *any* parameter, it's the
                    special "token" parameter that we're talking about,
                    but it's distinct from the invalid_token response.
                    The introspection endpoint uses the same pattern of
                    a token= parameter, but since the whole point of the
                    introspection endpoint is determining token validity
                    it doesn't actually throw an error here.

                    >> 

                    >> I agree that it doesn't need to be
                    registered (since it's on a different endpoint).

                    > For what it's worth my thinking was that if we
                    have an 'invalid_parameter' error, then the
                    description can define which parameter is invalid. I
                    don't think we should create a bunch of specific
                    error values that are endpoint specific and could
                    overlap which is where the whole error return value
                    started.

                    > 

                    Hm, I see what you're saying, but the error response
                    is already endpoint specific. Though there is value
                    in not having conflicting and/or confusing responses
                    from different endpoints that use the same error
                    code for different things. 

                    What it really comes down to is: what can the client
                    do with this error? Could it do something with
                    invalid_parameter that it couldn't do with
                    invalid_token_parameter (among others), or vice
                    versa? As I'm writing this out, I'm not convinced
                    that it could, really, so this may be a bike
                    shedding argument.

                    -- Justin

                    _______________________________________________

                    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

Could it
do something with invalid_parameter that it couldn't do with invalid_token_parameter
(among others), or vice versa? 

On Feb 4, 2013, at 3:57 PM, George Fletcher <
gffletch@aol.com
>

wrote:

> 

> On 2/4/13 3:41 PM, Richer, Justin P. wrote:

>> On Feb 3, 2013, at 8:01 AM, Torsten Lodderstedt <
torsten@lodderstedt.net
>
wrote:

>> 

>> 

>>> - invalid_token error code: I propose to use the new error
code "invalid_parameter" (as suggested by Peter and George).
I don't see the need to register it (see 
http://www.ietf.org/mail-archive/web/oauth/current/msg10604.html
)
but would like to get your advice.

>> something more like "invalid_token_parameter" would
maybe make sense, since it's not just *any* parameter, it's the special
"token" parameter that we're talking about, but it's distinct
from the invalid_token response. The introspection endpoint uses the same
pattern of a token= parameter, but since the whole point of the introspection
endpoint is determining token validity it doesn't actually throw an error
here.

>> 

>> I agree that it doesn't need to be registered (since it's on a
different endpoint).

> For what it's worth my thinking was that if we have an 'invalid_parameter'
error, then the description can define which parameter is invalid. I don't
think we should create a bunch of specific error values that are endpoint
specific and could overlap which is where the whole error return value
started.

> 

Hm, I see what you're saying, but the error response is already endpoint
specific. Though there is value in not having conflicting and/or confusing
responses from different endpoints that use the same error code for different
things. 

What it really comes down to is: what can the client do with this error?
Could it do something with invalid_parameter that it couldn't do with invalid_token_parameter
(among others), or vice versa? As I'm writing this out, I'm not convinced
that it could, really, so this may be a bike shedding argument.

-- Justin

_______________________________________________

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

Subject: Re: [OAUTH-WG] Why OAuth it self is not an authentication framework ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Feb 2013 00:48:36 -0000

--1458549034-106740509-1360111712=:54487
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Why use OAuth when OpenID does everything that OAuth can do as an authentic=
ation method and does a few things much better?=0A=0ASpecifically OAuth lac=
ks any defined way to:=0A=0A-feed back any additional information like the =
real user ID (as opposed to what the entered)=0A-bound an authentication ev=
ent in time=0A-provide any form of additional SSO payload like a display na=
me for the user=0A=0Athere's probably other things.=0A=0AIt'll mostly work =
but there are things it doesn't do. =C2=A0Could you solve some of the rest =
of this with token introspection or a user API that the RP could use to fet=
ch user info, sure, but why rebuild OpenID when OpenID exists?=0A=0A-bill=
=0A=0A=0A=0A________________________________=0A From: Lewis Adam-CAL022 =0ATo: Tim Bray ; William=
 Mills  =0ACc: "oauth@ietf.org WG" =
 =0ASent: Tuesday, February 5, 2013 2:27 PM=0ASubject: RE: [OAUTH-WG] Why O=
Auth it self is not an authentication framework ?=0A =0A=0A =0AI think this=
 is becoming a largely academic / philosophical argument by this time.=C2=
=A0 The people who designed OAuth will likely point out that it was concept=
ualized as an authorization protocol to enable a RO to delegate access to a=
 client to access its protected resources on some RS.=C2=A0 And of course t=
his is the history of it.=C2=A0 And the RO and end-user were typically the =
same entity.=C2=A0 But get caught up in what it was envisioned to do vs. re=
al life use cases that OAuth can solve (and is solving) beyond its initial =
use cases misses the point =E2=80=A6 because OAuth is gaining traction in t=
he enterprise and will be used in all different sorts of ways, including au=
thentication.=C2=A0 =0A=C2=A0=0AThis is especially true of RESTful APIs wit=
hin an enterprise where the RO and end-user are *not* the same: e.g. RO=3De=
nterprise and end-user=3Demployee.=C2=A0 In this model the end-user is not =
authorizing anything when their client requests a token from the AS =E2=80=
=A6 they authenticate to the AS and the client gets an AT, which will likel=
y be profiled by most enterprise deployments to look something like an OIDC=
 id_token.=C2=A0 The AT will be presented to the RS which will examine the =
claims (user identity, LOA, etc.) and make authorization decisions based on=
 business logic.=C2=A0 The AT has not authorized the user to do anything, i=
t has only made an assertion that the user has been authenticated by the AS=
 (sort of sounds a lot like an IdP now).=0A=C2=A0=0AAll this talked of OAut=
h being authorization and not authentication was extremely confusing to me =
when I first started looking at OAuth for my use cases, and I think at some=
 point the authors of OAuth are going to have to recognize that their baby =
has grown up to be multi-faceted (and I mean this as a complement).=C2=A0 T=
he abstractions left in the OAuth spec (while some have claimed of the lack=
 of interoperability it will cause) will also enable it to be used in ways =
possibly still not envisioned by any of us.=C2=A0 I think as soon as we can=
 stop trying to draw the artificial line around OAuth being =E2=80=9Can aut=
horization protocol=E2=80=9D the better things will be. =0A=C2=A0=0AI like =
to say that they authors had it right when they named it =E2=80=9COAuth=E2=
=80=9D and not =E2=80=9COAuthR=E2=80=9D J=0A=C2=A0=0A-adam=0A=C2=A0=0AFrom:=
oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Tim Bra=
y=0ASent: Tuesday, February 05, 2013 3:28 PM=0ATo: William Mills=0ACc: oaut=
h@ietf.org WG=0ASubject: Re: [OAUTH-WG] Why OAuth it self is not an authent=
ication framework ?=0A=C2=A0=0AOIDC seems about the most plausible candidat=
e for a =E2=80=9Cgood general solution=E2=80=9D that I=E2=80=99m aware of. =
=C2=A0 -T=0AOn Tue, Feb 5, 2013 at 1:22 PM, William Mills  wrote:=0AThere are some specific design mis-matches for OAuth as an=
 authentication protocol, it's not what it's designed for and there are som=
e problems you will run into. =C2=A0Some have used it as such, but it's not=
 a good general solution.=0A=C2=A0=0A-bill=0A=C2=A0=0A=0A__________________=
______________=0A =0AFrom:Paul Madsen =0ATo: John Br=
adley  =0ACc: "oauth@ietf.org WG"  =0ASe=
nt: Tuesday, February 5, 2013 1:12 PM=0ASubject: Re: [OAUTH-WG] Why OAuth i=
t self is not an authentication framework ?=0A=C2=A0=0Awhy pigeonhole it? =
=0A=0AOAuth can be deployed with no authz semantics at all (or at least as =
little as any authn mechanism), e.g client creds grant type with no scopes=
=0A=0AI agree that OAuth is not an *SSO* protocol.=0AOn 2/5/13 3:36 PM, Joh=
n Bradley wrote:=0AOAuth is an Authorization protocol as many of us have po=
inted out. =0A>=C2=A0=0A>The post is largely correct and based on one of mi=
ne.=0A>=C2=A0=0A>John B.=0A>=C2=A0=0A>On 2013-02-05, at 12:52 PM, Prabath S=
iriwardena  wrote:=0A>=C2=A0=0A>FYI and for your comments=
.. =0A>>=C2=A0=0A>>http://blog.facilelogin.com/2013/02/why-oauth-it-self-is=
-not-authentication.html=0A>>=0A>>=C2=A0=0A>>Thanks & Regards,=0A>>Prabath =
=0A>>=C2=A0=0A>>Mobile : +94 71 809 6732=C2=A0=0A>>http://blog.facilelogin.=
com/=0A>>http://rampartfaq.com/=0A>>_______________________________________=
________=0A>>OAuth mailing list=0A>>OAuth@ietf.org=0A>>https://www.ietf.org=
/mailman/listinfo/oauth=0A>=C2=A0=0A>=C2=A0=0A>____________________________=
___________________=0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https://www.=
ietf.org/mailman/listinfo/oauth=0A=C2=A0=0A=0A_____________________________=
__________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf=
.org/mailman/listinfo/oauth=0A=0A=0A=0A____________________________________=
___________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/ma=
ilman/listinfo/oauth
--1458549034-106740509-1360111712=:54487
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Why =
use OAuth when OpenID does everything that OAuth can do as an authenticatio=
n method and does a few things much better?

Specifically OAuth lacks any defined way to:

-=09feed back any additional information like=
 the
 real user ID (as opposed to what the entered)
-=
=09bound an=
 authentication event in time
-=09provide any form of addit=
ional SSO payload like a display name for the user

there's probably other things.

It'll mostly work but there are things=
 it doesn't do.  Could you solve some of the rest of this with token i=
ntrospection or a user API that the RP could use to fetch user info, sure, =
but why rebuild OpenID when OpenID exists?

<=
/div>-bill

        <=
b>From: Lewis Adam-CAL022 <=
Adam.Lewis@motorolasolutions.com>
 To: Tim Bray <twbray@google.com>; William Mills <wm=
ills_92105@yahoo.com> 
Cc:
 "oauth@ietf.org WG" <oauth@ietf.org> 
 Sent: Tuesday, February 5, 2013 2:27 PM
 Subject: RE: [OAUTH-WG] Why OAuth =
it self is not an authentication framework ?

=0A=0A=0A =0A =0A=0A=0A=0A=0AI think this is becoming a largely academic / philosop=
hical argument by this time.  The people who designed OAuth will likel=
y point out that it was conceptualized=0A as an authorization protocol to e=
nable a RO to delegate access to a client to access its protected resources=
 on some RS.  And of course this is the history of it.  And the R=
O and end-user were typically the same entity.  But get caught up in w=
hat it was envisioned=0A to do vs. real life use cases that OAuth can solve=
 (and is solving) beyond its initial use cases misses the point =E2=80=A6 b=
ecause OAuth is gaining traction in the enterprise and will be used in all =
different sorts of ways, including authentication. =0A =
=0A  
 =0A<=
span style=3D"font-size:10.5pt;color:olive;">This is especially true of RES=
Tful APIs within an enterprise where the RO and end-user are *not* t=
he same: e.g. RO=3Denterprise and end-user=3Demployee.  In=0A this mod=
el the end-user is not authorizing anything when their client requests a to=
ken from the AS =E2=80=A6 they authenticate to the AS and the client gets a=
n AT, which will likely be profiled by most enterprise deployments to look =
something like an OIDC id_token. =0A The AT will be presented to the R=
S which will examine the claims (user identity, LOA, etc.) and make authori=
zation decisions based on business logic.  The AT has not authorized t=
he user to do anything, it has only made an assertion that the user has bee=
n authenticated=0A by the AS (sort of sounds a lot like an IdP now).=
 =0A  
 =0AAll this talked of OAut=
h being authorization and not authentication was extremely confusing to me =
when I first started looking at OAuth for my use cases, and=0A I think at s=
ome point the authors of OAuth are going to have to recognize that their ba=
by has grown up to be multi-faceted (and I mean this as a complement). =
; The abstractions left in the OAuth spec (while some have claimed of the l=
ack of interoperability=0A it will cause) will also enable it to be used in=
 ways possibly still not envisioned by any of us.  I think as soon as =
we can stop trying to draw the artificial line around OAuth being =E2=80=9C=
an authorization protocol=E2=80=9D the better things will be.=0A =0A  
 =0AI like to say that they aut=
hors had it right when they named it =E2=80=9COAuth=E2=80=9D and not =E2=80=
=9COAuthR=E2=80=9D=0AJ
 =0A  
 =0A-adam
 =0A  
 =0A=0AFrom: oauth-bounces@ietf.org [mailto:oauth-bounc=
es@ietf.org]=0AOn Behalf Of Tim Bray
=0ASent: Tuesday, Feb=
ruary 05, 2013 3:28 PM
=0ATo: William Mills
=0ACc: oaut=
h@ietf.org WG
=0ASubject: Re: [OAUTH-WG] Why OAuth it self is not=
 an authentication framework ?
 =0A
=0A  
 =0AOIDC seems about the most plausible candidat=
e for a =E2=80=9Cgood general solution=E2=80=9D that I=E2=80=99m aware of. =
  -T
 =0A=0AOn Tue, Fe=
b 5, 2013 at 1:22 PM, William Mills <wmills_92105@yahoo.com> wrote:
 =0A=0A=0A=0AThere are some =
specific design mis-matches for OAuth as an authentication protocol, it's n=
ot what it's designed for and there are some problems you will run into. &n=
bsp;Some have used it as such,=0A but it's not a good general solution.
 =0A
=0A=0A  
 =0A
=0A=0A-bill
 =0A
=0A=0A   =0A<=
/div>=0A=0A=0A=0A=0A
=0A
=0AFrom: Paul M=
adsen <paul.madsen@gmail.com>
=0ATo: John Bradley <=
ve7jtb@ve7jtb.com>=0A
=0ACc: "oauth@ietf.org WG" <oauth@ietf.org&=
gt;=0A
=0ASent: Tuesday, February 5, 2013 1:12 PM
=0ASubjec=
t: Re: [OAUTH-WG] Why OAuth it self is not an authentication framework =
?
 =0A
=0A   =0A=0A=0A=0Awhy pigeonhole it?=0A
=0A=0AOAuth can be deployed with no authz semantics at all (or at least as li=
ttle as any authn mechanism), e.g client creds grant type with no scopes=0A
=0AI agree that OAuth is not an *SSO* protocol.
 =0A=0AOn 2/5/13 3:36 PM, John Bradley =
wrote:
 =0A
=0A
=0A=0A=0AOAuth i=
s an Authorization protocol as many of us have pointed out.=0A
 =0A=0A  
 =0A
=0A=
=0AThe post is largely correct and ba=
sed on one of mine.
 =0A
=0A=0A  
 =0A
=0A=0AJohn B.
 =0A
=0A
=0A=0A  
 =0A=0A=0A=0AOn 2013-02-05, at 12:52 PM, Prabath Siriwardena <prabath@wso2.com> wrote:
 =0A=
=0A  
 =0A
=0A=0A=0AFYI and for your comments.. 
 =0A=0A<=
div class=3D"yiv2141144710MsoNormal">  
 =0A
=0A
=0A=0A=0Ahttp://blog.facilelogin.=
com/2013/02/why-oauth-it-self-is-not-authentication.html
=
=0A
 =0A=0A  =0A=
=0AThanks & Regards,
=0A=
Prabath 
 =0A=0A   =0A
=0A
=0A=0A=0AMobile : =
=0A+94 71 809 6732 
 =0A
=0Ahttp://blog.facilelogin.com/
=0Ahttp://rampartfaq.com/ =
=0A
=0A
=0A=0A________=
_______________________________________
=0AOAuth mailing list
=0AOAuth@ietf.org
=0Ahttps://ww=
w.ietf.org/mailman/listinfo/oauth
 =0A
=0A
_______________________________________________
OAuth mailing list
OAuth@=
ietf.org
https://www.ietf.org/mailman/lis=
tinfo/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

That document
is not even a working group item. 
Hi Todd, 

two answers:

1) Token Revocation:

I had initiated a Working Group Last Call for the token revocation document
end of November:

http://www.ietf.org/mail-archive/web/oauth/current/msg10102.html

As you have seen on the list, this has generated a fair amount of discussion.

I hope that Torsten, the draft editor, is able to produce a new draft version
quickly with a resolution of the open issues that is acceptable to the
rest of the group. 

Then, we will have to judge whether the document can move forward to the
IESG. 

2) Introspection

That document is not even a working group item. 

Ciao

Hannes

On Feb 6, 2013, at 4:26 PM, Todd W Lainhart wrote:

> Does anyone have any intuition as to how far away we are on last call
for introspection and revocation? 

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

-- 
Thanks &=
amp; Regards,
Prabath
Mobile : +94 71 809 6732=A0
=

http://blog.f=
acilelogin.com

http://RampartFAQ.com

--047d7b624ab8fc455c04d50fa568--

From lainhart@us.ibm.com  Wed Feb  6 07:06:34 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9732C21F87A5 for ; Wed,  6 Feb 2013 07:06:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.537
X-Spam-Level: 
X-Spam-Status: No, score=-10.537 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83Th4-cvYXzX for ; Wed,  6 Feb 2013 07:06:33 -0800 (PST)
Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id 63F3221F8759 for ; Wed,  6 Feb 2013 07:06:33 -0800 (PST)
Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for  from ; Wed, 6 Feb 2013 10:06:31 -0500
Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted;  Wed, 6 Feb 2013 10:06:29 -0500
Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 4B30F6E8021 for ; Wed,  6 Feb 2013 10:06:27 -0500 (EST)
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r16F6SlG24969234 for ; Wed, 6 Feb 2013 10:06:28 -0500
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r16F6SRG032645 for ; Wed, 6 Feb 2013 10:06:28 -0500
Received: from d01ml255.pok.ibm.com (d01ml255.pok.ibm.com [9.63.10.54]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r16F6M3l032161; Wed, 6 Feb 2013 10:06:23 -0500
In-Reply-To: <51126F01.3010605@mitre.org>
References:  <64485787-77EE-4715-94E3-0A500992CDF2@gmx.net> <51126F01.3010605@mitre.org>
To: Justin Richer 
MIME-Version: 1.0
X-KeepSent: 2FACACEF:7751146F-85257B0A:0052D0AD; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3FP2 SHF22 July 19, 2012
Message-ID: 
From: Todd W Lainhart 
Date: Wed, 6 Feb 2013 10:06:15 -0500
X-MIMETrack: Serialize by Router on D01ML255/01/M/IBM(Release 8.5.3FP2 ZX853FP2HF4|December 14, 2012) at 02/06/2013 10:06:23, Serialize complete at 02/06/2013 10:06:23
Content-Type: multipart/alternative; boundary="=_alternative 0052F83285257B0A_="
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 13020615-7182-0000-0000-00000505DBDA
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] How soon until last call on introspection and revocation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Feb 2013 15:06:34 -0000

This is a multipart message in MIME format.
--=_alternative 0052F83285257B0A_=
Content-Type: text/plain; charset="US-ASCII"

>That said, it doesn't mean we can't all just *work* on it...

Agreed.  Thanks for the clarification.

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

From:   Justin Richer 
To:     Hannes Tschofenig , 
Cc:     Todd W Lainhart/Lexington/IBM@IBMUS, IETF oauth WG 

Date:   02/06/2013 09:57 AM
Subject:        Re: [OAUTH-WG] How soon until last call on introspection 
and revocation

As editor of introspection draft, I would like to see it become a 
working group item. After talking with the chairs, there appears to be 
some friction with the amount of open working items that the working 
group has right now, though, leading to hesitation to add more to our 
official plate.

That said, it doesn't mean we can't all just *work* on it, and I'm 
actively editing it based on feedback. We're implementing and deploying 
it in our own systems right now, too. I'm tracking issues to the draft 
here if you have any direct changes (or pull requests!):

   https://github.com/jricher/oauth-spec/issues

So I hope that we can at least stabilize the functionality of the spec 
so that by the time the IETF process can start to chew on it in an 
official fashion, it will be mostly baked and we can run it through 
relatively quickly.

  -- Justin

On 02/06/2013 09:45 AM, Hannes Tschofenig wrote:
> Hi Todd,
>
> two answers:
>
> 1) Token Revocation:
>
> I had initiated a Working Group Last Call for the token revocation 
document end of November:
> http://www.ietf.org/mail-archive/web/oauth/current/msg10102.html
>
> As you have seen on the list, this has generated a fair amount of 
discussion.
>
> I hope that Torsten, the draft editor, is able to produce a new draft 
version quickly with a resolution of the open issues that is acceptable to 
the rest of the group.
>
> Then, we will have to judge whether the document can move forward to the 
IESG.
>
> 2) Introspection
>
> That document is not even a working group item.
>
> Ciao
> Hannes
>
> On Feb 6, 2013, at 4:26 PM, Todd W Lainhart wrote:
>
>> Does anyone have any intuition as to how far away we are on last call 
for introspection and revocation?
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--=_alternative 0052F83285257B0A_=
Content-Type: text/html; charset="US-ASCII"

>That said,
it doesn't mean we can't all just *work* on it...

Agreed.  Thanks for the clarification.

Todd Lainhart

Rational software

IBM Corporation

550 King Street, Littleton, MA 01460-1250

1-978-899-4705

2-276-4705 (T/L)

lainhart@us.ibm.com

From:      
 Justin Richer <jricher@mitre.org>

To:      
 Hannes Tschofenig <hannes.tschofenig@gmx.net>,

Cc:      
 Todd W Lainhart/Lexington/IBM@IBMUS,
IETF oauth WG <oauth@ietf.org>

Date:      
 02/06/2013 09:57 AM

Subject:    
   Re: [OAUTH-WG]
How soon until last call on introspection and revocation

As editor of introspection draft, I would like to
see it become a 

working group item. After talking with the chairs, there appears to be

some friction with the amount of open working items that the working 

group has right now, though, leading to hesitation to add more to our 

official plate.

That said, it doesn't mean we can't all just *work* on it, and I'm 

actively editing it based on feedback. We're implementing and deploying

it in our own systems right now, too. I'm tracking issues to the draft

here if you have any direct changes (or pull requests!):

   https://github.com/jricher/oauth-spec/issues

So I hope that we can at least stabilize the functionality of the spec

so that by the time the IETF process can start to chew on it in an 

official fashion, it will be mostly baked and we can run it through 

relatively quickly.

  -- Justin

On 02/06/2013 09:45 AM, Hannes Tschofenig wrote:

> Hi Todd,

>

> two answers:

>

> 1) Token Revocation:

>

> I had initiated a Working Group Last Call for the token revocation
document end of November:

> http://www.ietf.org/mail-archive/web/oauth/current/msg10102.html

>

> As you have seen on the list, this has generated a fair amount of
discussion.

>

> I hope that Torsten, the draft editor, is able to produce a new draft
version quickly with a resolution of the open issues that is acceptable
to the rest of the group.

>

> Then, we will have to judge whether the document can move forward
to the IESG.

>

> 2) Introspection

>

> That document is not even a working group item.

>

> Ciao

> Hannes

>

> On Feb 6, 2013, at 4:26 PM, Todd W Lainhart wrote:

>

>> Does anyone have any intuition as to how far away we are on last
call for introspection and revocation?

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org

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

--=_alternative 0052F83285257B0A_=--

From prabath@wso2.com  Wed Feb  6 07:13:51 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8665421F85B2 for ; Wed,  6 Feb 2013 07:13:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.67
X-Spam-Level: 
X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=0.306,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snfADvYaAaAx for ; Wed,  6 Feb 2013 07:13:50 -0800 (PST)
Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by ietfa.amsl.com (Postfix) with ESMTP id 39A8721F8481 for ; Wed,  6 Feb 2013 07:13:50 -0800 (PST)
Received: by mail-ee0-f45.google.com with SMTP id b57so817712eek.4 for ; Wed, 06 Feb 2013 07:13:49 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=v1fiQGs3MW7kv+NOT0Q6EEnN4bcCfxewcndUoUWMpwk=; b=kaIuNye531kZoxCxrGGTgPO4SSpvyl0osz/t8YDu+BdaVw+1wdTqJ9R6dtgZFhQhV5 Rgvx/1oTaLKsTDusvBRJyqt2zKIgHM4/H816jazfMZngfK1XIO4Yp+XzMh/eGVUdF7CT MrxVGeYzNqbOXZXi12Dcn7XdaoWFodiAPlt3T4hufmhL9LMXU1Q/jM07iHiigUO1OFbM maQW7wpR3h3hPFPdbCuFt0rLJUBkTpwZsMul7drSiR3vxHvqGGZH/vUpm840S1L5jnrH Ea+h4mhaqzh/CfkFFZ5di5xmQoRbhcsMKAqlyl6iUo0Sl6+rc9V1DDSKFuhAHsAxInQm MAOw==
MIME-Version: 1.0
X-Received: by 10.14.203.3 with SMTP id e3mr98137999eeo.9.1360163629175; Wed, 06 Feb 2013 07:13:49 -0800 (PST)
Received: by 10.223.175.134 with HTTP; Wed, 6 Feb 2013 07:13:49 -0800 (PST)
In-Reply-To: <51126D65.2090707@mitre.org>
References:  <51126D65.2090707@mitre.org>
Date: Wed, 6 Feb 2013 20:43:49 +0530
Message-ID: 
From: Prabath Siriwardena 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=047d7b343b2af413b204d50fc53b
X-Gm-Message-State: ALoCoQk7j08RjbURYWtYyJUp+wECuhXLaTtjs+MENg//BYVsO3tMwe+pmc3U4yCWeRs5Tjefnl/r
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] A question on token revocation.
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Feb 2013 15:13:51 -0000

--047d7b343b2af413b204d50fc53b
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer  wrote:

>  These are generally handled through a user interface where the RO is
> authenticated directly to the AS, and there's not much need for a
> "protocol" here, in practice.
>

Why do you think leaving access token revocation by RO to a proprietary API
is a good practice ? IMO this an essential requirement in API security.

IMHO token revocation done my RO is more practical than token revocation
done by the Client.

> There are larger applications, like UMA, that have client and PR
> provisioning that would allow for this to be managed somewhat
> programmatically, but even in that case you're still generally doing token
> revocation by a "client" in some fashion. In UMA, though, several different
> pieces can play the role of a "client" at different parts of the process.
>
> Revoking a scope is a whole different mess. Generally, you'd want to just
> revoke an existing token and make a new authorization grant with lower
> access if you don't want that client getting that scope anymore. If you
> just want to downscope for a single transaction, you can already do that
> with either the refresh token or token chaining approaches, depending on
> where in the process you are. The latter of these are both client-focused,
> though, and the RO doesn't have a direct hand in it at this point.
>

Why do you think it a mess. If you revoke the entire token then Client
needs to go through the complete OAuth flow - and also needs to get the
user consent. If RO can  downgrade the scope, then we restrict API access
by the client at RS end and its transparent to the client.

Thanks & regards,
-Prabath

>
>
>  -- Justin
>
>
> On 02/06/2013 04:35 AM, Prabath Siriwardena wrote:
>
> I am sorry if this was already discussed in this list..
>
>  Looking at [1] it only talks about revoking the access token from the
> client.
>
>  How about the resource owner..?
>
>  There can be cases where resource owner needs to revoke an authorized
> access token from a given client. Or revoke an scope..
>
>  How are we going to address these requirements..? Thoughts appreciated...
>
>  [1] http://tools.ietf.org/html/draft-ietf-oauth-revocation-04
>
>  --
> Thanks & Regards,
> Prabath
>
>  Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.com

--047d7b343b2af413b204d50fc53b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

__________________________________=
_____________
OAuth mailing list
OAuth@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/oauth

On Wed, Feb 6, 2013 at 8:19 PM, Justin R=
icher <jricher@mitre.org> wrote:

 =20
   =20
 =20

    These are generally handled through a user interface where the RO is
    authenticated directly to the AS, and there's not much need for a
    "protocol" here, in practice. 

Why do you think leaving access token revocation by RO to a proprie=
tary API is a good practice ? IMO this an essential requirement in API secu=
rity.

IMHO token revocation done my RO is more practical than=
 token revocation done by the Client.
=A0

There are larger applications, li=
ke
    UMA, that have client and PR provisioning that would allow for this
    to be managed somewhat programmatically, but even in that case
    you're still generally doing token revocation by a "client&quo=
t; in some
    fashion. In UMA, though, several different pieces can play the role
    of a "client" at different parts of the process.

    Revoking a scope is a whole different mess. Generally, you'd want t=
o
    just revoke an existing token and make a new authorization grant
    with lower access if you don't want that client getting that scope
    anymore. If you just want to downscope for a single transaction, you
    can already do that with either the refresh token or token chaining
    approaches, depending on where in the process you are. The latter of
    these are both client-focused, though, and the RO doesn't have a
    direct hand in it at this point.

=
Why do you think it a mess. If you revoke the entire token then Client need=
s to go through the complete OAuth flow - and also needs to get the user co=
nsent. If RO can =A0downgrade the scope, then we restrict API access by the=
 client at RS end and its transparent to the client.

Thanks & regards,
-Prabath
=A0<=
/div>

    =A0-- Justin

    On 02/06/2013 04:35 AM, Prabath
      Siriwardena wrote:

     =20
      I am sorry if this was already discussed in this list..=A0

      Looking at [1] it only talks about revoking the access token
        from the client.

      How about the resource owner..?

      There can be cases where resource owner needs to revoke an
        authorized access token from a given client. Or revoke an
        scope..

      How are we going to address these requirements..? Thoughts
        appreciated...

      [1] http://tools.ietf.org/html/draft-ietf-oauth-revocati=
on-04

      -- 

      Thanks & Regards,

      Prabath

      Mobile : +94 71 809 6732=A0

        http://bl=
og.facilelogin.com

        http://RampartF=
AQ.com

__________________________________=
_____________
OAuth mailing list
OAuth@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/oauth

-- 
Thanks &=
 Regards,
Prabath
Mobile : +94 71 809 6732=A0

=
http://blog.facil=
elogin.com

http://RampartFAQ.com

--047d7b343b2af413b204d50fc53b--

From wmills_92105@yahoo.com  Wed Feb  6 07:19:32 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80BB21F875F for ; Wed,  6 Feb 2013 07:19:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.078
X-Spam-Level: 
X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=0.520,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Prx9KA5VSw-O for ; Wed,  6 Feb 2013 07:19:32 -0800 (PST)
Received: from nm39-vm2.bullet.mail.ne1.yahoo.com (nm39-vm2.bullet.mail.ne1.yahoo.com [98.138.229.162]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAE521F8585 for ; Wed,  6 Feb 2013 07:19:31 -0800 (PST)
Received: from [98.138.226.178] by nm39.bullet.mail.ne1.yahoo.com with NNFMP; 06 Feb 2013 15:19:31 -0000
Received: from [98.138.89.246] by tm13.bullet.mail.ne1.yahoo.com with NNFMP; 06 Feb 2013 15:19:31 -0000
Received: from [127.0.0.1] by omp1060.mail.ne1.yahoo.com with NNFMP; 06 Feb 2013 15:19:31 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 48141.39758.bm@omp1060.mail.ne1.yahoo.com
Received: (qmail 86362 invoked by uid 60001); 6 Feb 2013 15:19:30 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360163970; bh=S7/B7pZS6HZhl65cD9klIa98VsKh/3Lv1o8F3NTAYOs=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=PQ0JlwSsmO6LCgr/1VJ8F/OS24Z8IwVvx1dqCMEtZfZJA0Gdeuxju6KqbcjInCUszVJmqm5LMLM5ZqHR8hP23Kr3jrSGmVtlA1uhNhBg0njZG5AygmBvj4JH45NKvCXUuz8t76SN9rVn3mZctlxfCUT21k4K1iB369bkAaWMXgg=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=RFbdu3P0aCWDcodiL53JFP5ZJo+nwJs3Q7ILICnQqlcCdOktsjHpbdpnQ7qWRWz/vyyTwvukNxW3Yx69NhZDmNoLOullrPemK4Irlec+Pde4wdF77x++mRB9wKbI3J9tqtIfa54LswzrLE9rvF0m5S6+wxQXqB+0xObVaIPK4H0=;
X-YMail-OSG: YF5MwJYVM1ln0m41G2jZvHbiA5dtuLuEsL0VdMuUWjlRmHh uNelSYoqsoie8GplAnw4K8vP.n7dw2GaVVhWISc8AINZiWMhwYOJJ6bel_Ye Ym9.WLAOWch7diOp1n47LjIJYAswN_l98pVyxN.HL158i4NFG_r8_oP1ZRzL hcx9HXUJYd3g_ZB0afgco7gLyPUHPpaabNvKqXo_TSe5tdQaGkw418Uh9j.I Rr93Yz0tp2EfzFQEAugobGLU.6x.iAvb8X1lmzSsxdiX5ESQD_Zoh0FjZgbE J2rjECqHLjasWrMZwmhjY2_J0en2HvaDGPNhM_HGzudg.AYCsrGWbCiNInwG jmJ0M05VWB4kGqobYxLmcY6lRri71wyTGpAifWs3EtrotqL_UePY_IBPVvM2 b4kcuKOlEBWFsg5NMOqW_EAstq2nysYdPzAldGq0SSZ.SA.O4P5sFNKLo6iC .YZa4Z3EoEiGWJdNvhZr7PTwbRgcVT.v3328fpD3bnRSZgtj84slVirCN92C ys7o2Z4cU7O0e4i4hHv2MK9DXjfxex3AmsX64UHAUCSzliYQ1XbQ34ODdpvi AZoFMmkm6zbMdKf2qeqaKof1aEWDAjItZFTyLshggCCMteLcZIx5l5m7iWnj xUImz0kw6oAUy6YXiIfJmtWRwxIUDodaun01EI0MUjNU-
Received: from [209.131.62.115] by web31811.mail.mud.yahoo.com via HTTP; Wed, 06 Feb 2013 07:19:30 PST
X-Rocket-MIMEInfo: 001.001, KzEKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRnJvbTogUHJhYmF0aCBTaXJpd2FyZGVuYSA8cHJhYmF0aEB3c28yLmNvbT4KVG86IFRvZGQgVyBMYWluaGFydCA8bGFpbmhhcnRAdXMuaWJtLmNvbT4gCkNjOiAib2F1dGhAaWV0Zi5vcmcgV0ciIDxvYXV0aEBpZXRmLm9yZz47IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgNiwgMjAxMyA3OjA0IEFNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEEgcXVlc3Rpb24gb24gdG9rZW4gcmV2b2NhdGlvbi4BMAEBAQE-
X-Mailer: YahooMailWebService/0.8.133.504
References:   
Message-ID: <1360163970.12201.YahooMailNeo@web31811.mail.mud.yahoo.com>
Date: Wed, 6 Feb 2013 07:19:30 -0800 (PST)
From: William Mills 
To: Prabath Siriwardena , Todd W Lainhart 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="764183289-1769135125-1360163970=:12201"
Cc: "oauth@ietf.org WG" , "oauth-bounces@ietf.org" 
Subject: Re: [OAUTH-WG] A question on token revocation.
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Feb 2013 15:19:33 -0000

--764183289-1769135125-1360163970=:12201
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

+1=0A=0A=0A________________________________=0A From: Prabath Siriwardena =0ATo: Todd W Lainhart  =0ACc: "oauth@=
ietf.org WG" ; oauth-bounces@ietf.org =0ASent: Wednesday, F=
ebruary 6, 2013 7:04 AM=0ASubject: Re: [OAUTH-WG] A question on token revoc=
ation.=0A =0A=0A=0A=0A=0AOn Wed, Feb 6, 2013 at 7:51 PM, Todd W Lainhart  wrote:=0A=0A> There can be cases=0Awhere resource owner=
 needs to revoke an authorized access token from a=0Agiven client.  =0A>=0A=
>Why wouldn't the RO go through the client=0Ato revoke the token?=0A>=0A=0A=
RO needs not to go through the client to revoke. Resource owner should have=
 the capability to revoke an acces token by client.=0A=0AThanks & regards,=
=0A-Prabath=0A=A0=0A =0A>=0A>=0A>=0A>=0A>Todd Lainhart=0A>Rational software=
=0A>IBM Corporation=0A>550 King Street, Littleton, MA 01460-1250=0A>1-978-8=
99-4705=0A>2-276-4705 (T/L)=0A>lainhart@us.ibm.com =0A>=0A>=0A>=0A>=0A>From=
: =A0 =A0 =A0=0A=A0Prabath Siriwardena=0A =0A>To: =A0 =A0=
 =A0=0A=A0"oauth@ietf.org WG" ,  =0A>Date: =A0 =A0 =A0=0A=
=A002/06/2013 04:36 AM =0A>Subject: =A0 =A0=0A=A0 =A0[OAUTH-WG] A=0Aquestio=
n on token revocation. =0A>Sent by: =A0 =A0=0A=A0 =A0oauth-bounces@ietf.org=
 =0A>>________________________________=0A>=0A>=0A>=0A>=0A>I am sorry if thi=
s was already discussed in this list..=A0 =0A>=0A>Looking at [1] it only ta=
lks about revoking the access=0Atoken from the client. =0A>=0A>How about th=
e resource owner..? =0A>=0A>There can be cases where resource owner needs t=
o revoke=0Aan authorized access token from a given client. Or revoke an sco=
pe.. =0A>=0A>How are we going to address these requirements..? Thoughts=0Aa=
ppreciated... =0A>=0A>[1] http://tools.ietf.org/html/draft-ietf-oauth-revoc=
ation-04 =0A>=0A>-- =0A>Thanks & Regards,=0A>Prabath =0A>=0A>Mobile : +94 7=
1 809 6732=A0=0A>=0A>http://blog.facilelogin.com=0A>http://RampartFAQ.com__=
_____________________________________________=0A>OAuth mailing list=0A>OAut=
h@ietf.org=0A>https://www.ietf.org/mailman/listinfo/oauth=0A> =0A>=0A=0A=0A=
-- =0AThanks & Regards,=0APrabath=0A=0AMobile : +94 71 809 6732=A0=0A=0Ahtt=
p://blog.facilelogin.com=0Ahttp://RampartFAQ.com=0A________________________=
_______________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www=
.ietf.org/mailman/listinfo/oauth
--764183289-1769135125-1360163970=:12201
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

+1

=

  From: Prabath Siriwardena <pra=
bath@wso2.com>
 To: =
Todd W Lainhart <lainhart@us.ibm.com> 
Cc: "oauth@ietf.org WG" <oauth@ietf.org>; oauth=
-bounces@ietf.org 
 Sent: Wednesday, February 6, 2013 7:04 AM
 Subject: Re: [OAUTH-WG] A question on token revocation.  

=0A

On Wed, Feb 6, 2013 at 7:51 PM, Todd W Lainhart &l=
t;lainhart@us.ibm.com> =
wrote:
=0A> There =
can be cases=0Awhere resource owner needs to revoke an authorized access to=
ken from a=0Agiven client. =0A
=0A
Why wouldn't the RO go through the client=0Ato revoke the token?

RO needs not to go through the client=
 to revoke. Resource owner should have the capability to revoke an acces to=
ken by client.

Thanks & regards,
=0A=
-Prabath

=0A=0A
=0A=0A=0A
=0A
=0A
=0ATodd Lainhart
=0ARational software
=0AIBM C=
orporation
=0A550 King Street, Littleton, MA 01460-1250
=0A1-978-899-4705
=0A2-276-4705 (T/L)=0Alainhart@us.ibm.com
=0A
=0A
=0A
=0A
=0A
From:      =0A&=
nbsp;Prabath Siriwardena=0A<=
prabath@wso2.com>=0A
To:      =
=0A "oauth@ietf.org=0AWG" <oauth@ietf.=
org>, =0A
Date:      =0A 02/06/2013 04:36 AM=0A
Subject:    =0A   [OAUTH-WG] A=0Aquestion on token revocation.=
=0A
Sent b=
y:    =0A   oauth-bounces@ietf.org=0A
=0A
=0A
=
=0A
=0A
I am sorry if this was already discussed in =
this list.. =0A
=0A
Looking at [1] it on=
ly talks about revoking the access=0Atoken from the client.=0A
=
=0A
How about the resource owner..?=0A
=0AThere can be cases where resource owner needs to revoke=
=0Aan authorized access token from a given client. Or revoke an scope..=0A
=0A
How are we going to address these require=
ments..? Thoughts=0Aappreciated...=0A
=0A
[1]=
 ht=
tp://tools.ietf.org/html/draft-ietf-oauth-revocation-04=0A=0A
-- 
=0AThanks & Regards,
=0APrabath=0A
=0A
Mobile : +9=
4 71 809 6732 
=0A=0Ahttp://blog.facilelogin.=
com
=0A
http://RampartFAQ.com<=
tt>_______________________________________________
=0AOAuth mailin=
g list
=0AOAuth@ietf.org
=0A=
https://www.ietf.org/mailman/listinfo/oauth<=
/font>
=0A=0A

<=
br clear=3D"all">
-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732 

http://blog.facilelo=
gin.com
=0Ahttp://RampartFAQ.com
=0A

_________________=
______________________________
OAuth mailing list
OAuth@ietf.org
https=
://www.ietf.org/mailman/listinfo/oauth

--764183289-1769135125-1360163970=:12201--

From jricher@mitre.org  Wed Feb  6 07:19:45 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01DF21F892B for ; Wed,  6 Feb 2013 07:19:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.572
X-Spam-Level: 
X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.026,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a33bNESq1fvJ for ; Wed,  6 Feb 2013 07:19:44 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 856A021F88E6 for ; Wed,  6 Feb 2013 07:19:44 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1517C451000D; Wed,  6 Feb 2013 10:19:44 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id ECD2D1F2CA5; Wed,  6 Feb 2013 10:19:43 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 6 Feb 2013 10:19:43 -0500
Message-ID: <5112746B.70403@mitre.org>
Date: Wed, 6 Feb 2013 10:19:07 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Prabath Siriwardena 
References:  <51126D65.2090707@mitre.org> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050909000801090906040907"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] A question on token revocation.
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Feb 2013 15:19:45 -0000

--------------050909000801090906040907
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

On 02/06/2013 10:13 AM, Prabath Siriwardena wrote:
>
>
> On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer  > wrote:
>
>     These are generally handled through a user interface where the RO
>     is authenticated directly to the AS, and there's not much need for
>     a "protocol" here, in practice.
>
>
> Why do you think leaving access token revocation by RO to a 
> proprietary API is a good practice ? IMO this an essential requirement 
> in API security.
I think it makes more sense in the same way that having a "proprietary" 
UI/API for managing the user consent makes sense: unless you're doing a 
fully dynamic end-to-end system like UMA, then there's not much value in 
trying to squeeze disparate systems into the same mold, since they won't 
be talking to each other anyway.

And since you refer to it as an "API", what will the RO be using to call 
this API? Is there a token management client that's separate from the 
OAuth client?

>
> IMHO token revocation done my RO is more practical than token 
> revocation done by the Client.
They're both valid but require different kinds of protocols and 
considerations. This token revocation draft is meant to solve one 
problem, and that doesn't mean it can or should solve other seemingly 
related problems.

If you would like to see the RO-initiated token revocation go through 
(not grant revocation, mind you -- that's related, but different), then 
I would suggest that you start specifying exactly how that works. I 
predict it will be problematic in practice, though, as the RO often 
doesn't actually have direct access to the token itself.

>     There are larger applications, like UMA, that have client and PR
>     provisioning that would allow for this to be managed somewhat
>     programmatically, but even in that case you're still generally
>     doing token revocation by a "client" in some fashion. In UMA,
>     though, several different pieces can play the role of a "client"
>     at different parts of the process.
>
>     Revoking a scope is a whole different mess. Generally, you'd want
>     to just revoke an existing token and make a new authorization
>     grant with lower access if you don't want that client getting that
>     scope anymore. If you just want to downscope for a single
>     transaction, you can already do that with either the refresh token
>     or token chaining approaches, depending on where in the process
>     you are. The latter of these are both client-focused, though, and
>     the RO doesn't have a direct hand in it at this point.
>
>
> Why do you think it a mess. If you revoke the entire token then Client 
> needs to go through the complete OAuth flow - and also needs to get 
> the user consent. If RO can  downgrade the scope, then we restrict API 
> access by the client at RS end and its transparent to the client.
>

Downgrading the scope of tokens in the wild is hardly transparent to the 
client (stuff that it expects to work will suddenly start to fail, 
meaning that most clients will throw out the token and try to get a new 
one), and in a distributed system you've got to propagate that change to 
the RS. If you bake the scopes into the token itself (which many do) 
then you actually *can't* downgrade a single token, anyway.

  -- Justin

> Thanks & regards,
> -Prabath
>
>
>
>      -- Justin
>
>
>     On 02/06/2013 04:35 AM, Prabath Siriwardena wrote:
>>     I am sorry if this was already discussed in this list..
>>
>>     Looking at [1] it only talks about revoking the access token from
>>     the client.
>>
>>     How about the resource owner..?
>>
>>     There can be cases where resource owner needs to revoke an
>>     authorized access token from a given client. Or revoke an scope..
>>
>>     How are we going to address these requirements..? Thoughts
>>     appreciated...
>>
>>     [1] http://tools.ietf.org/html/draft-ietf-oauth-revocation-04
>>
>>     -- 
>>     Thanks & Regards,
>>     Prabath
>>
>>     Mobile : +94 71 809 6732 
>>
>>     http://blog.facilelogin.com
>>     http://RampartFAQ.com
>>
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     OAuth@ietf.org  
>>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> -- 
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com

--------------050909000801090906040907
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

    On 02/06/2013 10:13 AM, Prabath
      Siriwardena wrote:

      On Wed, Feb 6, 2013 at 8:19 PM, Justin
        Richer <jricher@mitre.org>
        wrote:

           These are generally
            handled through a user interface where the RO is
            authenticated directly to the AS, and there's not much need
            for a "protocol" here, in practice. 

        Why do you think leaving access token revocation by RO to a
          proprietary API is a good practice ? IMO this an essential
          requirement in API security.

    I think it makes more sense in the same way that having a
    "proprietary" UI/API for managing the user consent makes sense:
    unless you're doing a fully dynamic end-to-end system like UMA, then
    there's not much value in trying to squeeze disparate systems into
    the same mold, since they won't be talking to each other anyway. 

    And since you refer to it as an "API", what will the RO be using to
    call this API? Is there a token management client that's separate
    from the OAuth client? 

        IMHO token revocation done my RO is more practical than
          token revocation done by the Client.

    They're both valid but require different kinds of protocols and
    considerations. This token revocation draft is meant to solve one
    problem, and that doesn't mean it can or should solve other
    seemingly related problems.

    If you would like to see the RO-initiated token revocation go
    through (not grant revocation, mind you -- that's related, but
    different), then I would suggest that you start specifying exactly
    how that works. I predict it will be problematic in practice,
    though, as the RO often doesn't actually have direct access to the
    token itself. 

          There are larger
            applications, like UMA, that have client and PR provisioning
            that would allow for this to be managed somewhat
            programmatically, but even in that case you're still
            generally doing token revocation by a "client" in some
            fashion. In UMA, though, several different pieces can play
            the role of a "client" at different parts of the process.

            Revoking a scope is a whole different mess. Generally, you'd
            want to just revoke an existing token and make a new
            authorization grant with lower access if you don't want that
            client getting that scope anymore. If you just want to
            downscope for a single transaction, you can already do that
            with either the refresh token or token chaining approaches,
            depending on where in the process you are. The latter of
            these are both client-focused, though, and the RO doesn't
            have a direct hand in it at this point.

        Why do you think it a mess. If you revoke the entire token
          then Client needs to go through the complete OAuth flow - and
          also needs to get the user consent. If RO can  downgrade the
          scope, then we restrict API access by the client at RS end and
          its transparent to the client.

    Downgrading the scope of tokens in the wild is hardly transparent to
    the client (stuff that it expects to work will suddenly start to
    fail, meaning that most clients will throw out the token and try to
    get a new one), and in a distributed system you've got to propagate
    that change to the RS. If you bake the scopes into the token itself
    (which many do) then you actually *can't* downgrade a single token,
    anyway. 

     -- Justin

        Thanks & regards,
        -Prabath

                 -- Justin

                On 02/06/2013 04:35 AM, Prabath Siriwardena wrote:

                  I am sorry if this was already discussed in this
                    list.. 

                  Looking at [1] it only talks about revoking the
                    access token from the client.

                  How about the resource owner..?

                  There can be cases where resource owner needs to
                    revoke an authorized access token from a given
                    client. Or revoke an scope..

                  How are we going to address these requirements..?
                    Thoughts appreciated...

                  [1] http://tools.ietf.org/html/draft-ietf-oauth-revocation-04

                  -- 

                  Thanks & Regards,

                  Prabath

                  Mobile : +94 71 809
                      6732 

                    http://blog.facilelogin.com

                    http://RampartFAQ.com

                _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

      -- 

      Thanks & Regards,

      Prabath

      Mobile : +94 71 809 6732 

        http://blog.facilelogin.com

        http://RampartFAQ.com

--------------050909000801090906040907--

From tonynad@microsoft.com  Wed Feb  6 07:21:03 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C72921F8A04 for ; Wed,  6 Feb 2013 07:21:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.534
X-Spam-Level: 
X-Spam-Status: No, score=0.534 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qk9q4d9meFH7 for ; Wed,  6 Feb 2013 07:21:02 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.27]) by ietfa.amsl.com (Postfix) with ESMTP id 59D6221F8566 for ; Wed,  6 Feb 2013 07:21:01 -0800 (PST)
Received: from BY2FFO11FD003.protection.gbl (10.1.15.202) by BY2FFO11HUB023.protection.gbl (10.1.14.110) with Microsoft SMTP Server (TLS) id 15.0.609.9; Wed, 6 Feb 2013 15:20:52 +0000
Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD003.mail.protection.outlook.com (10.1.14.125) with Microsoft SMTP Server (TLS) id 15.0.609.9 via Frontend Transport; Wed, 6 Feb 2013 15:20:51 +0000
Received: from va3outboundpool.messaging.microsoft.com (157.54.51.81) by mail.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.2.318.3; Wed, 6 Feb 2013 15:20:20 +0000
Received: from mail54-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Wed, 6 Feb 2013 15:20:19 +0000
Received: from mail54-va3 (localhost [127.0.0.1])	by mail54-va3-R.bigfish.com (Postfix) with ESMTP id 1C2E94A0245	for ; Wed,  6 Feb 2013 15:20:19 +0000 (UTC)
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT003.namprd03.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -20
X-BigFish: PS-20(zzbb2dI98dI9371Ic89bh1432I1418Ic857hzz1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz1033IL17326ah8275bh8275dh18c673hz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h9a9j1155h)
Received-SPF: softfail (mail54-va3: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT003.namprd03.prod.outlook.com ;.outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BLUPR03MB036; H:BLUPR03MB035.namprd03.prod.outlook.com; LANG:en; 
Received: from mail54-va3 (localhost.localdomain [127.0.0.1]) by mail54-va3 (MessageSwitch) id 1360164011630956_3765; Wed,  6 Feb 2013 15:20:11 +0000 (UTC)
Received: from VA3EHSMHS027.bigfish.com (unknown [10.7.14.235])	by mail54-va3.bigfish.com (Postfix) with ESMTP id 9134D8069A; Wed,  6 Feb 2013 15:20:11 +0000 (UTC)
Received: from BL2PRD0310HT003.namprd03.prod.outlook.com (157.56.240.21) by VA3EHSMHS027.bigfish.com (10.7.99.37) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 6 Feb 2013 15:20:09 +0000
Received: from BLUPR03MB036.namprd03.prod.outlook.com (10.255.209.148) by BL2PRD0310HT003.namprd03.prod.outlook.com (10.255.97.38) with Microsoft SMTP Server (TLS) id 14.16.263.1; Wed, 6 Feb 2013 15:20:08 +0000
Received: from BLUPR03MB035.namprd03.prod.outlook.com (10.255.209.147) by BLUPR03MB036.namprd03.prod.outlook.com (10.255.209.148) with Microsoft SMTP Server (TLS) id 15.0.614.5; Wed, 6 Feb 2013 15:20:07 +0000
Received: from BLUPR03MB035.namprd03.prod.outlook.com ([169.254.1.43]) by BLUPR03MB035.namprd03.prod.outlook.com ([169.254.1.43]) with mapi id 15.00.0614.003; Wed, 6 Feb 2013 15:20:01 +0000
From: Anthony Nadalin 
To: Hannes Tschofenig , Justin Richer 
Thread-Topic: [OAUTH-WG] How soon until last call on introspection and revocation
Thread-Index: AQHOBH1uQnGxeW7vfEueX6bNKilo1g==
Date: Wed, 6 Feb 2013 15:20:01 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [96.8.44.21]
Content-Type: multipart/alternative; boundary="_000_c78f5209366f4a73b11dcdf37aa36900BLUPR03MB035namprd03pro_"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: BLUPR03MB036.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%MITRE.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%GMX.NET$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14HUBC103.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14HUBC103.redmond.corp.microsoft.com
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(47446002)(63696002)(53806001)(20776003)(77982001)(56776001)(56816002)(54356001)(74662001)(33646001)(59766001)(16676001)(44976002)(49866001)(79102001)(31966008)(76482001)(50986001)(74502001)(47736001)(4396001)(51856001)(6806001)(512874001)(47976001)(54316002)(5343635001)(46102001)(65816001)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB023; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0749DC2CE6
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] How soon until last call on introspection and	revocation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Feb 2013 15:21:03 -0000

--_000_c78f5209366f4a73b11dcdf37aa36900BLUPR03MB035namprd03pro_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSB0aGluayB0aGF0IHRoZXJlIGFyZSBzdGlsbCBmdW5kYW1lbnRhbCBkZXNpZ24gZGlzYWdyZWVt
ZW50cyB0aGF0IHdvdWxkIG5lZWQgdG8gYmUgcmVzb2x2ZWQuDQoNClNlbnQgZnJvbSBXaW5kb3dz
IE1haWwNCg0KRnJvbTogSnVzdGluIFJpY2hlcg0KU2VudDog4oCORmVicnVhcnnigI4g4oCONuKA
jiwg4oCOMjAxMyDigI424oCOOuKAjjU34oCOIOKAjkFNDQpUbzogSGFubmVzIFRzY2hvZmVuaWcN
CkNDOiBJRVRGIG9hdXRoIFdHDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBIb3cgc29vbiB1bnRp
bCBsYXN0IGNhbGwgb24gaW50cm9zcGVjdGlvbiBhbmQgcmV2b2NhdGlvbg0KDQpBcyBlZGl0b3Ig
b2YgaW50cm9zcGVjdGlvbiBkcmFmdCwgSSB3b3VsZCBsaWtlIHRvIHNlZSBpdCBiZWNvbWUgYQ0K
d29ya2luZyBncm91cCBpdGVtLiBBZnRlciB0YWxraW5nIHdpdGggdGhlIGNoYWlycywgdGhlcmUg
YXBwZWFycyB0byBiZQ0Kc29tZSBmcmljdGlvbiB3aXRoIHRoZSBhbW91bnQgb2Ygb3BlbiB3b3Jr
aW5nIGl0ZW1zIHRoYXQgdGhlIHdvcmtpbmcNCmdyb3VwIGhhcyByaWdodCBub3csIHRob3VnaCwg
bGVhZGluZyB0byBoZXNpdGF0aW9uIHRvIGFkZCBtb3JlIHRvIG91cg0Kb2ZmaWNpYWwgcGxhdGUu
DQoNClRoYXQgc2FpZCwgaXQgZG9lc24ndCBtZWFuIHdlIGNhbid0IGFsbCBqdXN0ICp3b3JrKiBv
biBpdCwgYW5kIEknbQ0KYWN0aXZlbHkgZWRpdGluZyBpdCBiYXNlZCBvbiBmZWVkYmFjay4gV2Un
cmUgaW1wbGVtZW50aW5nIGFuZCBkZXBsb3lpbmcNCml0IGluIG91ciBvd24gc3lzdGVtcyByaWdo
dCBub3csIHRvby4gSSdtIHRyYWNraW5nIGlzc3VlcyB0byB0aGUgZHJhZnQNCmhlcmUgaWYgeW91
IGhhdmUgYW55IGRpcmVjdCBjaGFuZ2VzIChvciBwdWxsIHJlcXVlc3RzISk6DQoNCiAgIGh0dHBz
Oi8vZ2l0aHViLmNvbS9qcmljaGVyL29hdXRoLXNwZWMvaXNzdWVzDQoNClNvIEkgaG9wZSB0aGF0
IHdlIGNhbiBhdCBsZWFzdCBzdGFiaWxpemUgdGhlIGZ1bmN0aW9uYWxpdHkgb2YgdGhlIHNwZWMN
CnNvIHRoYXQgYnkgdGhlIHRpbWUgdGhlIElFVEYgcHJvY2VzcyBjYW4gc3RhcnQgdG8gY2hldyBv
biBpdCBpbiBhbg0Kb2ZmaWNpYWwgZmFzaGlvbiwgaXQgd2lsbCBiZSBtb3N0bHkgYmFrZWQgYW5k
IHdlIGNhbiBydW4gaXQgdGhyb3VnaA0KcmVsYXRpdmVseSBxdWlja2x5Lg0KDQogIC0tIEp1c3Rp
bg0KDQpPbiAwMi8wNi8yMDEzIDA5OjQ1IEFNLCBIYW5uZXMgVHNjaG9mZW5pZyB3cm90ZToNCj4g
SGkgVG9kZCwNCj4NCj4gdHdvIGFuc3dlcnM6DQo+DQo+IDEpIFRva2VuIFJldm9jYXRpb246DQo+
DQo+IEkgaGFkIGluaXRpYXRlZCBhIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIGZvciB0aGUgdG9r
ZW4gcmV2b2NhdGlvbiBkb2N1bWVudCBlbmQgb2YgTm92ZW1iZXI6DQo+IGh0dHA6Ly93d3cuaWV0
Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzEwMTAyLmh0bWwNCj4NCj4g
QXMgeW91IGhhdmUgc2VlbiBvbiB0aGUgbGlzdCwgdGhpcyBoYXMgZ2VuZXJhdGVkIGEgZmFpciBh
bW91bnQgb2YgZGlzY3Vzc2lvbi4NCj4NCj4gSSBob3BlIHRoYXQgVG9yc3RlbiwgdGhlIGRyYWZ0
IGVkaXRvciwgaXMgYWJsZSB0byBwcm9kdWNlIGEgbmV3IGRyYWZ0IHZlcnNpb24gcXVpY2tseSB3
aXRoIGEgcmVzb2x1dGlvbiBvZiB0aGUgb3BlbiBpc3N1ZXMgdGhhdCBpcyBhY2NlcHRhYmxlIHRv
IHRoZSByZXN0IG9mIHRoZSBncm91cC4NCj4NCj4gVGhlbiwgd2Ugd2lsbCBoYXZlIHRvIGp1ZGdl
IHdoZXRoZXIgdGhlIGRvY3VtZW50IGNhbiBtb3ZlIGZvcndhcmQgdG8gdGhlIElFU0cuDQo+DQo+
IDIpIEludHJvc3BlY3Rpb24NCj4NCj4gVGhhdCBkb2N1bWVudCBpcyBub3QgZXZlbiBhIHdvcmtp
bmcgZ3JvdXAgaXRlbS4NCj4NCj4gQ2lhbw0KPiBIYW5uZXMNCj4NCj4gT24gRmViIDYsIDIwMTMs
IGF0IDQ6MjYgUE0sIFRvZGQgVyBMYWluaGFydCB3cm90ZToNCj4NCj4+IERvZXMgYW55b25lIGhh
dmUgYW55IGludHVpdGlvbiBhcyB0byBob3cgZmFyIGF3YXkgd2UgYXJlIG9uIGxhc3QgY2FsbCBm
b3IgaW50cm9zcGVjdGlvbiBhbmQgcmV2b2NhdGlvbj8NCj4gX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRo
QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgN
Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRo
IG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vb2F1dGgNCg0KDQo=

--_000_c78f5209366f4a73b11dcdf37aa36900BLUPR03MB035namprd03pro_
Content-Type: text/html; charset="utf-8"
Content-ID: <3598E3503A330D4283EF786DBB592526@microsoft.onmicrosoft.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSBkYXRhLWV4dGVybmFsc3R5bGU9InRy
dWUiPgpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0
UGFyYWdyYXBoIHsKbWFyZ2luLXRvcDowaW47Cm1hcmdpbi1yaWdodDowaW47Cm1hcmdpbi1ib3R0
b206MGluOwptYXJnaW4tbGVmdDouNWluOwptYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cn0KCnAuTXNv
TGlzdFBhcmFncmFwaEN4U3BGaXJzdCwgbGkuTXNvTGlzdFBhcmFncmFwaEN4U3BGaXJzdCwgZGl2
Lk1zb0xpc3RQYXJhZ3JhcGhDeFNwRmlyc3QsIHAuTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUs
IGxpLk1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlLCBkaXYuTXNvTGlzdFBhcmFncmFwaEN4U3BN
aWRkbGUsIHAuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0LCBsaS5Nc29MaXN0UGFyYWdyYXBoQ3hT
cExhc3QsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcExhc3QgewptYXJnaW4tdG9wOjBpbjsKbWFy
Z2luLXJpZ2h0OjBpbjsKbWFyZ2luLWJvdHRvbTowaW47Cm1hcmdpbi1sZWZ0Oi41aW47Cm1hcmdp
bi1ib3R0b206LjAwMDFwdDsKbGluZS1oZWlnaHQ6MTE1JTsKfQo8L3N0eWxlPg0KPC9oZWFkPg0K
PGJvZHk+DQo8ZGl2IGRhdGEtZXh0ZXJuYWxzdHlsZT0iZmFsc2UiIHN0eWxlPSJmb250LWZhbWls
eTpDYWxpYnJpLCdTZWdvZSBVSScsTWVpcnlvLCdNaWNyb3NvZnQgWWFIZWkgVUknLCdNaWNyb3Nv
ZnQgSmhlbmdIZWkgVUknLCdNYWxndW4gR290aGljJywnS2htZXIgVUknLCdOaXJtYWxhIFVJJyxU
dW5nYSwnTGFvIFVJJyxFYnJpbWEsc2Fucy1zZXJpZjtmb250LXNpemU6MTZweDsiPg0KPGRpdj5J
IHRoaW5rIHRoYXQgdGhlcmUgYXJlIHN0aWxsIGZ1bmRhbWVudGFsIGRlc2lnbiBkaXNhZ3JlZW1l
bnRzIHRoYXQgd291bGQgbmVlZCB0byBiZSByZXNvbHZlZC4mbmJzcDs8L2Rpdj4NCjxkaXYgZGF0
YS1zaWduYXR1cmVibG9jaz0idHJ1ZSI+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5TZW50IGZy
b20gV2luZG93cyBNYWlsPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0
eWxlPSJib3JkZXItdG9wLWNvbG9yOiByZ2IoMjI1LCAyMjUsIDIyNSk7IGJvcmRlci10b3Atd2lk
dGg6IDFweDsgYm9yZGVyLXRvcC1zdHlsZTogc29saWQ7Ij4NCjxzdHJvbmc+RnJvbTo8L3N0cm9u
Zz4mbmJzcDtKdXN0aW4gUmljaGVyPGJyPg0KPHN0cm9uZz5TZW50Ojwvc3Ryb25nPiZuYnNwO+KA
jkZlYnJ1YXJ54oCOIOKAjjbigI4sIOKAjjIwMTMg4oCONuKAjjrigI41N+KAjiDigI5BTTxicj4N
CjxzdHJvbmc+VG86PC9zdHJvbmc+Jm5ic3A7SGFubmVzIFRzY2hvZmVuaWc8YnI+DQo8c3Ryb25n
PkNDOjwvc3Ryb25nPiZuYnNwO0lFVEYgb2F1dGggV0c8YnI+DQo8c3Ryb25nPlN1YmplY3Q6PC9z
dHJvbmc+Jm5ic3A7UmU6IFtPQVVUSC1XR10gSG93IHNvb24gdW50aWwgbGFzdCBjYWxsIG9uIGlu
dHJvc3BlY3Rpb24gYW5kIHJldm9jYXRpb248YnI+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+
DQpBcyBlZGl0b3Igb2YgaW50cm9zcGVjdGlvbiBkcmFmdCwgSSB3b3VsZCBsaWtlIHRvIHNlZSBp
dCBiZWNvbWUgYSA8YnI+DQp3b3JraW5nIGdyb3VwIGl0ZW0uIEFmdGVyIHRhbGtpbmcgd2l0aCB0
aGUgY2hhaXJzLCB0aGVyZSBhcHBlYXJzIHRvIGJlIDxicj4NCnNvbWUgZnJpY3Rpb24gd2l0aCB0
aGUgYW1vdW50IG9mIG9wZW4gd29ya2luZyBpdGVtcyB0aGF0IHRoZSB3b3JraW5nIDxicj4NCmdy
b3VwIGhhcyByaWdodCBub3csIHRob3VnaCwgbGVhZGluZyB0byBoZXNpdGF0aW9uIHRvIGFkZCBt
b3JlIHRvIG91ciA8YnI+DQpvZmZpY2lhbCBwbGF0ZS48YnI+DQo8YnI+DQpUaGF0IHNhaWQsIGl0
IGRvZXNuJ3QgbWVhbiB3ZSBjYW4ndCBhbGwganVzdCAqd29yayogb24gaXQsIGFuZCBJJ20gPGJy
Pg0KYWN0aXZlbHkgZWRpdGluZyBpdCBiYXNlZCBvbiBmZWVkYmFjay4gV2UncmUgaW1wbGVtZW50
aW5nIGFuZCBkZXBsb3lpbmcgPGJyPg0KaXQgaW4gb3VyIG93biBzeXN0ZW1zIHJpZ2h0IG5vdywg
dG9vLiBJJ20gdHJhY2tpbmcgaXNzdWVzIHRvIHRoZSBkcmFmdCA8YnI+DQpoZXJlIGlmIHlvdSBo
YXZlIGFueSBkaXJlY3QgY2hhbmdlcyAob3IgcHVsbCByZXF1ZXN0cyEpOjxicj4NCjxicj4NCiZu
YnNwOyZuYnNwOyBodHRwczovL2dpdGh1Yi5jb20vanJpY2hlci9vYXV0aC1zcGVjL2lzc3Vlczxi
cj4NCjxicj4NClNvIEkgaG9wZSB0aGF0IHdlIGNhbiBhdCBsZWFzdCBzdGFiaWxpemUgdGhlIGZ1
bmN0aW9uYWxpdHkgb2YgdGhlIHNwZWMgPGJyPg0Kc28gdGhhdCBieSB0aGUgdGltZSB0aGUgSUVU
RiBwcm9jZXNzIGNhbiBzdGFydCB0byBjaGV3IG9uIGl0IGluIGFuIDxicj4NCm9mZmljaWFsIGZh
c2hpb24sIGl0IHdpbGwgYmUgbW9zdGx5IGJha2VkIGFuZCB3ZSBjYW4gcnVuIGl0IHRocm91Z2gg
PGJyPg0KcmVsYXRpdmVseSBxdWlja2x5Ljxicj4NCjxicj4NCiZuYnNwOyAtLSBKdXN0aW48YnI+
DQo8YnI+DQpPbiAwMi8wNi8yMDEzIDA5OjQ1IEFNLCBIYW5uZXMgVHNjaG9mZW5pZyB3cm90ZTo8
YnI+DQomZ3Q7IEhpIFRvZGQsPGJyPg0KJmd0Ozxicj4NCiZndDsgdHdvIGFuc3dlcnM6PGJyPg0K
Jmd0Ozxicj4NCiZndDsgMSkgVG9rZW4gUmV2b2NhdGlvbjo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJ
IGhhZCBpbml0aWF0ZWQgYSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBmb3IgdGhlIHRva2VuIHJl
dm9jYXRpb24gZG9jdW1lbnQgZW5kIG9mIE5vdmVtYmVyOjxicj4NCiZndDsgaHR0cDovL3d3dy5p
ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTAxMDIuaHRtbDxicj4N
CiZndDs8YnI+DQomZ3Q7IEFzIHlvdSBoYXZlIHNlZW4gb24gdGhlIGxpc3QsIHRoaXMgaGFzIGdl
bmVyYXRlZCBhIGZhaXIgYW1vdW50IG9mIGRpc2N1c3Npb24uPGJyPg0KJmd0Ozxicj4NCiZndDsg
SSBob3BlIHRoYXQgVG9yc3RlbiwgdGhlIGRyYWZ0IGVkaXRvciwgaXMgYWJsZSB0byBwcm9kdWNl
IGEgbmV3IGRyYWZ0IHZlcnNpb24gcXVpY2tseSB3aXRoIGEgcmVzb2x1dGlvbiBvZiB0aGUgb3Bl
biBpc3N1ZXMgdGhhdCBpcyBhY2NlcHRhYmxlIHRvIHRoZSByZXN0IG9mIHRoZSBncm91cC48YnI+
DQomZ3Q7PGJyPg0KJmd0OyBUaGVuLCB3ZSB3aWxsIGhhdmUgdG8ganVkZ2Ugd2hldGhlciB0aGUg
ZG9jdW1lbnQgY2FuIG1vdmUgZm9yd2FyZCB0byB0aGUgSUVTRy48YnI+DQomZ3Q7PGJyPg0KJmd0
OyAyKSBJbnRyb3NwZWN0aW9uPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhhdCBkb2N1bWVudCBpcyBu
b3QgZXZlbiBhIHdvcmtpbmcgZ3JvdXAgaXRlbS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBDaWFvPGJy
Pg0KJmd0OyBIYW5uZXM8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiBGZWIgNiwgMjAxMywgYXQgNDoy
NiBQTSwgVG9kZCBXIExhaW5oYXJ0IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyBEb2Vz
IGFueW9uZSBoYXZlIGFueSBpbnR1aXRpb24gYXMgdG8gaG93IGZhciBhd2F5IHdlIGFyZSBvbiBs
YXN0IGNhbGwgZm9yIGludHJvc3BlY3Rpb24gYW5kIHJldm9jYXRpb24/PGJyPg0KJmd0OyBfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgT0F1
dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBPQXV0aEBpZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj4NCjxicj4NCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGlu
ZyBsaXN0PGJyPg0KT0F1dGhAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL29hdXRoPGJyPg0KPGJyPg0KPGJyPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0
bWw+DQo=

--_000_c78f5209366f4a73b11dcdf37aa36900BLUPR03MB035namprd03pro_--

From lainhart@us.ibm.com  Wed Feb  6 07:30:57 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B52521F84C2 for ; Wed,  6 Feb 2013 07:30:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.542
X-Spam-Level: 
X-Spam-Status: No, score=-10.542 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBVW3cBqvVA5 for ; Wed,  6 Feb 2013 07:30:56 -0800 (PST)
Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id 1927521F853A for ; Wed,  6 Feb 2013 07:30:56 -0800 (PST)
Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for  from ; Wed, 6 Feb 2013 10:30:54 -0500
Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted;  Wed, 6 Feb 2013 10:30:52 -0500
Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 9012B6E8036; Wed,  6 Feb 2013 10:30:49 -0500 (EST)
Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r16FUj65328532; Wed, 6 Feb 2013 10:30:45 -0500
Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r16FUjLU025958; Wed, 6 Feb 2013 10:30:45 -0500
Received: from d01ml255.pok.ibm.com (d01ml255.pok.ibm.com [9.63.10.54]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r16FUjRa025905; Wed, 6 Feb 2013 10:30:45 -0500
In-Reply-To: <5112746B.70403@mitre.org>
References: 	<51126D65.2090707@mitre.org>  <5112746B.70403@mitre.org>
To: Justin Richer 
MIME-Version: 1.0
X-KeepSent: E5AD1D75:31752E83-85257B0A:00552A3B; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3FP2 SHF22 July 19, 2012
Message-ID: 
From: Todd W Lainhart 
Date: Wed, 6 Feb 2013 10:30:42 -0500
X-MIMETrack: Serialize by Router on D01ML255/01/M/IBM(Release 8.5.3FP2 ZX853FP2HF4|December 14, 2012) at 02/06/2013 10:30:45, Serialize complete at 02/06/2013 10:30:45
Content-Type: multipart/alternative; boundary="=_alternative 0055358A85257B0A_="
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 13020615-7182-0000-0000-00000506381E
Cc: "oauth@ietf.org WG" , oauth-bounces@ietf.org
Subject: Re: [OAUTH-WG] A question on token revocation.
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Feb 2013 15:30:57 -0000

This is a multipart message in MIME format.
--=_alternative 0055358A85257B0A_=
Content-Type: text/plain; charset="US-ASCII"

> If you would like to see the RO-initiated token revocation go through 
(not grant revocation, mind you -- that's related, but different), then I 
would suggest that you start specifying exactly how that works.

+1

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

From:   Justin Richer 
To:     Prabath Siriwardena , 
Cc:     "oauth@ietf.org WG" 
Date:   02/06/2013 10:21 AM
Subject:        Re: [OAUTH-WG] A question on token revocation.
Sent by:        oauth-bounces@ietf.org

On 02/06/2013 10:13 AM, Prabath Siriwardena wrote:

On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer  wrote:
These are generally handled through a user interface where the RO is 
authenticated directly to the AS, and there's not much need for a 
"protocol" here, in practice. 

Why do you think leaving access token revocation by RO to a proprietary 
API is a good practice ? IMO this an essential requirement in API 
security.
I think it makes more sense in the same way that having a "proprietary" 
UI/API for managing the user consent makes sense: unless you're doing a 
fully dynamic end-to-end system like UMA, then there's not much value in 
trying to squeeze disparate systems into the same mold, since they won't 
be talking to each other anyway. 

And since you refer to it as an "API", what will the RO be using to call 
this API? Is there a token management client that's separate from the 
OAuth client? 

IMHO token revocation done my RO is more practical than token revocation 
done by the Client.
They're both valid but require different kinds of protocols and 
considerations. This token revocation draft is meant to solve one problem, 
and that doesn't mean it can or should solve other seemingly related 
problems.

If you would like to see the RO-initiated token revocation go through (not 
grant revocation, mind you -- that's related, but different), then I would 
suggest that you start specifying exactly how that works. I predict it 
will be problematic in practice, though, as the RO often doesn't actually 
have direct access to the token itself. 

There are larger applications, like UMA, that have client and PR 
provisioning that would allow for this to be managed somewhat 
programmatically, but even in that case you're still generally doing token 
revocation by a "client" in some fashion. In UMA, though, several 
different pieces can play the role of a "client" at different parts of the 
process.

Revoking a scope is a whole different mess. Generally, you'd want to just 
revoke an existing token and make a new authorization grant with lower 
access if you don't want that client getting that scope anymore. If you 
just want to downscope for a single transaction, you can already do that 
with either the refresh token or token chaining approaches, depending on 
where in the process you are. The latter of these are both client-focused, 
though, and the RO doesn't have a direct hand in it at this point.

Why do you think it a mess. If you revoke the entire token then Client 
needs to go through the complete OAuth flow - and also needs to get the 
user consent. If RO can  downgrade the scope, then we restrict API access 
by the client at RS end and its transparent to the client.

Downgrading the scope of tokens in the wild is hardly transparent to the 
client (stuff that it expects to work will suddenly start to fail, meaning 
that most clients will throw out the token and try to get a new one), and 
in a distributed system you've got to propagate that change to the RS. If 
you bake the scopes into the token itself (which many do) then you 
actually *can't* downgrade a single token, anyway. 

 -- Justin

Thanks & regards,
-Prabath

 -- Justin 

On 02/06/2013 04:35 AM, Prabath Siriwardena wrote:
I am sorry if this was already discussed in this list.. 

Looking at [1] it only talks about revoking the access token from the 
client.

How about the resource owner..?

There can be cases where resource owner needs to revoke an authorized 
access token from a given client. Or revoke an scope..

How are we going to address these requirements..? Thoughts appreciated...

[1] http://tools.ietf.org/html/draft-ietf-oauth-revocation-04

-- 
Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

-- 
Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--=_alternative 0055358A85257B0A_=
Content-Type: text/html; charset="US-ASCII"

> If you would like
to see the RO-initiated token revocation go through (not grant revocation,
mind you -- that's related, but different), then I would suggest that you
start specifying exactly how that works.

+1

Todd Lainhart

Rational software

IBM Corporation

550 King Street, Littleton, MA 01460-1250

1-978-899-4705

2-276-4705 (T/L)

lainhart@us.ibm.com

From:      
 Justin Richer <jricher@mitre.org>

To:      
 Prabath Siriwardena
<prabath@wso2.com>, 

Cc:      
 "oauth@ietf.org
WG" <oauth@ietf.org>

Date:      
 02/06/2013 10:21 AM

Subject:    
   Re: [OAUTH-WG]
A question on token revocation.

Sent by:    
   oauth-bounces@ietf.org

On 02/06/2013 10:13 AM, Prabath Siriwardena wrote:

On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer <jricher@mitre.org>
wrote:

These are generally handled through a user interface where
the RO is authenticated directly to the AS, and there's not much need for
a "protocol" here, in practice. 

Why do you think leaving access token revocation by RO
to a proprietary API is a good practice ? IMO this an essential requirement
in API security.

I think it makes more sense in the same way that having
a "proprietary" UI/API for managing the user consent makes sense:
unless you're doing a fully dynamic end-to-end system like UMA, then there's
not much value in trying to squeeze disparate systems into the same mold,
since they won't be talking to each other anyway. 

And since you refer to it as an "API", what will the RO be using
to call this API? Is there a token management client that's separate from
the OAuth client? 

IMHO token revocation done my RO is more practical than
token revocation done by the Client.

They're both valid but require different kinds of protocols
and considerations. This token revocation draft is meant to solve one problem,
and that doesn't mean it can or should solve other seemingly related problems.

If you would like to see the RO-initiated token revocation go through (not
grant revocation, mind you -- that's related, but different), then I would
suggest that you start specifying exactly how that works. I predict it
will be problematic in practice, though, as the RO often doesn't actually
have direct access to the token itself. 

There are larger applications, like UMA, that have client
and PR provisioning that would allow for this to be managed somewhat programmatically,
but even in that case you're still generally doing token revocation by
a "client" in some fashion. In UMA, though, several different
pieces can play the role of a "client" at different parts of
the process.

Revoking a scope is a whole different mess. Generally, you'd want to just
revoke an existing token and make a new authorization grant with lower
access if you don't want that client getting that scope anymore. If you
just want to downscope for a single transaction, you can already do that
with either the refresh token or token chaining approaches, depending on
where in the process you are. The latter of these are both client-focused,
though, and the RO doesn't have a direct hand in it at this point.

Why do you think it a mess. If you revoke the entire token
then Client needs to go through the complete OAuth flow - and also needs
to get the user consent. If RO can  downgrade the scope, then we restrict
API access by the client at RS end and its transparent to the client.

Downgrading the scope of tokens in the wild is hardly transparent to the
client (stuff that it expects to work will suddenly start to fail, meaning
that most clients will throw out the token and try to get a new one), and
in a distributed system you've got to propagate that change to the RS.
If you bake the scopes into the token itself (which many do) then you actually
*can't* downgrade a single token, anyway. 

 -- Justin

Thanks & regards,

-Prabath

 -- Justin 

On 02/06/2013 04:35 AM, Prabath Siriwardena wrote:

I am sorry if this was already discussed in this list..

Looking at [1] it only talks about revoking the access
token from the client.

How about the resource owner..?

There can be cases where resource owner needs to revoke
an authorized access token from a given client. Or revoke an scope..

How are we going to address these requirements..? Thoughts
appreciated...

[1] http://tools.ietf.org/html/draft-ietf-oauth-revocation-04

-- 

Thanks & Regards,

Prabath 

Mobile : +94
71 809 6732 

http://blog.facilelogin.com

http://RampartFAQ.com

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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

-- 

Thanks & Regards,

Prabath 

Mobile : +94 71 809 6732 

http://blog.facilelogin.com

http://RampartFAQ.com

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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

--=_alternative 0055358A85257B0A_=--

From prabath@wso2.com  Wed Feb  6 07:31:33 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFA5D21F87F9 for ; Wed,  6 Feb 2013 07:31:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.403
X-Spam-Level: 
X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=0.573,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0CiiXUFP-PA for ; Wed,  6 Feb 2013 07:31:32 -0800 (PST)
Received: from mail-ea0-f180.google.com (mail-ea0-f180.google.com [209.85.215.180]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFE621F856F for ; Wed,  6 Feb 2013 07:31:31 -0800 (PST)
Received: by mail-ea0-f180.google.com with SMTP id c1so616469eaa.11 for ; Wed, 06 Feb 2013 07:31:31 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=xi9MVZtNIreYjjCkKamsk2gxd7cvYQ+aMRSS74ZkY4M=; b=VGpUHlAlQabsPCoI2d1wgShLWNQ4AbAtonFMxJyXgezbE/soFQOHX/zO7zN600+e+c 0GGDpAAoACvFU1oRwMiCGThO1xTfwB7BQ5vxlgIz+J5D59iRBZ//pqE0A6mRfOYydjeU TGgf0DO1DgpxPYFGafDm8WoHL+5ze1E5aRs+PbuGF2MXsyLkU9BxPiu5/EI8cX6/QwwO jvVf7I/V18s4VRlMHcQNjwDDTzJ7gFJcTsfrTne6ha8swT/GAtpeSJbO+4TgIdyBH3wP duyds+W+xkxzULS7x5HioOp0HC8Lt+PwrC0D+NMCKlaVu+apUEXvN3Qk0KJM2dWuxgkf 6ZvA==
MIME-Version: 1.0
X-Received: by 10.14.202.197 with SMTP id d45mr52218386eeo.1.1360164691145; Wed, 06 Feb 2013 07:31:31 -0800 (PST)
Received: by 10.223.175.134 with HTTP; Wed, 6 Feb 2013 07:31:31 -0800 (PST)
In-Reply-To: <5112746B.70403@mitre.org>
References:  <51126D65.2090707@mitre.org>  <5112746B.70403@mitre.org>
Date: Wed, 6 Feb 2013 21:01:31 +0530
Message-ID: 
From: Prabath Siriwardena 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=047d7b343b064074a904d51005e6
X-Gm-Message-State: ALoCoQlnDgbdriWEpRmKlLZneUzJtyggppNZrmXiX6IndZLGJSDuLVt6l7g0x4JL+NDv5n7f40oy
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] A question on token revocation.
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Feb 2013 15:31:33 -0000

--047d7b343b064074a904d51005e6
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Feb 6, 2013 at 8:49 PM, Justin Richer  wrote:

>
> On 02/06/2013 10:13 AM, Prabath Siriwardena wrote:
>
>
>
> On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer  wrote:
>
>>  These are generally handled through a user interface where the RO is
>> authenticated directly to the AS, and there's not much need for a
>> "protocol" here, in practice.
>>
>
>  Why do you think leaving access token revocation by RO to a proprietary
> API is a good practice ? IMO this an essential requirement in API security.
>
> I think it makes more sense in the same way that having a "proprietary"
> UI/API for managing the user consent makes sense: unless you're doing a
> fully dynamic end-to-end system like UMA, then there's not much value in
> trying to squeeze disparate systems into the same mold, since they won't be
> talking to each other anyway.
>

This is required in distributed setup for each API platform from different
vendors to perform in an interop manner.

>
> And since you refer to it as an "API", what will the RO be using to call
> this API? Is there a token management client that's separate from the OAuth
> client?
>

I didn't get your question right... If you meant the how to invoke
revocation end point, the the resource owner needs to know the consumer key
(represents the OAuth Client app) & scope to revoke the access token for a
given client.

>
>  IMHO token revocation done my RO is more practical than token revocation
> done by the Client.
>
> They're both valid but require different kinds of protocols and
> considerations. This token revocation draft is meant to solve one problem,
> and that doesn't mean it can or should solve other seemingly related
> problems.
>
> If you would like to see the RO-initiated token revocation go through (not
> grant revocation, mind you -- that's related, but different), then I would
> suggest that you start specifying exactly how that works. I predict it will
> be problematic in practice, though, as the RO often doesn't actually have
> direct access to the token itself.
>

Resource owner needs to know the consumer key (represents the OAuth Client
app) & scope to revoke the access token for a given client.

>
>
>
>> There are larger applications, like UMA, that have client and PR
>> provisioning that would allow for this to be managed somewhat
>> programmatically, but even in that case you're still generally doing token
>> revocation by a "client" in some fashion. In UMA, though, several different
>> pieces can play the role of a "client" at different parts of the process.
>>
>> Revoking a scope is a whole different mess. Generally, you'd want to just
>> revoke an existing token and make a new authorization grant with lower
>> access if you don't want that client getting that scope anymore. If you
>> just want to downscope for a single transaction, you can already do that
>> with either the refresh token or token chaining approaches, depending on
>> where in the process you are. The latter of these are both client-focused,
>> though, and the RO doesn't have a direct hand in it at this point.
>>
>
>  Why do you think it a mess. If you revoke the entire token then Client
> needs to go through the complete OAuth flow - and also needs to get the
> user consent. If RO can  downgrade the scope, then we restrict API access
> by the client at RS end and its transparent to the client.
>
>
> Downgrading the scope of tokens in the wild is hardly transparent to the
> client (stuff that it expects to work will suddenly start to fail, meaning
> that most clients will throw out the token and try to get a new one), and
> in a distributed system you've got to propagate that change to the RS. If
> you bake the scopes into the token itself (which many do) then you actually
> *can't* downgrade a single token, anyway.
>

Yes.. that is the expected behavior. I mean the process is transparent.
Client will notice at runtime.

Thanks & regards,
-Prabath

>
>  -- Justin
>
>
>  Thanks & regards,
> -Prabath
>
>
>>
>>
>>  -- Justin
>>
>>
>> On 02/06/2013 04:35 AM, Prabath Siriwardena wrote:
>>
>>  I am sorry if this was already discussed in this list..
>>
>>  Looking at [1] it only talks about revoking the access token from the
>> client.
>>
>>  How about the resource owner..?
>>
>>  There can be cases where resource owner needs to revoke an authorized
>> access token from a given client. Or revoke an scope..
>>
>>  How are we going to address these requirements..? Thoughts
>> appreciated...
>>
>>  [1] http://tools.ietf.org/html/draft-ietf-oauth-revocation-04
>>
>>  --
>> Thanks & Regards,
>> Prabath
>>
>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>
>> http://blog.facilelogin.com
>> http://RampartFAQ.com
>>
>>
>>   _______________________________________________
>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>
>
>  --
> Thanks & Regards,
> Prabath
>
>  Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com
>
>
>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.com

--047d7b343b064074a904d51005e6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 6, 2013 at 8:49 PM, Justin R=
icher <jricher@mitre.org> wrote:

 =20
   =20
 =20

    On 02/06/2013 10:13 AM, Prabath
      Siriwardena wrote:

     =20

      On Wed, Feb 6, 2013 at 8:19 PM, Justin
        Richer <jricher@mitre.org>
        wrote:

           These are generally
            handled through a user interface where the RO is
            authenticated directly to the AS, and there's not much need
            for a "protocol" here, in practice. 

        Why do you think leaving access token revocation by RO to a
          proprietary API is a good practice ? IMO this an essential
          requirement in API security.

    I think it makes more sense in the same way that having a
    "proprietary" UI/API for managing the user consent makes sens=
e:
    unless you're doing a fully dynamic end-to-end system like UMA, the=
n
    there's not much value in trying to squeeze disparate systems into
    the same mold, since they won't be talking to each other anyway. 

This is required in distributed se=
tup for each API platform from different vendors to perform in an interop m=
anner.
=A0

    And since you refer to it as an "API", what will the RO be us=
ing to
    call this API? Is there a token management client that's separate
    from the OAuth client? 

I did=
n't get your question right... If you meant the how to invoke revocatio=
n end point, the the resource owner needs to know the consumer key (represe=
nts the OAuth Client app) & scope to revoke the access token for a give=
n client.=A0

        IMHO token revocation done my RO is more practical than
          token revocation done by the Client.

    They're both valid but require different kinds of protocols and
    considerations. This token revocation draft is meant to solve one
    problem, and that doesn't mean it can or should solve other
    seemingly related problems.

    If you would like to see the RO-initiated token revocation go
    through (not grant revocation, mind you -- that's related, but
    different), then I would suggest that you start specifying exactly
    how that works. I predict it will be problematic in practice,
    though, as the RO often doesn't actually have direct access to the
    token itself. 

Resource owner=
 needs to know the consumer key (represents the OAuth Client app) & sco=
pe to revoke the access token for a given client.=A0

=A0

        =A0

          There are larger
            applications, like UMA, that have client and PR provisioning
            that would allow for this to be managed somewhat
            programmatically, but even in that case you're still
            generally doing token revocation by a "client" in som=
e
            fashion. In UMA, though, several different pieces can play
            the role of a "client" at different parts of the proc=
ess.

            Revoking a scope is a whole different mess. Generally, you'=
d
            want to just revoke an existing token and make a new
            authorization grant with lower access if you don't want tha=
t
            client getting that scope anymore. If you just want to
            downscope for a single transaction, you can already do that
            with either the refresh token or token chaining approaches,
            depending on where in the process you are. The latter of
            these are both client-focused, though, and the RO doesn't
            have a direct hand in it at this point.

        Why do you think it a mess. If you revoke the entire token
          then Client needs to go through the complete OAuth flow - and
          also needs to get the user consent. If RO can =A0downgrade the
          scope, then we restrict API access by the client at RS end and
          its transparent to the client.

    Downgrading the scope of tokens in the wild is hardly transparent to
    the client (stuff that it expects to work will suddenly start to
    fail, meaning that most clients will throw out the token and try to
    get a new one), and in a distributed system you've got to propagate
    that change to the RS. If you bake the scopes into the token itself
    (which many do) then you actually *can't* downgrade a single token,
    anyway. 

Yes.. that is the ex=
pected behavior. I mean the process is transparent. Client will notice at r=
untime.

Thanks & regards,
-Prabath
=A0

    =A0-- Justin

        Thanks & regards,
        -Prabath
        =A0

                =A0-- Justin

                On 02/06/2013 04:35 AM, Prabath Siriwardena wrote:

                  I am sorry if this was already discussed in this
                    list..=A0

                  Looking at [1] it only talks about revoking the
                    access token from the client.

                  How about the resource owner..?

                  There can be cases where resource owner needs to
                    revoke an authorized access token from a given
                    client. Or revoke an scope..

                  How are we going to address these requirements..?
                    Thoughts appreciated...

                  [1] http://tools.ietf.org/html/draft-ietf-oa=
uth-revocation-04

                  -- 

                  Thanks & Regards,

                  Prabath

                  Mobile : +94 71 809
                      6732=A0

                    http://blog.facilelogin.com

                    htt=
p://RampartFAQ.com

                _______________________________________________
OAuth mailing list
OAuth@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/oauth

      -- 

      Thanks & Regards,

      Prabath

      Mobile : +94 71 809 6732=A0

        http://bl=
og.facilelogin.com

        http://RampartF=
AQ.com

-- 
Thanks &=
 Regards,
Prabath
Mobile : +94 71 809 6732=A0

=
http://blog.facil=
elogin.com

http://RampartFAQ.com

--047d7b343b064074a904d51005e6--

From lainhart@us.ibm.com  Wed Feb  6 07:34:27 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5216621F875F for ; Wed,  6 Feb 2013 07:34:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.546
X-Spam-Level: 
X-Spam-Status: No, score=-10.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hN2B8qJTc7pn for ; Wed,  6 Feb 2013 07:34:26 -0800 (PST)
Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id E546521F868D for ; Wed,  6 Feb 2013 07:34:25 -0800 (PST)
Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for  from ; Wed, 6 Feb 2013 10:34:25 -0500
Received: from d01dlp03.pok.ibm.com (9.56.250.168) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted;  Wed, 6 Feb 2013 10:34:22 -0500
Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id E6693C90028; Wed,  6 Feb 2013 10:34:20 -0500 (EST)
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r16FYKUw29360192; Wed, 6 Feb 2013 10:34:20 -0500
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r16FYJQY009566; Wed, 6 Feb 2013 13:34:19 -0200
Received: from d01ml255.pok.ibm.com (d01ml255.pok.ibm.com [9.63.10.54]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r16FYA3u008297; Wed, 6 Feb 2013 13:34:14 -0200
In-Reply-To: 
References: 	<51126D65.2090707@mitre.org> 	<5112746B.70403@mitre.org> 
To: Prabath Siriwardena 
MIME-Version: 1.0
X-KeepSent: 8CC0704A:7E320CB4-85257B0A:0055661B; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3FP2 SHF22 July 19, 2012
Message-ID: 
From: Todd W Lainhart 
Date: Wed, 6 Feb 2013 10:34:09 -0500
X-MIMETrack: Serialize by Router on D01ML255/01/M/IBM(Release 8.5.3FP2 ZX853FP2HF4|December 14, 2012) at 02/06/2013 10:34:14, Serialize complete at 02/06/2013 10:34:14
Content-Type: multipart/alternative; boundary="=_alternative 0055864785257B0A_="
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 13020615-7182-0000-0000-00000506413B
Cc: oauth-bounces@ietf.org, "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] A question on token revocation.
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Feb 2013 15:34:27 -0000

This is a multipart message in MIME format.
--=_alternative 0055864785257B0A_=
Content-Type: text/plain; charset="US-ASCII"

> Resource owner needs to know the consumer key (represents the OAuth 
Client app) & scope to revoke the access token for a given client. 

I see - you're saying that requiring client credentials on the end point 
is the problem?

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

From:   Prabath Siriwardena 
To:     Justin Richer , 
Cc:     "oauth@ietf.org WG" 
Date:   02/06/2013 10:31 AM
Subject:        Re: [OAUTH-WG] A question on token revocation.
Sent by:        oauth-bounces@ietf.org

On Wed, Feb 6, 2013 at 8:49 PM, Justin Richer  wrote:

On 02/06/2013 10:13 AM, Prabath Siriwardena wrote:

On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer  wrote:
These are generally handled through a user interface where the RO is 
authenticated directly to the AS, and there's not much need for a 
"protocol" here, in practice. 

Why do you think leaving access token revocation by RO to a proprietary 
API is a good practice ? IMO this an essential requirement in API 
security.
I think it makes more sense in the same way that having a "proprietary" 
UI/API for managing the user consent makes sense: unless you're doing a 
fully dynamic end-to-end system like UMA, then there's not much value in 
trying to squeeze disparate systems into the same mold, since they won't 
be talking to each other anyway. 

This is required in distributed setup for each API platform from different 
vendors to perform in an interop manner.

And since you refer to it as an "API", what will the RO be using to call 
this API? Is there a token management client that's separate from the 
OAuth client? 

I didn't get your question right... If you meant the how to invoke 
revocation end point, the the resource owner needs to know the consumer 
key (represents the OAuth Client app) & scope to revoke the access token 
for a given client. 

IMHO token revocation done my RO is more practical than token revocation 
done by the Client.
They're both valid but require different kinds of protocols and 
considerations. This token revocation draft is meant to solve one problem, 
and that doesn't mean it can or should solve other seemingly related 
problems.

If you would like to see the RO-initiated token revocation go through (not 
grant revocation, mind you -- that's related, but different), then I would 
suggest that you start specifying exactly how that works. I predict it 
will be problematic in practice, though, as the RO often doesn't actually 
have direct access to the token itself. 

Resource owner needs to know the consumer key (represents the OAuth Client 
app) & scope to revoke the access token for a given client. 

There are larger applications, like UMA, that have client and PR 
provisioning that would allow for this to be managed somewhat 
programmatically, but even in that case you're still generally doing token 
revocation by a "client" in some fashion. In UMA, though, several 
different pieces can play the role of a "client" at different parts of the 
process.

Revoking a scope is a whole different mess. Generally, you'd want to just 
revoke an existing token and make a new authorization grant with lower 
access if you don't want that client getting that scope anymore. If you 
just want to downscope for a single transaction, you can already do that 
with either the refresh token or token chaining approaches, depending on 
where in the process you are. The latter of these are both client-focused, 
though, and the RO doesn't have a direct hand in it at this point.

Why do you think it a mess. If you revoke the entire token then Client 
needs to go through the complete OAuth flow - and also needs to get the 
user consent. If RO can  downgrade the scope, then we restrict API access 
by the client at RS end and its transparent to the client.

Downgrading the scope of tokens in the wild is hardly transparent to the 
client (stuff that it expects to work will suddenly start to fail, meaning 
that most clients will throw out the token and try to get a new one), and 
in a distributed system you've got to propagate that change to the RS. If 
you bake the scopes into the token itself (which many do) then you 
actually *can't* downgrade a single token, anyway. 

Yes.. that is the expected behavior. I mean the process is transparent. 
Client will notice at runtime.

Thanks & regards,
-Prabath

 -- Justin

Thanks & regards,
-Prabath

 -- Justin 

On 02/06/2013 04:35 AM, Prabath Siriwardena wrote:
I am sorry if this was already discussed in this list.. 

Looking at [1] it only talks about revoking the access token from the 
client.

How about the resource owner..?

There can be cases where resource owner needs to revoke an authorized 
access token from a given client. Or revoke an scope..

How are we going to address these requirements..? Thoughts appreciated...

[1] http://tools.ietf.org/html/draft-ietf-oauth-revocation-04

-- 
Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

-- 
Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--=_alternative 0055864785257B0A_=
Content-Type: text/html; charset="US-ASCII"

> Resource owner
needs to know the consumer key (represents the OAuth Client app) &
scope to revoke the access token for a given client. 

I see - you're saying that requiring
client credentials on the end point is the problem?

Todd Lainhart

Rational software

IBM Corporation

550 King Street, Littleton, MA 01460-1250

1-978-899-4705

2-276-4705 (T/L)

lainhart@us.ibm.com

From:      
 Prabath Siriwardena
<prabath@wso2.com>

To:      
 Justin Richer <jricher@mitre.org>,

Cc:      
 "oauth@ietf.org
WG" <oauth@ietf.org>

Date:      
 02/06/2013 10:31 AM

Subject:    
   Re: [OAUTH-WG]
A question on token revocation.

Sent by:    
   oauth-bounces@ietf.org

On Wed, Feb 6, 2013 at 8:49 PM, Justin Richer <jricher@mitre.org>
wrote:

On 02/06/2013 10:13 AM, Prabath Siriwardena wrote:

On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer <jricher@mitre.org>
wrote:

These are generally handled through a user interface where
the RO is authenticated directly to the AS, and there's not much need for
a "protocol" here, in practice. 

Why do you think leaving access token revocation by RO
to a proprietary API is a good practice ? IMO this an essential requirement
in API security.

I think it makes more sense in the same way that having
a "proprietary" UI/API for managing the user consent makes sense:
unless you're doing a fully dynamic end-to-end system like UMA, then there's
not much value in trying to squeeze disparate systems into the same mold,
since they won't be talking to each other anyway. 

This is required in distributed setup for each API platform
from different vendors to perform in an interop manner.

And since you refer to it as an "API", what will the RO be using
to call this API? Is there a token management client that's separate from
the OAuth client? 

I didn't get your question right... If you meant the how
to invoke revocation end point, the the resource owner needs to know the
consumer key (represents the OAuth Client app) & scope to revoke the
access token for a given client. 

IMHO token revocation done my RO is more practical than
token revocation done by the Client.

They're both valid but require different kinds of protocols
and considerations. This token revocation draft is meant to solve one problem,
and that doesn't mean it can or should solve other seemingly related problems.

If you would like to see the RO-initiated token revocation go through (not
grant revocation, mind you -- that's related, but different), then I would
suggest that you start specifying exactly how that works. I predict it
will be problematic in practice, though, as the RO often doesn't actually
have direct access to the token itself. 

Resource owner needs to know the consumer key (represents
the OAuth Client app) & scope to revoke the access token for a given
client. 

There are larger applications, like UMA, that have client
and PR provisioning that would allow for this to be managed somewhat programmatically,
but even in that case you're still generally doing token revocation by
a "client" in some fashion. In UMA, though, several different
pieces can play the role of a "client" at different parts of
the process.

Revoking a scope is a whole different mess. Generally, you'd want to just
revoke an existing token and make a new authorization grant with lower
access if you don't want that client getting that scope anymore. If you
just want to downscope for a single transaction, you can already do that
with either the refresh token or token chaining approaches, depending on
where in the process you are. The latter of these are both client-focused,
though, and the RO doesn't have a direct hand in it at this point.

Why do you think it a mess. If you revoke the entire token
then Client needs to go through the complete OAuth flow - and also needs
to get the user consent. If RO can  downgrade the scope, then we restrict
API access by the client at RS end and its transparent to the client.

Downgrading the scope of tokens in the wild is hardly
transparent to the client (stuff that it expects to work will suddenly
start to fail, meaning that most clients will throw out the token and try
to get a new one), and in a distributed system you've got to propagate
that change to the RS. If you bake the scopes into the token itself (which
many do) then you actually *can't* downgrade a single token, anyway. 

Yes.. that is the expected behavior. I mean the process
is transparent. Client will notice at runtime.

Thanks & regards,

-Prabath

 -- Justin

Thanks & regards,

-Prabath

 -- Justin 

On 02/06/2013 04:35 AM, Prabath Siriwardena wrote:

I am sorry if this was already discussed in this list.. 

Looking at [1] it only talks about revoking the access
token from the client.

How about the resource owner..?

There can be cases where resource owner needs to revoke
an authorized access token from a given client. Or revoke an scope..

How are we going to address these requirements..? Thoughts
appreciated...

[1] http://tools.ietf.org/html/draft-ietf-oauth-revocation-04

-- 

Thanks & Regards,

Prabath 

Mobile : +94
71 809 6732 

http://blog.facilelogin.com

http://RampartFAQ.com

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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

-- 

Thanks & Regards,

Prabath 

Mobile : +94
71 809 6732 

http://blog.facilelogin.com

http://RampartFAQ.com

-- 

Thanks & Regards,

Prabath

Mobile : +94 71 809 6732 

http://blog.facilelogin.com

http://RampartFAQ.com_______________________________________________

OAuth mailing list

OAuth@ietf.org

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

--=_alternative 0055864785257B0A_=--

From prabath@wso2.com  Wed Feb  6 07:34:33 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4541A21F8893 for ; Wed,  6 Feb 2013 07:34:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.467
X-Spam-Level: 
X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.509,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5vuzsJMgswm for ; Wed,  6 Feb 2013 07:34:32 -0800 (PST)
Received: from mail-ea0-f181.google.com (mail-ea0-f181.google.com [209.85.215.181]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3C221F897A for ; Wed,  6 Feb 2013 07:34:31 -0800 (PST)
Received: by mail-ea0-f181.google.com with SMTP id i13so671045eaa.26 for ; Wed, 06 Feb 2013 07:34:30 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=7IJA+kHYChNu8Rdxky5NCl7itvmL2VOsZhJgEtoPqhg=; b=Ke7bNyUjZxzIOQqyyOzA0IMhFX2ARS+OVgAA3mq6bPE8gRuJyVeHo3R6tEOvVzpHvs ugFHKdyRHD8GODeGz7Zg2j4bUSIfvH6lFUONczhhinx6o1qLc5c/q4tUPhFcE4FGfvl4 4JVXoGeIlz55O76qDOzz5ZRsA4h9eGLLhc5M0JpCsTK0cYyDPuZM3ghOx+Alf7U+xcu6 Bn4aBXeQ95RMFo6T7N75v3OjUnq3XzF3OPXu2ONm5UbPQg4qjPtAmW3Vq8rUxF8/1R6g vEYqGFLdEvuU4PaSBio6di61p6Gsz6yVcp7odq+5OX0bOd2cu8i/fnnGchav3SBgpko8 lDkw==
MIME-Version: 1.0
X-Received: by 10.14.211.137 with SMTP id w9mr97097235eeo.39.1360164870339; Wed, 06 Feb 2013 07:34:30 -0800 (PST)
Received: by 10.223.175.134 with HTTP; Wed, 6 Feb 2013 07:34:30 -0800 (PST)
In-Reply-To: 
References:  <51126D65.2090707@mitre.org>  <5112746B.70403@mitre.org> 
Date: Wed, 6 Feb 2013 21:04:30 +0530
Message-ID: 
From: Prabath Siriwardena 
To: Todd W Lainhart 
Content-Type: multipart/alternative; boundary=047d7b624ab8eebcf604d5100f36
X-Gm-Message-State: ALoCoQkAhqVAchA/nNm6EbHUFE3mMxBfqAjdyTL4CPFWU4gUcfamA/QfFB54VXcIoS/wBbBelZaw
Cc: oauth-bounces@ietf.org, "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] A question on token revocation.
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Feb 2013 15:34:33 -0000

--047d7b624ab8eebcf604d5100f36
Content-Type: text/plain; charset=ISO-8859-1

Sure that can done.. Do you see any issues having discuss that under the
same spec.. The purpose of both are the same. Only the actor differs.

Thanks & regards,
-Prabath

On Wed, Feb 6, 2013 at 9:00 PM, Todd W Lainhart  wrote:

> > If you would like to see the RO-initiated token revocation go through
> (not grant revocation, mind you -- that's related, but different), then I
> would suggest that you start specifying exactly how that works.
>
> +1
>
>  *
>
>
> Todd Lainhart
> Rational software
> IBM Corporation
> 550 King Street, Littleton, MA 01460-1250**
> 1-978-899-4705
> 2-276-4705 (T/L)
> lainhart@us.ibm.com*
>
>
>
>
> From:        Justin Richer 
> To:        Prabath Siriwardena ,
> Cc:        "oauth@ietf.org WG" 
> Date:        02/06/2013 10:21 AM
> Subject:        Re: [OAUTH-WG] A question on token revocation.
> Sent by:        oauth-bounces@ietf.org
> ------------------------------
>
>
>
>
> On 02/06/2013 10:13 AM, Prabath Siriwardena wrote:
>
>
> On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer <*jricher@mitre.org*>
> wrote:
> These are generally handled through a user interface where the RO is
> authenticated directly to the AS, and there's not much need for a
> "protocol" here, in practice.
>
> Why do you think leaving access token revocation by RO to a proprietary
> API is a good practice ? IMO this an essential requirement in API security.
> I think it makes more sense in the same way that having a "proprietary"
> UI/API for managing the user consent makes sense: unless you're doing a
> fully dynamic end-to-end system like UMA, then there's not much value in
> trying to squeeze disparate systems into the same mold, since they won't be
> talking to each other anyway.
>
> And since you refer to it as an "API", what will the RO be using to call
> this API? Is there a token management client that's separate from the OAuth
> client?
>
>
> IMHO token revocation done my RO is more practical than token revocation
> done by the Client.
> They're both valid but require different kinds of protocols and
> considerations. This token revocation draft is meant to solve one problem,
> and that doesn't mean it can or should solve other seemingly related
> problems.
>
> If you would like to see the RO-initiated token revocation go through (not
> grant revocation, mind you -- that's related, but different), then I would
> suggest that you start specifying exactly how that works. I predict it will
> be problematic in practice, though, as the RO often doesn't actually have
> direct access to the token itself.
>
>
> There are larger applications, like UMA, that have client and PR
> provisioning that would allow for this to be managed somewhat
> programmatically, but even in that case you're still generally doing token
> revocation by a "client" in some fashion. In UMA, though, several different
> pieces can play the role of a "client" at different parts of the process.
>
> Revoking a scope is a whole different mess. Generally, you'd want to just
> revoke an existing token and make a new authorization grant with lower
> access if you don't want that client getting that scope anymore. If you
> just want to downscope for a single transaction, you can already do that
> with either the refresh token or token chaining approaches, depending on
> where in the process you are. The latter of these are both client-focused,
> though, and the RO doesn't have a direct hand in it at this point.
>
> Why do you think it a mess. If you revoke the entire token then Client
> needs to go through the complete OAuth flow - and also needs to get the
> user consent. If RO can  downgrade the scope, then we restrict API access
> by the client at RS end and its transparent to the client.
>
>
> Downgrading the scope of tokens in the wild is hardly transparent to the
> client (stuff that it expects to work will suddenly start to fail, meaning
> that most clients will throw out the token and try to get a new one), and
> in a distributed system you've got to propagate that change to the RS. If
> you bake the scopes into the token itself (which many do) then you actually
> *can't* downgrade a single token, anyway.
>
> -- Justin
>
> Thanks & regards,
> -Prabath
>
>
>
> -- Justin
>
>
> On 02/06/2013 04:35 AM, Prabath Siriwardena wrote:
> I am sorry if this was already discussed in this list..
>
> Looking at [1] it only talks about revoking the access token from the
> client.
>
> How about the resource owner..?
>
> There can be cases where resource owner needs to revoke an authorized
> access token from a given client. Or revoke an scope..
>
> How are we going to address these requirements..? Thoughts appreciated...
>
> [1] *http://tools.ietf.org/html/draft-ietf-oauth-revocation-04*
>
> --
> Thanks & Regards,
> Prabath
>
> Mobile : *+94 71 809 6732* <%2B94%2071%20809%206732>
> *
> **http://blog.facilelogin.com* *
> **http://RampartFAQ.com* 
>
>
> _______________________________________________
> OAuth mailing list
> *OAuth@ietf.org* 
> *https://www.ietf.org/mailman/listinfo/oauth*
>
>
>
>
>
> --
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
> *
> **http://blog.facilelogin.com* *
> **http://RampartFAQ.com* 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.com

--047d7b624ab8eebcf604d5100f36
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Sure that can done.. Do you see any issues having discuss that under the sa=
me spec.. The purpose of both are the same. Only the actor differs.
Thanks & regards,-Prabath

On Wed, Feb 6, 2013 at 9:00 PM, Todd W Lainhart <lainhart@us.ibm.com=
> wrote:

> If=
 you would like
to see the RO-initiated token revocation go through (not grant revocation,
mind you -- that's related, but different), then I would suggest that y=
ou
start specifying exactly how that works.

+1

Todd Lainhart

Rational software

IBM Corporation

550 King Street, Littleton, MA 01460-1250

1-978-899-4705

2-276-4705 (T/L)

lainhart@us.ibm.co=
m

From: =A0 =
=A0 =A0
=A0Justin Richer <jricher@mitre.org>

To: =A0 =A0 =A0
=A0Prabath Siriwardena
<prabath@wso2.com<=
/a>>, 

Cc: =A0 =A0 =A0
=A0"oauth@ietf.org
WG" <oauth@ietf=
.org>

Date: =A0 =A0 =
=A0
=A002/06/2013 10:21 AM

Subject: =A0 =A0
=A0 =A0Re: [OAUTH-WG]
A question on token revocation.

Sent by: =
=A0 =A0
=A0 =A0oauth-bounces@ietf.org

On 02/06/2013 10:13 AM, Prabath Siriwardena wrote:

On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer <jricher@mitre.org>
wrote:

These are generally handled through a user interface w=
here
the RO is authenticated directly to the AS, and there's not much need f=
or
a "protocol" here, in practice. 

Why do you think leaving access token revocation by RO
to a proprietary API is a good practice ? IMO this an essential requirement
in API security.

I think it makes more sense in the same way that havin=
g
a "proprietary" UI/API for managing the user consent makes sense:
unless you're doing a fully dynamic end-to-end system like UMA, then th=
ere's
not much value in trying to squeeze disparate systems into the same mold,
since they won't be talking to each other anyway. 

And since you refer to it as an "API", what will the RO be using
to call this API? Is there a token management client that's separate fr=
om
the OAuth client? 

IMHO token revocation done my RO is more practical tha=
n
token revocation done by the Client.

They're both valid but require different kinds of =
protocols
and considerations. This token revocation draft is meant to solve one probl=
em,
and that doesn't mean it can or should solve other seemingly related pr=
oblems.

If you would like to see the RO-initiated token revocation go through (not
grant revocation, mind you -- that's related, but different), then I wo=
uld
suggest that you start specifying exactly how that works. I predict it
will be problematic in practice, though, as the RO often doesn't actual=
ly
have direct access to the token itself. 

=A0

There are larger applications, like UMA, that have cli=
ent
and PR provisioning that would allow for this to be managed somewhat progra=
mmatically,
but even in that case you're still generally doing token revocation by
a "client" in some fashion. In UMA, though, several different
pieces can play the role of a "client" at different parts of
the process.

Revoking a scope is a whole different mess. Generally, you'd want to ju=
st
revoke an existing token and make a new authorization grant with lower
access if you don't want that client getting that scope anymore. If you
just want to downscope for a single transaction, you can already do that
with either the refresh token or token chaining approaches, depending on
where in the process you are. The latter of these are both client-focused,
though, and the RO doesn't have a direct hand in it at this point.

Why do you think it a mess. If you revoke the entire t=
oken
then Client needs to go through the complete OAuth flow - and also needs
to get the user consent. If RO can =A0downgrade the scope, then we restrict
API access by the client at RS end and its transparent to the client.

Downgrading the scope of tokens in the wild is hardly transparent to the
client (stuff that it expects to work will suddenly start to fail, meaning
that most clients will throw out the token and try to get a new one), and
in a distributed system you've got to propagate that change to the RS.
If you bake the scopes into the token itself (which many do) then you actua=
lly
*can't* downgrade a single token, anyway. 

 -- Justin

Thanks & regards,

-Prabath

=A0

 -- Justin 

On 02/06/2013 04:35 AM, Prabath Siriwardena wrote:

I am sorry if this was already discussed in this list.=
.

Looking at [1] it only talks about revoking the access
token from the client.

How about the resource owner..?

There can be cases where resource owner needs to revok=
e
an authorized access token from a given client. Or revoke an scope..

How are we going to address these requirements..? Thou=
ghts
appreciated...

[1] http://tools.ietf.org/html/draft-ietf-oauth-revocation-04

-- 

Thanks & Regards,

Prabath 

Mobile : +94
71 809 6732 

http://blog.facilelogin.com

http://RampartFAQ.com

_______________________________________________
OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mai=
lman/listinfo/oauth

-- 

Thanks & Regards,

Prabath 

Mobile : +94 71 809 6732 

http://blog.facilelogin.com

http://RampartFAQ.com

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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

-- =

Thanks & Regards,
Prabath
Mobile : +94 71 809=
 6732=A0

h=
ttp://blog.facilelogin.com

http://RampartFAQ.com

--047d7b624ab8eebcf604d5100f36--

From prabath@wso2.com  Wed Feb  6 07:37:12 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F0821F84ED for ; Wed,  6 Feb 2013 07:37:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.559
X-Spam-Level: 
X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.417,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOCl-fVGWu+M for ; Wed,  6 Feb 2013 07:37:10 -0800 (PST)
Received: from mail-ea0-f177.google.com (mail-ea0-f177.google.com [209.85.215.177]) by ietfa.amsl.com (Postfix) with ESMTP id 5E67C21F875F for ; Wed,  6 Feb 2013 07:37:09 -0800 (PST)
Received: by mail-ea0-f177.google.com with SMTP id n13so611926eaa.36 for ; Wed, 06 Feb 2013 07:37:08 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=WNRgh1aUuCXV0xEVRJ5esQuCtTm4U2nIbcK7e3d0Jo4=; b=lxoIz6lIu34kLykiVFcX96x5WWDwhJ+h+U57sdKLMWu8zIK0ujM+xST+IEC3cM1H9W URvkSmhCeQqxbFYzj3NYewUIZMLP2f98FkNjs8vVUn9R2IPZCPQwiXajWU2cxmkhK5l2 HllfOuLbQxraNne2nRKhtlbg+bQ/A8af86SqcY/dhUziDhThH3uhlrS2oQiXvTz+3GUj M25qzYB1WViNTA4rGO+mQqgZi+pxKYV65CsH1FW6Pfz/Mzg9vYwDWsszzk19ba0Mn1f2 s2v+MRQLJx2zq7rWOZjYCMVrhppRUYa/wUxMLiHBlcGh4CpafMntIz7KTVTUlNbn/qSU 7ymg==
MIME-Version: 1.0
X-Received: by 10.14.173.196 with SMTP id v44mr97503267eel.29.1360165028348; Wed, 06 Feb 2013 07:37:08 -0800 (PST)
Received: by 10.223.175.134 with HTTP; Wed, 6 Feb 2013 07:37:08 -0800 (PST)
In-Reply-To: 
References:  <51126D65.2090707@mitre.org>  <5112746B.70403@mitre.org>  
Date: Wed, 6 Feb 2013 21:07:08 +0530
Message-ID: 
From: Prabath Siriwardena 
To: Todd W Lainhart 
Content-Type: multipart/alternative; boundary=047d7b60436859c55c04d51019f4
X-Gm-Message-State: ALoCoQlR4vHPB0C7WHgcr03YG46k0ZY+M/J3/5mKoR4sfpMXhB6g6yiOt6EwH3l745g2HHgxdrP1
Cc: oauth-bounces@ietf.org, "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] A question on token revocation.
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Feb 2013 15:37:12 -0000

--047d7b60436859c55c04d51019f4
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Feb 6, 2013 at 9:04 PM, Todd W Lainhart  wrote:

> > Resource owner needs to know the consumer key (represents the OAuth
> Client app) & scope to revoke the access token for a given client.
>
> I see - you're saying that requiring client credentials on the end point
> is the problem?
>

In fact what I meant was - when RO authorizes the an access token for
client for particular scope. Those information are kept at the AS.

Now - if the RO want to revoke access from the client - the RO needs to
authenticate him self to the AS and pass the consumer key and the scope. So
AS can revoke access.

Thanks & regards,
-Prabath

>
>  *
>
>
> Todd Lainhart
> Rational software
> IBM Corporation
> 550 King Street, Littleton, MA 01460-1250**
> 1-978-899-4705
> 2-276-4705 (T/L)
> lainhart@us.ibm.com*
>
>
>
>
> From:        Prabath Siriwardena 
> To:        Justin Richer ,
> Cc:        "oauth@ietf.org WG" 
> Date:        02/06/2013 10:31 AM
> Subject:        Re: [OAUTH-WG] A question on token revocation.
> Sent by:        oauth-bounces@ietf.org
> ------------------------------
>
>
>
>
>
> On Wed, Feb 6, 2013 at 8:49 PM, Justin Richer <*jricher@mitre.org*>
> wrote:
>
> On 02/06/2013 10:13 AM, Prabath Siriwardena wrote:
>
>
> On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer <*jricher@mitre.org*>
> wrote:
> These are generally handled through a user interface where the RO is
> authenticated directly to the AS, and there's not much need for a
> "protocol" here, in practice.
>
> Why do you think leaving access token revocation by RO to a proprietary
> API is a good practice ? IMO this an essential requirement in API security.
> I think it makes more sense in the same way that having a "proprietary"
> UI/API for managing the user consent makes sense: unless you're doing a
> fully dynamic end-to-end system like UMA, then there's not much value in
> trying to squeeze disparate systems into the same mold, since they won't be
> talking to each other anyway.
>
> This is required in distributed setup for each API platform from different
> vendors to perform in an interop manner.
>
>
> And since you refer to it as an "API", what will the RO be using to call
> this API? Is there a token management client that's separate from the OAuth
> client?
>
> I didn't get your question right... If you meant the how to invoke
> revocation end point, the the resource owner needs to know the consumer key
> (represents the OAuth Client app) & scope to revoke the access token for a
> given client.
>
>
>
> IMHO token revocation done my RO is more practical than token revocation
> done by the Client.
> They're both valid but require different kinds of protocols and
> considerations. This token revocation draft is meant to solve one problem,
> and that doesn't mean it can or should solve other seemingly related
> problems.
>
> If you would like to see the RO-initiated token revocation go through (not
> grant revocation, mind you -- that's related, but different), then I would
> suggest that you start specifying exactly how that works. I predict it will
> be problematic in practice, though, as the RO often doesn't actually have
> direct access to the token itself.
>
> Resource owner needs to know the consumer key (represents the OAuth Client
> app) & scope to revoke the access token for a given client.
>
>
>
>
> There are larger applications, like UMA, that have client and PR
> provisioning that would allow for this to be managed somewhat
> programmatically, but even in that case you're still generally doing token
> revocation by a "client" in some fashion. In UMA, though, several different
> pieces can play the role of a "client" at different parts of the process.
>
> Revoking a scope is a whole different mess. Generally, you'd want to just
> revoke an existing token and make a new authorization grant with lower
> access if you don't want that client getting that scope anymore. If you
> just want to downscope for a single transaction, you can already do that
> with either the refresh token or token chaining approaches, depending on
> where in the process you are. The latter of these are both client-focused,
> though, and the RO doesn't have a direct hand in it at this point.
>
> Why do you think it a mess. If you revoke the entire token then Client
> needs to go through the complete OAuth flow - and also needs to get the
> user consent. If RO can  downgrade the scope, then we restrict API access
> by the client at RS end and its transparent to the client.
>
>
> Downgrading the scope of tokens in the wild is hardly transparent to the
> client (stuff that it expects to work will suddenly start to fail, meaning
> that most clients will throw out the token and try to get a new one), and
> in a distributed system you've got to propagate that change to the RS. If
> you bake the scopes into the token itself (which many do) then you actually
> *can't* downgrade a single token, anyway.
>
> Yes.. that is the expected behavior. I mean the process is transparent.
> Client will notice at runtime.
>
> Thanks & regards,
> -Prabath
>
>
>  -- Justin
>
>
> Thanks & regards,
> -Prabath
>
>
>
>  -- Justin
>
>
> On 02/06/2013 04:35 AM, Prabath Siriwardena wrote:
> I am sorry if this was already discussed in this list..
>
> Looking at [1] it only talks about revoking the access token from the
> client.
>
> How about the resource owner..?
>
> There can be cases where resource owner needs to revoke an authorized
> access token from a given client. Or revoke an scope..
>
> How are we going to address these requirements..? Thoughts appreciated...
>
> [1] *http://tools.ietf.org/html/draft-ietf-oauth-revocation-04*
>
> --
> Thanks & Regards,
> Prabath
>
> Mobile : *+94 71 809 6732* <%2B94%2071%20809%206732>
> *
> **http://blog.facilelogin.com* *
> **http://RampartFAQ.com* 
>
>
> _______________________________________________
> OAuth mailing list
> *OAuth@ietf.org* 
> *https://www.ietf.org/mailman/listinfo/oauth*
>
>
>
>
>
> --
> Thanks & Regards,
> Prabath
>
> Mobile : *+94 71 809 6732* <%2B94%2071%20809%206732>
> *
> **http://blog.facilelogin.com* *
> **http://RampartFAQ.com* 
>
>
>
>
> --
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
> *
> **http://blog.facilelogin.com* *
> *
> *http://RampartFAQ.com* 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.com

--047d7b60436859c55c04d51019f4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 6, 2013 at 9:04 PM, Todd W L=
ainhart <lainhart@us.ibm.com> wrote:

> Re=
source owner
needs to know the consumer key (represents the OAuth Client app) &
scope to revoke the access token for a given client.=A0

I see - you're saying that requirin=
g
client credentials on the end point is the problem?
=

In fact what I meant was - when RO authorizes the an ac=
cess token for client for particular scope. Those information are kept at t=
he AS.

Now - if the RO want to revoke access from the client -=
 the RO needs to authenticate him self to the AS and pass the consumer key =
and the scope. So AS can revoke access.

Thanks &am=
p; regards,
-Prabath
=A0

Todd Lainhart

Rational software

IBM Corporation

550 King Street, Littleton, MA 01460-1250

1-978-899-4705

2-276-4705 (T/L)

lainhart@us.ibm.co=
m

From: =A0 =
=A0 =A0
=A0Prabath Siriwardena
<prabath@wso2.com<=
/a>>

To: =A0 =A0 =A0
=A0Justin Richer <jricher@mitre.org>,

Cc: =A0 =A0 =A0
=A0"oauth@ietf.org
WG" <oauth@ietf=
.org>

Date: =A0 =A0 =
=A0
=A002/06/2013 10:31 AM

Subject: =A0 =A0
=A0 =A0Re: [OAUTH-WG]
A question on token revocation.

Sent by: =A0 =A0
=A0 =A0oauth-bounces@ietf.org

On Wed, Feb 6, 2013 at 8:=
49 PM, Justin Richer <jricher@mitre.org=
>
wrote:

On 02/06/2013 10:13 AM, Prabath Siriwardena wrote:

On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer <jricher@mitre.org>
wrote:

These are generally handled through a user interface w=
here
the RO is authenticated directly to the AS, and there's not much need f=
or
a "protocol" here, in practice. 

Why do you think leaving access token revocation by RO
to a proprietary API is a good practice ? IMO this an essential requirement
in API security.

I think it makes more sense in the same way that havin=
g
a "proprietary" UI/API for managing the user consent makes sense:
unless you're doing a fully dynamic end-to-end system like UMA, then th=
ere's
not much value in trying to squeeze disparate systems into the same mold,
since they won't be talking to each other anyway. 

This is required in distributed setup for each API pla=
tform
from different vendors to perform in an interop manner.

=A0

And since you refer to it as an "API", what will the RO be using
to call this API? Is there a token management client that's separate fr=
om
the OAuth client? 

I didn't get your question right... If you meant t=
he how
to invoke revocation end point, the the resource owner needs to know the
consumer key (represents the OAuth Client app) & scope to revoke the
access token for a given client.=A0

IMHO token revocation done my RO is more practical tha=
n
token revocation done by the Client.

They're both valid but require different kinds of =
protocols
and considerations. This token revocation draft is meant to solve one probl=
em,
and that doesn't mean it can or should solve other seemingly related pr=
oblems.

If you would like to see the RO-initiated token revocation go through (not
grant revocation, mind you -- that's related, but different), then I wo=
uld
suggest that you start specifying exactly how that works. I predict it
will be problematic in practice, though, as the RO often doesn't actual=
ly
have direct access to the token itself. 

Resource owner needs to know the consumer key (represe=
nts
the OAuth Client app) & scope to revoke the access token for a given
client.=A0

=A0

=A0

There are larger applications, like UMA, that have cli=
ent
and PR provisioning that would allow for this to be managed somewhat progra=
mmatically,
but even in that case you're still generally doing token revocation by
a "client" in some fashion. In UMA, though, several different
pieces can play the role of a "client" at different parts of
the process.

Revoking a scope is a whole different mess. Generally, you'd want to ju=
st
revoke an existing token and make a new authorization grant with lower
access if you don't want that client getting that scope anymore. If you
just want to downscope for a single transaction, you can already do that
with either the refresh token or token chaining approaches, depending on
where in the process you are. The latter of these are both client-focused,
though, and the RO doesn't have a direct hand in it at this point.

Why do you think it a mess. If you revoke the entire t=
oken
then Client needs to go through the complete OAuth flow - and also needs
to get the user consent. If RO can =A0downgrade the scope, then we restrict
API access by the client at RS end and its transparent to the client.

Downgrading the scope of tokens in the wild is hardly
transparent to the client (stuff that it expects to work will suddenly
start to fail, meaning that most clients will throw out the token and try
to get a new one), and in a distributed system you've got to propagate
that change to the RS. If you bake the scopes into the token itself (which
many do) then you actually *can't* downgrade a single token, anyway. 

Yes.. that is the expected behavior. I mean the proces=
s
is transparent. Client will notice at runtime.

Thanks & regards,

-Prabath

=A0

=A0-- Justin

Thanks & regards,

-Prabath

=A0

=A0-- Justin 

On 02/06/2013 04:35 AM, Prabath Siriwardena wrote:

I am sorry if this was already discussed in this list.=
.=A0

Looking at [1] it only talks about revoking the access
token from the client.

How about the resource owner..?

There can be cases where resource owner needs to revok=
e
an authorized access token from a given client. Or revoke an scope..

How are we going to address these requirements..? Thou=
ghts
appreciated...

[1] http://tools.ietf.org/html/draft-ietf-oauth-revocation-04

-- 

Thanks & Regards,

Prabath 

Mobile : +94
71 809 6732=A0

http://blog.facilelogin.com

http://RampartFAQ.com

_______________________________________________
OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mai=
lman/listinfo/oauth

-- 

Thanks & Regards,

Prabath 

Mobile : +94
71 809 6732=A0

http://blog.facilelogin.com

http://RampartFAQ.com

-- 

Thanks & Regards,

Prabath

Mobile : +94 71 809 6732=A0

http://blog.facilelogin.com

http://RampartFAQ.com_______________________________________________

OAuth mailing list

OAuth@ietf.org

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

-- 
Thanks &=
amp; Regards,
Prabath
Mobile : +94 71 809 6732=A0
=

http://blog.f=
acilelogin.com

http://RampartFAQ.com

--047d7b60436859c55c04d51019f4--

From Adam.Lewis@motorolasolutions.com  Wed Feb  6 08:05:27 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722F821F8947 for ; Wed,  6 Feb 2013 08:05:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.516
X-Spam-Level: 
X-Spam-Status: No, score=-1.516 tagged_above=-999 required=5 tests=[AWL=-1.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_210=0.6, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rLPKudIRq62 for ; Wed,  6 Feb 2013 08:05:22 -0800 (PST)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 24B0A21F87FF for ; Wed,  6 Feb 2013 08:05:21 -0800 (PST)
Received: from mail131-va3-R.bigfish.com (10.7.14.246) by VA3EHSOBE011.bigfish.com (10.7.40.61) with Microsoft SMTP Server id 14.1.225.23; Wed, 6 Feb 2013 16:05:20 +0000
Received: from mail131-va3 (localhost [127.0.0.1])	by mail131-va3-R.bigfish.com (Postfix) with ESMTP id D51CC240160	for ; Wed,  6 Feb 2013 16:05:20 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:129.188.136.17; KIP:(null); UIP:(null); IPV:NLI; H:il06msg01.mot-solutions.com; RD:none; EFVD:NLI
X-SpamScore: -25
X-BigFish: VPS-25(zzbb2dI98dI9371Ic89bh936eI1b0bId772hc857hzz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL177df4h17326ah8275bh8275dh18c673hz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1155h)
Received-SPF: pass (mail131-va3: domain of motorolasolutions.com designates 129.188.136.17 as permitted sender) client-ip=129.188.136.17; envelope-from=Adam.Lewis@motorolasolutions.com; helo=il06msg01.mot-solutions.com ; olutions.com ; 
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.237.133; KIP:(null); UIP:(null); (null); H:BY2PRD0411HT005.namprd04.prod.outlook.com; R:internal; EFV:INT
Received: from mail131-va3 (localhost.localdomain [127.0.0.1]) by mail131-va3 (MessageSwitch) id 1360166716798860_17240; Wed,  6 Feb 2013 16:05:16 +0000 (UTC)
Received: from VA3EHSMHS001.bigfish.com (unknown [10.7.14.251])	by mail131-va3.bigfish.com (Postfix) with ESMTP id B3951C00A8	for ; Wed,  6 Feb 2013 16:05:16 +0000 (UTC)
Received: from il06msg01.mot-solutions.com (129.188.136.17) by VA3EHSMHS001.bigfish.com (10.7.99.11) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 6 Feb 2013 16:05:16 +0000
Received: from il06msg01.mot-solutions.com (il06vts02.mot.com [129.188.137.142])	by il06msg01.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r16H349a012958	for ; Wed, 6 Feb 2013 11:03:04 -0600 (CST)
Received: from CO9EHSOBE013.bigfish.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25])	by il06msg01.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r16H33ci012947	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 6 Feb 2013 11:03:04 -0600 (CST)
Received: from mail154-co9-R.bigfish.com (10.236.132.231) by CO9EHSOBE013.bigfish.com (10.236.130.76) with Microsoft SMTP Server id 14.1.225.23; Wed, 6 Feb 2013 16:05:14 +0000
Received: from mail154-co9 (localhost [127.0.0.1])	by mail154-co9-R.bigfish.com (Postfix) with ESMTP id 924FA4202E8	for ; Wed,  6 Feb 2013 16:05:14 +0000 (UTC)
Received: from mail154-co9 (localhost.localdomain [127.0.0.1]) by mail154-co9 (MessageSwitch) id 1360166711934037_31729; Wed,  6 Feb 2013 16:05:11 +0000 (UTC)
Received: from CO9EHSMHS007.bigfish.com (unknown [10.236.132.241])	by mail154-co9.bigfish.com (Postfix) with ESMTP id DF5F52C0072; Wed,  6 Feb 2013 16:05:11 +0000 (UTC)
Received: from BY2PRD0411HT005.namprd04.prod.outlook.com (157.56.237.133) by CO9EHSMHS007.bigfish.com (10.236.130.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 6 Feb 2013 16:05:11 +0000
Received: from BY2PRD0411MB441.namprd04.prod.outlook.com ([169.254.5.124]) by BY2PRD0411HT005.namprd04.prod.outlook.com ([10.255.128.40]) with mapi id 14.16.0263.000; Wed, 6 Feb 2013 16:05:09 +0000
From: Lewis Adam-CAL022 
To: William Mills , Tim Bray 
Thread-Topic: [OAUTH-WG] Why OAuth it self is not an authentication framework ?
Thread-Index: AQHOBAO7HOBDv8jxSkeu2jMRVB/25Jhs+8eAgAADjVA=
Date: Wed, 6 Feb 2013 16:05:08 +0000
Message-ID: <59E470B10C4630419ED717AC79FCF9A9483E7E50@BY2PRD0411MB441.namprd04.prod.outlook.com>
References:  <73B7EC23-AA93-42EE-B3EB-35BA1B82558F@ve7jtb.com> <511175AA.9030301@gmail.com> <1360099372.47338.YahooMailNeo@web31807.mail.mud.yahoo.com>  <59E470B10C4630419ED717AC79FCF9A9483E7B3D@BY2PRD0411MB441.namprd04.prod.outlook.com> <1360111712.54487.YahooMailNeo@web31812.mail.mud.yahoo.com> 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [150.130.10.219]
Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A9483E7E50BY2PRD0411MB441_"
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%1294$Dn%YAHOO.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn%
X-FOPE-CONNECTOR: Id%1294$Dn%GOOGLE.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn%
X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn%
X-CFilter-Loop: Reflected
X-OriginatorOrg: motorolasolutions.com
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Why OAuth it self is not an authentication framework ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Feb 2013 16:05:27 -0000

--_000_59E470B10C4630419ED717AC79FCF9A9483E7E50BY2PRD0411MB441_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgQmlsbCwNCg0KTXkgcmVhc29uIGZvciB1c2luZyBPQXV0aCByYXRoZXIgdGhhbiBPSURDIGlz
IGJlY2F1c2UgdGhlIGlkX3Rva2VuIGluIE9JREMgaXMgYXVkaWVuY2UgcmVzdHJpY3RlZCB0byB0
aGUgY2xpZW50LiAgVGhpcyB3YXMgY2xlYXJseSBpbnRlbmRlZCBmb3IgV2ViU1NPIC8gYXV0aGVu
dGljYXRpb24gdG8gYSBjbGllbnQgcnVubmluZyBvbiBhIHdlYiBzZXJ2ZXIuICBJdCBkb2VzIG5v
dCBoZWxwIHRoZSBjYXNlIHdoZXJlIHRoZSB1c2VyIG9mIGEgUkVTVGZ1bCBuYXRpdmUgY2xpZW50
IHdhbnQgdG8gYXV0aGVudGljYXRlIHRvIGEgUkVTVGZ1bCB3ZWIgc2VydmljZS4NCg0KSSBhZ3Jl
ZSB0aGF0IE9BdXRoIGxhY2tzIGEg4oCcZGVmaW5lZOKAnSB3YXkgdG8gY29tbXVuaWNhdGUgd2hh
dCBpcyBpbiB0aGUgQVQgKGFzIE9BdXRoIGRvZXMgbm90IGRlZmluZSB0aGUgY29udGVudCBvZiB0
aGUgQVQpLCBidXQgd2l0aGluIGFuIGVudGVycHJpc2UgZG9tYWluIHRoaXMgaXMgZWFzeSB0byBz
b2x2ZSBieSBwcm9maWxpbmcuICBBbmQgaW4gYW55IGltcGxlbWVudGF0aW9uIG9mIE9BdXRoIG9u
IHRoZSBJbnRlcm5ldCwgdGhlIEFUIG11c3QgYXQgc29tZSBsZXZlbCBpZGVudGlmeSB0aGUgdXNl
ciB0byB0aGUgUlMuICBPdGhlcndpc2UgaG93IGVsc2Ugd291bGQgdGhlIFJTIGtub3cgd2hv4oCZ
cyBwcm90ZWN0ZWQgcmVzb3VyY2VzIHRoZSBjbGllbnQgaXMgdHJ5aW5nIHRvIGFjY2Vzcz8gIE5v
dyB3aGV0aGVyIHRoZSBSUyBsZWFybnMgdGhhdCB0aHJvdWdoIGludHJvc3BlY3Rpb24gb3IgYnkg
cGFyc2luZyBhIEpXVC1zdHJ1Y3R1cmVkIEFUIGlzIG9mIGNvdXJzZSBub3QgZGVmaW5lZC4gIEJ1
dCBhdCB0aGUgZW5kIG9mIHRoZSBkYXksIHRoZSBBVCBkZWZpbml0ZWx5IChpbiBhbGwgY2FzZXMg
dGhhdCBJIGNhbiB0aGluayBvZikgaWRlbnRpZmllcyB0aGUgdXNlci4NCg0KSSBhbSBvcGVuIG1p
bmRlZCB0byB1c2luZyBPSURDIGlmIGluIHRoZSBmdXR1cmUgaWYgdGhlIGNsaWVudCBjYW4gcmVx
dWVzdCBhbiBpZF90b2tlbiB0aGF0IGlzIGF1ZGllbmNlIHJlc3RyaWN0ZWQgdG8gdGhlIFJTIGl0
IGlzIGdvaW5nIHRvIGNvbW11bmljYXRlLiAgSW4gb3RoZXIgd29yZHMsIHllcyBJIGFncmVlIHRo
YXQgT0lEQyBpcyB0aGUgcHJlZmVycmVkIG1lY2hhbmlzbSBmb3IgcGVyZm9ybWluZyDigJx1c2Vy
IGF1dGhlbnRpY2F0aW9uIHRvIGEgY2xpZW50LOKAnSBidXQgSSBhbHNvIGFyZ3VlIHRoYXQgT0F1
dGggaXMgdGhlIGJlc3QgbWV0aG9kIHRvIHBlcmZvcm0g4oCcdXNlciBhdXRoZW50aWNhdGlvbiB0
byBhbiBSU+KAnSAoaWYgeW91IHdhbnQgdG8gZ2V0IHlvdXIgUlMgb3V0IG9mIHRoZSBwYXNzd29y
ZCBjb25zdW1wdGlvbiBidXNpbmVzcykuICBJIGFtIG5vdCBhdCBhbGwgYWR2b2NhdGluZyBPQXV0
aCBmb3IgYXV0aGVudGljYXRpb24gdG8gYSBjbGllbnQuDQoNCi1hZGFtDQoNCkZyb206IFdpbGxp
YW0gTWlsbHMgW21haWx0bzp3bWlsbHNfOTIxMDVAeWFob28uY29tXQ0KU2VudDogVHVlc2RheSwg
RmVicnVhcnkgMDUsIDIwMTMgNjo0OSBQTQ0KVG86IExld2lzIEFkYW0tQ0FMMDIyOyBUaW0gQnJh
eQ0KQ2M6ICJXRyA8b2F1dGhAaWV0Zi5vcmc+IkBpbDA2ZXhyMDIubW90LmNvbQ0KU3ViamVjdDog
UmU6IFtPQVVUSC1XR10gV2h5IE9BdXRoIGl0IHNlbGYgaXMgbm90IGFuIGF1dGhlbnRpY2F0aW9u
IGZyYW1ld29yayA/DQoNCldoeSB1c2UgT0F1dGggd2hlbiBPcGVuSUQgZG9lcyBldmVyeXRoaW5n
IHRoYXQgT0F1dGggY2FuIGRvIGFzIGFuIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCBhbmQgZG9lcyBh
IGZldyB0aGluZ3MgbXVjaCBiZXR0ZXI/DQoNClNwZWNpZmljYWxseSBPQXV0aCBsYWNrcyBhbnkg
ZGVmaW5lZCB3YXkgdG86DQoNCi0gICAgZmVlZCBiYWNrIGFueSBhZGRpdGlvbmFsIGluZm9ybWF0
aW9uIGxpa2UgdGhlIHJlYWwgdXNlciBJRCAoYXMgb3Bwb3NlZCB0byB3aGF0IHRoZSBlbnRlcmVk
KQ0KLSAgICBib3VuZCBhbiBhdXRoZW50aWNhdGlvbiBldmVudCBpbiB0aW1lDQotICAgIHByb3Zp
ZGUgYW55IGZvcm0gb2YgYWRkaXRpb25hbCBTU08gcGF5bG9hZCBsaWtlIGEgZGlzcGxheSBuYW1l
IGZvciB0aGUgdXNlcg0KDQp0aGVyZSdzIHByb2JhYmx5IG90aGVyIHRoaW5ncy4NCg0KSXQnbGwg
bW9zdGx5IHdvcmsgYnV0IHRoZXJlIGFyZSB0aGluZ3MgaXQgZG9lc24ndCBkby4gIENvdWxkIHlv
dSBzb2x2ZSBzb21lIG9mIHRoZSByZXN0IG9mIHRoaXMgd2l0aCB0b2tlbiBpbnRyb3NwZWN0aW9u
IG9yIGEgdXNlciBBUEkgdGhhdCB0aGUgUlAgY291bGQgdXNlIHRvIGZldGNoIHVzZXIgaW5mbywg
c3VyZSwgYnV0IHdoeSByZWJ1aWxkIE9wZW5JRCB3aGVuIE9wZW5JRCBleGlzdHM/DQoNCi1iaWxs
DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IExld2lzIEFkYW0t
Q0FMMDIyIDxBZGFtLkxld2lzQG1vdG9yb2xhc29sdXRpb25zLmNvbT4NClRvOiBUaW0gQnJheSA8
dHdicmF5QGdvb2dsZS5jb20+OyBXaWxsaWFtIE1pbGxzIDx3bWlsbHNfOTIxMDVAeWFob28uY29t
Pg0KQ2M6ICJvYXV0aEBpZXRmLm9yZyBXRyIgPG9hdXRoQGlldGYub3JnPg0KU2VudDogVHVlc2Rh
eSwgRmVicnVhcnkgNSwgMjAxMyAyOjI3IFBNDQpTdWJqZWN0OiBSRTogW09BVVRILVdHXSBXaHkg
T0F1dGggaXQgc2VsZiBpcyBub3QgYW4gYXV0aGVudGljYXRpb24gZnJhbWV3b3JrID8NCg0KSSB0
aGluayB0aGlzIGlzIGJlY29taW5nIGEgbGFyZ2VseSBhY2FkZW1pYyAvIHBoaWxvc29waGljYWwg
YXJndW1lbnQgYnkgdGhpcyB0aW1lLiAgVGhlIHBlb3BsZSB3aG8gZGVzaWduZWQgT0F1dGggd2ls
bCBsaWtlbHkgcG9pbnQgb3V0IHRoYXQgaXQgd2FzIGNvbmNlcHR1YWxpemVkIGFzIGFuIGF1dGhv
cml6YXRpb24gcHJvdG9jb2wgdG8gZW5hYmxlIGEgUk8gdG8gZGVsZWdhdGUgYWNjZXNzIHRvIGEg
Y2xpZW50IHRvIGFjY2VzcyBpdHMgcHJvdGVjdGVkIHJlc291cmNlcyBvbiBzb21lIFJTLiAgQW5k
IG9mIGNvdXJzZSB0aGlzIGlzIHRoZSBoaXN0b3J5IG9mIGl0LiAgQW5kIHRoZSBSTyBhbmQgZW5k
LXVzZXIgd2VyZSB0eXBpY2FsbHkgdGhlIHNhbWUgZW50aXR5LiAgQnV0IGdldCBjYXVnaHQgdXAg
aW4gd2hhdCBpdCB3YXMgZW52aXNpb25lZCB0byBkbyB2cy4gcmVhbCBsaWZlIHVzZSBjYXNlcyB0
aGF0IE9BdXRoIGNhbiBzb2x2ZSAoYW5kIGlzIHNvbHZpbmcpIGJleW9uZCBpdHMgaW5pdGlhbCB1
c2UgY2FzZXMgbWlzc2VzIHRoZSBwb2ludCDigKYgYmVjYXVzZSBPQXV0aCBpcyBnYWluaW5nIHRy
YWN0aW9uIGluIHRoZSBlbnRlcnByaXNlIGFuZCB3aWxsIGJlIHVzZWQgaW4gYWxsIGRpZmZlcmVu
dCBzb3J0cyBvZiB3YXlzLCBpbmNsdWRpbmcgYXV0aGVudGljYXRpb24uDQoNClRoaXMgaXMgZXNw
ZWNpYWxseSB0cnVlIG9mIFJFU1RmdWwgQVBJcyB3aXRoaW4gYW4gZW50ZXJwcmlzZSB3aGVyZSB0
aGUgUk8gYW5kIGVuZC11c2VyIGFyZSAqbm90KiB0aGUgc2FtZTogZS5nLiBSTz1lbnRlcnByaXNl
IGFuZCBlbmQtdXNlcj1lbXBsb3llZS4gIEluIHRoaXMgbW9kZWwgdGhlIGVuZC11c2VyIGlzIG5v
dCBhdXRob3JpemluZyBhbnl0aGluZyB3aGVuIHRoZWlyIGNsaWVudCByZXF1ZXN0cyBhIHRva2Vu
IGZyb20gdGhlIEFTIOKApiB0aGV5IGF1dGhlbnRpY2F0ZSB0byB0aGUgQVMgYW5kIHRoZSBjbGll
bnQgZ2V0cyBhbiBBVCwgd2hpY2ggd2lsbCBsaWtlbHkgYmUgcHJvZmlsZWQgYnkgbW9zdCBlbnRl
cnByaXNlIGRlcGxveW1lbnRzIHRvIGxvb2sgc29tZXRoaW5nIGxpa2UgYW4gT0lEQyBpZF90b2tl
bi4gIFRoZSBBVCB3aWxsIGJlIHByZXNlbnRlZCB0byB0aGUgUlMgd2hpY2ggd2lsbCBleGFtaW5l
IHRoZSBjbGFpbXMgKHVzZXIgaWRlbnRpdHksIExPQSwgZXRjLikgYW5kIG1ha2UgYXV0aG9yaXph
dGlvbiBkZWNpc2lvbnMgYmFzZWQgb24gYnVzaW5lc3MgbG9naWMuICBUaGUgQVQgaGFzIG5vdCBh
dXRob3JpemVkIHRoZSB1c2VyIHRvIGRvIGFueXRoaW5nLCBpdCBoYXMgb25seSBtYWRlIGFuIGFz
c2VydGlvbiB0aGF0IHRoZSB1c2VyIGhhcyBiZWVuIGF1dGhlbnRpY2F0ZWQgYnkgdGhlIEFTIChz
b3J0IG9mIHNvdW5kcyBhIGxvdCBsaWtlIGFuIElkUCBub3cpLg0KDQpBbGwgdGhpcyB0YWxrZWQg
b2YgT0F1dGggYmVpbmcgYXV0aG9yaXphdGlvbiBhbmQgbm90IGF1dGhlbnRpY2F0aW9uIHdhcyBl
eHRyZW1lbHkgY29uZnVzaW5nIHRvIG1lIHdoZW4gSSBmaXJzdCBzdGFydGVkIGxvb2tpbmcgYXQg
T0F1dGggZm9yIG15IHVzZSBjYXNlcywgYW5kIEkgdGhpbmsgYXQgc29tZSBwb2ludCB0aGUgYXV0
aG9ycyBvZiBPQXV0aCBhcmUgZ29pbmcgdG8gaGF2ZSB0byByZWNvZ25pemUgdGhhdCB0aGVpciBi
YWJ5IGhhcyBncm93biB1cCB0byBiZSBtdWx0aS1mYWNldGVkIChhbmQgSSBtZWFuIHRoaXMgYXMg
YSBjb21wbGVtZW50KS4gIFRoZSBhYnN0cmFjdGlvbnMgbGVmdCBpbiB0aGUgT0F1dGggc3BlYyAo
d2hpbGUgc29tZSBoYXZlIGNsYWltZWQgb2YgdGhlIGxhY2sgb2YgaW50ZXJvcGVyYWJpbGl0eSBp
dCB3aWxsIGNhdXNlKSB3aWxsIGFsc28gZW5hYmxlIGl0IHRvIGJlIHVzZWQgaW4gd2F5cyBwb3Nz
aWJseSBzdGlsbCBub3QgZW52aXNpb25lZCBieSBhbnkgb2YgdXMuICBJIHRoaW5rIGFzIHNvb24g
YXMgd2UgY2FuIHN0b3AgdHJ5aW5nIHRvIGRyYXcgdGhlIGFydGlmaWNpYWwgbGluZSBhcm91bmQg
T0F1dGggYmVpbmcg4oCcYW4gYXV0aG9yaXphdGlvbiBwcm90b2NvbOKAnSB0aGUgYmV0dGVyIHRo
aW5ncyB3aWxsIGJlLg0KDQpJIGxpa2UgdG8gc2F5IHRoYXQgdGhleSBhdXRob3JzIGhhZCBpdCBy
aWdodCB3aGVuIHRoZXkgbmFtZWQgaXQg4oCcT0F1dGjigJ0gYW5kIG5vdCDigJxPQXV0aFLigJ0g
4pi6DQoNCi1hZGFtDQoNCkZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0
aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGltIEJyYXkNClNlbnQ6IFR1ZXNkYXks
IEZlYnJ1YXJ5IDA1LCAyMDEzIDM6MjggUE0NClRvOiBXaWxsaWFtIE1pbGxzDQpDYzogb2F1dGhA
aWV0Zi5vcmcgV0cNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFdoeSBPQXV0aCBpdCBzZWxmIGlz
IG5vdCBhbiBhdXRoZW50aWNhdGlvbiBmcmFtZXdvcmsgPw0KDQpPSURDIHNlZW1zIGFib3V0IHRo
ZSBtb3N0IHBsYXVzaWJsZSBjYW5kaWRhdGUgZm9yIGEg4oCcZ29vZCBnZW5lcmFsIHNvbHV0aW9u
4oCdIHRoYXQgSeKAmW0gYXdhcmUgb2YuICAgLVQNCk9uIFR1ZSwgRmViIDUsIDIwMTMgYXQgMToy
MiBQTSwgV2lsbGlhbSBNaWxscyA8d21pbGxzXzkyMTA1QHlhaG9vLmNvbTxtYWlsdG86d21pbGxz
XzkyMTA1QHlhaG9vLmNvbT4+IHdyb3RlOg0KVGhlcmUgYXJlIHNvbWUgc3BlY2lmaWMgZGVzaWdu
IG1pcy1tYXRjaGVzIGZvciBPQXV0aCBhcyBhbiBhdXRoZW50aWNhdGlvbiBwcm90b2NvbCwgaXQn
cyBub3Qgd2hhdCBpdCdzIGRlc2lnbmVkIGZvciBhbmQgdGhlcmUgYXJlIHNvbWUgcHJvYmxlbXMg
eW91IHdpbGwgcnVuIGludG8uICBTb21lIGhhdmUgdXNlZCBpdCBhcyBzdWNoLCBidXQgaXQncyBu
b3QgYSBnb29kIGdlbmVyYWwgc29sdXRpb24uDQoNCi1iaWxsDQoNCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQpGcm9tOiBQYXVsIE1hZHNlbiA8cGF1bC5tYWRzZW5AZ21haWwuY29t
PG1haWx0bzpwYXVsLm1hZHNlbkBnbWFpbC5jb20+Pg0KVG86IEpvaG4gQnJhZGxleSA8dmU3anRi
QHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4NCkNjOiAib2F1dGhAaWV0Zi5v
cmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPiBXRyIgPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0
aEBpZXRmLm9yZz4+DQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSA1LCAyMDEzIDE6MTIgUE0NClN1
YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFdoeSBPQXV0aCBpdCBzZWxmIGlzIG5vdCBhbiBhdXRoZW50
aWNhdGlvbiBmcmFtZXdvcmsgPw0KDQp3aHkgcGlnZW9uaG9sZSBpdD8NCg0KT0F1dGggY2FuIGJl
IGRlcGxveWVkIHdpdGggbm8gYXV0aHogc2VtYW50aWNzIGF0IGFsbCAob3IgYXQgbGVhc3QgYXMg
bGl0dGxlIGFzIGFueSBhdXRobiBtZWNoYW5pc20pLCBlLmcgY2xpZW50IGNyZWRzIGdyYW50IHR5
cGUgd2l0aCBubyBzY29wZXMNCg0KSSBhZ3JlZSB0aGF0IE9BdXRoIGlzIG5vdCBhbiAqU1NPKiBw
cm90b2NvbC4NCk9uIDIvNS8xMyAzOjM2IFBNLCBKb2huIEJyYWRsZXkgd3JvdGU6DQpPQXV0aCBp
cyBhbiBBdXRob3JpemF0aW9uIHByb3RvY29sIGFzIG1hbnkgb2YgdXMgaGF2ZSBwb2ludGVkIG91
dC4NCg0KVGhlIHBvc3QgaXMgbGFyZ2VseSBjb3JyZWN0IGFuZCBiYXNlZCBvbiBvbmUgb2YgbWlu
ZS4NCg0KSm9obiBCLg0KDQpPbiAyMDEzLTAyLTA1LCBhdCAxMjo1MiBQTSwgUHJhYmF0aCBTaXJp
d2FyZGVuYSA8cHJhYmF0aEB3c28yLmNvbTxtYWlsdG86cHJhYmF0aEB3c28yLmNvbT4+IHdyb3Rl
Og0KDQpGWUkgYW5kIGZvciB5b3VyIGNvbW1lbnRzLi4NCg0KaHR0cDovL2Jsb2cuZmFjaWxlbG9n
aW4uY29tLzIwMTMvMDIvd2h5LW9hdXRoLWl0LXNlbGYtaXMtbm90LWF1dGhlbnRpY2F0aW9uLmh0
bWwNCg0KVGhhbmtzICYgUmVnYXJkcywNClByYWJhdGgNCg0KTW9iaWxlIDogKzk0IDcxIDgwOSA2
NzMyDQpodHRwOi8vYmxvZy5mYWNpbGVsb2dpbi5jb20vDQpodHRwOi8vcmFtcGFydGZhcS5jb20v
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGgg
bWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxp
c3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhA
aWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86
T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h
dXRoDQoNCg0K

--_000_59E470B10C4630419ED717AC79FCF9A9483E7E50BY2PRD0411MB441_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp
ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7
YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0
I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh
W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAw
IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh
bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7
Zm9udC1mYW1pbHk6IkJvb2sgQW50aXF1YSI7DQoJcGFub3NlLTE6MiA0IDYgMiA1IDMgNSAzIDMg
NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEg
NiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg
bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv
bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS
b21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K
YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h
dHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250
LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsInNlcmlmIjt9DQpzcGFu
LkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRl
ZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg
UHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpwLnlpdjIxNDExNDQ3MTBt
c29ub3JtYWwsIGxpLnlpdjIxNDExNDQ3MTBtc29ub3JtYWwsIGRpdi55aXYyMTQxMTQ0NzEwbXNv
bm9ybWFsDQoJe21zby1zdHlsZS1uYW1lOnlpdjIxNDExNDQ3MTBtc29ub3JtYWw7DQoJbXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250
LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAueWl2MjE0MTE0NDcxMG1zb25v
cm1hbDEsIGxpLnlpdjIxNDExNDQ3MTBtc29ub3JtYWwxLCBkaXYueWl2MjE0MTE0NDcxMG1zb25v
cm1hbDENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjE0MTE0NDcxMG1zb25vcm1hbDE7DQoJbWFyZ2lu
OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250
LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uYXBwbGUtdGFiLXNwYW4N
Cgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNwYW47fQ0Kc3Bhbi55aXYyMTQxMTQ0NzEwbXNv
aHlwZXJsaW5rDQoJe21zby1zdHlsZS1uYW1lOnlpdjIxNDExNDQ3MTBtc29oeXBlcmxpbms7fQ0K
c3Bhbi55aXYyMTQxMTQ0NzEwbXNvaHlwZXJsaW5rZm9sbG93ZWQNCgl7bXNvLXN0eWxlLW5hbWU6
eWl2MjE0MTE0NDcxMG1zb2h5cGVybGlua2ZvbGxvd2VkO30NCnNwYW4ueWl2MjE0MTE0NDcxMGh0
bWxwcmVmb3JtYXR0ZWRjaGFyDQoJe21zby1zdHlsZS1uYW1lOnlpdjIxNDExNDQ3MTBodG1scHJl
Zm9ybWF0dGVkY2hhcjt9DQpzcGFuLnlpdjIxNDExNDQ3MTBlbWFpbHN0eWxlMTkNCgl7bXNvLXN0
eWxlLW5hbWU6eWl2MjE0MTE0NDcxMGVtYWlsc3R5bGUxOTt9DQpzcGFuLnlpdjIxNDExNDQ3MTBt
c29oeXBlcmxpbmsxDQoJe21zby1zdHlsZS1uYW1lOnlpdjIxNDExNDQ3MTBtc29oeXBlcmxpbmsx
Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLnlpdjIx
NDExNDQ3MTBtc29oeXBlcmxpbmtmb2xsb3dlZDENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjE0MTE0
NDcxMG1zb2h5cGVybGlua2ZvbGxvd2VkMTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0
aW9uOnVuZGVybGluZTt9DQpzcGFuLnlpdjIxNDExNDQ3MTBodG1scHJlZm9ybWF0dGVkY2hhcjEN
Cgl7bXNvLXN0eWxlLW5hbWU6eWl2MjE0MTE0NDcxMGh0bWxwcmVmb3JtYXR0ZWRjaGFyMTsNCglm
b250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLnlpdjIxNDExNDQ3MTBlbWFpbHN0eWxlMTkxDQoJ
e21zby1zdHlsZS1uYW1lOnlpdjIxNDExNDQ3MTBlbWFpbHN0eWxlMTkxOw0KCWZvbnQtZmFtaWx5
OiJCb29rIEFudGlxdWEiLCJzZXJpZiI7DQoJY29sb3I6b2xpdmU7DQoJZm9udC13ZWlnaHQ6bm9y
bWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0K
c3Bhbi5FbWFpbFN0eWxlMzANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p
bHk6IkJvb2sgQW50aXF1YSIsInNlcmlmIjsNCgljb2xvcjpvbGl2ZTsNCglmb250LXdlaWdodDpu
b3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9
DQpzcGFuLkVtYWlsU3R5bGUzMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm
b250LWZhbWlseToiQm9vayBBbnRpcXVhIiwic2VyaWYiOw0KCWNvbG9yOm9saXZlOw0KCWZvbnQt
d2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9u
ZSBub25lO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K
CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu
MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x
DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4
bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94
bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2
OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw
ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs
aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh
bWlseTomcXVvdDtCb29rIEFudGlxdWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6b2xp
dmUiPkhpIEJpbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9vayBBbnRp
cXVhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOm9saXZlIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtCb29rIEFudGlxdWEmcXVvdDssJnF1b3Q7c2VyaWYm
cXVvdDs7Y29sb3I6b2xpdmUiPk15IHJlYXNvbiBmb3IgdXNpbmcgT0F1dGggcmF0aGVyIHRoYW4g
T0lEQyBpcyBiZWNhdXNlIHRoZSBpZF90b2tlbiBpbiBPSURDIGlzIGF1ZGllbmNlIHJlc3RyaWN0
ZWQgdG8gdGhlIGNsaWVudC4mbmJzcDsgVGhpcyB3YXMgY2xlYXJseSBpbnRlbmRlZCBmb3IgV2Vi
U1NPIC8gYXV0aGVudGljYXRpb24NCiB0byBhIGNsaWVudCBydW5uaW5nIG9uIGEgd2ViIHNlcnZl
ci4mbmJzcDsgSXQgZG9lcyBub3QgaGVscCB0aGUgY2FzZSB3aGVyZSB0aGUgdXNlciBvZiBhIFJF
U1RmdWwgbmF0aXZlIGNsaWVudCB3YW50IHRvIGF1dGhlbnRpY2F0ZSB0byBhIFJFU1RmdWwgd2Vi
IHNlcnZpY2UuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtCb29r
IEFudGlxdWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6b2xpdmUiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2sgQW50aXF1YSZxdW90OywmcXVvdDtz
ZXJpZiZxdW90Oztjb2xvcjpvbGl2ZSI+SSBhZ3JlZSB0aGF0IE9BdXRoIGxhY2tzIGEg4oCcZGVm
aW5lZOKAnSB3YXkgdG8gY29tbXVuaWNhdGUgd2hhdCBpcyBpbiB0aGUgQVQgKGFzIE9BdXRoIGRv
ZXMgbm90IGRlZmluZSB0aGUgY29udGVudCBvZiB0aGUgQVQpLCBidXQgd2l0aGluIGFuIGVudGVy
cHJpc2UgZG9tYWluIHRoaXMNCiBpcyBlYXN5IHRvIHNvbHZlIGJ5IHByb2ZpbGluZy4mbmJzcDsg
QW5kIGluIGFueSBpbXBsZW1lbnRhdGlvbiBvZiBPQXV0aCBvbiB0aGUgSW50ZXJuZXQsIHRoZSBB
VCBtdXN0IGF0IHNvbWUgbGV2ZWwgaWRlbnRpZnkgdGhlIHVzZXIgdG8gdGhlIFJTLiZuYnNwOyBP
dGhlcndpc2UgaG93IGVsc2Ugd291bGQgdGhlIFJTIGtub3cgd2hv4oCZcyBwcm90ZWN0ZWQgcmVz
b3VyY2VzIHRoZSBjbGllbnQgaXMgdHJ5aW5nIHRvIGFjY2Vzcz8mbmJzcDsgTm93IHdoZXRoZXIg
dGhlIFJTIGxlYXJucw0KIHRoYXQgdGhyb3VnaCBpbnRyb3NwZWN0aW9uIG9yIGJ5IHBhcnNpbmcg
YSBKV1Qtc3RydWN0dXJlZCBBVCBpcyBvZiBjb3Vyc2Ugbm90IGRlZmluZWQuJm5ic3A7IEJ1dCBh
dCB0aGUgZW5kIG9mIHRoZSBkYXksIHRoZSBBVCBkZWZpbml0ZWx5IChpbiBhbGwgY2FzZXMgdGhh
dCBJIGNhbiB0aGluayBvZikgaWRlbnRpZmllcyB0aGUgdXNlci4mbmJzcDsNCjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2sgQW50aXF1YSZxdW90OywmcXVvdDtzZXJpZiZx
dW90Oztjb2xvcjpvbGl2ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Qm9vayBBbnRpcXVhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOm9saXZlIj5JIGFt
IG9wZW4gbWluZGVkIHRvIHVzaW5nIE9JREMgaWYgaW4gdGhlIGZ1dHVyZSBpZiB0aGUgY2xpZW50
IGNhbiByZXF1ZXN0IGFuIGlkX3Rva2VuIHRoYXQgaXMgYXVkaWVuY2UgcmVzdHJpY3RlZCB0byB0
aGUgUlMgaXQgaXMgZ29pbmcgdG8gY29tbXVuaWNhdGUuJm5ic3A7IEluIG90aGVyDQogd29yZHMs
IHllcyBJIGFncmVlIHRoYXQgT0lEQyBpcyB0aGUgcHJlZmVycmVkIG1lY2hhbmlzbSBmb3IgcGVy
Zm9ybWluZyDigJx1c2VyIGF1dGhlbnRpY2F0aW9uIHRvIGEgY2xpZW50LOKAnSBidXQgSSBhbHNv
IGFyZ3VlIHRoYXQgT0F1dGggaXMgdGhlIGJlc3QgbWV0aG9kIHRvIHBlcmZvcm0g4oCcdXNlciBh
dXRoZW50aWNhdGlvbiB0byBhbiBSU+KAnSAoaWYgeW91IHdhbnQgdG8gZ2V0IHlvdXIgUlMgb3V0
IG9mIHRoZSBwYXNzd29yZCBjb25zdW1wdGlvbiBidXNpbmVzcykuJm5ic3A7DQogSSBhbSBub3Qg
YXQgYWxsIGFkdm9jYXRpbmcgT0F1dGggZm9yIGF1dGhlbnRpY2F0aW9uIHRvIGEgY2xpZW50LiZu
YnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtCb29rIEFudGlxdWEmcXVv
dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6b2xpdmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0
O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2sgQW50aXF1YSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztj
b2xvcjpvbGl2ZSI+LWFkYW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtCb29r
IEFudGlxdWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6b2xpdmUiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw
YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh
aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gV2lsbGlhbSBNaWxscyBbbWFpbHRv
OndtaWxsc185MjEwNUB5YWhvby5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgRmVi
cnVhcnkgMDUsIDIwMTMgNjo0OSBQTTxicj4NCjxiPlRvOjwvYj4gTGV3aXMgQWRhbS1DQUwwMjI7
IFRpbSBCcmF5PGJyPg0KPGI+Q2M6PC9iPiAmcXVvdDtXRyAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7
JnF1b3Q7QGlsMDZleHIwMi5tb3QuY29tPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgt
V0ddIFdoeSBPQXV0aCBpdCBzZWxmIGlzIG5vdCBhbiBhdXRoZW50aWNhdGlvbiBmcmFtZXdvcmsg
PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+V2h5
IHVzZSBPQXV0aCB3aGVuIE9wZW5JRCBkb2VzIGV2ZXJ5dGhpbmcgdGhhdCBPQXV0aCBjYW4gZG8g
YXMgYW4gYXV0aGVudGljYXRpb24gbWV0aG9kIGFuZCBkb2VzIGEgZmV3IHRoaW5ncyBtdWNoIGJl
dHRlcj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDss
JnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlNwZWNpZmljYWxseSBPQXV0aCBsYWNrcyBh
bnkgZGVmaW5lZCB3YXkgdG86PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYm
cXVvdDs7Y29sb3I6YmxhY2siPi08c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZu
YnNwOyZuYnNwOw0KPC9zcGFuPmZlZWQgYmFjayBhbnkgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBs
aWtlIHRoZSByZWFsIHVzZXIgSUQgKGFzIG9wcG9zZWQgdG8gd2hhdCB0aGUgZW50ZXJlZCk8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2Vy
aWYmcXVvdDs7Y29sb3I6YmxhY2siPi08c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNw
OyZuYnNwOyZuYnNwOw0KPC9zcGFuPmJvdW5kIGFuIGF1dGhlbnRpY2F0aW9uIGV2ZW50IGluIHRp
bWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1
b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPi08c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4i
PiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPnByb3ZpZGUgYW55IGZvcm0gb2YgYWRkaXRpb25h
bCBTU08gcGF5bG9hZCBsaWtlIGEgZGlzcGxheSBuYW1lIGZvciB0aGUgdXNlcjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90
Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj50aGVyZSdzIHBy
b2JhYmx5IG90aGVyIHRoaW5ncy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJp
ZiZxdW90Oztjb2xvcjpibGFjayI+SXQnbGwgbW9zdGx5IHdvcmsgYnV0IHRoZXJlIGFyZSB0aGlu
Z3MgaXQgZG9lc24ndCBkby4gJm5ic3A7Q291bGQgeW91IHNvbHZlIHNvbWUgb2YgdGhlIHJlc3Qg
b2YgdGhpcyB3aXRoIHRva2VuIGludHJvc3BlY3Rpb24gb3IgYSB1c2VyIEFQSSB0aGF0IHRoZSBS
UCBjb3VsZCB1c2UgdG8gZmV0Y2ggdXNlciBpbmZvLA0KIHN1cmUsIGJ1dCB3aHkgcmVidWlsZCBP
cGVuSUQgd2hlbiBPcGVuSUQgZXhpc3RzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90
O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4tYmlsbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIg
YWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUi
Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+DQo8aHIgc2l6ZT0iMSIg
d2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOmJsYWNrIj4gTGV3aXMgQWRhbS1DQUwwMjIgJmx0O0FkYW0uTGV3aXNAbW90b3Jv
bGFzb2x1dGlvbnMuY29tJmd0Ozxicj4NCjxiPlRvOjwvYj4gVGltIEJyYXkgJmx0O3R3YnJheUBn
b29nbGUuY29tJmd0OzsgV2lsbGlhbSBNaWxscyAmbHQ7d21pbGxzXzkyMTA1QHlhaG9vLmNvbSZn
dDsgPGJyPg0KPGI+Q2M6PC9iPiAmcXVvdDtvYXV0aEBpZXRmLm9yZyBXRyZxdW90OyAmbHQ7b2F1
dGhAaWV0Zi5vcmcmZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBGZWJydWFyeSA1LCAy
MDEzIDI6MjcgUE08YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtPQVVUSC1XR10gV2h5IE9BdXRo
IGl0IHNlbGYgaXMgbm90IGFuIGF1dGhlbnRpY2F0aW9uIGZyYW1ld29yayA/PC9zcGFuPjxzcGFu
IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNv
bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IGlkPSJ5aXYyMTQx
MTQ0NzEwIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpv
bGl2ZSI+SSB0aGluayB0aGlzIGlzIGJlY29taW5nIGEgbGFyZ2VseSBhY2FkZW1pYyAvIHBoaWxv
c29waGljYWwgYXJndW1lbnQgYnkgdGhpcyB0aW1lLiZuYnNwOyBUaGUgcGVvcGxlIHdobyBkZXNp
Z25lZCBPQXV0aCB3aWxsIGxpa2VseSBwb2ludCBvdXQgdGhhdCBpdCB3YXMgY29uY2VwdHVhbGl6
ZWQgYXMgYW4NCiBhdXRob3JpemF0aW9uIHByb3RvY29sIHRvIGVuYWJsZSBhIFJPIHRvIGRlbGVn
YXRlIGFjY2VzcyB0byBhIGNsaWVudCB0byBhY2Nlc3MgaXRzIHByb3RlY3RlZCByZXNvdXJjZXMg
b24gc29tZSBSUy4mbmJzcDsgQW5kIG9mIGNvdXJzZSB0aGlzIGlzIHRoZSBoaXN0b3J5IG9mIGl0
LiZuYnNwOyBBbmQgdGhlIFJPIGFuZCBlbmQtdXNlciB3ZXJlIHR5cGljYWxseSB0aGUgc2FtZSBl
bnRpdHkuJm5ic3A7IEJ1dCBnZXQgY2F1Z2h0IHVwIGluIHdoYXQgaXQgd2FzIGVudmlzaW9uZWQN
CiB0byBkbyB2cy4gcmVhbCBsaWZlIHVzZSBjYXNlcyB0aGF0IE9BdXRoIGNhbiBzb2x2ZSAoYW5k
IGlzIHNvbHZpbmcpIGJleW9uZCBpdHMgaW5pdGlhbCB1c2UgY2FzZXMgbWlzc2VzIHRoZSBwb2lu
dCDigKYgYmVjYXVzZSBPQXV0aCBpcyBnYWluaW5nIHRyYWN0aW9uIGluIHRoZSBlbnRlcnByaXNl
IGFuZCB3aWxsIGJlIHVzZWQgaW4gYWxsIGRpZmZlcmVudCBzb3J0cyBvZiB3YXlzLCBpbmNsdWRp
bmcgYXV0aGVudGljYXRpb24uJm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr
Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41
cHQ7Y29sb3I6b2xpdmUiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtj
b2xvcjpvbGl2ZSI+VGhpcyBpcyBlc3BlY2lhbGx5IHRydWUgb2YgUkVTVGZ1bCBBUElzIHdpdGhp
biBhbiBlbnRlcnByaXNlIHdoZXJlIHRoZSBSTyBhbmQgZW5kLXVzZXIgYXJlICo8Yj5ub3Q8L2I+
KiB0aGUgc2FtZTogZS5nLiBSTz1lbnRlcnByaXNlIGFuZCBlbmQtdXNlcj1lbXBsb3llZS4mbmJz
cDsgSW4gdGhpcyBtb2RlbA0KIHRoZSBlbmQtdXNlciBpcyBub3QgYXV0aG9yaXppbmcgYW55dGhp
bmcgd2hlbiB0aGVpciBjbGllbnQgcmVxdWVzdHMgYSB0b2tlbiBmcm9tIHRoZSBBUyDigKYgdGhl
eSBhdXRoZW50aWNhdGUgdG8gdGhlIEFTIGFuZCB0aGUgY2xpZW50IGdldHMgYW4gQVQsIHdoaWNo
IHdpbGwgbGlrZWx5IGJlIHByb2ZpbGVkIGJ5IG1vc3QgZW50ZXJwcmlzZSBkZXBsb3ltZW50cyB0
byBsb29rIHNvbWV0aGluZyBsaWtlIGFuIE9JREMgaWRfdG9rZW4uJm5ic3A7IFRoZSBBVCB3aWxs
DQogYmUgcHJlc2VudGVkIHRvIHRoZSBSUyB3aGljaCB3aWxsIGV4YW1pbmUgdGhlIGNsYWltcyAo
dXNlciBpZGVudGl0eSwgTE9BLCBldGMuKSBhbmQgbWFrZSBhdXRob3JpemF0aW9uIGRlY2lzaW9u
cyBiYXNlZCBvbiBidXNpbmVzcyBsb2dpYy4mbmJzcDsgVGhlIEFUIGhhcyBub3QgYXV0aG9yaXpl
ZCB0aGUgdXNlciB0byBkbyBhbnl0aGluZywgaXQgaGFzIG9ubHkgbWFkZSBhbiBhc3NlcnRpb24g
dGhhdCB0aGUgdXNlciBoYXMgYmVlbiBhdXRoZW50aWNhdGVkDQogYnkgdGhlIEFTIChzb3J0IG9m
IHNvdW5kcyBhIGxvdCBsaWtlIGFuIElkUCBub3cpLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6
YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjVwdDtjb2xvcjpvbGl2ZSI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj
ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
NXB0O2NvbG9yOm9saXZlIj5BbGwgdGhpcyB0YWxrZWQgb2YgT0F1dGggYmVpbmcgYXV0aG9yaXph
dGlvbiBhbmQgbm90IGF1dGhlbnRpY2F0aW9uIHdhcyBleHRyZW1lbHkgY29uZnVzaW5nIHRvIG1l
IHdoZW4gSSBmaXJzdCBzdGFydGVkIGxvb2tpbmcgYXQgT0F1dGggZm9yIG15IHVzZSBjYXNlcywg
YW5kIEkgdGhpbmsgYXQNCiBzb21lIHBvaW50IHRoZSBhdXRob3JzIG9mIE9BdXRoIGFyZSBnb2lu
ZyB0byBoYXZlIHRvIHJlY29nbml6ZSB0aGF0IHRoZWlyIGJhYnkgaGFzIGdyb3duIHVwIHRvIGJl
IG11bHRpLWZhY2V0ZWQgKGFuZCBJIG1lYW4gdGhpcyBhcyBhIGNvbXBsZW1lbnQpLiZuYnNwOyBU
aGUgYWJzdHJhY3Rpb25zIGxlZnQgaW4gdGhlIE9BdXRoIHNwZWMgKHdoaWxlIHNvbWUgaGF2ZSBj
bGFpbWVkIG9mIHRoZSBsYWNrIG9mIGludGVyb3BlcmFiaWxpdHkgaXQgd2lsbCBjYXVzZSkNCiB3
aWxsIGFsc28gZW5hYmxlIGl0IHRvIGJlIHVzZWQgaW4gd2F5cyBwb3NzaWJseSBzdGlsbCBub3Qg
ZW52aXNpb25lZCBieSBhbnkgb2YgdXMuJm5ic3A7IEkgdGhpbmsgYXMgc29vbiBhcyB3ZSBjYW4g
c3RvcCB0cnlpbmcgdG8gZHJhdyB0aGUgYXJ0aWZpY2lhbCBsaW5lIGFyb3VuZCBPQXV0aCBiZWlu
ZyDigJxhbiBhdXRob3JpemF0aW9uIHByb3RvY29s4oCdIHRoZSBiZXR0ZXIgdGhpbmdzIHdpbGwg
YmUuDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu
ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6b2xpdmUiPiZuYnNw
Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo
aXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpvbGl2ZSI+SSBsaWtlIHRv
IHNheSB0aGF0IHRoZXkgYXV0aG9ycyBoYWQgaXQgcmlnaHQgd2hlbiB0aGV5IG5hbWVkIGl0IOKA
nE9BdXRo4oCdIGFuZCBub3Qg4oCcT0F1dGhS4oCdDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOm9saXZlIj5KPC9zcGFuPjxz
cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOm9saXZlIj4mbmJzcDs8L3NwYW4+PHNwYW4g
c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6b2xpdmUiPi1hZGFtPC9zcGFuPjxzcGFuIHN0eWxl
PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuNXB0O2NvbG9yOm9saXZlIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNv
bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJv
cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp
biAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu
ZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPkZy
b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+
IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXQ0K
PGI+T24gQmVoYWxmIE9mIDwvYj5UaW0gQnJheTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBG
ZWJydWFyeSAwNSwgMjAxMyAzOjI4IFBNPGJyPg0KPGI+VG86PC9iPiBXaWxsaWFtIE1pbGxzPGJy
Pg0KPGI+Q2M6PC9iPiBvYXV0aEBpZXRmLm9yZyBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog
W09BVVRILVdHXSBXaHkgT0F1dGggaXQgc2VsZiBpcyBub3QgYW4gYXV0aGVudGljYXRpb24gZnJh
bWV3b3JrID88L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w
cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu
IHN0eWxlPSJjb2xvcjpibGFjayI+T0lEQyBzZWVtcyBhYm91dCB0aGUgbW9zdCBwbGF1c2libGUg
Y2FuZGlkYXRlIGZvciBhIOKAnGdvb2QgZ2VuZXJhbCBzb2x1dGlvbuKAnSB0aGF0IEnigJltIGF3
YXJlIG9mLiAmbmJzcDsgLVQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu
IHN0eWxlPSJjb2xvcjpibGFjayI+T24gVHVlLCBGZWIgNSwgMjAxMyBhdCAxOjIyIFBNLCBXaWxs
aWFtIE1pbGxzICZsdDs8YSBocmVmPSJtYWlsdG86d21pbGxzXzkyMTA1QHlhaG9vLmNvbSIgdGFy
Z2V0PSJfYmxhbmsiPndtaWxsc185MjEwNUB5YWhvby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNv
bG9yOmJsYWNrIj5UaGVyZSBhcmUgc29tZSBzcGVjaWZpYyBkZXNpZ24gbWlzLW1hdGNoZXMgZm9y
IE9BdXRoIGFzIGFuIGF1dGhlbnRpY2F0aW9uIHByb3RvY29sLCBpdCdzIG5vdCB3aGF0IGl0J3Mg
ZGVzaWduZWQgZm9yIGFuZCB0aGVyZSBhcmUgc29tZSBwcm9ibGVtcyB5b3Ugd2lsbCBydW4gaW50
by4gJm5ic3A7U29tZSBoYXZlIHVzZWQgaXQgYXMNCiBzdWNoLCBidXQgaXQncyBub3QgYSBnb29k
IGdlbmVyYWwgc29sdXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp
dGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+LWJpbGw8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9y
OmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBz
dHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0i
Y29sb3I6YmxhY2siPg0KPGhyIHNpemU9IjEiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4N
Cjwvc3Bhbj48L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy
b3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+
PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4gUGF1bCBNYWRzZW4gJmx0OzxhIGhyZWY9Im1haWx0
bzpwYXVsLm1hZHNlbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5wYXVsLm1hZHNlbkBnbWFp
bC5jb208L2E+Jmd0Ozxicj4NCjxiPlRvOjwvYj4gSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJt
YWlsdG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0iX2JsYW5rIj52ZTdqdGJAdmU3anRiLmNv
bTwvYT4mZ3Q7DQo8YnI+DQo8Yj5DYzo8L2I+ICZxdW90OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBp
ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPiBXRyZxdW90OyAmbHQ7
PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0
Zi5vcmc8L2E+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEZlYnJ1YXJ5IDUsIDIw
MTMgMToxMiBQTTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBXaHkgT0F1dGgg
aXQgc2VsZiBpcyBub3QgYW4gYXV0aGVudGljYXRpb24gZnJhbWV3b3JrID88bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBz
dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+d2h5IHBpZ2Vvbmhv
bGUgaXQ/DQo8YnI+DQo8YnI+DQpPQXV0aCBjYW4gYmUgZGVwbG95ZWQgd2l0aCBubyBhdXRoeiBz
ZW1hbnRpY3MgYXQgYWxsIChvciBhdCBsZWFzdCBhcyBsaXR0bGUgYXMgYW55IGF1dGhuIG1lY2hh
bmlzbSksIGUuZyBjbGllbnQgY3JlZHMgZ3JhbnQgdHlwZSB3aXRoIG5vIHNjb3Blczxicj4NCjxi
cj4NCkkgYWdyZWUgdGhhdCBPQXV0aCBpcyBub3QgYW4gKlNTTyogcHJvdG9jb2wuPG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk9uIDIv
NS8xMyAzOjM2IFBNLCBKb2huIEJyYWRsZXkgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w
cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk9B
dXRoIGlzIGFuIEF1dGhvcml6YXRpb24gcHJvdG9jb2wgYXMgbWFueSBvZiB1cyBoYXZlIHBvaW50
ZWQgb3V0Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i
Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo
aXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSBwb3N0IGlzIGxhcmdlbHkgY29ycmVj
dCBhbmQgYmFzZWQgb24gb25lIG9mIG1pbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn
cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+
Sm9obiBCLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi
PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+T24gMjAx
My0wMi0wNSwgYXQgMTI6NTIgUE0sIFByYWJhdGggU2lyaXdhcmRlbmEgJmx0OzxhIGhyZWY9Im1h
aWx0bzpwcmFiYXRoQHdzbzIuY29tIiB0YXJnZXQ9Il9ibGFuayI+cHJhYmF0aEB3c28yLmNvbTwv
YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0
eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206
NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy
b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5GWUkgYW5kIGZvciB5b3VyIGNv
bW1lbnRzLi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9
ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5odHRwOi8vYmxv
Zy5mYWNpbGVsb2dpbi5jb20vMjAxMy8wMi93aHktb2F1dGgtaXQtc2VsZi1pcy1ub3QtYXV0aGVu
dGljYXRpb24uaHRtbDxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu
ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoYW5rcyAmYW1w
OyBSZWdhcmRzLDxicj4NClByYWJhdGggPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl
Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu
LWJvdHRvbToxMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6
d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+TW9iaWxlIDogPC9zcGFuPg0KPHNwYW4g
Y2xhc3M9Ik1zb0h5cGVybGluayI+JiM0Mzs5NCA3MSA4MDkgNjczMjwvc3Bhbj48c3BhbiBzdHls
ZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi
PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+aHR0cDovL2Jsb2cuZmFjaWxlbG9naW4uY29tLzxi
cj4NCmh0dHA6Ly9yYW1wYXJ0ZmFxLmNvbS88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBs
aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+
T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu
YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBz
dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48
c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNr
Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk9BdXRoIG1haWxpbmcgbGlz
dDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+
PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmci
IHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj
ayI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIg
dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1
dGg8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g
c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tn
cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0KX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxp
c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5P
QXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn
aW4tYm90dG9tOjEyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu
ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+DQpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxi
cj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRo
QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi
PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNv
bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_59E470B10C4630419ED717AC79FCF9A9483E7E50BY2PRD0411MB441_--

From ve7jtb@ve7jtb.com  Wed Feb  6 08:21:59 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3222721F879E for ; Wed,  6 Feb 2013 08:21:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.148
X-Spam-Level: 
X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_210=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3YAc0VuIITB for ; Wed,  6 Feb 2013 08:21:56 -0800 (PST)
Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) by ietfa.amsl.com (Postfix) with ESMTP id 616F921F8715 for ; Wed,  6 Feb 2013 08:21:55 -0800 (PST)
Received: by mail-ob0-f169.google.com with SMTP id ta14so1648605obb.0 for ; Wed, 06 Feb 2013 08:21:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=3dYtosZyuZo8zqG+Hb3vZz1Hy89DoR6tFd86sUT0FzQ=; b=bg2yGxoIU3lX8MSR+FyUWjNx5AC0uqkaiLrYj44lYqS1DFQfI5MW+ecBLWgVUTTIxr rRCyq3x7INy2MZ44/YYl3kL9/S+0IGjZs6U3UO7yNS/vwaM4FHjSk5CJ8OjMio7oCHZv apVI9hdPWLmDDSEXOo6L45lqUXDFQia0TO5GZCu52kBEcVbD3m2JJkhRlp+oDrg152Hl p5LLMln6cor1ZMaCn8P348cCwdsWTVAnaQez6EFFnCJ3jp1prS+FSTGTOE5d7QlKCepa Z+MTdYC2lvWg60uxmvCD7Ph8wweNPlVq1Q//ddzCMyyO9pH32zW0p21BydqjtQfWehk5 aeqQ==
X-Received: by 10.60.32.84 with SMTP id g20mr4622536oei.42.1360167714779; Wed, 06 Feb 2013 08:21:54 -0800 (PST)
Received: from [10.37.15.80] ([96.8.44.21]) by mx.google.com with ESMTPS id dl6sm29747856obb.5.2013.02.06.08.21.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Feb 2013 08:21:53 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_2029DE69-EFBF-41E5-A6CB-1B623885D36E"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <59E470B10C4630419ED717AC79FCF9A9483E7E50@BY2PRD0411MB441.namprd04.prod.outlook.com>
Date: Wed, 6 Feb 2013 09:21:48 -0700
Message-Id: 
References:  <73B7EC23-AA93-42EE-B3EB-35BA1B82558F@ve7jtb.com> <511175AA.9030301@gmail.com> <1360099372.47338.YahooMailNeo@web31807.mail.mud.yahoo.com>  <59E470B10C4630419ED717AC79FCF9A9483E7B3D@BY2PRD0411MB441.namprd04.prod.outlook.com> <1360111712.54487.YahooMailNeo@web31812.mail.mud.yahoo.com> <59E470B10C4630419ED717AC79FCF9A9483E7E50@BY2PRD0411MB441.namprd04.prod.outlook.com>
To: Lewis Adam-CAL022 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQm92hoKcp5/dVg+LRxKVi4XS6Ztl+s1x6xbbu4c9Sphzr+O+8lkMqT2Y1P3r2JiUWBmz2J6
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Why OAuth it self is not an authentication framework ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Feb 2013 16:21:59 -0000

--Apple-Mail=_2029DE69-EFBF-41E5-A6CB-1B623885D36E
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_03D00D03-26D7-4694-A2F6-AE4E72199A00"

--Apple-Mail=_03D00D03-26D7-4694-A2F6-AE4E72199A00
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Adam,

We have made some changes in the latest draft to address some input from =
Google that I think may also address your need to using the id_token in =
an assertion or possibly as an access token to a federated RS.

I can go over it with you if you like.

John B.

On 2013-02-06, at 9:05 AM, Lewis Adam-CAL022 =
 wrote:

> Hi Bill,
> =20
> My reason for using OAuth rather than OIDC is because the id_token in =
OIDC is audience restricted to the client.  This was clearly intended =
for WebSSO / authentication to a client running on a web server.  It =
does not help the case where the user of a RESTful native client want to =
authenticate to a RESTful web service.=20
> =20
> I agree that OAuth lacks a =93defined=94 way to communicate what is in =
the AT (as OAuth does not define the content of the AT), but within an =
enterprise domain this is easy to solve by profiling.  And in any =
implementation of OAuth on the Internet, the AT must at some level =
identify the user to the RS.  Otherwise how else would the RS know who=92s=
 protected resources the client is trying to access?  Now whether the RS =
learns that through introspection or by parsing a JWT-structured AT is =
of course not defined.  But at the end of the day, the AT definitely (in =
all cases that I can think of) identifies the user.=20
> =20
> I am open minded to using OIDC if in the future if the client can =
request an id_token that is audience restricted to the RS it is going to =
communicate.  In other words, yes I agree that OIDC is the preferred =
mechanism for performing =93user authentication to a client,=94 but I =
also argue that OAuth is the best method to perform =93user =
authentication to an RS=94 (if you want to get your RS out of the =
password consumption business).  I am not at all advocating OAuth for =
authentication to a client.=20
> =20
> -adam
> =20
> From: William Mills [mailto:wmills_92105@yahoo.com]=20
> Sent: Tuesday, February 05, 2013 6:49 PM
> To: Lewis Adam-CAL022; Tim Bray
> Cc: "WG "@il06exr02.mot.com
> Subject: Re: [OAUTH-WG] Why OAuth it self is not an authentication =
framework ?
> =20
> Why use OAuth when OpenID does everything that OAuth can do as an =
authentication method and does a few things much better?
> =20
> Specifically OAuth lacks any defined way to:
> =20
> -    feed back any additional information like the real user ID (as =
opposed to what the entered)
> -    bound an authentication event in time
> -    provide any form of additional SSO payload like a display name =
for the user
> =20
> there's probably other things.
> =20
> It'll mostly work but there are things it doesn't do.  Could you solve =
some of the rest of this with token introspection or a user API that the =
RP could use to fetch user info, sure, but why rebuild OpenID when =
OpenID exists?
> =20
> -bill
> =20
> =20
> From: Lewis Adam-CAL022 
> To: Tim Bray ; William Mills =
=20
> Cc: "oauth@ietf.org WG" =20
> Sent: Tuesday, February 5, 2013 2:27 PM
> Subject: RE: [OAUTH-WG] Why OAuth it self is not an authentication =
framework ?
> =20
> I think this is becoming a largely academic / philosophical argument =
by this time.  The people who designed OAuth will likely point out that =
it was conceptualized as an authorization protocol to enable a RO to =
delegate access to a client to access its protected resources on some =
RS.  And of course this is the history of it.  And the RO and end-user =
were typically the same entity.  But get caught up in what it was =
envisioned to do vs. real life use cases that OAuth can solve (and is =
solving) beyond its initial use cases misses the point =85 because OAuth =
is gaining traction in the enterprise and will be used in all different =
sorts of ways, including authentication.=20
> =20
> This is especially true of RESTful APIs within an enterprise where the =
RO and end-user are *not* the same: e.g. RO=3Denterprise and =
end-user=3Demployee.  In this model the end-user is not authorizing =
anything when their client requests a token from the AS =85 they =
authenticate to the AS and the client gets an AT, which will likely be =
profiled by most enterprise deployments to look something like an OIDC =
id_token.  The AT will be presented to the RS which will examine the =
claims (user identity, LOA, etc.) and make authorization decisions based =
on business logic.  The AT has not authorized the user to do anything, =
it has only made an assertion that the user has been authenticated by =
the AS (sort of sounds a lot like an IdP now).
> =20
> All this talked of OAuth being authorization and not authentication =
was extremely confusing to me when I first started looking at OAuth for =
my use cases, and I think at some point the authors of OAuth are going =
to have to recognize that their baby has grown up to be multi-faceted =
(and I mean this as a complement).  The abstractions left in the OAuth =
spec (while some have claimed of the lack of interoperability it will =
cause) will also enable it to be used in ways possibly still not =
envisioned by any of us.  I think as soon as we can stop trying to draw =
the artificial line around OAuth being =93an authorization protocol=94 =
the better things will be.
> =20
> I like to say that they authors had it right when they named it =
=93OAuth=94 and not =93OAuthR=94 J
> =20
> -adam
> =20
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf =
Of Tim Bray
> Sent: Tuesday, February 05, 2013 3:28 PM
> To: William Mills
> Cc: oauth@ietf.org WG
> Subject: Re: [OAUTH-WG] Why OAuth it self is not an authentication =
framework ?
> =20
> OIDC seems about the most plausible candidate for a =93good general =
solution=94 that I=92m aware of.   -T
> On Tue, Feb 5, 2013 at 1:22 PM, William Mills  =
wrote:
> There are some specific design mis-matches for OAuth as an =
authentication protocol, it's not what it's designed for and there are =
some problems you will run into.  Some have used it as such, but it's =
not a good general solution.
> =20
> -bill
> =20
> From: Paul Madsen 
> To: John Bradley =20
> Cc: "oauth@ietf.org WG" =20
> Sent: Tuesday, February 5, 2013 1:12 PM
> Subject: Re: [OAUTH-WG] Why OAuth it self is not an authentication =
framework ?
> =20
> why pigeonhole it?=20
>=20
> OAuth can be deployed with no authz semantics at all (or at least as =
little as any authn mechanism), e.g client creds grant type with no =
scopes
>=20
> I agree that OAuth is not an *SSO* protocol.
> On 2/5/13 3:36 PM, John Bradley wrote:
> OAuth is an Authorization protocol as many of us have pointed out.
> =20
> The post is largely correct and based on one of mine.
> =20
> John B.
> =20
> On 2013-02-05, at 12:52 PM, Prabath Siriwardena  =
wrote:
> =20
> FYI and for your comments..
> =20
> =
http://blog.facilelogin.com/2013/02/why-oauth-it-self-is-not-authenticatio=
n.html
> =20
> Thanks & Regards,
> Prabath
> =20
> Mobile : +94 71 809 6732=20
> http://blog.facilelogin.com/
> http://rampartfaq.com/
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> =20
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> =20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> =20
> =20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail=_03D00D03-26D7-4694-A2F6-AE4E72199A00
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Adam,
We =
have made some changes in the latest draft to address some input from =
Google that I think may also address your need to using the id_token in =
an assertion or possibly as an access token to a federated =
RS.

I can go over it with you if you =
like.

John B.
On =
2013-02-06, at 9:05 AM, Lewis Adam-CAL022 <Adam.Lewis@motorolasoluti=
ons.com> wrote:

Hi =
Bill,

My reason for using OAuth rather than OIDC is because the =
id_token in OIDC is audience restricted to the client.  This was =
clearly intended for WebSSO / authentication to a client running on a =
web server.  It does not help the case where the user of a RESTful =
native client want to authenticate to a RESTful web =
service. 

I agree that OAuth lacks a =93defined=94 way to =
communicate what is in the AT (as OAuth does not define the content of =
the AT), but within an enterprise domain this is easy to solve by =
profiling.  And in any implementation of OAuth on the Internet, the =
AT must at some level identify the user to the RS.  Otherwise how =
else would the RS know who=92s protected resources the client is trying =
to access?  Now whether the RS learns that through introspection or =
by parsing a JWT-structured AT is of course not defined.  But at =
the end of the day, the AT definitely (in all cases that I can think of) =
identifies the user. 

I am open minded to using OIDC if in the future if the =
client can request an id_token that is audience restricted to the RS it =
is going to communicate.  In other words, yes I agree that OIDC is =
the preferred mechanism for performing =93user authentication to a =
client,=94 but I also argue that OAuth is the best method to perform =
=93user authentication to an RS=94 (if you want to get your RS out of =
the password consumption business).  I am not at all advocating =
OAuth for authentication to a client. 

-adam

From: William Mills =
[mailto:wmills_92105@yahoo.com] 
Sent: Tuesday, February 05, 2013 =
6:49 PM
To: Lewis Adam-CAL022; Tim =
Bray
Cc: "WG =
<oauth@ietf.org>"@il06exr02.mot.com
Subject:=
 Re: [OAUTH-WG] Why =
OAuth it self is not an authentication framework =
?
Why use OAuth when OpenID does everything that OAuth can do as =
an authentication method and does a few things much =
better?

Specifically OAuth =
lacks any defined way to:
-    feed back any =
additional information like the real user ID (as opposed to what the =
entered)
-    bound an =
authentication event in time
    provide any form of =
additional SSO payload like a display name for the =
user
there's probably other =
things.
It'll mostly work but =
there are things it doesn't do.  Could you solve some of the rest =
of this with token introspection or a user API that the RP could use to =
fetch user info, sure, but why rebuild OpenID when OpenID =
exists?
From: Lewis Adam-CAL022 <Adam.Lewis@motorolasoluti=
ons.com>
To: Tim Bray <twbray@google.com>; William =
Mills <wmills_92105@yahoo.com> 
Cc: "oauth@ietf.org WG" <oauth@ietf.org> 
Sent: Tuesday, February 5, 2013 =
2:27 PM
Subject: RE: [OAUTH-WG] Why OAuth it =
self is not an authentication framework ?

I think this is becoming a largely academic / philosophical =
argument by this time.  The people who designed OAuth will likely =
point out that it was conceptualized as an authorization protocol to =
enable a RO to delegate access to a client to access its protected =
resources on some RS.  And of course this is the history of =
it.  And the RO and end-user were typically the same entity.  =
But get caught up in what it was envisioned to do vs. real life use =
cases that OAuth can solve (and is solving) beyond its initial use cases =
misses the point =85 because OAuth is gaining traction in the enterprise =
and will be used in all different sorts of ways, including =
authentication. 

This is especially true of RESTful APIs within an enterprise =
where the RO and end-user are *not* the same: e.g. RO=3Denterprise =
and end-user=3Demployee.  In this model the end-user is not =
authorizing anything when their client requests a token from the AS =85 =
they authenticate to the AS and the client gets an AT, which will likely =
be profiled by most enterprise deployments to look something like an =
OIDC id_token.  The AT will be presented to the RS which will =
examine the claims (user identity, LOA, etc.) and make authorization =
decisions based on business logic.  The AT has not authorized the =
user to do anything, it has only made an assertion that the user has =
been authenticated by the AS (sort of sounds a lot like an IdP =
now).

All this talked of OAuth being authorization and not =
authentication was extremely confusing to me when I first started =
looking at OAuth for my use cases, and I think at some point the authors =
of OAuth are going to have to recognize that their baby has grown up to =
be multi-faceted (and I mean this as a complement).  The =
abstractions left in the OAuth spec (while some have claimed of the lack =
of interoperability it will cause) will also enable it to be used in =
ways possibly still not envisioned by any of us.  I think as soon =
as we can stop trying to draw the artificial line around OAuth being =93an=
 authorization protocol=94 the better things will be.

I like to say that they authors had it right when they named it =
=93OAuth=94 and not =93OAuthR=94 

-adam

From: oauth-bounces@ietf.org =
[mailto:oauth-bounces@ietf.org] On Behalf Of Tim =
Bray
Sent: Tuesday, February 05, 2013 =
3:28 PM
To: William =
Mills
Cc: oauth@ietf.org =
WG
Subject: Re: [OAUTH-WG] Why OAuth it =
self is not an authentication framework ?

OIDC seems about the most =
plausible candidate for a =93good general solution=94 that I=92m aware =
of.   -T
On Tue, Feb 5, 2013 =
at 1:22 PM, William Mills <There are some specific =
design mis-matches for OAuth as an authentication protocol, it's not =
what it's designed for and there are some problems you will run into. =
 Some have used it as such, but it's not a good general =
solution.

-bill

From: Paul Madsen < John Bradley <ve7jtb@ve7jtb.com> 
Cc: "oauth@ietf.org WG" <oauth@ietf.org> 
Sent: Tuesday, February 5, 2013 =
1:12 PM
Subject: Re: [OAUTH-WG] Why OAuth it =
self is not an authentication framework =
?

why pigeonhole it? 

OAuth can be =
deployed with no authz semantics at all (or at least as little as any =
authn mechanism), e.g client creds grant type with no scopes

I =
agree that OAuth is not an *SSO* =
protocol.
On 2/5/13 3:36 PM, John =
Bradley wrote:
OAuth is =
an Authorization protocol as many of us have pointed =
out.

The post is largely =
correct and based on one of mine.

John =
B.

On =
2013-02-05, at 12:52 PM, Prabath Siriwardena <prabath@wso2.com> =
wrote:

FYI and =
for your comments..

http://blog.facilelogin.com/2013/02/why-oauth-it-self-is-n=
ot-authentication.html

Thanks & =
Regards,
Prabath

Mobile :  
http://blog.facilelogin.com/
=
http://rampartfaq.com/
_______________________________________________
OAuth =
mailing list

_______________________________________________
OAuth mailing =
list

_______________________________________________
OAuth =
mailing list

_______________________________________________
OAuth =
mailing list

____________________________=
___________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/=
mailman/listinfo/oauth

=

--Apple-Mail=_03D00D03-26D7-4694-A2F6-AE4E72199A00--

--Apple-Mail=_2029DE69-EFBF-41E5-A6CB-1B623885D36E
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMjA2MTYyMTQ5WjAjBgkqhkiG9w0BCQQxFgQUctYTYTFO
6N1goRKixuxrN8ne2Q8wgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAQtj0dZ45SBCgCKckoAjr1feXsKGzzwUPp3QSTebE
9f/9JelXmuPQD/HvHFXs8CW6rlyVYHP0bGV2nEuDJeNewXcP/QmEsSX7lvixlAdmTk4uRGSTjWw+
wfeGMT2ma8qiqzv/iBCE8Zc043nstR5v8XWCSesYI4tXK4VplxeDXmU3K/+AQZnE0VT092+h0Sj6
WHPDqpnUMMo+BkmZLEpwgl98Wza4TgU7lz7WvxG228zLw6CuHzVTs19aiIMLcJPgqoe6/bBJx2NP
sJcUXypRZPSNjJzUqKbNO6LxlL4wflHmQjeOFMFkIod9BESiRXVYBcQCvQWPKel1Uq6EYLn9fwAA
AAAAAA==

--Apple-Mail=_2029DE69-EFBF-41E5-A6CB-1B623885D36E--

From prabath@wso2.com  Wed Feb  6 08:23:07 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB4D21F88CA for ; Wed,  6 Feb 2013 08:23:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.594
X-Spam-Level: 
X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.382,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4GC-JF1sSix for ; Wed,  6 Feb 2013 08:23:06 -0800 (PST)
Received: from mail-ea0-f169.google.com (mail-ea0-f169.google.com [209.85.215.169]) by ietfa.amsl.com (Postfix) with ESMTP id E234421F879E for ; Wed,  6 Feb 2013 08:23:04 -0800 (PST)
Received: by mail-ea0-f169.google.com with SMTP id d13so704620eaa.14 for ; Wed, 06 Feb 2013 08:23:04 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=8efow7MFoc9jZx7Cx2U7WQDtYUPcaNAhbqstTlsAULc=; b=gofaVkQGM1sRW+wDX4xq/Mq6rsqat3wOkGF1dBWspoh56QR9AECCqI5vxDoLn7EEJD v4KKHoKhsgtdNfVyeIZFl2Rg29/X2wB1qA7hS8HXw+q8aIVWyDLrclUosCV+cW7o7H3U VT+KAnjI8iEqB2m6jlJD5cqgrDhhQHJGx+0dXY/aarNvNINef0xsGAAvVhrWdq3GKWGk v6yxupew3Ut3RdTCMjeF1+k6tZuz0U3gmITQ46VQ5mh8cc/DqSvs1GsWtLeTI2jQ6/Xn GQwCa4D4v8G/BwZ3F5kYBQ1M5nOC5jo91EnnPBKC18Qt4T2WUSaCuKuQdmREIwcU+cOm Zr+g==
MIME-Version: 1.0
X-Received: by 10.14.203.3 with SMTP id e3mr98776253eeo.9.1360167783684; Wed, 06 Feb 2013 08:23:03 -0800 (PST)
Received: by 10.223.175.134 with HTTP; Wed, 6 Feb 2013 08:23:03 -0800 (PST)
In-Reply-To: <1359995273.56871.YahooMailNeo@web31809.mail.mud.yahoo.com>
References:  <1359995273.56871.YahooMailNeo@web31809.mail.mud.yahoo.com>
Date: Wed, 6 Feb 2013 21:53:03 +0530
Message-ID: 
From: Prabath Siriwardena 
To: William Mills 
Content-Type: multipart/alternative; boundary=047d7b343b2a94d91704d510bd21
X-Gm-Message-State: ALoCoQlzVCzfnHkkQ9/z61AMkYLvP6k/UstZZoaMR3YAR0e4aKlfYsm4sfAo6ZQ+H1LNuvfWJ0tz
Cc: "oauth@ietf.org" , "L. Preston Sego III" 
Subject: Re: [OAUTH-WG] I'm concerned about how the sniffability of oauth2 requests
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Feb 2013 16:23:08 -0000

--047d7b343b2a94d91704d510bd21
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Feb 4, 2013 at 9:57 PM, William Mills wrote:

> There are two efforts at signed token types: MAC which is still a
> possibility if we wake up and do it, and the "Holder Of Key" type tokens.
>

If someone can use sslstrip then even MAC is not safe - since MAC key needs
to be transferred over SSL to the Client from the AS.

There are standard ways in HTTP to avoid or protect from sslstrip - IMHO we
need to occupy those best practices...

Thanks & regards,
-Prabath

>
> There are a lot of folks that agree with you.
>
>   ------------------------------
> *From:* L. Preston Sego III 
> *To:* oauth@ietf.org
> *Sent:* Friday, February 1, 2013 7:37 AM
> *Subject:* [OAUTH-WG] I'm concerned about how the sniffability of oauth2
> requests
>
> In an oauth2 request, the access token is passed along in the header, with
> nothing else.
>
> As I understand it, oauth2 was designed to be simple for everyone to use.
> And while, that's true, I don't really like how all of the security is
> reliant on SSL.
>
> what if an attack can strip away SSL using a tool such as sslstrip (or
> whatever else would be more suitable for modern https)? They would be able
> to see the access token and start forging whatever request he or she wants
> to.
>
> Why not do some sort of RSA-type public-private key thing like back in
> Oauth1, where there is verification of the payload on each request? Just
> use a better algorithm?
>
> _______________________________________________
> 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
>
>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.com

--047d7b343b2a94d91704d510bd21
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 4, 2013 at 9:57 PM, William =
Mills <wmills_92105@yahoo.com> wrote:

There are two efforts at signed token types:=
 MAC which is still a possibility if we wake up and do it, and the "Ho=
lder Of Key" type tokens.

If someone can use sslstrip th=
en even MAC is not safe - since MAC key needs to be transferred over SSL to=
 the Client from the AS.

There are standard ways i=
n HTTP to avoid or protect from sslstrip - IMHO we need to occupy those bes=
t practices...

Thanks & regards,
-Prabath
=A0<=
/div>

There are a lot of folks that agree with you.

  From: L. Preston Sego III <LPSego3@gmail.com>
 To: oauth@ietf.org 

 Sent: Friday, February 1, 2=
013 7:37 AM
 Subject: [OA=
UTH-WG] I'm concerned about how the sniffability of oauth2 requests

In an oauth2 request, the access token is passed alon=
g in the header, with nothing else.
As I understand it, =
oauth2 was designed to be simple for everyone to use. And while, that's=
 true, I don't really like how all of the security is reliant on SSL.

what if an attack can strip away SSL using a tool such =
as sslstrip (or whatever else would be more suitable for modern https)? The=
y would be able to see the access token and start forging whatever request =
he or she wants to.

Why not do some sort of RSA-type public-private key thi=
ng like back in Oauth1, where there is verification of the payload on each =
request? Just use a better algorithm?

_______________________________________________
OA=
uth mailing list
OAu=
th@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___________________________________=
____________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

-- 
Thanks &=
amp; Regards,
Prabath
Mobile : +94 71 809 6732=A0
=

http://blog.f=
acilelogin.com

http://RampartFAQ.com

--047d7b343b2a94d91704d510bd21--

From wmills_92105@yahoo.com  Wed Feb  6 09:56:25 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF28E21F8630 for ; Wed,  6 Feb 2013 09:56:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.143
X-Spam-Level: 
X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=0.455,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5ciK5jDZc5S for ; Wed,  6 Feb 2013 09:56:20 -0800 (PST)
Received: from nm6-vm2.bullet.mail.ne1.yahoo.com (nm6-vm2.bullet.mail.ne1.yahoo.com [98.138.90.154]) by ietfa.amsl.com (Postfix) with ESMTP id B2F5221F85E2 for ; Wed,  6 Feb 2013 09:56:13 -0800 (PST)
Received: from [98.138.90.49] by nm6.bullet.mail.ne1.yahoo.com with NNFMP; 06 Feb 2013 17:56:11 -0000
Received: from [98.138.226.164] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 06 Feb 2013 17:56:11 -0000
Received: from [127.0.0.1] by omp1065.mail.ne1.yahoo.com with NNFMP; 06 Feb 2013 17:56:11 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 38595.93204.bm@omp1065.mail.ne1.yahoo.com
Received: (qmail 63399 invoked by uid 60001); 6 Feb 2013 17:56:10 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360173370; bh=uA7P+9Gc+N0pLxgSJQpOnyIhRPZKSTFuCGfoAmi7vJY=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=XccjutE915Xs8mOoDEzvFzusgoOWrRm0meDx6jVNALm2g0v++gnfL49CxgAL8L2nCfVWkJAfF9fZh/N2PK3kMGxpeHujajpYdf+GBs8V/GW1r2WbAsjB/QYldfNCGQYkx0SfXR1Cg1L5VQQQ8UsuiVzlJsluag/Ymg1I+sutz8E=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=GfmODnykze7LnGuTGwhfgqbSycY3GXW5ZO6uvgBcMD70Nmfm9/ZZRRZoAUU5jOR6Io26pDi4qrxavnLHMooLKtIUOh45LSTSF5sUhHhC/jHq/LK3Lfg3mHt+99yraoJsaKSgw7sU4WwQANYDL3sfzAnyXHD2GJapwhfUuVK3qC4=;
X-YMail-OSG: 0tliOfEVM1nulP0_R2LmqoVG1jKCO2jbBmL_gZTpdJH9D9m kgmN4HWVPnkTBpghj01mdYEEQJ5oy3A1qC_7QlbXJoVRKCL72a1UcnKwEapY Um5SFtbGi_sykuxEbxd5P1jtf_4l8MG9n_mzBJHhe9F.y1R6SnntR9s03RtC LGtHZ7TCccw5Ecuck7fYzBL5AsJMNiqvM8EPy4Tmjgqk16XCQggA7r0c2OsM oAUDL6JFNWHJnAHOBwMN8k8XcttVjuo_5AGbeO2hqyOASmu2IBu2TpzYSOfI GOGK2qf2Tu1kokaKk8O8rO4MaRqX3aHp6FfU0O0JgHfBlFxRF_O5IcfJeBrP SX6lnemRMVy5m5opclrXhnjp.0AQbvyomJ2Hk9zlidSSBTdX34patJC2d.uA 9B17fLwpVLBqrj4lbrWhKEzbbiOcD1H9DCZXM.boxY1vHXv1Ime_zbZ7ch4V Em9nn0XoELYMNiGrkLlzoVP3i0KVvrqUiiclmAkt98NDqoMwk8hmh8RaIzXf 44Vib_LEpaLHXCLE8SUlpwxGUCoXbIAcvQvZnLQ3H_.8v6MoIT3fbt8LcUvg VOk1BKNnA3BgNMPxDysNdiLDgFw88MZOaRN6Xp20wvaxhjiofP7VKoRN7ghA CD0PpKdVwqw4nHMKe7jbxyVrsvVA7zKPGoYRmRDO9Rlk-
Received: from [209.131.62.145] by web31810.mail.mud.yahoo.com via HTTP; Wed, 06 Feb 2013 09:56:09 PST
X-Rocket-MIMEInfo: 001.001, WWVzLCBNQUMgcmVsaWVzIG9uIFNTTCBmb3IgdHJhbnNwb3J0IHNlY3VyaXR5LiDCoEJ1dCB5b3UgaGF2ZSBiaWdnZXIgcHJvYmxlbXMgdGhhbiB0aGF0IGlmIFNTTCBpcyBicm9rZW4sIGJlY2F1c2UgeW91ciBwcmltYXJ5IGF1dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWwgaXMgY29tcHJvbWlzZWQgbm93LgoKRG8gd2UgbmVlZCB0byBhZGRyZXNzIHNzbHN0cmlwIGhlcmUgaWYgaXQncyBhIGdlbmVyYWwgYXR0YWNrIG9uIFNTTCB0cmFuc3BvcnQgZm9yIHRoZSBicm93c2VyPwoKCl9fX19fX19fX19fX19fX19fX18BMAEBAQE-
X-Mailer: YahooMailWebService/0.8.133.504
References:  <1359995273.56871.YahooMailNeo@web31809.mail.mud.yahoo.com> 
Message-ID: <1360173369.63130.YahooMailNeo@web31810.mail.mud.yahoo.com>
Date: Wed, 6 Feb 2013 09:56:09 -0800 (PST)
From: William Mills 
To: Prabath Siriwardena 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="1935884094-1082862167-1360173369=:63130"
Cc: "oauth@ietf.org" , "L. Preston Sego III" 
Subject: Re: [OAUTH-WG] I'm concerned about how the sniffability of oauth2 requests
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Feb 2013 17:56:25 -0000

--1935884094-1082862167-1360173369=:63130
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Yes, MAC relies on SSL for transport security. =A0But you have bigger probl=
ems than that if SSL is broken, because your primary authentication credent=
ial is compromised now.=0A=0ADo we need to address sslstrip here if it's a =
general attack on SSL transport for the browser?=0A=0A=0A__________________=
______________=0A From: Prabath Siriwardena =0ATo: Willia=
m Mills  =0ACc: L. Preston Sego III ; "oauth@ietf.org"  =0ASent: Wednesday, February 6, 201=
3 8:23 AM=0ASubject: Re: [OAUTH-WG] I'm concerned about how the sniffabilit=
y of oauth2 requests=0A =0A=0A=0A=0A=0AOn Mon, Feb 4, 2013 at 9:57 PM, Will=
iam Mills  wrote:=0A=0AThere are two efforts at sig=
ned token types: MAC which is still a possibility if we wake up and do it, =
and the "Holder Of Key" type tokens.=0A=0AIf someone can use sslstrip then =
even MAC is not safe - since MAC key needs to be transferred over SSL to th=
e Client from the AS.=0A=0AThere are standard ways in HTTP to avoid or prot=
ect from sslstrip - IMHO we need to occupy those best practices...=0A=0ATha=
nks & regards,=0A-Prabath=0A=A0=0A=0A>=0A>There are a lot of folks that agr=
ee with you.=0A>=0A>=0A>=0A>________________________________=0A> From: L. P=
reston Sego III =0A>To: oauth@ietf.org =0A>Sent: Friday,=
 February 1, 2013 7:37 AM=0A>Subject: [OAUTH-WG] I'm concerned about how th=
e sniffability of oauth2 requests=0A> =0A>=0A>=0A>In an oauth2 request, the=
 access token is passed along in the header, with nothing else.=0A>=0A>=0A>=
As I understand it, oauth2 was designed to be simple for everyone to use. A=
nd while, that's true, I don't really like how all of the security is relia=
nt on SSL.=0A>=0A>=0A>what if an attack can strip away SSL using a tool suc=
h as sslstrip (or whatever else would be more suitable for modern https)? T=
hey would be able to see the access token and start forging whatever reques=
t he or she wants to.=0A>=0A>=0A>Why not do some sort of RSA-type public-pr=
ivate key thing like back in Oauth1, where there is verification of the pay=
load on each request? Just use a better algorithm?=0A>_____________________=
__________________________=0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https=
://www.ietf.org/mailman/listinfo/oauth=0A>=0A>=0A>=0A>_____________________=
__________________________=0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https=
://www.ietf.org/mailman/listinfo/oauth=0A>=0A>=0A=0A=0A-- =0AThanks & Regar=
ds,=0APrabath=0A=0AMobile : +94 71 809 6732=A0=0A=0Ahttp://blog.facilelogin=
.com=0Ahttp://RampartFAQ.com
--1935884094-1082862167-1360173369=:63130
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Yes, MAC relies on SSL for transport security.  But you have bigger =
problems than that if SSL is broken, because your primary authentication cr=
edential is compromised now.

Do we need to address sslstrip here =
if it's a general attack on SSL transport for the browser?

  From: Prabath Siriwardena <prabath@wso2.com>
 =
To: William Mills <wmil=
ls_92105@yahoo.com> 
Cc:=
 L. Preston Sego III <LPSego3@gmail.com>; "oauth@ietf.org" <oa=
uth@ietf.org> 
 Sent: Wednesday, February 6, 2013 8:23 AM
 Subject: Re: [OAUTH-WG] I'm concerned about how the sniffab=
ility of oauth2 requests

=0A

On Mon, Feb 4, 2013 at 9:57=
 PM, William Mills <wmills_92105@yahoo.com> wrote:
=0ATher=
e are two efforts at signed token types: MAC which is still a possibility i=
f we wake up and do it, and the "Holder Of Key" type tokens.=
=0A

If someone can use sslstrip=
 then even MAC is not safe - since MAC key needs to be transferred over SSL=
 to the Client from the AS.

There are standard way=
s in HTTP to avoid or protect from sslstrip - IMHO we need to occupy those =
best practices...
=0A
Thanks & regards,
-Prabath
 =0A
=0AT=
here are a lot of folks that agree with you.

  <=
div style=3D"font-size:12pt;"> =0A   
  From: L. Preston Sego III <LPSego3@gmail.com>
 To: oauth@ietf.org 
=0A Sent: Friday, February 1, 201=
3 7:37 AM
 Subject: [OAU=
TH-WG] I'm concerned about how the sniffability of oauth2 requests
=0A <=
/font> 

=0AIn an oauth2 request, the access token is passed along in the header, wi=
th nothing else.
As I understand it, oauth2 was designed=
 to be simple for everyone to use. And while, that's true, I don't really l=
ike how all of the security is reliant on SSL.
=0A=0A=0A
what if an attack can strip away SSL using a tool such as sslstrip (o=
r whatever else would be more suitable for modern https)? They would be abl=
e to see the access token and start forging whatever request he or she want=
s to.
=0A=0A=0A
Why not do some sort of RSA-type pu=
blic-private key thing like back in Oauth1, where there is verification of =
the payload on each request? Just use a better algorithm?
=0A
_______________________________________________
OAuth=
 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
=0A

______________________________________________=
_
=0AOAuth mailing list
=0AOAuth@ietf.org=

=0Ahttps://www.ietf.org/mailman/listinfo/oauth<=
br>=0A

-- 
Th=
anks & Regards,
Prabath
Mobile : +94 71 809 6732&=
nbsp;

http://blog.facilelogin.com
=0Ahttp://RampartFAQ.com=
=0A

--1935884094-1082862167-1360173369=:63130--

From prabath@wso2.com  Wed Feb  6 10:00:08 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E5D21F897A for ; Wed,  6 Feb 2013 10:00:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.624
X-Spam-Level: 
X-Spam-Status: No, score=-2.624 tagged_above=-999 required=5 tests=[AWL=0.353,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itGJ3mO8Q6lu for ; Wed,  6 Feb 2013 10:00:07 -0800 (PST)
Received: from mail-ea0-f170.google.com (mail-ea0-f170.google.com [209.85.215.170]) by ietfa.amsl.com (Postfix) with ESMTP id 092AF21F8999 for ; Wed,  6 Feb 2013 10:00:06 -0800 (PST)
Received: by mail-ea0-f170.google.com with SMTP id a11so751151eaa.29 for ; Wed, 06 Feb 2013 10:00:05 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=eD7t1a4+wajK+YEDWqhM4roaw22nDGOiYK7K0NyvGMQ=; b=fca67tW+2zzPo+7rmukg/TtgNRbrkWPRGLvJSJnQmBuamD4wHtg5Jf9vikeg8B2Vyy tTE5fGY7HGaYR08sErlG3VcXq8dExNMieESaFJvQg7EqtEb2VkXf3mCsWX2ikv5LxXT2 IT7iE78czl1IeyQ45nAiHx0s1WWCbbqU13JtkitdnrkT83rRsPE2VcIpwcMoSLfmvGVi xYCZ98VcBYmBV325ls6bzh7bFBstonGVNgwBtca5Afe7afmEroMjCxXib5Rz7KzyAWGJ EZqW0on2eFW3FUu3MNiloei02VQO8PpBSNNuknRstg+BzH4LEpwUl13wGb3Vl+p7R9dY dC1A==
MIME-Version: 1.0
X-Received: by 10.14.173.196 with SMTP id v44mr98741393eel.29.1360173605597; Wed, 06 Feb 2013 10:00:05 -0800 (PST)
Received: by 10.223.175.134 with HTTP; Wed, 6 Feb 2013 10:00:05 -0800 (PST)
In-Reply-To: <1360173369.63130.YahooMailNeo@web31810.mail.mud.yahoo.com>
References:  <1359995273.56871.YahooMailNeo@web31809.mail.mud.yahoo.com>  <1360173369.63130.YahooMailNeo@web31810.mail.mud.yahoo.com>
Date: Wed, 6 Feb 2013 23:30:05 +0530
Message-ID: 
From: Prabath Siriwardena 
To: William Mills 
Content-Type: multipart/alternative; boundary=047d7b60436898324504d5121835
X-Gm-Message-State: ALoCoQnC/27UDv6p7Kp3CnUA5npY9iiiNeEPxGyBJwmiqdAzDE8tdeSr27n4hOFl5sKKnEA6z6bm
Cc: "oauth@ietf.org" , "L. Preston Sego III" 
Subject: Re: [OAUTH-WG] I'm concerned about how the sniffability of oauth2 requests
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Feb 2013 18:00:08 -0000

--047d7b60436898324504d5121835
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Feb 6, 2013 at 11:26 PM, William Mills wrote:

> Yes, MAC relies on SSL for transport security.  But you have bigger
> problems than that if SSL is broken, because your primary authentication
> credential is compromised now.
>

+1

>
> Do we need to address sslstrip here if it's a general attack on SSL
> transport for the browser?
>

Yes.. its a general attack against SSL and counter measures defined too..

Thanks & regards,
-Prabath

>   ------------------------------
> *From:* Prabath Siriwardena 
> *To:* William Mills 
> *Cc:* L. Preston Sego III ; "oauth@ietf.org" <
> oauth@ietf.org>
> *Sent:* Wednesday, February 6, 2013 8:23 AM
> *Subject:* Re: [OAUTH-WG] I'm concerned about how the sniffability of
> oauth2 requests
>
>
>
> On Mon, Feb 4, 2013 at 9:57 PM, William Mills wrote:
>
> There are two efforts at signed token types: MAC which is still a
> possibility if we wake up and do it, and the "Holder Of Key" type tokens.
>
>
> If someone can use sslstrip then even MAC is not safe - since MAC key
> needs to be transferred over SSL to the Client from the AS.
>
> There are standard ways in HTTP to avoid or protect from sslstrip - IMHO
> we need to occupy those best practices...
>
> Thanks & regards,
> -Prabath
>
>
>
> There are a lot of folks that agree with you.
>
>   ------------------------------
> *From:* L. Preston Sego III 
> *To:* oauth@ietf.org
> *Sent:* Friday, February 1, 2013 7:37 AM
> *Subject:* [OAUTH-WG] I'm concerned about how the sniffability of oauth2
> requests
>
> In an oauth2 request, the access token is passed along in the header, with
> nothing else.
>
> As I understand it, oauth2 was designed to be simple for everyone to use.
> And while, that's true, I don't really like how all of the security is
> reliant on SSL.
>
> what if an attack can strip away SSL using a tool such as sslstrip (or
> whatever else would be more suitable for modern https)? They would be able
> to see the access token and start forging whatever request he or she wants
> to.
>
> Why not do some sort of RSA-type public-private key thing like back in
> Oauth1, where there is verification of the payload on each request? Just
> use a better algorithm?
>
> _______________________________________________
> 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
>
>
>
>
> --
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com
>
>
>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.com

--047d7b60436898324504d5121835
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 6, 2013 at 11:26 PM, William=
 Mills <wmills_92105@yahoo.com> wrote:

Yes, MAC relies on SSL for transport securit=
y. =A0But you have bigger problems than that if SSL is broken, because your=
 primary authentication credential is compromised now.

+1
=A0

Do we need to address sslstrip here if it's a general attack on S=
SL transport for the browser?
Yes.. its a general attack against SSL and counter measures def=
ined too..=A0

Thanks & regards,
-Prabath

=

  From: Prabath Siriwardena =
<prabath@wso2.com<=
/a>>
 To: William Mill=
s <wmills_92=
105@yahoo.com> 

Cc: L. Preston Sego III <=
LPSego3@gmail.com>; "oauth@ietf=
.org" <oaut=
h@ietf.org> 

 Sent: Wednesday, February 6=
, 2013 8:23 AM
 Subject: =
Re: [OAUTH-WG] I'm concerned about how the sniffability of oauth2 reque=
sts

On Mon, Feb 4, 2013 at 9:57 PM, William Mills <wmills_92105@yahoo.com> wrote:

There are two efforts at signed to=
ken types: MAC which is still a possibility if we wake up and do it, and th=
e "Holder Of Key" type tokens.

If someone can use sslstrip th=
en even MAC is not safe - since MAC key needs to be transferred over SSL to=
 the Client from the AS.

There are standard ways i=
n HTTP to avoid or protect from sslstrip - IMHO we need to occupy those bes=
t practices...

Thanks & regards,
-Prabath
=A0<=
/div>

There are a lot of folks that agree with you.

  From: L. Preston Sego III <LPSego3@gmail.com<=
/a>>

 To: oauth@ietf.org 

 Sent: Friday, February 1, 2=
013 7:37 AM
 Subject: [OA=
UTH-WG] I'm concerned about how the sniffability of oauth2 requests

In an oauth2 request, the access token is passed alon=
g in the header, with nothing else.
As I understand it, =
oauth2 was designed to be simple for everyone to use. And while, that's=
 true, I don't really like how all of the security is reliant on SSL.

what if an attack can strip away SSL using a tool such =
as sslstrip (or whatever else would be more suitable for modern https)? The=
y would be able to see the access token and start forging whatever request =
he or she wants to.

Why not do some sort of RSA-type public-private key thi=
ng like back in Oauth1, where there is verification of the payload on each =
request? Just use a better algorithm?

_______________________________________________
OA=
uth mailing list
OAuth@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/oauth

___________________________________=
____________

OAuth mailing list

OAuth@=
ietf.org

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

-- 
Thanks &=
amp; Regards,
Prabath
Mobile : +94 71 809 6732<=
/a>=A0

http://blog.f=
acilelogin.com

http://RampartFAQ.com

-- 
Thanks & Regards,
Prabath<=
div>

Mobile : +94 71 809 6732=A0

http://blog.facilelogin.com

http://RampartFAQ.com

--047d7b60436898324504d5121835--

From torsten@lodderstedt.net  Wed Feb  6 10:26:05 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F1C21F8A71; Wed,  6 Feb 2013 10:26:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.651
X-Spam-Level: 
X-Spam-Status: No, score=-0.651 tagged_above=-999 required=5 tests=[AWL=0.201,  BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5ddq8xTTToR; Wed,  6 Feb 2013 10:26:04 -0800 (PST)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.41]) by ietfa.amsl.com (Postfix) with ESMTP id B2E3921F8A9B; Wed,  6 Feb 2013 10:26:03 -0800 (PST)
Received: from [79.253.12.66] (helo=[192.168.71.56]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1U39gt-0007yE-UZ; Wed, 06 Feb 2013 19:25:52 +0100
References:  <51126D65.2090707@mitre.org>  <5112746B.70403@mitre.org>   
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: multipart/alternative; boundary=Apple-Mail-86FAD03F-F32C-4118-9F10-28BE9AF4C20F
Content-Transfer-Encoding: 7bit
Message-Id: <611639B1-8B4B-4010-A1DF-A0A8057F3EA8@lodderstedt.net>
X-Mailer: iPad Mail (10B141)
From: Torsten Lodderstedt 
Date: Wed, 6 Feb 2013 19:25:54 +0100
To: Prabath Siriwardena 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: "oauth-bounces@ietf.org" , "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] A question on token revocation.
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Feb 2013 18:26:05 -0000

--Apple-Mail-86FAD03F-F32C-4118-9F10-28BE9AF4C20F
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Hi Prabath,

we tried to address both use cases in the first revisions of the draft. The A=
PI was well suited for client-driven revocation but not the resource owner -=
 driven use case. There are definitely differences with respect to the proto=
col design, at least regarding authentication and authorization of the respe=
ctive actors. This made the spec more complex and caused ambiguities and con=
fusion. Moreover, the working group seemed not convinced by the the latter u=
se case.

Therefore the working group decided to focus on the single use cases of the r=
evocation by clients. This makes a lot of sense since this interface is most=
 important with respect to interoperability.

I'm focusing right now on finishing this draft. And the open issues discusse=
d on the list in the last couple of weeks illustrate that even this poses a c=
onsiderable amount of work. So I'm very reluctant to add support for a whole=
 new use case at that point of the process.

If you feel this is an important use case worth an RFC, don't hesitate to pu=
blish a new I-D.

regards,
Torsten.

Am 06.02.2013 um 16:37 schrieb Prabath Siriwardena :

>=20
>=20
> On Wed, Feb 6, 2013 at 9:04 PM, Todd W Lainhart  wrot=
e:
>> > Resource owner needs to know the consumer key (represents the OAuth Cli=
ent app) & scope to revoke the access token for a given client. =20
>>=20
>> I see - you're saying that requiring client credentials on the end point i=
s the problem?
>=20
> In fact what I meant was - when RO authorizes the an access token for clie=
nt for particular scope. Those information are kept at the AS.
>=20
> Now - if the RO want to revoke access from the client - the RO needs to au=
thenticate him self to the AS and pass the consumer key and the scope. So AS=
 can revoke access.
>=20
> Thanks & regards,
> -Prabath
> =20
>>=20
>>=20
>>=20
>>=20
>> Todd Lainhart
>> Rational software
>> IBM Corporation
>> 550 King Street, Littleton, MA 01460-1250
>> 1-978-899-4705
>> 2-276-4705 (T/L)
>> lainhart@us.ibm.com
>>=20
>>=20
>>=20
>>=20
>>=20
>> From:        Prabath Siriwardena =20
>> To:        Justin Richer ,=20
>> Cc:        "oauth@ietf.org WG" =20
>> Date:        02/06/2013 10:31 AM=20
>> Subject:        Re: [OAUTH-WG] A question on token revocation.=20
>> Sent by:        oauth-bounces@ietf.org=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> On Wed, Feb 6, 2013 at 8:49 PM, Justin Richer  wrote:=20=

>>=20
>> On 02/06/2013 10:13 AM, Prabath Siriwardena wrote:=20
>>=20
>>=20
>> On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer  wrote:=20=

>> These are generally handled through a user interface where the RO is auth=
enticated directly to the AS, and there's not much need for a "protocol" her=
e, in practice.=20
>>=20
>> Why do you think leaving access token revocation by RO to a proprietary A=
PI is a good practice ? IMO this an essential requirement in API security.=20=

>> I think it makes more sense in the same way that having a "proprietary" U=
I/API for managing the user consent makes sense: unless you're doing a fully=
 dynamic end-to-end system like UMA, then there's not much value in trying t=
o squeeze disparate systems into the same mold, since they won't be talking t=
o each other anyway.=20
>>=20
>> This is required in distributed setup for each API platform from differen=
t vendors to perform in an interop manner.=20
>>  =20
>>=20
>> And since you refer to it as an "API", what will the RO be using to call t=
his API? Is there a token management client that's separate from the OAuth c=
lient?=20
>>=20
>> I didn't get your question right... If you meant the how to invoke revoca=
tion end point, the the resource owner needs to know the consumer key (repre=
sents the OAuth Client app) & scope to revoke the access token for a given c=
lient. =20
>>=20
>>=20
>>=20
>> IMHO token revocation done my RO is more practical than token revocation d=
one by the Client.=20
>> They're both valid but require different kinds of protocols and considera=
tions. This token revocation draft is meant to solve one problem, and that d=
oesn't mean it can or should solve other seemingly related problems.
>>=20
>> If you would like to see the RO-initiated token revocation go through (no=
t grant revocation, mind you -- that's related, but different), then I would=
 suggest that you start specifying exactly how that works. I predict it will=
 be problematic in practice, though, as the RO often doesn't actually have d=
irect access to the token itself.=20
>>=20
>> Resource owner needs to know the consumer key (represents the OAuth Clien=
t app) & scope to revoke the access token for a given client. =20
>>=20
>>  =20
>>=20
>>  =20
>> There are larger applications, like UMA, that have client and PR provisio=
ning that would allow for this to be managed somewhat programmatically, but e=
ven in that case you're still generally doing token revocation by a "client"=
 in some fashion. In UMA, though, several different pieces can play the role=
 of a "client" at different parts of the process.
>>=20
>> Revoking a scope is a whole different mess. Generally, you'd want to just=
 revoke an existing token and make a new authorization grant with lower acce=
ss if you don't want that client getting that scope anymore. If you just wan=
t to downscope for a single transaction, you can already do that with either=
 the refresh token or token chaining approaches, depending on where in the p=
rocess you are. The latter of these are both client-focused, though, and the=
 RO doesn't have a direct hand in it at this point.=20
>>=20
>> Why do you think it a mess. If you revoke the entire token then Client ne=
eds to go through the complete OAuth flow - and also needs to get the user c=
onsent. If RO can  downgrade the scope, then we restrict API access by the c=
lient at RS end and its transparent to the client.=20
>>=20
>>=20
>> Downgrading the scope of tokens in the wild is hardly transparent to the c=
lient (stuff that it expects to work will suddenly start to fail, meaning th=
at most clients will throw out the token and try to get a new one), and in a=
 distributed system you've got to propagate that change to the RS. If you ba=
ke the scopes into the token itself (which many do) then you actually *can't=
* downgrade a single token, anyway.=20
>>=20
>> Yes.. that is the expected behavior. I mean the process is transparent. C=
lient will notice at runtime.=20
>>=20
>> Thanks & regards,=20
>> -Prabath=20
>>  =20
>>=20
>>  -- Justin=20
>>=20
>>=20
>> Thanks & regards,=20
>> -Prabath=20
>>  =20
>>=20
>>=20
>>  -- Justin=20
>>=20
>>=20
>> On 02/06/2013 04:35 AM, Prabath Siriwardena wrote:=20
>> I am sorry if this was already discussed in this list.. =20
>>=20
>> Looking at [1] it only talks about revoking the access token from the cli=
ent.=20
>>=20
>> How about the resource owner..?=20
>>=20
>> There can be cases where resource owner needs to revoke an authorized acc=
ess token from a given client. Or revoke an scope..=20
>>=20
>> How are we going to address these requirements..? Thoughts appreciated...=
=20
>>=20
>> [1] http://tools.ietf.org/html/draft-ietf-oauth-revocation-04=20
>>=20
>> --=20
>> Thanks & Regards,
>> Prabath=20
>>=20
>> Mobile : +94 71 809 6732=20
>>=20
>> http://blog.facilelogin.com
>> http://RampartFAQ.com=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>>=20
>>=20
>>=20
>>=20
>> --=20
>> Thanks & Regards,
>> Prabath=20
>>=20
>> Mobile : +94 71 809 6732=20
>>=20
>> http://blog.facilelogin.com
>> http://RampartFAQ.com=20
>>=20
>>=20
>>=20
>>=20
>> --=20
>> Thanks & Regards,
>> Prabath=20
>>=20
>> Mobile : +94 71 809 6732=20
>>=20
>> http://blog.facilelogin.com
>> http://RampartFAQ.com_______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20
>=20
> --=20
> Thanks & Regards,
> Prabath
>=20
> Mobile : +94 71 809 6732=20
>=20
> http://blog.facilelogin.com
> http://RampartFAQ.com
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-86FAD03F-F32C-4118-9F10-28BE9AF4C20F
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Prabath,

w=
e tried to address both use cases in the first revisions of the draft. The A=
PI was well suited for client-driven revocation but not the resource owner -=
 driven use case. There are definitely differences with respect to the proto=
col design, at least regarding  caused ambiguities and confusion. Moreover, the working group seem=
ed not convinced by the the latter use case.

Therefore the working group decided to focus on the single use cases of the=
 revocation by clients. This makes a lot of sense since this interface is mo=
st important with respect to interoperability.

I'm f=
ocusing right now on finishing this draft. And the open issues discussed on t=
he list in the last couple of weeks illustrate that even this poses a consid=
erable amount of work. So I'm very reluctant to add support for a whole new u=
se case at that point of the process.

If you feel t=
his is an important use case worth an RFC, don't hesitate to publish a new I=
-D.

regards,
Torsten.

Am 06.02.2013 um 16:37 schrieb Prabath Siriwardena <prabath@wso2.com>:

On Wed, Feb 6, 2013 at 9:0=
4 PM, Todd W Lainhart <lainhart@us.ibm.com> wrote:

> Res=
ource owner
needs to know the consumer key (represents the OAuth Client app) &
scope to revoke the access token for a given client. 

I see - you're saying that requiring
client credentials on the end point is the problem?
<=
div>

In fact what I meant was - when RO authorizes the an acce=
ss token for client for particular scope. Those information are kept at the A=
S.

Now - if the RO want to revoke access from the client - t=
he RO needs to authenticate him self to the AS and pass the consumer key and=
 the scope. So AS can revoke access.

Thanks & r=
egards,
-Prabath

Todd Lainhart

Rational software

IBM Corporation

550 King Street, Littleton, MA 01460-1250

1-978-899-4705

2-276-4705 (T/L)

lainhart@us.ibm.com=

From:  =
;    
 Prabath Siriwardena
<prabath@wso2.com>

To:    =

 Justin Richer <jricher@mitre.org>,

Cc:    =

 "oauth@ietf.org
WG" <oauth@ietf.org>

Date:   &nbs=
p;  
 02/06/2013 10:31 AM=

Subject:    
   Re: [OAUTH-WG]
A question on token revocation.

Sent by:   &=
nbsp;
   oauth-bounces@ietf.org

On Wed, Feb 6, 2013 at 8:4=
9 PM, Justin Richer <jricher@mitre.org=
>
wrote:

On 02/06/2013 10:13 AM, Prabath Siriwardena wrote:

On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer <jricher@mitre.org>
wrote:

These are generally handled through a user interface wh=
ere
the RO is authenticated directly to the AS, and there's not much need for
a "protocol" here, in practice. 

Why do you think leaving access token revocation by RO
to a proprietary API is a good practice ? IMO this an essential requirement
in API security.

I think it makes more sense in the same way that having=

a "proprietary" UI/API for managing the user consent makes sense:
unless you're doing a fully dynamic end-to-end system like UMA, then there's=

not much value in trying to squeeze disparate systems into the same mold,
since they won't be talking to each other anyway. 

This is required in distributed setup for each API plat=
form
from different vendors to perform in an interop manner.

And since you refer to it as an "API", what will the RO be using
to call this API? Is there a token management client that's separate from
the OAuth client? 

I didn't get your question right... If you meant the ho=
w
to invoke revocation end point, the the resource owner needs to know the
consumer key (represents the OAuth Client app) & scope to revoke the
access token for a given client. 

IMHO token revocation done my RO is more practical than=

token revocation done by the Client.

They're both valid but require different kinds of proto=
cols
and considerations. This token revocation draft is meant to solve one proble=
m,
and that doesn't mean it can or should solve other seemingly related problem=
s.

If you would like to see the RO-initiated token revocation go through (not
grant revocation, mind you -- that's related, but different), then I would
suggest that you start specifying exactly how that works. I predict it
will be problematic in practice, though, as the RO often doesn't actually
have direct access to the token itself. 

Resource owner needs to know the consumer key (represen=
ts
the OAuth Client app) & scope to revoke the access token for a given
client. 

There are larger applications, like UMA, that have clie=
nt
and PR provisioning that would allow for this to be managed somewhat program=
matically,
but even in that case you're still generally doing token revocation by
a "client" in some fashion. In UMA, though, several different
pieces can play the role of a "client" at different parts of
the process.

Revoking a scope is a whole different mess. Generally, you'd want to just
revoke an existing token and make a new authorization grant with lower
access if you don't want that client getting that scope anymore. If you
just want to downscope for a single transaction, you can already do that
with either the refresh token or token chaining approaches, depending on
where in the process you are. The latter of these are both client-focused,
though, and the RO doesn't have a direct hand in it at this point.

Why do you think it a mess. If you revoke the entire to=
ken
then Client needs to go through the complete OAuth flow - and also needs
to get the user consent. If RO can  downgrade the scope, then we restri=
ct
API access by the client at RS end and its transparent to the client.=

Downgrading the scope of tokens in the wild is hardly
transparent to the client (stuff that it expects to work will suddenly
start to fail, meaning that most clients will throw out the token and try
to get a new one), and in a distributed system you've got to propagate
that change to the RS. If you bake the scopes into the token itself (which
many do) then you actually *can't* downgrade a single token, anyway. =

Yes.. that is the expected behavior. I mean the process=

is transparent. Client will notice at runtime.

Thanks & regards,

-Prabath

 -- Justin

Thanks & regards,

-Prabath

 -- Justin 

On 02/06/2013 04:35 AM, Prabath Siriwardena wrote:

I am sorry if this was already discussed in this list..=

Looking at [1] it only talks about revoking the access
token from the client.

How about the resource owner..?

There can be cases where resource owner needs to revoke=

an authorized access token from a given client. Or revoke an scope..

How are we going to address these requirements..? Thoug=
hts
appreciated...

[1] =
http://tools.ietf.org/html/draft-ietf-oauth-revocation-04

-- 

Thanks & Regards,

Prabath 

Mobile : +94
71 809 6732 

http://blog.facilelogin.com

http://RampartFAQ.com

_______________________________________________
=

OAuth mailing list

OAuth@ietf.org

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

-- 

Thanks & Regards,

Prabath 

Mobile : +94
71 809 6732 

http://blog.facilelogin.com

http://RampartFAQ.com

-- 

Thanks & Regards,

Prabath

Mobile : +94 71 809 6732 

http://blog.facilelogin.com

=
http://RampartFAQ.com<=
font>_______________________________________________

OAuth mailing list

OAuth@ietf.org

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

-- 
Thanks &a=
mp; Regards,
Prabath
Mobile : +94 71 809 6732 
http://blog.f=
acilelogin.com

http://RampartFAQ.com

____________________=
___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai=
lman/listinfo/oauth
=

--Apple-Mail-86FAD03F-F32C-4118-9F10-28BE9AF4C20F--

From prabath@wso2.com  Wed Feb  6 10:32:32 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E7A21F8715 for ; Wed,  6 Feb 2013 10:32:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.649
X-Spam-Level: 
X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.327,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWrupykWlaWR for ; Wed,  6 Feb 2013 10:32:30 -0800 (PST)
Received: from mail-ea0-f169.google.com (mail-ea0-f169.google.com [209.85.215.169]) by ietfa.amsl.com (Postfix) with ESMTP id 122F021F8548 for ; Wed,  6 Feb 2013 10:32:29 -0800 (PST)
Received: by mail-ea0-f169.google.com with SMTP id d13so799586eaa.28 for ; Wed, 06 Feb 2013 10:32:29 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=JaegM0qbecKvBClI7o/Rti64268RzLgAmda5WwRDVF4=; b=LRt1Wgip7DF8iNZEok4iShnFEWxCzZKVu96o/XC/+1rxvXsCoN3Tq+/ueRcJCqrAZZ 9WI5tGL8XyaiaCZntXPax80g3bCF3FyH4KAbRIBIuy1iZLHvm3puG1P4rbVi16IN7/g9 k/5f65M5ZHarYlFuP3dljTaEOHqEeNXIiJDf8FYThFbFPfwTHzqVZNZAKtpBl+59+Hzs gcuA75qLlreYxoPLkBqJWYxnZ+fPzzOhunr0+8HKUIqMUXYHZdGp0o5d/9QWL705jhYP B3a+jQDZ4IpEOQ1guAsTPfoNc06lPipgELM2xL5TQMbHivcuKOFCCL3Hu1hzoAbshwHQ 8stQ==
MIME-Version: 1.0
X-Received: by 10.14.178.196 with SMTP id f44mr99792474eem.14.1360175548693; Wed, 06 Feb 2013 10:32:28 -0800 (PST)
Received: by 10.223.175.134 with HTTP; Wed, 6 Feb 2013 10:32:28 -0800 (PST)
In-Reply-To: <611639B1-8B4B-4010-A1DF-A0A8057F3EA8@lodderstedt.net>
References:  <51126D65.2090707@mitre.org>  <5112746B.70403@mitre.org>    <611639B1-8B4B-4010-A1DF-A0A8057F3EA8@lodderstedt.net>
Date: Thu, 7 Feb 2013 00:02:28 +0530
Message-ID: 
From: Prabath Siriwardena 
To: Torsten Lodderstedt 
Content-Type: multipart/alternative; boundary=047d7b622520697dcb04d5128c89
X-Gm-Message-State: ALoCoQle1IVPaCqPQaNe1CkFzB4j2s6+wAwuExwc7O4Jc5ZQXOidGkD2KH0r2lyd/oe3gGJKghuE
Cc: "oauth-bounces@ietf.org" , "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] A question on token revocation.
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Feb 2013 18:32:32 -0000

--047d7b622520697dcb04d5128c89
Content-Type: text/plain; charset=ISO-8859-1

Hi Torsten,

Thanks for your feedback.. I will submit a draft...

Thanks & regards,
-Prabath

On Wed, Feb 6, 2013 at 11:55 PM, Torsten Lodderstedt <
torsten@lodderstedt.net> wrote:

> Hi Prabath,
>
> we tried to address both use cases in the first revisions of the draft.
> The API was well suited for client-driven revocation but not the resource
> owner - driven use case. There are definitely differences with respect to
> the protocol design, at least regarding authentication and authorization
> of the respective actors. This made the spec more complex and caused
> ambiguities and confusion. Moreover, the working group seemed not convinced
> by the the latter use case.
>
> Therefore the working group decided to focus on the single use cases of
> the revocation by clients. This makes a lot of sense since this interface
> is most important with respect to interoperability.
>
> I'm focusing right now on finishing this draft. And the open issues
> discussed on the list in the last couple of weeks illustrate that even this
> poses a considerable amount of work. So I'm very reluctant to add support
> for a whole new use case at that point of the process.
>
> If you feel this is an important use case worth an RFC, don't hesitate to
> publish a new I-D.
>
> regards,
> Torsten.
>
> Am 06.02.2013 um 16:37 schrieb Prabath Siriwardena :
>
>
>
> On Wed, Feb 6, 2013 at 9:04 PM, Todd W Lainhart wrote:
>
>> > Resource owner needs to know the consumer key (represents the OAuth
>> Client app) & scope to revoke the access token for a given client.
>>
>> I see - you're saying that requiring client credentials on the end point
>> is the problem?
>>
>
> In fact what I meant was - when RO authorizes the an access token for
> client for particular scope. Those information are kept at the AS.
>
> Now - if the RO want to revoke access from the client - the RO needs to
> authenticate him self to the AS and pass the consumer key and the scope. So
> AS can revoke access.
>
> Thanks & regards,
> -Prabath
>
>
>>
>>  *
>>
>>
>> Todd Lainhart
>> Rational software
>> IBM Corporation
>> 550 King Street, Littleton, MA 01460-1250**
>> 1-978-899-4705
>> 2-276-4705 (T/L)
>> lainhart@us.ibm.com*
>>
>>
>>
>>
>> From:        Prabath Siriwardena 
>> To:        Justin Richer ,
>> Cc:        "oauth@ietf.org WG" 
>> Date:        02/06/2013 10:31 AM
>> Subject:        Re: [OAUTH-WG] A question on token revocation.
>> Sent by:        oauth-bounces@ietf.org
>> ------------------------------
>>
>>
>>
>>
>>
>> On Wed, Feb 6, 2013 at 8:49 PM, Justin Richer <*jricher@mitre.org*>
>> wrote:
>>
>> On 02/06/2013 10:13 AM, Prabath Siriwardena wrote:
>>
>>
>> On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer <*jricher@mitre.org*>
>> wrote:
>> These are generally handled through a user interface where the RO is
>> authenticated directly to the AS, and there's not much need for a
>> "protocol" here, in practice.
>>
>> Why do you think leaving access token revocation by RO to a proprietary
>> API is a good practice ? IMO this an essential requirement in API security.
>> I think it makes more sense in the same way that having a "proprietary"
>> UI/API for managing the user consent makes sense: unless you're doing a
>> fully dynamic end-to-end system like UMA, then there's not much value in
>> trying to squeeze disparate systems into the same mold, since they won't be
>> talking to each other anyway.
>>
>> This is required in distributed setup for each API platform from
>> different vendors to perform in an interop manner.
>>
>>
>> And since you refer to it as an "API", what will the RO be using to call
>> this API? Is there a token management client that's separate from the OAuth
>> client?
>>
>> I didn't get your question right... If you meant the how to invoke
>> revocation end point, the the resource owner needs to know the consumer key
>> (represents the OAuth Client app) & scope to revoke the access token for a
>> given client.
>>
>>
>>
>> IMHO token revocation done my RO is more practical than token revocation
>> done by the Client.
>> They're both valid but require different kinds of protocols and
>> considerations. This token revocation draft is meant to solve one problem,
>> and that doesn't mean it can or should solve other seemingly related
>> problems.
>>
>> If you would like to see the RO-initiated token revocation go through
>> (not grant revocation, mind you -- that's related, but different), then I
>> would suggest that you start specifying exactly how that works. I predict
>> it will be problematic in practice, though, as the RO often doesn't
>> actually have direct access to the token itself.
>>
>> Resource owner needs to know the consumer key (represents the OAuth
>> Client app) & scope to revoke the access token for a given client.
>>
>>
>>
>>
>> There are larger applications, like UMA, that have client and PR
>> provisioning that would allow for this to be managed somewhat
>> programmatically, but even in that case you're still generally doing token
>> revocation by a "client" in some fashion. In UMA, though, several different
>> pieces can play the role of a "client" at different parts of the process.
>>
>> Revoking a scope is a whole different mess. Generally, you'd want to just
>> revoke an existing token and make a new authorization grant with lower
>> access if you don't want that client getting that scope anymore. If you
>> just want to downscope for a single transaction, you can already do that
>> with either the refresh token or token chaining approaches, depending on
>> where in the process you are. The latter of these are both client-focused,
>> though, and the RO doesn't have a direct hand in it at this point.
>>
>> Why do you think it a mess. If you revoke the entire token then Client
>> needs to go through the complete OAuth flow - and also needs to get the
>> user consent. If RO can  downgrade the scope, then we restrict API access
>> by the client at RS end and its transparent to the client.
>>
>>
>> Downgrading the scope of tokens in the wild is hardly transparent to the
>> client (stuff that it expects to work will suddenly start to fail, meaning
>> that most clients will throw out the token and try to get a new one), and
>> in a distributed system you've got to propagate that change to the RS. If
>> you bake the scopes into the token itself (which many do) then you actually
>> *can't* downgrade a single token, anyway.
>>
>> Yes.. that is the expected behavior. I mean the process is transparent.
>> Client will notice at runtime.
>>
>> Thanks & regards,
>> -Prabath
>>
>>
>>  -- Justin
>>
>>
>> Thanks & regards,
>> -Prabath
>>
>>
>>
>>  -- Justin
>>
>>
>> On 02/06/2013 04:35 AM, Prabath Siriwardena wrote:
>> I am sorry if this was already discussed in this list..
>>
>> Looking at [1] it only talks about revoking the access token from the
>> client.
>>
>> How about the resource owner..?
>>
>> There can be cases where resource owner needs to revoke an authorized
>> access token from a given client. Or revoke an scope..
>>
>> How are we going to address these requirements..? Thoughts appreciated...
>>
>> [1] *http://tools.ietf.org/html/draft-ietf-oauth-revocation-04*
>>
>> --
>> Thanks & Regards,
>> Prabath
>>
>> Mobile : *+94 71 809 6732* <%2B94%2071%20809%206732>
>> *
>> **http://blog.facilelogin.com* *
>> **http://RampartFAQ.com* 
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> *OAuth@ietf.org* 
>> *https://www.ietf.org/mailman/listinfo/oauth*
>>
>>
>>
>>
>>
>> --
>> Thanks & Regards,
>> Prabath
>>
>> Mobile : *+94 71 809 6732* <%2B94%2071%20809%206732>
>> *
>> **http://blog.facilelogin.com* *
>> **http://RampartFAQ.com* 
>>
>>
>>
>>
>> --
>> Thanks & Regards,
>> Prabath
>>
>> Mobile : +94 71 809 6732
>> *
>> **http://blog.facilelogin.com* *
>> *
>> *http://RampartFAQ.com* 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
>
> --
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.com

--047d7b622520697dcb04d5128c89
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi=A0Torsten,
Thanks for your feedback.. I will submit a=
 draft...

Thanks & regards,
_______________________________________________
OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mai=
lman/listinfo/oauth

-Prabath=

On Wed, Feb 6, 2013 at 11:55 PM, Torsten=
 Lodderstedt <torsten@lodderstedt.net> wrote:

Hi Prabath,

we tried to address both use cases in the first revisions o=
f the draft. The API was well suited for client-driven revocation but not t=
he resource owner - driven use case. There are definitely differences with =
respect to the protocol design, at least regarding authentication and=
 authorization of the respective actors.=A0This made the spec more c=
omplex and=A0caused ambiguities and confusion. Moreover, the working =
group seemed not convinced by the the latter use case.

Therefore the working group decided to focus on the sin=
gle use cases of the revocation by clients. This makes a lot of sense since=
 this interface is most important with respect to interoperability.

I'm focusing right now on finishing this draft. And=
 the open issues discussed on the list in the last couple of weeks illustra=
te that even this poses a considerable amount of work. So I'm very relu=
ctant to add support for a whole new use case at that point of the process.=

If you feel this is an important use case worth an RFC,=
 don't hesitate to publish a new I-D.

regards,=
Torsten.

Am 06.02.2013 um 16:37 schrieb=
 Prabath Siriwardena <prabath@wso2.com>:

On Wed, Feb 6, 2013 at 9:04 PM, Todd W Lainhart <lainhart@us.ibm.com> wrote:

> Resource owner
needs to know the consumer key (represents the OAuth Client app) &
scope to revoke the access token for a given client.=A0

I see - you're saying that requirin=
g
client credentials on the end point is the problem?
=

In fact what I meant was - when RO authorizes the an ac=
cess token for client for particular scope. Those information are kept at t=
he AS.

Now - if the RO want to revoke access from the client -=
 the RO needs to authenticate him self to the AS and pass the consumer key =
and the scope. So AS can revoke access.

Thanks &am=
p; regards,

-Prabath
=A0

Todd Lainhart

Rational software

IBM Corporation

550 King Street, Littleton, MA 01460-1250

1-978-899-4705

2-276-4705 (T/L)

lainhart@us.ibm.co=
m

From: =A0 =
=A0 =A0
=A0Prabath Siriwardena
<prabath@wso2.com<=
/a>>

To: =A0 =A0 =A0
=A0Justin Richer <jricher@mitre.org>,

Cc: =A0 =A0 =A0
=A0"oauth@ietf.org
WG" <oauth@ietf=
.org>

Date: =A0 =A0 =
=A0
=A002/06/2013 10:31 AM

Subject: =
=A0 =A0
=A0 =A0Re: [OAUTH-WG]
A question on token revocation.

Sent by: =A0 =A0
=A0 =A0oauth-bounces@ietf.org

On Wed, Feb 6, 2013 at 8:49 PM, Justin=
 Richer <<=
font size=3D"3" color=3D"blue">jricher@mitre.org>
wrote:

On 02/06/2013 10:13 AM, Prabath Siriwardena wrote:

On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer <jricher@mitre.org>
wrote:

These are generally handled through a user interface w=
here
the RO is authenticated directly to the AS, and there's not much need f=
or
a "protocol" here, in practice. 

Why do you think leaving access token revocation by RO
to a proprietary API is a good practice ? IMO this an essential requirement
in API security.

I think it makes more sense in the same way that havin=
g
a "proprietary" UI/API for managing the user consent makes sense:
unless you're doing a fully dynamic end-to-end system like UMA, then th=
ere's
not much value in trying to squeeze disparate systems into the same mold,
since they won't be talking to each other anyway. 

This is required in distributed setup for each API pla=
tform
from different vendors to perform in an interop manner.

=A0

And since you refer to it as an "API", what will the RO be using
to call this API? Is there a token management client that's separate fr=
om
the OAuth client? 

I didn't get your question right... If you meant t=
he how
to invoke revocation end point, the the resource owner needs to know the
consumer key (represents the OAuth Client app) & scope to revoke the
access token for a given client.=A0

IMHO token revocation done my RO is more practical tha=
n
token revocation done by the Client.

They're both valid but require different kinds of =
protocols
and considerations. This token revocation draft is meant to solve one probl=
em,
and that doesn't mean it can or should solve other seemingly related pr=
oblems.

If you would like to see the RO-initiated token revocation go through (not
grant revocation, mind you -- that's related, but different), then I wo=
uld
suggest that you start specifying exactly how that works. I predict it
will be problematic in practice, though, as the RO often doesn't actual=
ly
have direct access to the token itself. 

Resource owner needs to know the consumer key (represe=
nts
the OAuth Client app) & scope to revoke the access token for a given
client.=A0

=A0

=A0

There are larger applications, like UMA, that have cli=
ent
and PR provisioning that would allow for this to be managed somewhat progra=
mmatically,
but even in that case you're still generally doing token revocation by
a "client" in some fashion. In UMA, though, several different
pieces can play the role of a "client" at different parts of
the process.

Revoking a scope is a whole different mess. Generally, you'd want to ju=
st
revoke an existing token and make a new authorization grant with lower
access if you don't want that client getting that scope anymore. If you
just want to downscope for a single transaction, you can already do that
with either the refresh token or token chaining approaches, depending on
where in the process you are. The latter of these are both client-focused,
though, and the RO doesn't have a direct hand in it at this point.

Why do you think it a mess. If you revoke the entire t=
oken
then Client needs to go through the complete OAuth flow - and also needs
to get the user consent. If RO can =A0downgrade the scope, then we restrict
API access by the client at RS end and its transparent to the client.

Downgrading the scope of tokens in the wild is hardly
transparent to the client (stuff that it expects to work will suddenly
start to fail, meaning that most clients will throw out the token and try
to get a new one), and in a distributed system you've got to propagate
that change to the RS. If you bake the scopes into the token itself (which
many do) then you actually *can't* downgrade a single token, anyway. 

Yes.. that is the expected behavior. I mean the proces=
s
is transparent. Client will notice at runtime.

Thanks & regards,

-Prabath

=A0

=A0-- Justin

Thanks & regards,

-Prabath

=A0

=A0-- Justin 

On 02/06/2013 04:35 AM, Prabath Siriwardena wrote:

I am sorry if this was already discussed in this list.=
.=A0

Looking at [1] it only talks about revoking the access
token from the client.

How about the resource owner..?

There can be cases where resource owner needs to revok=
e
an authorized access token from a given client. Or revoke an scope..

How are we going to address these requirements..? Thou=
ghts
appreciated...

[1] http://tools.ietf.org/html/draft-ietf-oauth-revocation-04

-- 

Thanks & Regards,

Prabath 

Mobile : +94
71 809 6732=A0

http://blog.facilelogin.com

http://RampartFAQ.com

_______________________________________________
OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mai=
lman/listinfo/oauth

-- 

Thanks & Regards,

Prabath 

Mobile : +94
71 809 6732=A0

http://blog.facilelogin.com

http://RampartFAQ.com

-- 

Thanks & Regards,

Prabath

Mobile : +94 71 809 6732=A0

http://blog.facilelogin.com

http://RampartFAQ.com_______________________________________________

OAuth mailing list

OAuth@ietf.org

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

-- 
Thanks &=
amp; Regards,
Prabath
Mobile : +94 71 809 6732<=
/a>=A0

http://blog.f=
acilelogin.com

http://RampartFAQ.com

___________________=
____________________________
OAuth mailing list
<=
span>OAuth@ietf.org=

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

=

-- 
Thanks & Regards,
Prabath
Mobile : +94 71 =
809 6732=A0

http://blog.facilelogin.com
http://RampartFAQ.com

--047d7b622520697dcb04d5128c89--

From jricher@mitre.org  Wed Feb  6 11:25:56 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2500221F8A42 for ; Wed,  6 Feb 2013 11:25:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.573
X-Spam-Level: 
X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.025,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xq4tF3DPBFLr for ; Wed,  6 Feb 2013 11:25:43 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8C921F8556 for ; Wed,  6 Feb 2013 11:25:39 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 33BE51F13F2 for ; Wed,  6 Feb 2013 14:25:36 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 0D71E1F0780 for ; Wed,  6 Feb 2013 14:25:36 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 6 Feb 2013 14:25:35 -0500
Message-ID: <5112AE0B.1080501@mitre.org>
Date: Wed, 6 Feb 2013 14:24:59 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: "oauth@ietf.org" 
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com>
In-Reply-To: <20130206192420.32698.21027.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20130206192420.32698.21027.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------020909060905060508070501"
X-Originating-IP: [129.83.31.58]
Subject: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Feb 2013 19:25:56 -0000

--------------020909060905060508070501
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit

Updated introspection draft based on recent comments. Changes include:

  - "scope" return parameter now follows RFC6749 format instead of JSON 
array
  - "subject" -> "sub", and "audience" -> "aud", to be parallel with JWT 
claims
  - clarified what happens if the authentication is bad

  -- Justin

-------- Original Message --------
Subject: 	New Version Notification for 
draft-richer-oauth-introspection-02.txt
Date: 	Wed, 6 Feb 2013 11:24:20 -0800
From: 	
To: 	

A new version of I-D, draft-richer-oauth-introspection-02.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 02
Title:		 OAuth Token Introspection
Creation date:	 2013-02-06
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02

Abstract:
    This specification defines a method for a client or protected
    resource to query an OAuth authorization server to determine meta-
    information about an OAuth token.

The IETF Secretariat

--------------020909060905060508070501
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 8bit

    Updated introspection draft based on recent comments. Changes
    include:

     - "scope" return parameter now follows RFC6749 format instead of
    JSON array

     - "subject" -> "sub", and "audience" -> "aud", to be parallel
    with JWT claims

     - clarified what happens if the authentication is bad

     -- Justin

      -------- Original Message --------

            Subject:

            New Version Notification for
              draft-richer-oauth-introspection-02.txt

            Date: 
            Wed, 6 Feb 2013 11:24:20 -0800

            From: 
            <internet-drafts@ietf.org>

            To: 
            <jricher@mitre.org>

      A new version of I-D, draft-richer-oauth-introspection-02.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 02
Title:		 OAuth Token Introspection
Creation date:	 2013-02-06
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.

The IETF Secretariat

--------------020909060905060508070501--

From internet-drafts@ietf.org  Wed Feb  6 12:15:36 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87FD921E803F; Wed,  6 Feb 2013 12:15:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzsfXO5TADsv; Wed,  6 Feb 2013 12:15:36 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5661621E8041; Wed,  6 Feb 2013 12:15:34 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.37
Message-ID: <20130206201534.13236.6681.idtracker@ietfa.amsl.com>
Date: Wed, 06 Feb 2013 12:15:34 -0800
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-05.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Feb 2013 20:15:36 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Web Authorization Protocol Working Group =
of the IETF.

	Title           : OAuth Dynamic Client Registration Protocol
	Author(s)       : Justin Richer
                          John Bradley
                          Michael B. Jones
                          Maciej Machulak
	Filename        : draft-ietf-oauth-dyn-reg-05.txt
	Pages           : 21
	Date            : 2013-02-06

Abstract:
   This specification defines an endpoint and protocol for dynamic
   registration of OAuth Clients at an Authorization Server.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-05

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

From jricher@mitre.org  Wed Feb  6 12:35:51 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDAC421E8043 for ; Wed,  6 Feb 2013 12:35:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.574
X-Spam-Level: 
X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zV5bAxV5JoVs for ; Wed,  6 Feb 2013 12:35:49 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF0D21E8042 for ; Wed,  6 Feb 2013 12:35:36 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id F29BC1F13DB for ; Wed,  6 Feb 2013 15:35:35 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B012E1F077D for ; Wed,  6 Feb 2013 15:35:35 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 6 Feb 2013 15:35:35 -0500
Message-ID: <5112BE73.2070003@mitre.org>
Date: Wed, 6 Feb 2013 15:34:59 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: 
References: <20130206201534.13236.6681.idtracker@ietfa.amsl.com>
In-Reply-To: <20130206201534.13236.6681.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.58]
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-05.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Feb 2013 20:35:51 -0000

Thanks to all of the discussion over the last few weeks and some key 
input from Nat Sakimura, Eve Maler, and others, I've put out a revision 
of the DynReg specification that is a major change from recent 
revisions, but actually brings it back closer to the original -01 draft. 
The "operation" parameter is now gone and there are instead several 
logical endpoints for different kinds of operations. These endpoints are 
communicated to the client through a well-defined link structure.

It basically works like this:

1. client shows up at the Client Registration Endpoint, posts a JSON 
object with a few bits of metadata about itself (and potentially 
presents an Access Token that it got from some out of band process that 
acts as a "class registration" or "developer key", important to several 
known real-world use cases)

2. client gets back a JSON object filled with whatever metadata the 
server has about it, including a newly-minted client_id and (possibly) 
client_secret. The client also gets back a registration access token and 
a fully qualified URL that points to the "update endpoint". This url can 
take any form (the server can't count on the client being able to 
generate it from parts), but it's recommended that it follow a 
REST-style URL template of the form 
"https://server/registration_base_url/client_id".

3. client sends updates to this update URL, authenticated by the 
registration access token, by PUTting a JSON object with all of its 
parameters. Any fields the client leaves off the JSON object, the server 
leaves alone. Anything with a "null" value, the server deletes the 
value. The server remains free to override *any* field the client 
requests setting a particular value for. The client is not allowed to 
request a particular value for the client_secret or 
registration_access_token, for obvious reasons -- but see part 7 below.

4. The server responds back with the current state of the client as a 
JSON object, including any fields the server has provisioned on the 
client's behalf (defaults, for instance). Any fields the server has 
overridden, it currently MUST respond with. So if the client asks for 
"scope: A B C" and the server can only give it "scope: A B", then the 
server has to tell that to the client by including the field "scope: A 
B" in its response.

5. client can send an HTTP GET to the update URL to get its current 
state as a JSON object as in 4.

6. client can send an HTTP DELETE to the update URL to deprovision itself.

7. there's also a parallel endpoint for rotating the registration access 
token and client secret, since these are both security values that are 
provisioned by the server. There is some open debate of whether the 
client actually needs to be able to trigger this operation, or if the 
server should just do this as part of normal update/get requests to the 
update endpoint.

It's a major functionality change on the wire, and there's still sawdust 
on the spec language. By going with a JSON-based data model and a 
RESTful update protocol, we're getting away from core OAuth patterns, 
but I think that ultimately this can be a good thing. There have been a 
few proposals that would go somewhere between what OAuth does on other 
endpoints and what a real RESTful system would do, but I didn't see much 
purpose in going half way when the results would end up *more* complicated.

I request that everyone read it over to see if this will work for their 
use cases. The idea here remains that application protocols like OIDC 
and UMA would use this mechanism as-is with nearly all customizations in 
the client metadata table.

I hope that this all actually makes sense...

  -- Justin

On 02/06/2013 03:15 PM, internet-drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the Web Authorization Protocol Working Group of the IETF.
>
> 	Title           : OAuth Dynamic Client Registration Protocol
> 	Author(s)       : Justin Richer
>                            John Bradley
>                            Michael B. Jones
>                            Maciej Machulak
> 	Filename        : draft-ietf-oauth-dyn-reg-05.txt
> 	Pages           : 21
> 	Date            : 2013-02-06
>
> Abstract:
>     This specification defines an endpoint and protocol for dynamic
>     registration of OAuth Clients at an Authorization Server.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-05
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From sberyozkin@gmail.com  Wed Feb  6 13:48:51 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA5E21F85DF for ; Wed,  6 Feb 2013 13:48:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.333
X-Spam-Level: 
X-Spam-Status: No, score=-3.333 tagged_above=-999 required=5 tests=[AWL=0.266,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-CD4tgtpO6E for ; Wed,  6 Feb 2013 13:48:50 -0800 (PST)
Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0E021F84D8 for ; Wed,  6 Feb 2013 13:48:49 -0800 (PST)
Received: by mail-wi0-f173.google.com with SMTP id hq4so6124427wib.6 for ; Wed, 06 Feb 2013 13:48:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ZYXI5uko7xFjZNCQGtjBTp0Y+lA8adqjqeS6AyjKRtg=; b=C8s4cVilo0zb+Nem86peo2dVuM0QI2x0DSBQQ0TjPcu3fCEOPyrCWXteHQCz22ruCw mh54HdXsvpbNWEXEF7AS9S8blNSHl7maeOACoCHKD/Ntmhlh/Jiim+bvio5b4ZPwXnzH q6OmY/KLsAB5TD4eMUccgxVC/+Z3/4+qnmzfaFlx3BLosmOc1qbN3Pju1Gf7+xmtGLlb LWmrLIUsBJ2EUet3tqVAH5SVmc6UDneMXKRszJy7KhbYl2i67y20G7y8T245gmqO/dD6 V/Io6E26F0lM4PRX50LNm8C2sRbCF1ilBbw4OnHI6sUg98kG/JL1jjyjF6l5riVfNbD+ XrdA==
X-Received: by 10.180.108.3 with SMTP id hg3mr7267542wib.33.1360187328965; Wed, 06 Feb 2013 13:48:48 -0800 (PST)
Received: from [192.168.2.5] ([89.100.140.13]) by mx.google.com with ESMTPS id j9sm5416834wia.5.2013.02.06.13.48.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Feb 2013 13:48:48 -0800 (PST)
Message-ID: <5112CFAF.4000609@gmail.com>
Date: Wed, 06 Feb 2013 21:48:31 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: oauth@ietf.org
References:  <1359995273.56871.YahooMailNeo@web31809.mail.mud.yahoo.com>  <1360173369.63130.YahooMailNeo@web31810.mail.mud.yahoo.com>
In-Reply-To: <1360173369.63130.YahooMailNeo@web31810.mail.mud.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [OAUTH-WG] I'm concerned about how the sniffability of oauth2 requests
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Feb 2013 21:48:51 -0000

On 06/02/13 17:56, William Mills wrote:
> Yes, MAC relies on SSL for transport security. But you have bigger
> problems than that if SSL is broken, because your primary authentication
> credential is compromised now.
>
+1
> Do we need to address sslstrip here if it's a general attack on SSL
> transport for the browser?
When MAC is passed back to the client requesting a token in exchange for 
a grant, no browser is even involved, right ? Besides, one can exchange 
MAC token over two-way TLS in order to authenticate and I guess it is 
much much trickier to have a man in the middle attack with two-way TLS

Cheers, Sergey

>
> ------------------------------------------------------------------------
> *From:* Prabath Siriwardena 
> *To:* William Mills 
> *Cc:* L. Preston Sego III ; "oauth@ietf.org"
> 
> *Sent:* Wednesday, February 6, 2013 8:23 AM
> *Subject:* Re: [OAUTH-WG] I'm concerned about how the sniffability of
> oauth2 requests
>
>
>
> On Mon, Feb 4, 2013 at 9:57 PM, William Mills  > wrote:
>
>     There are two efforts at signed token types: MAC which is still a
>     possibility if we wake up and do it, and the "Holder Of Key" type
>     tokens.
>
>
> If someone can use sslstrip then even MAC is not safe - since MAC key
> needs to be transferred over SSL to the Client from the AS.
>
> There are standard ways in HTTP to avoid or protect from sslstrip - IMHO
> we need to occupy those best practices...
>
> Thanks & regards,
> -Prabath
>
>
>     There are a lot of folks that agree with you.
>
>     ------------------------------------------------------------------------
>     *From:* L. Preston Sego III      >
>     *To:* oauth@ietf.org 
>     *Sent:* Friday, February 1, 2013 7:37 AM
>     *Subject:* [OAUTH-WG] I'm concerned about how the sniffability of
>     oauth2 requests
>
>     In an oauth2 request, the access token is passed along in the
>     header, with nothing else.
>
>     As I understand it, oauth2 was designed to be simple for everyone to
>     use. And while, that's true, I don't really like how all of the
>     security is reliant on SSL.
>
>     what if an attack can strip away SSL using a tool such as sslstrip
>     (or whatever else would be more suitable for modern https)? They
>     would be able to see the access token and start forging whatever
>     request he or she wants to.
>
>     Why not do some sort of RSA-type public-private key thing like back
>     in Oauth1, where there is verification of the payload on each
>     request? Just use a better algorithm?
>
>     _______________________________________________
>     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
>
>
>
>
> --
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From sakimura@gmail.com  Wed Feb  6 17:49:23 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B61D21F8546 for ; Wed,  6 Feb 2013 17:49:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.466
X-Spam-Level: 
X-Spam-Status: No, score=-1.466 tagged_above=-999 required=5 tests=[AWL=0.533,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_210=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7ViYSnpORWB for ; Wed,  6 Feb 2013 17:49:22 -0800 (PST)
Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 62A4821F8545 for ; Wed,  6 Feb 2013 17:49:21 -0800 (PST)
Received: by mail-la0-f54.google.com with SMTP id gw10so2033353lab.41 for ; Wed, 06 Feb 2013 17:49:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jIxmrultPAQ09IV2MgIhEknkdZddU/nB1KcsrBI6Lr0=; b=0Q+8YbWRv6PVB5FX9YuMsnp9Qw6PDF29Vu9nbL9Ove+7/+OW83zmAJltfuR9CN3KvZ iWlse44hpdq95qqwPqIkn6YzqNEPrIF2AbQ1UVjEn39RfHJYdZCRLqcVNETv6lzj7atL IdKhC+MooVd/DoZv4LV80u6enU1klD21aCnbIaislrNMPZiDXefmf3HY8sB5CFo6y2Q9 RpitULqYTMv65WmyiK5RgAi4sSzcKUSW2Wly4Yx0y+UoEfpGotWj75QO+2Kuq0xdd7om 6So884ZIG5y9n9MjTKNVofX/LPfGG6hmpx7/u3EZB2Yw3vyd1vzj1P9+WmRnkss19bVW mQCg==
MIME-Version: 1.0
X-Received: by 10.152.133.52 with SMTP id oz20mr28586785lab.30.1360201759885;  Wed, 06 Feb 2013 17:49:19 -0800 (PST)
Received: by 10.112.6.70 with HTTP; Wed, 6 Feb 2013 17:49:19 -0800 (PST)
In-Reply-To: 
References:  <73B7EC23-AA93-42EE-B3EB-35BA1B82558F@ve7jtb.com> <511175AA.9030301@gmail.com> <1360099372.47338.YahooMailNeo@web31807.mail.mud.yahoo.com>  <59E470B10C4630419ED717AC79FCF9A9483E7B3D@BY2PRD0411MB441.namprd04.prod.outlook.com> <1360111712.54487.YahooMailNeo@web31812.mail.mud.yahoo.com> <59E470B10C4630419ED717AC79FCF9A9483E7E50@BY2PRD0411MB441.namprd04.prod.outlook.com> 
Date: Wed, 6 Feb 2013 18:49:19 -0700
Message-ID: 
From: Nat Sakimura 
To: John Bradley 
Content-Type: multipart/alternative; boundary=f46d0435c24cb888eb04d518a664
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Why OAuth it self is not an authentication framework ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Feb 2013 01:49:23 -0000

--f46d0435c24cb888eb04d518a664
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Lewis,

Specifically, we have defined the following to the id_token.

issREQUIRED. Issuer Identifier for the Issuer of the response.subREQUIRED.
Subject identifier. A locally unique and never reassigned identifier within
the Issuer for the End-User, which is intended to be consumed by the
Client. e.g. 24400320 or AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4. It MUST
NOT exceed 255 ASCII characters in length.audREQUIRED. Audience that this
ID Token is intended for. It MUST contain the OAuth 2.0 client_id of the
Client.azpOPTIONAL. Authorized Party. This member identifies an OAuth 2.0
client authorized to use this ID Token as an OAuth access token. This Claim
is only needed when the Authorized Party is different than the Client that
requested the ID Token. It MUST contain the client_id of the authorized
party.
This 'azp' is the new thing. I proposed it as 'reg' (after 'registered
instrument/token) and Google is using 'cid' (client id) but it ended up
'azp' (authorized party, which I have a hard time remembering :-) So, if
you want to use id_token to authenticate the client to a resource server,
then you put the client_id (that the resource server understands) into azp,
and the identifier of the resource server into aud.

Best,

Nat

2013/2/6 John Bradley 

> Adam,
>
> We have made some changes in the latest draft to address some input from
> Google that I think may also address your need to using the id_token in a=
n
> assertion or possibly as an access token to a federated RS.
>
> I can go over it with you if you like.
>
> John B.
>
> On 2013-02-06, at 9:05 AM, Lewis Adam-CAL022 <
> Adam.Lewis@motorolasolutions.com> wrote:
>
> Hi Bill,****
>
> My reason for using OAuth rather than OIDC is because the id_token in OID=
C
> is audience restricted to the client.  This was clearly intended for WebS=
SO
> / authentication to a client running on a web server.  It does not help t=
he
> case where the user of a RESTful native client want to authenticate to a
> RESTful web service. ****
>
> I agree that OAuth lacks a =93defined=94 way to communicate what is in th=
e AT
> (as OAuth does not define the content of the AT), but within an enterpris=
e
> domain this is easy to solve by profiling.  And in any implementation of
> OAuth on the Internet, the AT must at some level identify the user to the
> RS.  Otherwise how else would the RS know who=92s protected resources the
> client is trying to access?  Now whether the RS learns that through
> introspection or by parsing a JWT-structured AT is of course not defined.
> But at the end of the day, the AT definitely (in all cases that I can thi=
nk
> of) identifies the user. ****
>
> I am open minded to using OIDC if in the future if the client can request
> an id_token that is audience restricted to the RS it is going to
> communicate.  In other words, yes I agree that OIDC is the preferred
> mechanism for performing =93user authentication to a client,=94 but I als=
o
> argue that OAuth is the best method to perform =93user authentication to =
an
> RS=94 (if you want to get your RS out of the password consumption busines=
s).
> I am not at all advocating OAuth for authentication to a client. ****
>
> -adam****
>
> *From:* William Mills [mailto:wmills_92105@yahoo.com]
> *Sent:* Tuesday, February 05, 2013 6:49 PM
> *To:* Lewis Adam-CAL022; Tim Bray
> *Cc:* "WG "@il06exr02.mot.com
> *Subject:* Re: [OAUTH-WG] Why OAuth it self is not an authentication
> framework ?****
> ** **
> Why use OAuth when OpenID does everything that OAuth can do as an
> authentication method and does a few things much better?****
>
> Specifically OAuth lacks any defined way to:****
>
> -    feed back any additional information like the real user ID (as
> opposed to what the entered)****
> -    bound an authentication event in time****
> -    provide any form of additional SSO payload like a display name for
> the user****
>
> there's probably other things.****
>
> It'll mostly work but there are things it doesn't do.  Could you solve
> some of the rest of this with token introspection or a user API that the =
RP
> could use to fetch user info, sure, but why rebuild OpenID when OpenID
> exists?****
>
> -bill****
>
>
> ------------------------------
> *From:* Lewis Adam-CAL022 
> *To:* Tim Bray ; William Mills 
>
> *Cc:* "oauth@ietf.org WG" 
> *Sent:* Tuesday, February 5, 2013 2:27 PM
> *Subject:* RE: [OAUTH-WG] Why OAuth it self is not an authentication
> framework ?****
>
> I think this is becoming a largely academic / philosophical argument by
> this time.  The people who designed OAuth will likely point out that it w=
as
> conceptualized as an authorization protocol to enable a RO to delegate
> access to a client to access its protected resources on some RS.  And of
> course this is the history of it.  And the RO and end-user were typically
> the same entity.  But get caught up in what it was envisioned to do vs.
> real life use cases that OAuth can solve (and is solving) beyond its
> initial use cases misses the point =85 because OAuth is gaining traction =
in
> the enterprise and will be used in all different sorts of ways, including
> authentication. ****
>  ****
> This is especially true of RESTful APIs within an enterprise where the RO
> and end-user are **not** the same: e.g. RO=3Denterprise and
> end-user=3Demployee.  In this model the end-user is not authorizing anyth=
ing
> when their client requests a token from the AS =85 they authenticate to t=
he
> AS and the client gets an AT, which will likely be profiled by most
> enterprise deployments to look something like an OIDC id_token.  The AT
> will be presented to the RS which will examine the claims (user identity,
> LOA, etc.) and make authorization decisions based on business logic.  The
> AT has not authorized the user to do anything, it has only made an
> assertion that the user has been authenticated by the AS (sort of sounds =
a
> lot like an IdP now).****
>  ****
> All this talked of OAuth being authorization and not authentication was
> extremely confusing to me when I first started looking at OAuth for my us=
e
> cases, and I think at some point the authors of OAuth are going to have t=
o
> recognize that their baby has grown up to be multi-faceted (and I mean th=
is
> as a complement).  The abstractions left in the OAuth spec (while some ha=
ve
> claimed of the lack of interoperability it will cause) will also enable i=
t
> to be used in ways possibly still not envisioned by any of us.  I think a=
s
> soon as we can stop trying to draw the artificial line around OAuth being
> =93an authorization protocol=94 the better things will be.****
>  ****
> I like to say that they authors had it right when they named it =93OAuth=
=94
> and not =93OAuthR=94 J****
>  ****
> -adam****
>  ****
> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf
> Of *Tim Bray
> *Sent:* Tuesday, February 05, 2013 3:28 PM
> *To:* William Mills
> *Cc:* oauth@ietf.org WG
> *Subject:* Re: [OAUTH-WG] Why OAuth it self is not an authentication
> framework ?****
>  ****
> OIDC seems about the most plausible candidate for a =93good general
> solution=94 that I=92m aware of.   -T****
> On Tue, Feb 5, 2013 at 1:22 PM, William Mills 
> wrote:****
> There are some specific design mis-matches for OAuth as an authentication
> protocol, it's not what it's designed for and there are some problems you
> will run into.  Some have used it as such, but it's not a good general
> solution.****
>  ****
> -bill****
>  ****
> ------------------------------
> *From:* Paul Madsen 
> *To:* John Bradley 
> *Cc:* "oauth@ietf.org WG" 
> *Sent:* Tuesday, February 5, 2013 1:12 PM
> *Subject:* Re: [OAUTH-WG] Why OAuth it self is not an authentication
> framework ?****
>  ****
> why pigeonhole it?
>
> OAuth can be deployed with no authz semantics at all (or at least as
> little as any authn mechanism), e.g client creds grant type with no scope=
s
>
> I agree that OAuth is not an *SSO* protocol.****
> On 2/5/13 3:36 PM, John Bradley wrote:****
>
> OAuth is an Authorization protocol as many of us have pointed out.****
>  ****
> The post is largely correct and based on one of mine.****
>  ****
> John B.****
>  ****
> On 2013-02-05, at 12:52 PM, Prabath Siriwardena  wrote:=
*
> ***
>  ****
>
> FYI and for your comments..****
>  ****
>
> http://blog.facilelogin.com/2013/02/why-oauth-it-self-is-not-authenticati=
on.html
> ****
>  ****
> Thanks & Regards,
> Prabath****
>  ****
> Mobile : +94 71 809 6732 ****
> http://blog.facilelogin.com/
> http://rampartfaq.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 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
>
>

--=20
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--f46d0435c24cb888eb04d518a664
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Lewis,=A0
Specifically, we have defined the following to=
 the id_token.=A0

iss=

REQUIRED. Issuer Identifier for the Issuer of =
the response.

sub
REQUIRED. Subject identifier. A locall=
y unique and never reassigned identifier within the Issuer for the End-User=
, which is intended to be consumed by the Client. e.g.=A02440032=
0=A0or=A0AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4. It M=
UST NOT exceed 255 ASCII characters in length.
aud
REQUIRED.=
 Audience that this ID Token is intended for. It MUST contain the OAuth 2.0=
=A0client_id=A0of the Client.
azp
OPTIONAL.=
 Authorized Party. This member identifies an OAuth 2.0 client authorized to=
 use this ID Token as an OAuth access token. This Claim is only needed when=
 the Authorized Party is different than the Client that requested the ID To=
ken. It MUST contain the=A0client_id=A0of the authorized pa=
rty.

This 'azp' is the new thing. I propo=
sed it as 'reg' (after 'registered instrument/token) and Google=
 is using 'cid' (client id) but it ended up 'azp' (authoriz=
ed party, which I have a hard time remembering :-) So, if you want to use i=
d_token to authenticate the client to a resource server, then you put the c=
lient_id (that the resource server understands) into azp, and the identifie=
r of the resource server into aud.=A0

Best,=A0
Nat

=

2013/2/6 John Bradley <ve7jtb@ve7jtb.com>

Adam,
We have made s=
ome changes in the latest draft to address some input from Google that I th=
ink may also address your need to using the id_token in an assertion or pos=
sibly as an access token to a federated RS.

I can go over it with you if you like.

John B.

On 2013-02-=
06, at 9:05 AM, Lewis Adam-CAL022 <Adam.Lewis@motorolasolutions.com> w=
rote:

Hi Bill,<=
div style=3D"margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times =
New Roman',serif">
=A0
My reason for =
using OAuth rather than OIDC is because the id_token in OIDC is audience re=
stricted to the client.=A0 This was clearly intended for WebSSO / authentic=
ation to a client running on a web server.=A0 It does not help the case whe=
re the user of a RESTful native client want to authenticate to a RESTful we=
b service.=A0
=A0

I agree that OAuth lacks a =93defined=94 way to communicate what=
 is in the AT (as OAuth does not define the content of the AT), but within =
an enterprise domain this is easy to solve by profiling.=A0 And in any impl=
ementation of OAuth on the Internet, the AT must at some level identify the=
 user to the RS.=A0 Otherwise how else would the RS know who=92s protected =
resources the client is trying to access?=A0 Now whether the RS learns that=
 through introspection or by parsing a JWT-structured AT is of course not d=
efined.=A0 But at the end of the day, the AT definitely (in all cases that =
I can think of) identifies the user.=A0
=A0

I am open minded to using OIDC if in the future if the client ca=
n request an id_token that is audience restricted to the RS it is going to =
communicate.=A0 In other words, yes I agree that OIDC is the preferred mech=
anism for performing =93user authentication to a client,=94 but I also argu=
e that OAuth is the best method to perform =93user authentication to an RS=
=94 (if you want to get your RS out of the password consumption business).=
=A0 I am not at all advocating OAuth for authentication to a client.=A0<=
/u>

=A0

-adam
=
From:=A0William Mills [mailto:wmills_92105@yahoo.com=
]=A0

Sent:=A0Tuesday, February 05, 2013 6:49 PM
To:=A0Lewis Adam-CAL022; Tim Bray
Cc:=A0&=
quot;WG <oauth@ietf.=
org>"@il=
06exr02.mot.com

Subject:=A0Re: [OAUTH-WG] Why OAuth it self is not an a=
uthentication framework ?

=A0
Why use OAuth when OpenID does everyth=
ing that OAuth can do as an authentication method and does a few things muc=
h better?

=A0

Specifically OAuth =
lacks any defined way to:

=A0
-=A0=A0=A0=A0feed back any additional=
 information like the real user ID (as opposed to what the entered)<=
u>

-=A0=A0=A0=A0bound an authenticati=
on event in time

-=A0=A0=A0=A0provide any form of a=
dditional SSO payload like a display name for the user=

=A0

there's probabl=
y other things.

=A0
It'll mostly work but there are things it doesn't do. =
=A0Could you solve some of the rest of this with token introspection or a u=
ser API that the RP could use to fetch user info, sure, but why rebuild Ope=
nID when OpenID exists?

=A0

-bill=
=A0

=A0

From:=A0Le=
wis Adam-CAL022 <Adam.Lewis@motorolasolutions.com>

To:=A0Tim Bray <twbray@google.com>; William Mills <wmills_92105@yahoo.com=
>=A0

Cc:=A0"oauth@ietf.org WG" <oauth@ietf.org>=A0
Sent:=A0Tuesday, February 5, 2013 2:27 PM

Subject:=A0RE: [OAUTH-WG] Why OAuth it self is not an a=
uthentication framework ?

=A0
I think this is becoming a largely academic / phil=
osophical argument by this time.=A0 The people who designed OAuth will like=
ly point out that it was conceptualized as an authorization protocol to ena=
ble a RO to delegate access to a client to access its protected resources o=
n some RS.=A0 And of course this is the history of it.=A0 And the RO and en=
d-user were typically the same entity.=A0 But get caught up in what it was =
envisioned to do vs. real life use cases that OAuth can solve (and is solvi=
ng) beyond its initial use cases misses the point =85 because OAuth is gain=
ing traction in the enterprise and will be used in all different sorts of w=
ays, including authentication.=A0

=A0

This is especially true of RES=
Tful APIs within an enterprise where the RO and end-user are *not* t=
he same: e.g. RO=3Denterprise and end-user=3Demployee.=A0 In this model the=
 end-user is not authorizing anything when their client requests a token fr=
om the AS =85 they authenticate to the AS and the client gets an AT, which =
will likely be profiled by most enterprise deployments to look something li=
ke an OIDC id_token.=A0 The AT will be presented to the RS which will exami=
ne the claims (user identity, LOA, etc.) and make authorization decisions b=
ased on business logic.=A0 The AT has not authorized the user to do anythin=
g, it has only made an assertion that the user has been authenticated by th=
e AS (sort of sounds a lot like an IdP now).

=A0

All this talked of OAuth being=
 authorization and not authentication was extremely confusing to me when I =
first started looking at OAuth for my use cases, and I think at some point =
the authors of OAuth are going to have to recognize that their baby has gro=
wn up to be multi-faceted (and I mean this as a complement).=A0 The abstrac=
tions left in the OAuth spec (while some have claimed of the lack of intero=
perability it will cause) will also enable it to be used in ways possibly s=
till not envisioned by any of us.=A0 I think as soon as we can stop trying =
to draw the artificial line around OAuth being =93an authorization protocol=
=94 the better things will be.

=A0

I like to say that they author=
s had it right when they named it =93OAuth=94 and not =93OAuthR=94=A0=
J

=A0

-adam
=A0

From:=A0oauth-bounces@ietf.org [mailto:oauth-bo=
unces@ietf.org]=A0On Behalf Of=A0Tim B=
ray

Sent:=A0Tuesday, February 05, 2013 3:28 PM
To:=A0William Mills
Cc:=A0oauth@ietf.org WG
Subject:=A0Re: [OAUTH-WG] Why OAuth it self is not an authentication=
 framework ?

=A0

OIDC seems about the most plausible candidate for a =93good general s=
olution=94 that I=92m aware of. =A0 -T

On Tue, Feb 5, 2013 at 1:22 PM, William Mills <wmills_92105@yahoo.com> wrote:
There are some specific design=
 mis-matches for OAuth as an authentication protocol, it's not what it&=
#39;s designed for and there are some problems you will run into. =A0Some h=
ave used it as such, but it's not a good general solution.

=A0

-bill
=A0

From:=A0Paul Madsen <paul.madsen@gmail.com>

To:=A0John Bradley <ve7=
jtb@ve7jtb.com>=A0
Cc:=A0"<=
a href=3D"mailto:oauth@ietf.org" style=3D"color:purple;text-decoration:unde=
rline" target=3D"_blank">oauth@ietf.org=A0WG" <oauth@ietf.org>=A0

Sent:=A0Tuesday, February 5, 2013 1:12 PM
Subject=
:=A0Re: [OAUTH-WG] Why OAuth it self is not an authenticat=
ion framework ?

=A0
why pigeonhole it?=A0<=
br>

OAuth can be deployed with no authz semantics at all (or at least as little=
 as any authn mechanism), e.g client creds grant type with no scopes
I agree that OAuth is not an *SSO* protocol.

On 2/5/13 3:36 PM, John Bradley wro=
te:

OAuth is an Authorization protocol a=
s many of us have pointed out.

=A0
The post is largely correct and based on one of mine.=

=A0

John B.
=A0

On 2013-02-05, at 12:52 PM, Prabath Siriwardena <prabath@wso2.com> wrote:

=A0

FYI and for your comments..
=A0

http:=
//blog.facilelogin.com/2013/02/why-oauth-it-self-is-not-authentication.html=

=A0

Thanks & Regards,
Prabath
=A0

Mobile =
:=A0+94 71 809 6732=A0
http://blog.facilelogin.com/
http://rampartfaq.com/=

_______________________=
________________________
OAuth mailing list
OAuth@ietf.org

https://www.ietf.org/mailma=
n/listinfo/oauth

=A0

=A0_______________________________________________
OAuth mailing li=
st
OAuth@ietf.orghttps://www.ietf.org/=
mailman/listinfo/oauth

=A0

_______________________________________________
OAuth mailing =
list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth ma=
iling list

OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth=

=A0

=A0
_____________________________________=
__________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oau=
th

________________________=
_______________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

-- 
Nat Saki=
mura (=3Dnat)Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--f46d0435c24cb888eb04d518a664--

From Michael.Jones@microsoft.com  Wed Feb  6 18:10:21 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1181D21F84F2 for ; Wed,  6 Feb 2013 18:10:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOe0ECDAq-b2 for ; Wed,  6 Feb 2013 18:10:20 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.31]) by ietfa.amsl.com (Postfix) with ESMTP id 044E521F84ED for ; Wed,  6 Feb 2013 18:10:19 -0800 (PST)
Received: from BL2FFO11FD005.protection.gbl (10.173.161.201) by BL2FFO11HUB015.protection.gbl (10.173.160.107) with Microsoft SMTP Server (TLS) id 15.0.609.9; Thu, 7 Feb 2013 02:10:16 +0000
Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD005.mail.protection.outlook.com (10.173.161.1) with Microsoft SMTP Server (TLS) id 15.0.609.9 via Frontend Transport; Thu, 7 Feb 2013 02:10:16 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.132]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Thu, 7 Feb 2013 02:09:55 +0000
From: Mike Jones 
To: Justin Richer , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-05.txt
Thread-Index: AQHOBKbqNr9jMiD4C0es77r/sOJcE5htSY+AgABS7aA=
Date: Thu, 7 Feb 2013 02:09:55 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394367418E35@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <20130206201534.13236.6681.idtracker@ietfa.amsl.com> <5112BE73.2070003@mitre.org>
In-Reply-To: <5112BE73.2070003@mitre.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.35]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(479174001)(377454001)(377424002)(52604002)(51704002)(13464002)(51444002)(54164002)(189002)(24454001)(199002)(33656001)(54356001)(77982001)(47446002)(59766001)(74502001)(79102001)(46102001)(65816001)(74662001)(66066001)(46406002)(47776003)(53806001)(16406001)(56816002)(80022001)(47736001)(44976002)(56776001)(54316002)(23726001)(55846006)(76482001)(15202345001)(50986001)(31966008)(47976001)(49866001)(20776003)(63696002)(4396001)(5343655001)(51856001)(50466001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB015; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:ErrorRetry; MX:1; A:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0750463DC9
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-05.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Feb 2013 02:10:21 -0000

Hi Justin,

Thanks for working to make progress on the OAuth Registration draft.  Readi=
ng through the changes, it seems to me that a number of changes were made t=
hat there wasn't yet working consensus for - in fact, some of which I don't=
 recall being discussed by the working group at all.  These changes include=
:

  - Splitting the registration endpoint into multiple endpoints
  - Changing from form-encoded to JSON registration representation
  - Adding Get and Delete operations
  - Adding the Self URI concept and representation

My point is separate from whether some of those changes might be good ideas=
.  (Some may be.)  I would hope that in the future, before changes are made=
 to working group drafts, that sufficient time will be first be given to th=
e working group to adequately discuss them and come to agreement on them.

				Thank you,
				-- Mike

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J=
ustin Richer
Sent: Wednesday, February 06, 2013 12:35 PM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-05.txt

Thanks to all of the discussion over the last few weeks and some key input =
from Nat Sakimura, Eve Maler, and others, I've put out a revision of the Dy=
nReg specification that is a major change from recent revisions, but actual=
ly brings it back closer to the original -01 draft.=20
The "operation" parameter is now gone and there are instead several logical=
 endpoints for different kinds of operations. These endpoints are communica=
ted to the client through a well-defined link structure.

It basically works like this:

1. client shows up at the Client Registration Endpoint, posts a JSON object=
 with a few bits of metadata about itself (and potentially presents an Acce=
ss Token that it got from some out of band process that acts as a "class re=
gistration" or "developer key", important to several known real-world use c=
ases)

2. client gets back a JSON object filled with whatever metadata the server =
has about it, including a newly-minted client_id and (possibly) client_secr=
et. The client also gets back a registration access token and a fully quali=
fied URL that points to the "update endpoint". This url can take any form (=
the server can't count on the client being able to generate it from parts),=
 but it's recommended that it follow a REST-style URL template of the form =
"https://server/registration_base_url/client_id".

3. client sends updates to this update URL, authenticated by the registrati=
on access token, by PUTting a JSON object with all of its parameters. Any f=
ields the client leaves off the JSON object, the server leaves alone. Anyth=
ing with a "null" value, the server deletes the value. The server remains f=
ree to override *any* field the client requests setting a particular value =
for. The client is not allowed to request a particular value for the client=
_secret or registration_access_token, for obvious reasons -- but see part 7=
 below.

4. The server responds back with the current state of the client as a JSON =
object, including any fields the server has provisioned on the client's beh=
alf (defaults, for instance). Any fields the server has overridden, it curr=
ently MUST respond with. So if the client asks for
"scope: A B C" and the server can only give it "scope: A B", then the serve=
r has to tell that to the client by including the field "scope: A B" in its=
 response.

5. client can send an HTTP GET to the update URL to get its current state a=
s a JSON object as in 4.

6. client can send an HTTP DELETE to the update URL to deprovision itself.

7. there's also a parallel endpoint for rotating the registration access to=
ken and client secret, since these are both security values that are provis=
ioned by the server. There is some open debate of whether the client actual=
ly needs to be able to trigger this operation, or if the server should just=
 do this as part of normal update/get requests to the update endpoint.

It's a major functionality change on the wire, and there's still sawdust on=
 the spec language. By going with a JSON-based data model and a RESTful upd=
ate protocol, we're getting away from core OAuth patterns, but I think that=
 ultimately this can be a good thing. There have been a few proposals that =
would go somewhere between what OAuth does on other endpoints and what a re=
al RESTful system would do, but I didn't see much purpose in going half way=
 when the results would end up *more* complicated.

I request that everyone read it over to see if this will work for their use=
 cases. The idea here remains that application protocols like OIDC and UMA =
would use this mechanism as-is with nearly all customizations in the client=
 metadata table.

I hope that this all actually makes sense...

  -- Justin

On 02/06/2013 03:15 PM, internet-drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
>   This draft is a work item of the Web Authorization Protocol Working Gro=
up of the IETF.
>
> 	Title           : OAuth Dynamic Client Registration Protocol
> 	Author(s)       : Justin Richer
>                            John Bradley
>                            Michael B. Jones
>                            Maciej Machulak
> 	Filename        : draft-ietf-oauth-dyn-reg-05.txt
> 	Pages           : 21
> 	Date            : 2013-02-06
>
> Abstract:
>     This specification defines an endpoint and protocol for dynamic
>     registration of OAuth Clients at an Authorization Server.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-05
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> 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

From prabath@wso2.com  Wed Feb  6 19:47:09 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69CE721E8049 for ; Wed,  6 Feb 2013 19:47:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.801
X-Spam-Level: 
X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[AWL=0.175,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4d2aVTm3CDt for ; Wed,  6 Feb 2013 19:47:07 -0800 (PST)
Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD3821E8034 for ; Wed,  6 Feb 2013 19:47:06 -0800 (PST)
Received: by mail-ee0-f52.google.com with SMTP id b15so1040326eek.11 for ; Wed, 06 Feb 2013 19:47:05 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=pkub1qxZfr6JnmW6a8u2eu5Jeabw5l/acE6mlhMgFCo=; b=J8WpdCSyqlS6prxWrOh9R/GWvJ3xeUT1g/p+d3TyQGBduSG86am0JlPR16u+nKAakl ZWamXs3tpm2akGfI4S0QVtX5YO5ibMZ/ZVmJqsENgvD/L7bydxYVckUNwBI61TZ5Zgox fk+DXs132BV7z/i/yj5mA7iy/ehiMm32uKLJz450d7ro7AScUZFmHZDSjybrsDreFDVf FHV0Mm7PrypTDxXWEBpLwWosrXfBl2UKG4cQ8Q4vVS3Bmt2SpxBEzho7sVGBoxJmcyVO Fwqx+2/pEHFdKPkIwMrVQCMmFph0EjFiPP+RJQPL26MTzn0VsYZo4ydlGZo3FgQhl9Ot M2qQ==
MIME-Version: 1.0
X-Received: by 10.14.202.197 with SMTP id d45mr58932569eeo.1.1360208825032; Wed, 06 Feb 2013 19:47:05 -0800 (PST)
Received: by 10.223.175.134 with HTTP; Wed, 6 Feb 2013 19:47:04 -0800 (PST)
In-Reply-To: <5112AE0B.1080501@mitre.org>
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com> <5112AE0B.1080501@mitre.org>
Date: Thu, 7 Feb 2013 09:17:04 +0530
Message-ID: 
From: Prabath Siriwardena 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=047d7b343b06d61fc704d51a4b4f
X-Gm-Message-State: ALoCoQnEy6hGb15ITVgHThV71NHnlJ/Vta4Sf/Z4GohezNexo0/+1yEc3JcYrJBwqIlo6Ujo2MSS
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Feb 2013 03:47:09 -0000

--047d7b343b06d61fc704d51a4b4f
Content-Type: text/plain; charset=ISO-8859-1

Hi Justin,

I believe this is addressing one of the key missing part in OAuth 2.0...

One question - I guess this was discussed already...

In the spec - in the introspection response it has the attribute "valid" -
this is basically the validity of the token provided in the request.

Validation criteria depends on the token and well as token type ( Bearer,
MAC..).

In the spec it seems like it's coupled with Bearer token type... But I
guess, by adding "token_type" to the request we can remove this dependency.

WDYT..?

Thanks & regards,
-Prabath

On Thu, Feb 7, 2013 at 12:54 AM, Justin Richer  wrote:

>  Updated introspection draft based on recent comments. Changes include:
>
>  - "scope" return parameter now follows RFC6749 format instead of JSON
> array
>  - "subject" -> "sub", and "audience" -> "aud", to be parallel with JWT
> claims
>  - clarified what happens if the authentication is bad
>
>  -- Justin
>
>
> -------- Original Message --------  Subject: New Version Notification for
> draft-richer-oauth-introspection-02.txt  Date: Wed, 6 Feb 2013 11:24:20
> -0800  From:    To:
>  
>
> A new version of I-D, draft-richer-oauth-introspection-02.txt
> has been successfully submitted by Justin Richer and posted to the
> IETF repository.
>
> Filename:	 draft-richer-oauth-introspection
> Revision:	 02
> Title:		 OAuth Token Introspection
> Creation date:	 2013-02-06
> WG ID:		 Individual Submission
> Number of pages: 6
> URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
> Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
> Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-02
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02
>
> Abstract:
>    This specification defines a method for a client or protected
>    resource to query an OAuth authorization server to determine meta-
>    information about an OAuth token.
>
>
>
>
>
> The IETF Secretariat
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.com

--047d7b343b06d61fc704d51a4b4f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Justin,
I believe this is addressing one of the key m=
issing part in OAuth 2.0...

One question - I guess=
 this was discussed already...

In the spec - in th=
e introspection response it has the attribute "valid" - this is b=
asically the validity of the token provided in the request.

Validation=A0criteria depends on the token and well as =
token type ( Bearer, MAC..).

In the spec it seems =
like it's coupled with Bearer token type... But I guess, by adding &quo=
t;token_type" to the request we can remove this dependency.

WDYT..?

Thanks & regards,<=
/div>-Prabath=A0

On Thu, Feb =
7, 2013 at 12:54 AM, Justin Richer <jricher@mitre.org> wrote=
:

 =20

   =20
 =20

    Updated introspection draft based on recent comments. Changes
    include:

    =A0- "scope" return parameter now follows RFC6749 format inst=
ead of
    JSON array

    =A0- "subject" -> "sub", and "audience"=
; -> "aud", to be parallel
    with JWT claims

    =A0- clarified what happens if the authentication is bad

    =A0-- Justin

      -------- Original Message --------

            Subject:

            New Version Notification for
              draft-richer-oauth-introspection-02.txt

            Date: 
            Wed, 6 Feb 2013 11:24:20 -0800

            From: 
            <internet-drafts@ietf.org>

            To: 
            <=
jricher@mitre.org>

      A new version of I-D, draft-richer-oauth-introspection-02.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 02
Title:		 OAuth Token Introspection
Creation date:	 2013-02-06
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/interne=
t-drafts/draft-richer-oauth-introspection-02.txt
Status:          http://datatracker.ietf.org/doc/draft-=
richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-=
oauth-introspection-02
Diff:            http://www.ietf.org/rfcdiff?url2=
=3Ddraft-richer-oauth-introspection-02

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.

                                                                           =
      =20

The IETF Secretariat

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

-- 
Thanks &=
amp; Regards,
Prabath
Mobile : +94 71 809 6732=A0
=

http://blog.f=
acilelogin.com

http://RampartFAQ.com

--047d7b343b06d61fc704d51a4b4f--

From zhou.sujing@zte.com.cn  Wed Feb  6 23:20:29 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A6521F868B; Wed,  6 Feb 2013 23:20:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.395
X-Spam-Level: 
X-Spam-Status: No, score=-98.395 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2kHH6fhXwXD; Wed,  6 Feb 2013 23:20:28 -0800 (PST)
Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 931C521F8684; Wed,  6 Feb 2013 23:20:27 -0800 (PST)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 748DD192AE99; Thu,  7 Feb 2013 15:19:57 +0800 (CST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id D4278174A4C3; Thu,  7 Feb 2013 15:20:04 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id r177JxID084759; Thu, 7 Feb 2013 15:19:59 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: 
To: Prabath Siriwardena 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: zhou.sujing@zte.com.cn
Date: Thu, 7 Feb 2013 15:19:48 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-02-07 15:19:54, Serialize complete at 2013-02-07 15:19:54
Content-Type: multipart/alternative; boundary="=_alternative 0028506D48257B0B_="
X-MAIL: mse01.zte.com.cn r177JxID084759
Cc: "oauth@ietf.org WG" , "oauth-bounces@ietf.org" 
Subject: Re: [OAUTH-WG] A question on token revocation.
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Feb 2013 07:20:29 -0000

This is a multipart message in MIME format.
--=_alternative 0028506D48257B0B_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

SSBndWVzcyBSTyBjb3VsZCBpbml0aWF0ZSBhY2Nlc3MgdG9rZW4gcmV2b2NhdGlvbiBmb3IgYSBj
bGllbnQgYnkgDQppbmNsdWRpbmcgYXV0aG9yaXphdGlvbiBjb2RlIGluIHRoZSByZXF1ZXN0IHRv
IEFTLg0KQ29tbWVudHM/IA0KDQoNCg0Kb2F1dGgtYm91bmNlc0BpZXRmLm9yZyDQtNPaIDIwMTMt
MDItMDcgMDI6MzI6Mjg6DQoNCj4gSGkgVG9yc3RlbiwNCj4gDQo+IFRoYW5rcyBmb3IgeW91ciBm
ZWVkYmFjay4uIEkgd2lsbCBzdWJtaXQgYSBkcmFmdC4uLg0KPiANCj4gVGhhbmtzICYgcmVnYXJk
cywNCj4gLVByYWJhdGgNCg0KPiBPbiBXZWQsIEZlYiA2LCAyMDEzIGF0IDExOjU1IFBNLCBUb3Jz
dGVuIExvZGRlcnN0ZWR0IA0KPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0DQo+ID4gd3JvdGU6DQo+
IEhpIFByYWJhdGgsDQo+IA0KPiB3ZSB0cmllZCB0byBhZGRyZXNzIGJvdGggdXNlIGNhc2VzIGlu
IHRoZSBmaXJzdCByZXZpc2lvbnMgb2YgdGhlIA0KPiBkcmFmdC4gVGhlIEFQSSB3YXMgd2VsbCBz
dWl0ZWQgZm9yIGNsaWVudC1kcml2ZW4gcmV2b2NhdGlvbiBidXQgbm90IA0KPiB0aGUgcmVzb3Vy
Y2Ugb3duZXIgLSBkcml2ZW4gdXNlIGNhc2UuIFRoZXJlIGFyZSBkZWZpbml0ZWx5IA0KPiBkaWZm
ZXJlbmNlcyB3aXRoIHJlc3BlY3QgdG8gdGhlIHByb3RvY29sIGRlc2lnbiwgYXQgbGVhc3QgcmVn
YXJkaW5nIA0KPiBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBvZiB0aGUgcmVzcGVj
dGl2ZSBhY3RvcnMuIFRoaXMgbWFkZQ0KPiB0aGUgc3BlYyBtb3JlIGNvbXBsZXggYW5kIGNhdXNl
ZCBhbWJpZ3VpdGllcyBhbmQgY29uZnVzaW9uLiANCj4gTW9yZW92ZXIsIHRoZSB3b3JraW5nIGdy
b3VwIHNlZW1lZCBub3QgY29udmluY2VkIGJ5IHRoZSB0aGUgbGF0dGVyIHVzZSANCmNhc2UuDQo+
IA0KPiBUaGVyZWZvcmUgdGhlIHdvcmtpbmcgZ3JvdXAgZGVjaWRlZCB0byBmb2N1cyBvbiB0aGUg
c2luZ2xlIHVzZSBjYXNlcw0KPiBvZiB0aGUgcmV2b2NhdGlvbiBieSBjbGllbnRzLiBUaGlzIG1h
a2VzIGEgbG90IG9mIHNlbnNlIHNpbmNlIHRoaXMgDQo+IGludGVyZmFjZSBpcyBtb3N0IGltcG9y
dGFudCB3aXRoIHJlc3BlY3QgdG8gaW50ZXJvcGVyYWJpbGl0eS4NCj4gDQo+IEknbSBmb2N1c2lu
ZyByaWdodCBub3cgb24gZmluaXNoaW5nIHRoaXMgZHJhZnQuIEFuZCB0aGUgb3BlbiBpc3N1ZXMg
DQo+IGRpc2N1c3NlZCBvbiB0aGUgbGlzdCBpbiB0aGUgbGFzdCBjb3VwbGUgb2Ygd2Vla3MgaWxs
dXN0cmF0ZSB0aGF0IA0KPiBldmVuIHRoaXMgcG9zZXMgYSBjb25zaWRlcmFibGUgYW1vdW50IG9m
IHdvcmsuIFNvIEknbSB2ZXJ5IHJlbHVjdGFudA0KPiB0byBhZGQgc3VwcG9ydCBmb3IgYSB3aG9s
ZSBuZXcgdXNlIGNhc2UgYXQgdGhhdCBwb2ludCBvZiB0aGUgcHJvY2Vzcy4NCj4gDQo+IElmIHlv
dSBmZWVsIHRoaXMgaXMgYW4gaW1wb3J0YW50IHVzZSBjYXNlIHdvcnRoIGFuIFJGQywgZG9uJ3Qg
DQo+IGhlc2l0YXRlIHRvIHB1Ymxpc2ggYSBuZXcgSS1ELg0KPiANCj4gcmVnYXJkcywNCj4gVG9y
c3Rlbi4NCj4gDQo+IEFtIDA2LjAyLjIwMTMgdW0gMTY6Mzcgc2NocmllYiBQcmFiYXRoIFNpcml3
YXJkZW5hIDxwcmFiYXRoQHdzbzIuY29tPjoNCg0KPiANCg0KPiBPbiBXZWQsIEZlYiA2LCAyMDEz
IGF0IDk6MDQgUE0sIFRvZGQgVyBMYWluaGFydCA8bGFpbmhhcnRAdXMuaWJtLmNvbT4gDQp3cm90
ZToNCj4gPiBSZXNvdXJjZSBvd25lciBuZWVkcyB0byBrbm93IHRoZSBjb25zdW1lciBrZXkgKHJl
cHJlc2VudHMgdGhlIA0KPiBPQXV0aCBDbGllbnQgYXBwKSAmIHNjb3BlIHRvIHJldm9rZSB0aGUg
YWNjZXNzIHRva2VuIGZvciBhIGdpdmVuIA0KY2xpZW50LiAgDQoNCj4gSSBzZWUgLSB5b3UncmUg
c2F5aW5nIHRoYXQgcmVxdWlyaW5nIGNsaWVudCBjcmVkZW50aWFscyBvbiB0aGUgZW5kIA0KPiBw
b2ludCBpcyB0aGUgcHJvYmxlbT8NCj4gDQo+IEluIGZhY3Qgd2hhdCBJIG1lYW50IHdhcyAtIHdo
ZW4gUk8gYXV0aG9yaXplcyB0aGUgYW4gYWNjZXNzIHRva2VuIA0KPiBmb3IgY2xpZW50IGZvciBw
YXJ0aWN1bGFyIHNjb3BlLiBUaG9zZSBpbmZvcm1hdGlvbiBhcmUga2VwdCBhdCB0aGUgQVMuDQo+
IA0KPiBOb3cgLSBpZiB0aGUgUk8gd2FudCB0byByZXZva2UgYWNjZXNzIGZyb20gdGhlIGNsaWVu
dCAtIHRoZSBSTyBuZWVkcw0KPiB0byBhdXRoZW50aWNhdGUgaGltIHNlbGYgdG8gdGhlIEFTIGFu
ZCBwYXNzIHRoZSBjb25zdW1lciBrZXkgYW5kIHRoZQ0KPiBzY29wZS4gU28gQVMgY2FuIHJldm9r
ZSBhY2Nlc3MuDQo+IA0KPiBUaGFua3MgJiByZWdhcmRzLA0KPiAtUHJhYmF0aA0KPiAgDQo+IA0K
PiANCj4gDQo+IA0KPiBUb2RkIExhaW5oYXJ0DQo+IFJhdGlvbmFsIHNvZnR3YXJlDQo+IElCTSBD
b3Jwb3JhdGlvbg0KPiA1NTAgS2luZyBTdHJlZXQsIExpdHRsZXRvbiwgTUEgMDE0NjAtMTI1MA0K
PiAxLTk3OC04OTktNDcwNQ0KPiAyLTI3Ni00NzA1IChUL0wpDQo+IGxhaW5oYXJ0QHVzLmlibS5j
b20NCj4gDQo+IA0KPiANCj4gDQo+IA0KDQo+IEZyb206ICAgICAgICBQcmFiYXRoIFNpcml3YXJk
ZW5hIDxwcmFiYXRoQHdzbzIuY29tPiANCj4gVG86ICAgICAgICBKdXN0aW4gUmljaGVyIDxqcmlj
aGVyQG1pdHJlLm9yZz4sIA0KPiBDYzogICAgICAgICJvYXV0aEBpZXRmLm9yZyBXRyIgPG9hdXRo
QGlldGYub3JnPiANCj4gRGF0ZTogICAgICAgIDAyLzA2LzIwMTMgMTA6MzEgQU0gDQo+IFN1Ympl
Y3Q6ICAgICAgICBSZTogW09BVVRILVdHXSBBIHF1ZXN0aW9uIG9uIHRva2VuIHJldm9jYXRpb24u
IA0KPiBTZW50IGJ5OiAgICAgICAgb2F1dGgtYm91bmNlc0BpZXRmLm9yZyANCj4gDQo+IA0KPiAN
Cj4gDQoNCj4gT24gV2VkLCBGZWIgNiwgMjAxMyBhdCA4OjQ5IFBNLCBKdXN0aW4gUmljaGVyIDxq
cmljaGVyQG1pdHJlLm9yZz4gd3JvdGU6IA0KDQo+IA0KPiBPbiAwMi8wNi8yMDEzIDEwOjEzIEFN
LCBQcmFiYXRoIFNpcml3YXJkZW5hIHdyb3RlOiANCj4gDQo+IA0KPiBPbiBXZWQsIEZlYiA2LCAy
MDEzIGF0IDg6MTkgUE0sIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0cmUub3JnPiB3cm90ZTog
DQoNCj4gVGhlc2UgYXJlIGdlbmVyYWxseSBoYW5kbGVkIHRocm91Z2ggYSB1c2VyIGludGVyZmFj
ZSB3aGVyZSB0aGUgUk8gaXMNCj4gYXV0aGVudGljYXRlZCBkaXJlY3RseSB0byB0aGUgQVMsIGFu
ZCB0aGVyZSdzIG5vdCBtdWNoIG5lZWQgZm9yIGEgDQo+ICJwcm90b2NvbCIgaGVyZSwgaW4gcHJh
Y3RpY2UuIA0KPiANCj4gV2h5IGRvIHlvdSB0aGluayBsZWF2aW5nIGFjY2VzcyB0b2tlbiByZXZv
Y2F0aW9uIGJ5IFJPIHRvIGEgDQo+IHByb3ByaWV0YXJ5IEFQSSBpcyBhIGdvb2QgcHJhY3RpY2Ug
PyBJTU8gdGhpcyBhbiBlc3NlbnRpYWwgDQo+IHJlcXVpcmVtZW50IGluIEFQSSBzZWN1cml0eS4g
DQo+IEkgdGhpbmsgaXQgbWFrZXMgbW9yZSBzZW5zZSBpbiB0aGUgc2FtZSB3YXkgdGhhdCBoYXZp
bmcgYSANCj4gInByb3ByaWV0YXJ5IiBVSS9BUEkgZm9yIG1hbmFnaW5nIHRoZSB1c2VyIGNvbnNl
bnQgbWFrZXMgc2Vuc2U6IA0KPiB1bmxlc3MgeW91J3JlIGRvaW5nIGEgZnVsbHkgZHluYW1pYyBl
bmQtdG8tZW5kIHN5c3RlbSBsaWtlIFVNQSwgdGhlbg0KPiB0aGVyZSdzIG5vdCBtdWNoIHZhbHVl
IGluIHRyeWluZyB0byBzcXVlZXplIGRpc3BhcmF0ZSBzeXN0ZW1zIGludG8gDQo+IHRoZSBzYW1l
IG1vbGQsIHNpbmNlIHRoZXkgd29uJ3QgYmUgdGFsa2luZyB0byBlYWNoIG90aGVyIGFueXdheS4g
DQo+IA0KPiBUaGlzIGlzIHJlcXVpcmVkIGluIGRpc3RyaWJ1dGVkIHNldHVwIGZvciBlYWNoIEFQ
SSBwbGF0Zm9ybSBmcm9tIA0KPiBkaWZmZXJlbnQgdmVuZG9ycyB0byBwZXJmb3JtIGluIGFuIGlu
dGVyb3AgbWFubmVyLiANCj4gICANCj4gDQo+IEFuZCBzaW5jZSB5b3UgcmVmZXIgdG8gaXQgYXMg
YW4gIkFQSSIsIHdoYXQgd2lsbCB0aGUgUk8gYmUgdXNpbmcgdG8gDQo+IGNhbGwgdGhpcyBBUEk/
IElzIHRoZXJlIGEgdG9rZW4gbWFuYWdlbWVudCBjbGllbnQgdGhhdCdzIHNlcGFyYXRlIA0KPiBm
cm9tIHRoZSBPQXV0aCBjbGllbnQ/IA0KPiANCj4gSSBkaWRuJ3QgZ2V0IHlvdXIgcXVlc3Rpb24g
cmlnaHQuLi4gSWYgeW91IG1lYW50IHRoZSBob3cgdG8gaW52b2tlIA0KPiByZXZvY2F0aW9uIGVu
ZCBwb2ludCwgdGhlIHRoZSByZXNvdXJjZSBvd25lciBuZWVkcyB0byBrbm93IHRoZSANCj4gY29u
c3VtZXIga2V5IChyZXByZXNlbnRzIHRoZSBPQXV0aCBDbGllbnQgYXBwKSAmIHNjb3BlIHRvIHJl
dm9rZSB0aGUNCj4gYWNjZXNzIHRva2VuIGZvciBhIGdpdmVuIGNsaWVudC4gIA0KPiANCj4gDQo+
IA0KPiBJTUhPIHRva2VuIHJldm9jYXRpb24gZG9uZSBteSBSTyBpcyBtb3JlIHByYWN0aWNhbCB0
aGFuIHRva2VuIA0KPiByZXZvY2F0aW9uIGRvbmUgYnkgdGhlIENsaWVudC4gDQo+IFRoZXkncmUg
Ym90aCB2YWxpZCBidXQgcmVxdWlyZSBkaWZmZXJlbnQga2luZHMgb2YgcHJvdG9jb2xzIGFuZCAN
Cj4gY29uc2lkZXJhdGlvbnMuIFRoaXMgdG9rZW4gcmV2b2NhdGlvbiBkcmFmdCBpcyBtZWFudCB0
byBzb2x2ZSBvbmUgDQo+IHByb2JsZW0sIGFuZCB0aGF0IGRvZXNuJ3QgbWVhbiBpdCBjYW4gb3Ig
c2hvdWxkIHNvbHZlIG90aGVyIA0KPiBzZWVtaW5nbHkgcmVsYXRlZCBwcm9ibGVtcy4NCj4gDQo+
IElmIHlvdSB3b3VsZCBsaWtlIHRvIHNlZSB0aGUgUk8taW5pdGlhdGVkIHRva2VuIHJldm9jYXRp
b24gZ28gDQo+IHRocm91Z2ggKG5vdCBncmFudCByZXZvY2F0aW9uLCBtaW5kIHlvdSAtLSB0aGF0
J3MgcmVsYXRlZCwgYnV0IA0KPiBkaWZmZXJlbnQpLCB0aGVuIEkgd291bGQgc3VnZ2VzdCB0aGF0
IHlvdSBzdGFydCBzcGVjaWZ5aW5nIGV4YWN0bHkgDQo+IGhvdyB0aGF0IHdvcmtzLiBJIHByZWRp
Y3QgaXQgd2lsbCBiZSBwcm9ibGVtYXRpYyBpbiBwcmFjdGljZSwgDQo+IHRob3VnaCwgYXMgdGhl
IFJPIG9mdGVuIGRvZXNuJ3QgYWN0dWFsbHkgaGF2ZSBkaXJlY3QgYWNjZXNzIHRvIHRoZSANCj4g
dG9rZW4gaXRzZWxmLiANCj4gDQo+IFJlc291cmNlIG93bmVyIG5lZWRzIHRvIGtub3cgdGhlIGNv
bnN1bWVyIGtleSAocmVwcmVzZW50cyB0aGUgT0F1dGggDQo+IENsaWVudCBhcHApICYgc2NvcGUg
dG8gcmV2b2tlIHRoZSBhY2Nlc3MgdG9rZW4gZm9yIGEgZ2l2ZW4gY2xpZW50LiAgDQo+IA0KPiAg
IA0KPiANCj4gICANCj4gVGhlcmUgYXJlIGxhcmdlciBhcHBsaWNhdGlvbnMsIGxpa2UgVU1BLCB0
aGF0IGhhdmUgY2xpZW50IGFuZCBQUiANCj4gcHJvdmlzaW9uaW5nIHRoYXQgd291bGQgYWxsb3cg
Zm9yIHRoaXMgdG8gYmUgbWFuYWdlZCBzb21ld2hhdCANCj4gcHJvZ3JhbW1hdGljYWxseSwgYnV0
IGV2ZW4gaW4gdGhhdCBjYXNlIHlvdSdyZSBzdGlsbCBnZW5lcmFsbHkgZG9pbmcNCj4gdG9rZW4g
cmV2b2NhdGlvbiBieSBhICJjbGllbnQiIGluIHNvbWUgZmFzaGlvbi4gSW4gVU1BLCB0aG91Z2gs
IA0KPiBzZXZlcmFsIGRpZmZlcmVudCBwaWVjZXMgY2FuIHBsYXkgdGhlIHJvbGUgb2YgYSAiY2xp
ZW50IiBhdCANCj4gZGlmZmVyZW50IHBhcnRzIG9mIHRoZSBwcm9jZXNzLg0KPiANCj4gUmV2b2tp
bmcgYSBzY29wZSBpcyBhIHdob2xlIGRpZmZlcmVudCBtZXNzLiBHZW5lcmFsbHksIHlvdSdkIHdh
bnQgdG8NCj4ganVzdCByZXZva2UgYW4gZXhpc3RpbmcgdG9rZW4gYW5kIG1ha2UgYSBuZXcgYXV0
aG9yaXphdGlvbiBncmFudCANCj4gd2l0aCBsb3dlciBhY2Nlc3MgaWYgeW91IGRvbid0IHdhbnQg
dGhhdCBjbGllbnQgZ2V0dGluZyB0aGF0IHNjb3BlIA0KPiBhbnltb3JlLiBJZiB5b3UganVzdCB3
YW50IHRvIGRvd25zY29wZSBmb3IgYSBzaW5nbGUgdHJhbnNhY3Rpb24sIHlvdQ0KPiBjYW4gYWxy
ZWFkeSBkbyB0aGF0IHdpdGggZWl0aGVyIHRoZSByZWZyZXNoIHRva2VuIG9yIHRva2VuIGNoYWlu
aW5nIA0KPiBhcHByb2FjaGVzLCBkZXBlbmRpbmcgb24gd2hlcmUgaW4gdGhlIHByb2Nlc3MgeW91
IGFyZS4gVGhlIGxhdHRlciBvZg0KPiB0aGVzZSBhcmUgYm90aCBjbGllbnQtZm9jdXNlZCwgdGhv
dWdoLCBhbmQgdGhlIFJPIGRvZXNuJ3QgaGF2ZSBhIA0KPiBkaXJlY3QgaGFuZCBpbiBpdCBhdCB0
aGlzIHBvaW50LiANCj4gDQo+IFdoeSBkbyB5b3UgdGhpbmsgaXQgYSBtZXNzLiBJZiB5b3UgcmV2
b2tlIHRoZSBlbnRpcmUgdG9rZW4gdGhlbiANCj4gQ2xpZW50IG5lZWRzIHRvIGdvIHRocm91Z2gg
dGhlIGNvbXBsZXRlIE9BdXRoIGZsb3cgLSBhbmQgYWxzbyBuZWVkcyANCj4gdG8gZ2V0IHRoZSB1
c2VyIGNvbnNlbnQuIElmIFJPIGNhbiAgZG93bmdyYWRlIHRoZSBzY29wZSwgdGhlbiB3ZSANCj4g
cmVzdHJpY3QgQVBJIGFjY2VzcyBieSB0aGUgY2xpZW50IGF0IFJTIGVuZCBhbmQgaXRzIHRyYW5z
cGFyZW50IHRvIA0KPiB0aGUgY2xpZW50LiANCj4gDQo+IA0KPiBEb3duZ3JhZGluZyB0aGUgc2Nv
cGUgb2YgdG9rZW5zIGluIHRoZSB3aWxkIGlzIGhhcmRseSB0cmFuc3BhcmVudCB0bw0KPiB0aGUg
Y2xpZW50IChzdHVmZiB0aGF0IGl0IGV4cGVjdHMgdG8gd29yayB3aWxsIHN1ZGRlbmx5IHN0YXJ0
IHRvIA0KPiBmYWlsLCBtZWFuaW5nIHRoYXQgbW9zdCBjbGllbnRzIHdpbGwgdGhyb3cgb3V0IHRo
ZSB0b2tlbiBhbmQgdHJ5IHRvIA0KPiBnZXQgYSBuZXcgb25lKSwgYW5kIGluIGEgZGlzdHJpYnV0
ZWQgc3lzdGVtIHlvdSd2ZSBnb3QgdG8gcHJvcGFnYXRlIA0KPiB0aGF0IGNoYW5nZSB0byB0aGUg
UlMuIElmIHlvdSBiYWtlIHRoZSBzY29wZXMgaW50byB0aGUgdG9rZW4gaXRzZWxmIA0KPiAod2hp
Y2ggbWFueSBkbykgdGhlbiB5b3UgYWN0dWFsbHkgKmNhbid0KiBkb3duZ3JhZGUgYSBzaW5nbGUg
dG9rZW4sIA0KYW55d2F5LiANCj4gDQo+IFllcy4uIHRoYXQgaXMgdGhlIGV4cGVjdGVkIGJlaGF2
aW9yLiBJIG1lYW4gdGhlIHByb2Nlc3MgaXMgDQo+IHRyYW5zcGFyZW50LiBDbGllbnQgd2lsbCBu
b3RpY2UgYXQgcnVudGltZS4gDQo+IA0KPiBUaGFua3MgJiByZWdhcmRzLCANCj4gLVByYWJhdGgg
DQo+ICAgDQo+IA0KPiAgLS0gSnVzdGluIA0KPiANCj4gDQo+IFRoYW5rcyAmIHJlZ2FyZHMsIA0K
PiAtUHJhYmF0aCANCj4gICANCj4gDQo+IA0KPiAgLS0gSnVzdGluIA0KPiANCj4gDQo+IE9uIDAy
LzA2LzIwMTMgMDQ6MzUgQU0sIFByYWJhdGggU2lyaXdhcmRlbmEgd3JvdGU6IA0KPiBJIGFtIHNv
cnJ5IGlmIHRoaXMgd2FzIGFscmVhZHkgZGlzY3Vzc2VkIGluIHRoaXMgbGlzdC4uICANCj4gDQo+
IExvb2tpbmcgYXQgWzFdIGl0IG9ubHkgdGFsa3MgYWJvdXQgcmV2b2tpbmcgdGhlIGFjY2VzcyB0
b2tlbiBmcm9tIHRoZSANCmNsaWVudC4gDQo+IA0KPiBIb3cgYWJvdXQgdGhlIHJlc291cmNlIG93
bmVyLi4/IA0KPiANCj4gVGhlcmUgY2FuIGJlIGNhc2VzIHdoZXJlIHJlc291cmNlIG93bmVyIG5l
ZWRzIHRvIHJldm9rZSBhbiANCj4gYXV0aG9yaXplZCBhY2Nlc3MgdG9rZW4gZnJvbSBhIGdpdmVu
IGNsaWVudC4gT3IgcmV2b2tlIGFuIHNjb3BlLi4gDQo+IA0KPiBIb3cgYXJlIHdlIGdvaW5nIHRv
IGFkZHJlc3MgdGhlc2UgcmVxdWlyZW1lbnRzLi4/IFRob3VnaHRzIA0KYXBwcmVjaWF0ZWQuLi4g
DQo+IA0KPiBbMV0gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1y
ZXZvY2F0aW9uLTA0IA0KPiANCj4gLS0gDQo+IFRoYW5rcyAmIFJlZ2FyZHMsDQo+IFByYWJhdGgg
DQo+IA0KPiBNb2JpbGUgOiArOTQgNzEgODA5IDY3MzIgDQo+IA0KPiBodHRwOi8vYmxvZy5mYWNp
bGVsb2dpbi5jb20NCj4gaHR0cDovL1JhbXBhcnRGQVEuY29tIA0KPiANCj4gDQo+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9BdXRoIG1haWxpbmcg
bGlzdA0KPiBPQXV0aEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29hdXRoDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gLS0gDQo+IFRoYW5rcyAmIFJlZ2Fy
ZHMsDQo+IFByYWJhdGggDQo+IA0KPiBNb2JpbGUgOiArOTQgNzEgODA5IDY3MzIgDQo+IA0KPiBo
dHRwOi8vYmxvZy5mYWNpbGVsb2dpbi5jb20NCj4gaHR0cDovL1JhbXBhcnRGQVEuY29tIA0KPiAN
Cj4gDQo+IA0KPiANCj4gLS0gDQo+IFRoYW5rcyAmIFJlZ2FyZHMsDQo+IFByYWJhdGggDQo+IA0K
PiBNb2JpbGUgOiArOTQgNzEgODA5IDY3MzIgDQo+IA0KPiBodHRwOi8vYmxvZy5mYWNpbGVsb2dp
bi5jb20NCj4gaHR0cDovL1JhbXBhcnRGQVEuY29tX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGlldGYu
b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KPiAN
Cg0KPiANCj4gLS0gDQo+IFRoYW5rcyAmIFJlZ2FyZHMsDQo+IFByYWJhdGgNCj4gDQo+IE1vYmls
ZSA6ICs5NCA3MSA4MDkgNjczMiANCj4gDQo+IGh0dHA6Ly9ibG9nLmZhY2lsZWxvZ2luLmNvbQ0K
PiBodHRwOi8vUmFtcGFydEZBUS5jb20NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGlldGYub3Jn
DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4gDQoNCj4g
DQo+IC0tIA0KPiBUaGFua3MgJiBSZWdhcmRzLA0KPiBQcmFiYXRoDQo+IA0KPiBNb2JpbGUgOiAr
OTQgNzEgODA5IDY3MzIgDQo+IA0KPiBodHRwOi8vYmxvZy5mYWNpbGVsb2dpbi5jb20NCj4gaHR0
cDovL1JhbXBhcnRGQVEuY29tX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGlldGYub3JnDQo+IGh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K
--=_alternative 0028506D48257B0B_=
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgZ3Vlc3MgUk8gY291bGQgaW5p
dGlhdGUgYWNjZXNzIHRva2VuDQpyZXZvY2F0aW9uIGZvciBhIGNsaWVudCBieSBpbmNsdWRpbmcg
YXV0aG9yaXphdGlvbiBjb2RlIGluIHRoZSByZXF1ZXN0DQp0byBBUy48L2ZvbnQ+DQo8YnI+PGZv
bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkNvbW1lbnRzPyA8L2ZvbnQ+DQo8YnI+DQo8YnI+
DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5vYXV0aC1ib3VuY2VzQGlldGYub3JnIOWGmeS6
jiAyMDEzLTAyLTA3IDAyOjMyOjI4Ojxicj4NCjxicj4NCiZndDsgSGkmbmJzcDtUb3JzdGVuLDwv
Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFRoYW5rcyBm
b3IgeW91ciBmZWVkYmFjay4uIEkgd2lsbCBzdWJtaXQgYSBkcmFmdC4uLjwvZm9udD48L3R0Pg0K
PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFRoYW5rcyAmYW1wOyByZWdhcmRz
LDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAtUHJhYmF0aDxicj4NCjwv
Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBPbiBXZWQsIEZlYiA2LCAyMDEz
IGF0IDExOjU1IFBNLCBUb3JzdGVuIExvZGRlcnN0ZWR0DQombHQ7dG9yc3RlbkBsb2RkZXJzdGVk
dC5uZXQ8YnI+DQomZ3Q7ICZndDsgd3JvdGU6PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp
emU9Mj4mZ3Q7IEhpIFByYWJhdGgsPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m
Z3Q7IDxicj4NCiZndDsgd2UgdHJpZWQgdG8gYWRkcmVzcyBib3RoIHVzZSBjYXNlcyBpbiB0aGUg
Zmlyc3QgcmV2aXNpb25zIG9mIHRoZSA8YnI+DQomZ3Q7IGRyYWZ0LiBUaGUgQVBJIHdhcyB3ZWxs
IHN1aXRlZCBmb3IgY2xpZW50LWRyaXZlbiByZXZvY2F0aW9uIGJ1dCBub3QNCjxicj4NCiZndDsg
dGhlIHJlc291cmNlIG93bmVyIC0gZHJpdmVuIHVzZSBjYXNlLiBUaGVyZSBhcmUgZGVmaW5pdGVs
eSA8YnI+DQomZ3Q7IGRpZmZlcmVuY2VzIHdpdGggcmVzcGVjdCB0byB0aGUgcHJvdG9jb2wgZGVz
aWduLCBhdCBsZWFzdCByZWdhcmRpbmcNCjxicj4NCiZndDsgYXV0aGVudGljYXRpb24gYW5kIGF1
dGhvcml6YXRpb24gb2YgdGhlIHJlc3BlY3RpdmUgYWN0b3JzLiZuYnNwO1RoaXMNCm1hZGU8YnI+
DQomZ3Q7IHRoZSBzcGVjIG1vcmUgY29tcGxleCBhbmQmbmJzcDtjYXVzZWQgYW1iaWd1aXRpZXMg
YW5kIGNvbmZ1c2lvbi4gPGJyPg0KJmd0OyBNb3Jlb3ZlciwgdGhlIHdvcmtpbmcgZ3JvdXAgc2Vl
bWVkIG5vdCBjb252aW5jZWQgYnkgdGhlIHRoZSBsYXR0ZXINCnVzZSBjYXNlLjwvZm9udD48L3R0
Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFRoZXJlZm9yZSB0aGUgd29y
a2luZyBncm91cCBkZWNpZGVkIHRvIGZvY3VzIG9uIHRoZSBzaW5nbGUgdXNlIGNhc2VzPGJyPg0K
Jmd0OyBvZiB0aGUgcmV2b2NhdGlvbiBieSBjbGllbnRzLiBUaGlzIG1ha2VzIGEgbG90IG9mIHNl
bnNlIHNpbmNlIHRoaXMNCjxicj4NCiZndDsgaW50ZXJmYWNlIGlzIG1vc3QgaW1wb3J0YW50IHdp
dGggcmVzcGVjdCB0byBpbnRlcm9wZXJhYmlsaXR5LjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u
dCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IEknbSBmb2N1c2luZyByaWdodCBub3cgb24gZmluaXNo
aW5nIHRoaXMgZHJhZnQuIEFuZCB0aGUgb3BlbiBpc3N1ZXMNCjxicj4NCiZndDsgZGlzY3Vzc2Vk
IG9uIHRoZSBsaXN0IGluIHRoZSBsYXN0IGNvdXBsZSBvZiB3ZWVrcyBpbGx1c3RyYXRlIHRoYXQN
Cjxicj4NCiZndDsgZXZlbiB0aGlzIHBvc2VzIGEgY29uc2lkZXJhYmxlIGFtb3VudCBvZiB3b3Jr
LiBTbyBJJ20gdmVyeSByZWx1Y3RhbnQ8YnI+DQomZ3Q7IHRvIGFkZCBzdXBwb3J0IGZvciBhIHdo
b2xlIG5ldyB1c2UgY2FzZSBhdCB0aGF0IHBvaW50IG9mIHRoZSBwcm9jZXNzLjwvZm9udD48L3R0
Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IElmIHlvdSBmZWVsIHRoaXMg
aXMgYW4gaW1wb3J0YW50IHVzZSBjYXNlIHdvcnRoIGFuIFJGQywgZG9uJ3QgPGJyPg0KJmd0OyBo
ZXNpdGF0ZSB0byBwdWJsaXNoIGEgbmV3IEktRC48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg
c2l6ZT0yPiZndDsgPGJyPg0KJmd0OyByZWdhcmRzLDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u
dCBzaXplPTI+Jmd0OyBUb3JzdGVuLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+
Jmd0OyA8YnI+DQomZ3Q7IEFtIDA2LjAyLjIwMTMgdW0gMTY6Mzcgc2NocmllYiBQcmFiYXRoIFNp
cml3YXJkZW5hICZsdDtwcmFiYXRoQHdzbzIuY29tJmd0Ozo8YnI+DQo8L2ZvbnQ+PC90dD4NCjxi
cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250
IHNpemU9Mj4mZ3Q7IE9uIFdlZCwgRmViIDYsIDIwMTMgYXQgOTowNCBQTSwgVG9kZCBXIExhaW5o
YXJ0DQombHQ7bGFpbmhhcnRAdXMuaWJtLmNvbSZndDsgd3JvdGU6PC9mb250PjwvdHQ+DQo8YnI+
PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZndDsgUmVzb3VyY2Ugb3duZXIgbmVlZHMgdG8ga25vdyB0
aGUgY29uc3VtZXINCmtleSAocmVwcmVzZW50cyB0aGUgPGJyPg0KJmd0OyBPQXV0aCBDbGllbnQg
YXBwKSAmYW1wOyBzY29wZSB0byByZXZva2UgdGhlIGFjY2VzcyB0b2tlbiBmb3IgYSBnaXZlbg0K
Y2xpZW50LiZuYnNwOyA8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn
dDsgSSBzZWUgLSB5b3UncmUgc2F5aW5nIHRoYXQgcmVxdWlyaW5nIGNsaWVudCBjcmVkZW50aWFs
cw0Kb24gdGhlIGVuZCA8YnI+DQomZ3Q7IHBvaW50IGlzIHRoZSBwcm9ibGVtPzwvZm9udD48L3R0
Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IEluIGZhY3Qgd2hhdCBJIG1l
YW50IHdhcyAtIHdoZW4gUk8gYXV0aG9yaXplcyB0aGUgYW4gYWNjZXNzIHRva2VuDQo8YnI+DQom
Z3Q7IGZvciBjbGllbnQgZm9yIHBhcnRpY3VsYXIgc2NvcGUuIFRob3NlIGluZm9ybWF0aW9uIGFy
ZSBrZXB0IGF0IHRoZQ0KQVMuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7
IDxicj4NCiZndDsgTm93IC0gaWYgdGhlIFJPIHdhbnQgdG8gcmV2b2tlIGFjY2VzcyBmcm9tIHRo
ZSBjbGllbnQgLSB0aGUgUk8gbmVlZHM8YnI+DQomZ3Q7IHRvIGF1dGhlbnRpY2F0ZSBoaW0gc2Vs
ZiB0byB0aGUgQVMgYW5kIHBhc3MgdGhlIGNvbnN1bWVyIGtleSBhbmQgdGhlPGJyPg0KJmd0OyBz
Y29wZS4gU28gQVMgY2FuIHJldm9rZSBhY2Nlc3MuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250
IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgVGhhbmtzICZhbXA7IHJlZ2FyZHMsPC9mb250PjwvdHQ+
DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IC1QcmFiYXRoPC9mb250PjwvdHQ+DQo8YnI+PHR0
Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl
PTI+Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRvZGQg
TGFpbmhhcnQ8YnI+DQomZ3Q7IFJhdGlvbmFsIHNvZnR3YXJlPGJyPg0KJmd0OyBJQk0gQ29ycG9y
YXRpb248YnI+DQomZ3Q7IDU1MCBLaW5nIFN0cmVldCwgTGl0dGxldG9uLCBNQSAwMTQ2MC0xMjUw
PGJyPg0KJmd0OyAxLTk3OC04OTktNDcwNTxicj4NCiZndDsgMi0yNzYtNDcwNSAoVC9MKTxicj4N
CiZndDsgbGFpbmhhcnRAdXMuaWJtLmNvbTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl
PTI+Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4N
CjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBGcm9tOiAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDtQcmFiYXRoIFNpcml3YXJkZW5hDQombHQ7cHJhYmF0aEB3c28yLmNv
bSZndDsgPGJyPg0KJmd0OyBUbzogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SnVzdGluIFJp
Y2hlciAmbHQ7anJpY2hlckBtaXRyZS5vcmcmZ3Q7LA0KPGJyPg0KJmd0OyBDYzogJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7b2F1dGhAaWV0Zi5vcmcgV0cmcXVvdDsgJmx0O29hdXRo
QGlldGYub3JnJmd0Ow0KPGJyPg0KJmd0OyBEYXRlOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDswMi8wNi8yMDEzIDEwOjMxIEFNIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+
Jmd0OyBTdWJqZWN0OiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtSZTogW09BVVRILVdHXQ0K
QSBxdWVzdGlvbiBvbiB0b2tlbiByZXZvY2F0aW9uLiA8YnI+DQomZ3Q7IFNlbnQgYnk6ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwO29hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgPGJyPg0KJmd0OyA8
YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48
dHQ+PGZvbnQgc2l6ZT0yPiZndDsgT24gV2VkLCBGZWIgNiwgMjAxMyBhdCA4OjQ5IFBNLCBKdXN0
aW4gUmljaGVyDQombHQ7anJpY2hlckBtaXRyZS5vcmcmZ3Q7IHdyb3RlOiA8YnI+DQomZ3Q7IDxi
cj4NCiZndDsgT24gMDIvMDYvMjAxMyAxMDoxMyBBTSwgUHJhYmF0aCBTaXJpd2FyZGVuYSB3cm90
ZTogPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gV2VkLCBGZWIgNiwgMjAxMyBh
dCA4OjE5IFBNLCBKdXN0aW4gUmljaGVyICZsdDtqcmljaGVyQG1pdHJlLm9yZyZndDsNCndyb3Rl
OiA8YnI+DQomZ3Q7IFRoZXNlIGFyZSBnZW5lcmFsbHkgaGFuZGxlZCB0aHJvdWdoIGEgdXNlciBp
bnRlcmZhY2Ugd2hlcmUgdGhlIFJPDQppczxicj4NCiZndDsgYXV0aGVudGljYXRlZCBkaXJlY3Rs
eSB0byB0aGUgQVMsIGFuZCB0aGVyZSdzIG5vdCBtdWNoIG5lZWQgZm9yIGENCjxicj4NCiZndDsg
JnF1b3Q7cHJvdG9jb2wmcXVvdDsgaGVyZSwgaW4gcHJhY3RpY2UuIDxicj4NCiZndDsgPGJyPg0K
Jmd0OyBXaHkgZG8geW91IHRoaW5rIGxlYXZpbmcgYWNjZXNzIHRva2VuIHJldm9jYXRpb24gYnkg
Uk8gdG8gYSA8YnI+DQomZ3Q7IHByb3ByaWV0YXJ5IEFQSSBpcyBhIGdvb2QgcHJhY3RpY2UgPyBJ
TU8gdGhpcyBhbiBlc3NlbnRpYWwgPGJyPg0KJmd0OyByZXF1aXJlbWVudCBpbiBBUEkgc2VjdXJp
dHkuIDxicj4NCiZndDsgSSB0aGluayBpdCBtYWtlcyBtb3JlIHNlbnNlIGluIHRoZSBzYW1lIHdh
eSB0aGF0IGhhdmluZyBhIDxicj4NCiZndDsgJnF1b3Q7cHJvcHJpZXRhcnkmcXVvdDsgVUkvQVBJ
IGZvciBtYW5hZ2luZyB0aGUgdXNlciBjb25zZW50IG1ha2VzDQpzZW5zZTogPGJyPg0KJmd0OyB1
bmxlc3MgeW91J3JlIGRvaW5nIGEgZnVsbHkgZHluYW1pYyBlbmQtdG8tZW5kIHN5c3RlbSBsaWtl
IFVNQSwgdGhlbjxicj4NCiZndDsgdGhlcmUncyBub3QgbXVjaCB2YWx1ZSBpbiB0cnlpbmcgdG8g
c3F1ZWV6ZSBkaXNwYXJhdGUgc3lzdGVtcyBpbnRvDQo8YnI+DQomZ3Q7IHRoZSBzYW1lIG1vbGQs
IHNpbmNlIHRoZXkgd29uJ3QgYmUgdGFsa2luZyB0byBlYWNoIG90aGVyIGFueXdheS4gPGJyPg0K
Jmd0OyA8YnI+DQomZ3Q7IFRoaXMgaXMgcmVxdWlyZWQgaW4gZGlzdHJpYnV0ZWQgc2V0dXAgZm9y
IGVhY2ggQVBJIHBsYXRmb3JtIGZyb20gPGJyPg0KJmd0OyBkaWZmZXJlbnQgdmVuZG9ycyB0byBw
ZXJmb3JtIGluIGFuIGludGVyb3AgbWFubmVyLiA8YnI+DQomZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7
IDxicj4NCiZndDsgQW5kIHNpbmNlIHlvdSByZWZlciB0byBpdCBhcyBhbiAmcXVvdDtBUEkmcXVv
dDssIHdoYXQgd2lsbCB0aGUgUk8NCmJlIHVzaW5nIHRvIDxicj4NCiZndDsgY2FsbCB0aGlzIEFQ
ST8gSXMgdGhlcmUgYSB0b2tlbiBtYW5hZ2VtZW50IGNsaWVudCB0aGF0J3Mgc2VwYXJhdGUNCjxi
cj4NCiZndDsgZnJvbSB0aGUgT0F1dGggY2xpZW50PyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBk
aWRuJ3QgZ2V0IHlvdXIgcXVlc3Rpb24gcmlnaHQuLi4gSWYgeW91IG1lYW50IHRoZSBob3cgdG8g
aW52b2tlDQo8YnI+DQomZ3Q7IHJldm9jYXRpb24gZW5kIHBvaW50LCB0aGUgdGhlIHJlc291cmNl
IG93bmVyIG5lZWRzIHRvIGtub3cgdGhlIDxicj4NCiZndDsgY29uc3VtZXIga2V5IChyZXByZXNl
bnRzIHRoZSBPQXV0aCBDbGllbnQgYXBwKSAmYW1wOyBzY29wZSB0byByZXZva2UNCnRoZTxicj4N
CiZndDsgYWNjZXNzIHRva2VuIGZvciBhIGdpdmVuIGNsaWVudC4mbmJzcDsgPGJyPg0KJmd0OyA8
YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBJTUhPIHRva2VuIHJldm9jYXRpb24gZG9u
ZSBteSBSTyBpcyBtb3JlIHByYWN0aWNhbCB0aGFuIHRva2VuIDxicj4NCiZndDsgcmV2b2NhdGlv
biBkb25lIGJ5IHRoZSBDbGllbnQuIDxicj4NCiZndDsgVGhleSdyZSBib3RoIHZhbGlkIGJ1dCBy
ZXF1aXJlIGRpZmZlcmVudCBraW5kcyBvZiBwcm90b2NvbHMgYW5kIDxicj4NCiZndDsgY29uc2lk
ZXJhdGlvbnMuIFRoaXMgdG9rZW4gcmV2b2NhdGlvbiBkcmFmdCBpcyBtZWFudCB0byBzb2x2ZSBv
bmUNCjxicj4NCiZndDsgcHJvYmxlbSwgYW5kIHRoYXQgZG9lc24ndCBtZWFuIGl0IGNhbiBvciBz
aG91bGQgc29sdmUgb3RoZXIgPGJyPg0KJmd0OyBzZWVtaW5nbHkgcmVsYXRlZCBwcm9ibGVtcy48
YnI+DQomZ3Q7IDxicj4NCiZndDsgSWYgeW91IHdvdWxkIGxpa2UgdG8gc2VlIHRoZSBSTy1pbml0
aWF0ZWQgdG9rZW4gcmV2b2NhdGlvbiBnbyA8YnI+DQomZ3Q7IHRocm91Z2ggKG5vdCBncmFudCBy
ZXZvY2F0aW9uLCBtaW5kIHlvdSAtLSB0aGF0J3MgcmVsYXRlZCwgYnV0IDxicj4NCiZndDsgZGlm
ZmVyZW50KSwgdGhlbiBJIHdvdWxkIHN1Z2dlc3QgdGhhdCB5b3Ugc3RhcnQgc3BlY2lmeWluZyBl
eGFjdGx5DQo8YnI+DQomZ3Q7IGhvdyB0aGF0IHdvcmtzLiBJIHByZWRpY3QgaXQgd2lsbCBiZSBw
cm9ibGVtYXRpYyBpbiBwcmFjdGljZSwgPGJyPg0KJmd0OyB0aG91Z2gsIGFzIHRoZSBSTyBvZnRl
biBkb2Vzbid0IGFjdHVhbGx5IGhhdmUgZGlyZWN0IGFjY2VzcyB0byB0aGUNCjxicj4NCiZndDsg
dG9rZW4gaXRzZWxmLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgUmVzb3VyY2Ugb3duZXIgbmVlZHMg
dG8ga25vdyB0aGUgY29uc3VtZXIga2V5IChyZXByZXNlbnRzIHRoZSBPQXV0aA0KPGJyPg0KJmd0
OyBDbGllbnQgYXBwKSAmYW1wOyBzY29wZSB0byByZXZva2UgdGhlIGFjY2VzcyB0b2tlbiBmb3Ig
YSBnaXZlbiBjbGllbnQuJm5ic3A7DQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7IDxicj4N
CiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyBUaGVyZSBhcmUgbGFyZ2VyIGFwcGxp
Y2F0aW9ucywgbGlrZSBVTUEsIHRoYXQgaGF2ZSBjbGllbnQgYW5kIFBSIDxicj4NCiZndDsgcHJv
dmlzaW9uaW5nIHRoYXQgd291bGQgYWxsb3cgZm9yIHRoaXMgdG8gYmUgbWFuYWdlZCBzb21ld2hh
dCA8YnI+DQomZ3Q7IHByb2dyYW1tYXRpY2FsbHksIGJ1dCBldmVuIGluIHRoYXQgY2FzZSB5b3Un
cmUgc3RpbGwgZ2VuZXJhbGx5IGRvaW5nPGJyPg0KJmd0OyB0b2tlbiByZXZvY2F0aW9uIGJ5IGEg
JnF1b3Q7Y2xpZW50JnF1b3Q7IGluIHNvbWUgZmFzaGlvbi4gSW4gVU1BLA0KdGhvdWdoLCA8YnI+
DQomZ3Q7IHNldmVyYWwgZGlmZmVyZW50IHBpZWNlcyBjYW4gcGxheSB0aGUgcm9sZSBvZiBhICZx
dW90O2NsaWVudCZxdW90Ow0KYXQgPGJyPg0KJmd0OyBkaWZmZXJlbnQgcGFydHMgb2YgdGhlIHBy
b2Nlc3MuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJldm9raW5nIGEgc2NvcGUgaXMgYSB3aG9sZSBk
aWZmZXJlbnQgbWVzcy4gR2VuZXJhbGx5LCB5b3UnZCB3YW50DQp0bzxicj4NCiZndDsganVzdCBy
ZXZva2UgYW4gZXhpc3RpbmcgdG9rZW4gYW5kIG1ha2UgYSBuZXcgYXV0aG9yaXphdGlvbiBncmFu
dCA8YnI+DQomZ3Q7IHdpdGggbG93ZXIgYWNjZXNzIGlmIHlvdSBkb24ndCB3YW50IHRoYXQgY2xp
ZW50IGdldHRpbmcgdGhhdCBzY29wZQ0KPGJyPg0KJmd0OyBhbnltb3JlLiBJZiB5b3UganVzdCB3
YW50IHRvIGRvd25zY29wZSBmb3IgYSBzaW5nbGUgdHJhbnNhY3Rpb24sIHlvdTxicj4NCiZndDsg
Y2FuIGFscmVhZHkgZG8gdGhhdCB3aXRoIGVpdGhlciB0aGUgcmVmcmVzaCB0b2tlbiBvciB0b2tl
biBjaGFpbmluZw0KPGJyPg0KJmd0OyBhcHByb2FjaGVzLCBkZXBlbmRpbmcgb24gd2hlcmUgaW4g
dGhlIHByb2Nlc3MgeW91IGFyZS4gVGhlIGxhdHRlcg0Kb2Y8YnI+DQomZ3Q7IHRoZXNlIGFyZSBi
b3RoIGNsaWVudC1mb2N1c2VkLCB0aG91Z2gsIGFuZCB0aGUgUk8gZG9lc24ndCBoYXZlIGEgPGJy
Pg0KJmd0OyBkaXJlY3QgaGFuZCBpbiBpdCBhdCB0aGlzIHBvaW50LiA8YnI+DQomZ3Q7IDxicj4N
CiZndDsgV2h5IGRvIHlvdSB0aGluayBpdCBhIG1lc3MuIElmIHlvdSByZXZva2UgdGhlIGVudGly
ZSB0b2tlbiB0aGVuIDxicj4NCiZndDsgQ2xpZW50IG5lZWRzIHRvIGdvIHRocm91Z2ggdGhlIGNv
bXBsZXRlIE9BdXRoIGZsb3cgLSBhbmQgYWxzbyBuZWVkcw0KPGJyPg0KJmd0OyB0byBnZXQgdGhl
IHVzZXIgY29uc2VudC4gSWYgUk8gY2FuICZuYnNwO2Rvd25ncmFkZSB0aGUgc2NvcGUsIHRoZW4N
CndlIDxicj4NCiZndDsgcmVzdHJpY3QgQVBJIGFjY2VzcyBieSB0aGUgY2xpZW50IGF0IFJTIGVu
ZCBhbmQgaXRzIHRyYW5zcGFyZW50IHRvDQo8YnI+DQomZ3Q7IHRoZSBjbGllbnQuIDxicj4NCiZn
dDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IERvd25ncmFkaW5nIHRoZSBzY29wZSBvZiB0b2tlbnMg
aW4gdGhlIHdpbGQgaXMgaGFyZGx5IHRyYW5zcGFyZW50DQp0bzxicj4NCiZndDsgdGhlIGNsaWVu
dCAoc3R1ZmYgdGhhdCBpdCBleHBlY3RzIHRvIHdvcmsgd2lsbCBzdWRkZW5seSBzdGFydCB0byA8
YnI+DQomZ3Q7IGZhaWwsIG1lYW5pbmcgdGhhdCBtb3N0IGNsaWVudHMgd2lsbCB0aHJvdyBvdXQg
dGhlIHRva2VuIGFuZCB0cnkgdG8NCjxicj4NCiZndDsgZ2V0IGEgbmV3IG9uZSksIGFuZCBpbiBh
IGRpc3RyaWJ1dGVkIHN5c3RlbSB5b3UndmUgZ290IHRvIHByb3BhZ2F0ZQ0KPGJyPg0KJmd0OyB0
aGF0IGNoYW5nZSB0byB0aGUgUlMuIElmIHlvdSBiYWtlIHRoZSBzY29wZXMgaW50byB0aGUgdG9r
ZW4gaXRzZWxmDQo8YnI+DQomZ3Q7ICh3aGljaCBtYW55IGRvKSB0aGVuIHlvdSBhY3R1YWxseSAq
Y2FuJ3QqIGRvd25ncmFkZSBhIHNpbmdsZSB0b2tlbiwNCmFueXdheS4gPGJyPg0KJmd0OyA8YnI+
DQomZ3Q7IFllcy4uIHRoYXQgaXMgdGhlIGV4cGVjdGVkIGJlaGF2aW9yLiBJIG1lYW4gdGhlIHBy
b2Nlc3MgaXMgPGJyPg0KJmd0OyB0cmFuc3BhcmVudC4gQ2xpZW50IHdpbGwgbm90aWNlIGF0IHJ1
bnRpbWUuIDxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGFua3MgJmFtcDsgcmVnYXJkcywgPGJyPg0K
Jmd0OyAtUHJhYmF0aCA8YnI+DQomZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5i
c3A7LS0gSnVzdGluIDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5rcyAmYW1w
OyByZWdhcmRzLCA8YnI+DQomZ3Q7IC1QcmFiYXRoIDxicj4NCiZndDsgJm5ic3A7IDxicj4NCiZn
dDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOy0tIEp1c3RpbiA8YnI+DQomZ3Q7IDxicj4N
CiZndDsgPGJyPg0KJmd0OyBPbiAwMi8wNi8yMDEzIDA0OjM1IEFNLCBQcmFiYXRoIFNpcml3YXJk
ZW5hIHdyb3RlOiA8YnI+DQomZ3Q7IEkgYW0gc29ycnkgaWYgdGhpcyB3YXMgYWxyZWFkeSBkaXNj
dXNzZWQgaW4gdGhpcyBsaXN0Li4mbmJzcDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IExvb2tpbmcg
YXQgWzFdIGl0IG9ubHkgdGFsa3MgYWJvdXQgcmV2b2tpbmcgdGhlIGFjY2VzcyB0b2tlbiBmcm9t
DQp0aGUgY2xpZW50LiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSG93IGFib3V0IHRoZSByZXNvdXJj
ZSBvd25lci4uPyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlcmUgY2FuIGJlIGNhc2VzIHdoZXJl
IHJlc291cmNlIG93bmVyIG5lZWRzIHRvIHJldm9rZSBhbiA8YnI+DQomZ3Q7IGF1dGhvcml6ZWQg
YWNjZXNzIHRva2VuIGZyb20gYSBnaXZlbiBjbGllbnQuIE9yIHJldm9rZSBhbiBzY29wZS4uDQo8
YnI+DQomZ3Q7IDxicj4NCiZndDsgSG93IGFyZSB3ZSBnb2luZyB0byBhZGRyZXNzIHRoZXNlIHJl
cXVpcmVtZW50cy4uPyBUaG91Z2h0cyBhcHByZWNpYXRlZC4uLg0KPGJyPg0KJmd0OyA8YnI+DQom
Z3Q7IFsxXSBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXJldm9j
YXRpb24tMDQgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC0tIDxicj4NCiZndDsgVGhhbmtzICZhbXA7
IFJlZ2FyZHMsPGJyPg0KJmd0OyBQcmFiYXRoIDxicj4NCiZndDsgPGJyPg0KJmd0OyBNb2JpbGUg
OiArOTQgNzEgODA5IDY3MzImbmJzcDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgaHR0cDovL2Jsb2cu
ZmFjaWxlbG9naW4uY29tPGJyPg0KJmd0OyBodHRwOi8vUmFtcGFydEZBUS5jb20gPGJyPg0KJmd0
OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX188YnI+DQomZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgT0F1
dGhAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vb2F1dGg8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4N
CiZndDsgPGJyPg0KJmd0OyAtLSA8YnI+DQomZ3Q7IFRoYW5rcyAmYW1wOyBSZWdhcmRzLDxicj4N
CiZndDsgUHJhYmF0aCA8YnI+DQomZ3Q7IDxicj4NCiZndDsgTW9iaWxlIDogKzk0IDcxIDgwOSA2
NzMyJm5ic3A7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IGh0dHA6Ly9ibG9nLmZhY2lsZWxvZ2luLmNv
bTxicj4NCiZndDsgaHR0cDovL1JhbXBhcnRGQVEuY29tIDxicj4NCiZndDsgPGJyPg0KJmd0OyA8
YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAtLSA8YnI+DQomZ3Q7IFRoYW5rcyAmYW1w
OyBSZWdhcmRzLDxicj4NCiZndDsgUHJhYmF0aCA8YnI+DQomZ3Q7IDxicj4NCiZndDsgTW9iaWxl
IDogKzk0IDcxIDgwOSA2NzMyJm5ic3A7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IGh0dHA6Ly9ibG9n
LmZhY2lsZWxvZ2luLmNvbTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBo
dHRwOi8vUmFtcGFydEZBUS5jb21fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXzxicj4NCiZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBPQXV0aEBp
ZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v
YXV0aDxicj4NCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQo8
L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAtLSA8YnI+
DQomZ3Q7IFRoYW5rcyAmYW1wOyBSZWdhcmRzLDxicj4NCiZndDsgUHJhYmF0aDwvZm9udD48L3R0
Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IE1vYmlsZSA6ICs5NCA3MSA4
MDkgNjczMiZuYnNwOzxicj4NCiZndDsgPGJyPg0KJmd0OyBodHRwOi8vYmxvZy5mYWNpbGVsb2dp
bi5jb208YnI+DQomZ3Q7IGh0dHA6Ly9SYW1wYXJ0RkFRLmNvbTwvZm9udD48L3R0Pg0KPGJyPjx0
dD48Zm9udCBzaXplPTI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXzxicj4NCiZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBPQXV0aEBp
ZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v
YXV0aDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQo8L2ZvbnQ+
PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAtLSA8YnI+DQomZ3Q7
IFRoYW5rcyAmYW1wOyBSZWdhcmRzLDxicj4NCiZndDsgUHJhYmF0aDwvZm9udD48L3R0Pg0KPGJy
Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IE1vYmlsZSA6ICs5NCA3MSA4MDkgNjcz
MiZuYnNwOzxicj4NCiZndDsgPGJyPg0KJmd0OyBodHRwOi8vYmxvZy5mYWNpbGVsb2dpbi5jb208
YnI+DQomZ3Q7IGh0dHA6Ly9SYW1wYXJ0RkFRLmNvbV9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQom
Z3Q7IE9BdXRoQGlldGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL29hdXRoPGJyPg0KPC9mb250PjwvdHQ+DQo=
--=_alternative 0028506D48257B0B_=--

From prabath@wso2.com  Wed Feb  6 23:25:05 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF86C21F871D for ; Wed,  6 Feb 2013 23:25:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level: 
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[AWL=-0.862, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6Kc+j8qJlBy for ; Wed,  6 Feb 2013 23:25:04 -0800 (PST)
Received: from mail-ea0-f174.google.com (mail-ea0-f174.google.com [209.85.215.174]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7B321F8715 for ; Wed,  6 Feb 2013 23:25:03 -0800 (PST)
Received: by mail-ea0-f174.google.com with SMTP id 1so985929eaa.33 for ; Wed, 06 Feb 2013 23:25:02 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=ut/eoFgW+xm3i6SPW8i6XOhTC72LCYYyUoZVo/Rm8RY=; b=eeXuzX3zg9Nao4E59yvGiDWeF9QcXL8Me8KiEBHQPUgfs4y73kleDYELARm17Akk5G /OIQMWSOuVnUdAHpXbE3YZIoB9GJ90zYJd+HQr4NSejOPBXqGYrcdry/TXcWWfSdwc/u WBuGIWQuTKseJkHR/Dbt/5geAg8CWM3qr3xfX767Y5m6TXpci8RNNNN9zZ2PTD3vVBrr Y2mkvpI9GxG1gto9l/4+Mo8NEUNtVCkoMz4leEMdZsFxj2120ue1RwYSgRUE6Mkioav4 NimXzwyY5JB3GNh3TkValPmUZxldCwsUtO1QtUm9AMzSbYypqIhAf6/kru0BrV7kugkd KlKA==
MIME-Version: 1.0
X-Received: by 10.14.202.197 with SMTP id d45mr1481803eeo.1.1360221902365; Wed, 06 Feb 2013 23:25:02 -0800 (PST)
Received: by 10.223.175.134 with HTTP; Wed, 6 Feb 2013 23:25:02 -0800 (PST)
In-Reply-To: 
References:  
Date: Thu, 7 Feb 2013 12:55:02 +0530
Message-ID: 
From: Prabath Siriwardena 
To: zhou.sujing@zte.com.cn
Content-Type: multipart/alternative; boundary=047d7b343b064e620f04d51d574c
X-Gm-Message-State: ALoCoQlXz/3KNboYx6DCD4bdWB9e+7VrJqzLkouUuYxq+XsmzXwqrAP0W+HBUWL+0z2ugkpnfE4p
Cc: "oauth@ietf.org WG" , "oauth-bounces@ietf.org" 
Subject: Re: [OAUTH-WG] A question on token revocation.
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Feb 2013 07:25:05 -0000

--047d7b343b064e620f04d51d574c
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 7, 2013 at 12:49 PM,  wrote:

>
> I guess RO could initiate access token revocation for a client by
> including authorization code in the request to AS.
> Comments?

That creates a dependency on the grant type.

Thanks & regards,
-Prabath

>
>
>
>
> oauth-bounces@ietf.org =D0=B4=D3=DA 2013-02-07 02:32:28:
>
> > Hi Torsten,
> >
> > Thanks for your feedback.. I will submit a draft...
> >
> > Thanks & regards,
> > -Prabath
>
> > On Wed, Feb 6, 2013 at 11:55 PM, Torsten Lodderstedt <
> torsten@lodderstedt.net
> > > wrote:
> > Hi Prabath,
> >
> > we tried to address both use cases in the first revisions of the
> > draft. The API was well suited for client-driven revocation but not
> > the resource owner - driven use case. There are definitely
> > differences with respect to the protocol design, at least regarding
> > authentication and authorization of the respective actors. This made
> > the spec more complex and caused ambiguities and confusion.
> > Moreover, the working group seemed not convinced by the the latter use
> case.
> >
> > Therefore the working group decided to focus on the single use cases
> > of the revocation by clients. This makes a lot of sense since this
> > interface is most important with respect to interoperability.
> >
> > I'm focusing right now on finishing this draft. And the open issues
> > discussed on the list in the last couple of weeks illustrate that
> > even this poses a considerable amount of work. So I'm very reluctant
> > to add support for a whole new use case at that point of the process.
> >
> > If you feel this is an important use case worth an RFC, don't
> > hesitate to publish a new I-D.
> >
> > regards,
> > Torsten.
> >
> > Am 06.02.2013 um 16:37 schrieb Prabath Siriwardena :
>
> >
>
> > On Wed, Feb 6, 2013 at 9:04 PM, Todd W Lainhart 
> wrote:
> > > Resource owner needs to know the consumer key (represents the
> > OAuth Client app) & scope to revoke the access token for a given
> client.
>
> > I see - you're saying that requiring client credentials on the end
> > point is the problem?
> >
> > In fact what I meant was - when RO authorizes the an access token
> > for client for particular scope. Those information are kept at the AS.
> >
> > Now - if the RO want to revoke access from the client - the RO needs
> > to authenticate him self to the AS and pass the consumer key and the
> > scope. So AS can revoke access.
> >
> > Thanks & regards,
> > -Prabath
> >
> >
> >
> >
> >
> > Todd Lainhart
> > Rational software
> > IBM Corporation
> > 550 King Street, Littleton, MA 01460-1250
> > 1-978-899-4705
> > 2-276-4705 (T/L)
> > lainhart@us.ibm.com
> >
> >
> >
> >
> >
>
> > From:        Prabath Siriwardena 
> > To:        Justin Richer ,
> > Cc:        "oauth@ietf.org WG" 
> > Date:        02/06/2013 10:31 AM
> > Subject:        Re: [OAUTH-WG] A question on token revocation.
> > Sent by:        oauth-bounces@ietf.org
> >
> >
> >
> >
>
> > On Wed, Feb 6, 2013 at 8:49 PM, Justin Richer 
> wrote:
> >
> > On 02/06/2013 10:13 AM, Prabath Siriwardena wrote:
> >
> >
> > On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer 
> wrote:
> > These are generally handled through a user interface where the RO is
> > authenticated directly to the AS, and there's not much need for a
> > "protocol" here, in practice.
> >
> > Why do you think leaving access token revocation by RO to a
> > proprietary API is a good practice ? IMO this an essential
> > requirement in API security.
> > I think it makes more sense in the same way that having a
> > "proprietary" UI/API for managing the user consent makes sense:
> > unless you're doing a fully dynamic end-to-end system like UMA, then
> > there's not much value in trying to squeeze disparate systems into
> > the same mold, since they won't be talking to each other anyway.
> >
> > This is required in distributed setup for each API platform from
> > different vendors to perform in an interop manner.
> >
> >
> > And since you refer to it as an "API", what will the RO be using to
> > call this API? Is there a token management client that's separate
> > from the OAuth client?
> >
> > I didn't get your question right... If you meant the how to invoke
> > revocation end point, the the resource owner needs to know the
> > consumer key (represents the OAuth Client app) & scope to revoke the
> > access token for a given client.
> >
> >
> >
> > IMHO token revocation done my RO is more practical than token
> > revocation done by the Client.
> > They're both valid but require different kinds of protocols and
> > considerations. This token revocation draft is meant to solve one
> > problem, and that doesn't mean it can or should solve other
> > seemingly related problems.
> >
> > If you would like to see the RO-initiated token revocation go
> > through (not grant revocation, mind you -- that's related, but
> > different), then I would suggest that you start specifying exactly
> > how that works. I predict it will be problematic in practice,
> > though, as the RO often doesn't actually have direct access to the
> > token itself.
> >
> > Resource owner needs to know the consumer key (represents the OAuth
> > Client app) & scope to revoke the access token for a given client.
> >
> >
> >
> >
> > There are larger applications, like UMA, that have client and PR
> > provisioning that would allow for this to be managed somewhat
> > programmatically, but even in that case you're still generally doing
> > token revocation by a "client" in some fashion. In UMA, though,
> > several different pieces can play the role of a "client" at
> > different parts of the process.
> >
> > Revoking a scope is a whole different mess. Generally, you'd want to
> > just revoke an existing token and make a new authorization grant
> > with lower access if you don't want that client getting that scope
> > anymore. If you just want to downscope for a single transaction, you
> > can already do that with either the refresh token or token chaining
> > approaches, depending on where in the process you are. The latter of
> > these are both client-focused, though, and the RO doesn't have a
> > direct hand in it at this point.
> >
> > Why do you think it a mess. If you revoke the entire token then
> > Client needs to go through the complete OAuth flow - and also needs
> > to get the user consent. If RO can  downgrade the scope, then we
> > restrict API access by the client at RS end and its transparent to
> > the client.
> >
> >
> > Downgrading the scope of tokens in the wild is hardly transparent to
> > the client (stuff that it expects to work will suddenly start to
> > fail, meaning that most clients will throw out the token and try to
> > get a new one), and in a distributed system you've got to propagate
> > that change to the RS. If you bake the scopes into the token itself
> > (which many do) then you actually *can't* downgrade a single token,
> anyway.
> >
> > Yes.. that is the expected behavior. I mean the process is
> > transparent. Client will notice at runtime.
> >
> > Thanks & regards,
> > -Prabath
> >
> >
> >  -- Justin
> >
> >
> > Thanks & regards,
> > -Prabath
> >
> >
> >
> >  -- Justin
> >
> >
> > On 02/06/2013 04:35 AM, Prabath Siriwardena wrote:
> > I am sorry if this was already discussed in this list..
> >
> > Looking at [1] it only talks about revoking the access token from the
> client.
> >
> > How about the resource owner..?
> >
> > There can be cases where resource owner needs to revoke an
> > authorized access token from a given client. Or revoke an scope..
> >
> > How are we going to address these requirements..? Thoughts
> appreciated...
> >
> > [1] http://tools.ietf.org/html/draft-ietf-oauth-revocation-04
> >
> > --
> > Thanks & Regards,
> > Prabath
> >
> > Mobile : +94 71 809 6732
> >
> > http://blog.facilelogin.com
> > http://RampartFAQ.com
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> >
> >
> >
> > --
> > Thanks & Regards,
> > Prabath
> >
> > Mobile : +94 71 809 6732
> >
> > http://blog.facilelogin.com
> > http://RampartFAQ.com
> >
> >
> >
> >
> > --
> > Thanks & Regards,
> > Prabath
> >
> > Mobile : +94 71 809 6732
> >
> > http://blog.facilelogin.com
> > http://RampartFAQ.com_______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> >
>
> >
> > --
> > Thanks & Regards,
> > Prabath
> >
> > Mobile : +94 71 809 6732
> >
> > http://blog.facilelogin.com
> > http://RampartFAQ.com
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
>
> >
> > --
> > Thanks & Regards,
> > Prabath
> >
> > Mobile : +94 71 809 6732
> >
> > http://blog.facilelogin.com
> > http://RampartFAQ.com_______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>

--=20
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.com

--047d7b343b064e620f04d51d574c
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 7, 2013 at 12:49 PM,  <zhou.sujing@zte.com.cn> wrote:

I guess RO could initiate access token
revocation for a client by including authorization code in the request
to AS.

Comments? 

=
That creates a dependency on the grant type.

=
Thanks & regards,
-Prabath

o=
auth-bounces@ietf.org =D0=B4=D3=DA 2013-02-07 02:32:28:

> Hi Torsten,

> 

> Thanks for your feedback.. I will submit a draft...

> 

> Thanks & regards,

> -Prabath

> On Wed, Feb 6, 2013 at 11:55 PM, Torsten Lodderstedt
<torsten@lo=
dderstedt.net

> > wrote:

> Hi Prabath,

> 

> we tried to address both use cases in the first revisions of the 

> draft. The API was well suited for client-driven revocation but not

> the resource owner - driven use case. There are definitely 

> differences with respect to the protocol design, at least regarding

> authentication and authorization of the respective actors. This
made

> the spec more complex and caused ambiguities and confusion. 

> Moreover, the working group seemed not convinced by the the latter
use case.

> 

> Therefore the working group decided to focus on the single use cases
> of the revocation by clients. This makes a lot of sense since this

> interface is most important with respect to interoperability.

> 

> I'm focusing right now on finishing this draft. And the open issue=
s

> discussed on the list in the last couple of weeks illustrate that

> even this poses a considerable amount of work. So I'm very relucta=
nt

> to add support for a whole new use case at that point of the process.<=
/font>

> 

> If you feel this is an important use case worth an RFC, don't 

> hesitate to publish a new I-D.

> 

> regards,

> Torsten.

> 

> Am 06.02.2013 um 16:37 schrieb Prabath Siriwardena <prabath@wso2.com>:

> 

> On Wed, Feb 6, 2013 at 9:04 PM, Todd W Lainhart
<lainhart@us.ib=
m.com> wrote:

> > Resource owner needs to know the consumer
key (represents the 

> OAuth Client app) & scope to revoke the access token for a given
client.  

> I see - you're saying that requiring client credenti=
als
on the end 

> point is the problem?

> 

> In fact what I meant was - when RO authorizes the an access token

> for client for particular scope. Those information are kept at the
AS.

> 

> Now - if the RO want to revoke access from the client - the RO needs
> to authenticate him self to the AS and pass the consumer key and the
> scope. So AS can revoke access.

> 

> Thanks & regards,

> -Prabath

>  

> 

> 

> 

> 

> Todd Lainhart

> Rational software

> IBM Corporation

> 550 King Street, Littleton, MA 01460-1250

> 1-978-899-4705

> 2-276-4705 (T/L)

> lainhart@us.i=
bm.com

> 

> 

> 

> 

> 

> From:        Prabath Siriwardena
<prabath@wso2.com<=
/a>> 

> To:        Justin Richer <jricher@mitre.org>,

> Cc:        "oauth@ietf.org WG" <oauth@ietf.org>

> Date:        02/06/2013 10:31 AM 

> Subject:        Re: [OAUTH-WG]
A question on token revocation. 

> Sent by:        oauth-bounces@ietf.org 

> 

> 

> 

> 

> On W=
ed, Feb 6, 2013 at 8:49 PM, Justin Richer
<jricher@mitre.or=
g> wrote: 

> 

> On 02/06/2013 10:13 AM, Prabath Siriwardena wrote: 

> 

> 

> On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer <jricher@mitre.org>
wrote: 

> These are generally handled through a user interface where the RO
is

> authenticated directly to the AS, and there's not much need for a

> "protocol" here, in practice. 

> 

> Why do you think leaving access token revocation by RO to a 

> proprietary API is a good practice ? IMO this an essential 

> requirement in API security. 

> I think it makes more sense in the same way that having a 

> "proprietary" UI/API for managing the user consent makes
sense: 

> unless you're doing a fully dynamic end-to-end system like UMA, th=
en

> there's not much value in trying to squeeze disparate systems into

> the same mold, since they won't be talking to each other anyway. <=
br>
> 

> This is required in distributed setup for each API platform from 

> different vendors to perform in an interop manner. 

>   

> 

> And since you refer to it as an "API", what will the RO
be using to 

> call this API? Is there a token management client that's separate

> from the OAuth client? 

> 

> I didn't get your question right... If you meant the how to invoke

> revocation end point, the the resource owner needs to know the 

> consumer key (represents the OAuth Client app) & scope to revoke
the

> access token for a given client.  

> 

> 

> 

> IMHO token revocation done my RO is more practical than token 

> revocation done by the Client. 

> They're both valid but require different kinds of protocols and 
> considerations. This token revocation draft is meant to solve one

> problem, and that doesn't mean it can or should solve other 

> seemingly related problems.

> 

> If you would like to see the RO-initiated token revocation go 

> through (not grant revocation, mind you -- that's related, but 
> different), then I would suggest that you start specifying exactly

> how that works. I predict it will be problematic in practice, 

> though, as the RO often doesn't actually have direct access to the

> token itself. 

> 

> Resource owner needs to know the consumer key (represents the OAuth

> Client app) & scope to revoke the access token for a given client.=

> 

>   

> 

>   

> There are larger applications, like UMA, that have client and PR 

> provisioning that would allow for this to be managed somewhat 

> programmatically, but even in that case you're still generally doi=
ng

> token revocation by a "client" in some fashion. In UMA,
though, 

> several different pieces can play the role of a "client"
at 

> different parts of the process.

> 

> Revoking a scope is a whole different mess. Generally, you'd want
to

> just revoke an existing token and make a new authorization grant 

> with lower access if you don't want that client getting that scope

> anymore. If you just want to downscope for a single transaction, you
> can already do that with either the refresh token or token chaining

> approaches, depending on where in the process you are. The latter
of

> these are both client-focused, though, and the RO doesn't have a <=
br>
> direct hand in it at this point. 

> 

> Why do you think it a mess. If you revoke the entire token then 

> Client needs to go through the complete OAuth flow - and also needs

> to get the user consent. If RO can  downgrade the scope, then
we 

> restrict API access by the client at RS end and its transparent to

> the client. 

> 

> 

> Downgrading the scope of tokens in the wild is hardly transparent
to

> the client (stuff that it expects to work will suddenly start to 

> fail, meaning that most clients will throw out the token and try to

> get a new one), and in a distributed system you've got to propagat=
e

> that change to the RS. If you bake the scopes into the token itself

> (which many do) then you actually *can't* downgrade a single token=
,
anyway. 

> 

> Yes.. that is the expected behavior. I mean the process is 

> transparent. Client will notice at runtime. 

> 

> Thanks & regards, 

> -Prabath 

>   

> 

>  -- Justin 

> 

> 

> Thanks & regards, 

> -Prabath 

>   

> 

> 

>  -- Justin 

> 

> 

> On 02/06/2013 04:35 AM, Prabath Siriwardena wrote: 

> I am sorry if this was already discussed in this list..  

> 

> Looking at [1] it only talks about revoking the access token from
the client. 

> 

> How about the resource owner..? 

> 

> There can be cases where resource owner needs to revoke an 

> authorized access token from a given client. Or revoke an scope..

> 

> How are we going to address these requirements..? Thoughts appreciated=
...

> 

> [1] http://tools.ietf.org/html/draft-ietf-oauth-revocatio=
n-04 

> 

> -- 

> Thanks & Regards,

> Prabath 

> 

> Mobile : +94 71 809 6732 

> 

> http://blog.=
facilelogin.com

> http://RampartFAQ.=
com 

> 

> 

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=

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

> 

> 

> 

> 

> 

> -- 

> Thanks & Regards,

> Prabath 

> 

> Mobile : +94 71 809 6732 

> 

> http://blog.=
facilelogin.com

> http://RampartFAQ.=
com 

> 

> 

> 

> 

> -- 

> Thanks & Regards,

> Prabath 

> 

> Mobile : +94 71 809 6732 

> 

> http://blog.=
facilelogin.com

> http://RampartFAQ.com___________=
____________________________________

> OAuth mailing list

> OAuth@ietf.org=

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

> 

> 

> -- 

> Thanks & Regards,

> Prabath

> 

> Mobile : +94 71 809 6732 

> 

> http://blog.=
facilelogin.com

> http://RampartFAQ.=
com

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=

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

> 

> 

> -- 

> Thanks & Regards,

> Prabath

> 

> Mobile : +94 71 809 6732 

> 

> http://blog.=
facilelogin.com

> http://RampartFAQ.com_________________________=
______________________

> OAuth mailing list

> OAuth@ietf.org=

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

-- 
=
Thanks & Regards,
Prabath
Mobile : +94 71 809 673=
2 

ht=
tp://blog.facilelogin.com

http://RampartFAQ.com

--047d7b343b064e620f04d51d574c--

From zhou.sujing@zte.com.cn  Thu Feb  7 00:47:08 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1638121F8639; Thu,  7 Feb 2013 00:47:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.395
X-Spam-Level: 
X-Spam-Status: No, score=-98.395 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50yyqEywujxe; Thu,  7 Feb 2013 00:47:06 -0800 (PST)
Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id CA79C21F8635; Thu,  7 Feb 2013 00:47:05 -0800 (PST)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 8D09F124518A; Thu,  7 Feb 2013 16:45:37 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id r178kbqf022381; Thu, 7 Feb 2013 16:46:37 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: 
To: Prabath Siriwardena 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: zhou.sujing@zte.com.cn
Date: Thu, 7 Feb 2013 16:46:26 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-02-07 16:46:33, Serialize complete at 2013-02-07 16:46:33
Content-Type: multipart/alternative; boundary="=_alternative 00303F2748257B0B_="
X-MAIL: mse02.zte.com.cn r178kbqf022381
Cc: "oauth@ietf.org WG" , "oauth-bounces@ietf.org" 
Subject: Re: [OAUTH-WG] A question on token revocation.
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Feb 2013 08:47:08 -0000

This is a multipart message in MIME format.
--=_alternative 00303F2748257B0B_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

RHVyaW5nIHRoZSBmb3VyIGdyYW50IHR5cGVzIG9mIE9hdXRoLA0KICAxLiBhdXRob3JpemF0aW9u
IGNvZGU6IFJPIGtub3dzIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgdXBvbiB3aGljaCANCmFjY2Vz
cy10b2tlbnMtdG8tYmUtcmV2b2tlZCBhcmUgaXNzdWVkIA0KICAyLiBpbXBsaWNpdGUgZmxvdzog
Uk8ga25vd3MgdGhlIGFjY2Vzcy10b2tlbnMtdG8tYmUtcmV2b2tlZA0KICAzLiBwYXNzd29yZCBh
bmQgY2xpZW50IGNyZWRlbnRpYWwgdHlwZXM6IFJPIGhhcyBubyB3YXkgb2Yga25vd2luZyBhY2Nl
c3MgDQp0b2tlbnMuIA0KDQpTbyxJTU8sICBpdCBpcyBub3QgcHJvcGVyIGZvciBSTyB0byByZXZv
a2UgYW4gZWFjaCBhY2Nlc3MgdG9rZW4gDQppbmRpdmlkdWFsbHksDQpyYXRoZXIgaXQgY291bGQg
cmV2b2tlIHNvbWUgYWNjZXNzIHRva2VucyBieSBzcGVjaWZ5aW5nIGNvbmRpdGlvbnMsIHN1Y2gg
DQphcyBjbGllbnRfaWQsIHRpbWVfcGVyaW9kLCBzY29wZSANCkNvbW1lbnRzPyANCg0KUHJhYmF0
aCBTaXJpd2FyZGVuYSA8cHJhYmF0aEB3c28yLmNvbT4g0LTT2iAyMDEzLTAyLTA3IDE1OjI1OjAy
Og0KDQo+IA0KDQo+IE9uIFRodSwgRmViIDcsIDIwMTMgYXQgMTI6NDkgUE0sIDx6aG91LnN1amlu
Z0B6dGUuY29tLmNuPiB3cm90ZToNCj4gDQo+IEkgZ3Vlc3MgUk8gY291bGQgaW5pdGlhdGUgYWNj
ZXNzIHRva2VuIHJldm9jYXRpb24gZm9yIGEgY2xpZW50IGJ5IA0KPiBpbmNsdWRpbmcgYXV0aG9y
aXphdGlvbiBjb2RlIGluIHRoZSByZXF1ZXN0IHRvIEFTLiANCj4gQ29tbWVudHM/IA0KPiANCj4g
VGhhdCBjcmVhdGVzIGEgZGVwZW5kZW5jeSBvbiB0aGUgZ3JhbnQgdHlwZS4NCj4gDQo+IFRoYW5r
cyAmIHJlZ2FyZHMsDQo+IC1QcmFiYXRoDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gb2F1dGgtYm91
bmNlc0BpZXRmLm9yZyDQtNPaIDIwMTMtMDItMDcgMDI6MzI6Mjg6DQo+IA0KPiA+IEhpIFRvcnN0
ZW4sIA0KPiA+IA0KPiA+IFRoYW5rcyBmb3IgeW91ciBmZWVkYmFjay4uIEkgd2lsbCBzdWJtaXQg
YSBkcmFmdC4uLiANCj4gPiANCj4gPiBUaGFua3MgJiByZWdhcmRzLCANCj4gPiAtUHJhYmF0aA0K
PiANCj4gPiBPbiBXZWQsIEZlYiA2LCAyMDEzIGF0IDExOjU1IFBNLCBUb3JzdGVuIExvZGRlcnN0
ZWR0IDwNCj4gdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQNCj4gPiA+IHdyb3RlOiANCj4gPiBIaSBQ
cmFiYXRoLCANCj4gPiANCj4gPiB3ZSB0cmllZCB0byBhZGRyZXNzIGJvdGggdXNlIGNhc2VzIGlu
IHRoZSBmaXJzdCByZXZpc2lvbnMgb2YgdGhlIA0KPiA+IGRyYWZ0LiBUaGUgQVBJIHdhcyB3ZWxs
IHN1aXRlZCBmb3IgY2xpZW50LWRyaXZlbiByZXZvY2F0aW9uIGJ1dCBub3QgDQo+ID4gdGhlIHJl
c291cmNlIG93bmVyIC0gZHJpdmVuIHVzZSBjYXNlLiBUaGVyZSBhcmUgZGVmaW5pdGVseSANCj4g
PiBkaWZmZXJlbmNlcyB3aXRoIHJlc3BlY3QgdG8gdGhlIHByb3RvY29sIGRlc2lnbiwgYXQgbGVh
c3QgcmVnYXJkaW5nIA0KPiA+IGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIG9mIHRo
ZSByZXNwZWN0aXZlIGFjdG9ycy4gVGhpcyBtYWRlDQo+ID4gdGhlIHNwZWMgbW9yZSBjb21wbGV4
IGFuZCBjYXVzZWQgYW1iaWd1aXRpZXMgYW5kIGNvbmZ1c2lvbi4gDQo+ID4gTW9yZW92ZXIsIHRo
ZSB3b3JraW5nIGdyb3VwIHNlZW1lZCBub3QgY29udmluY2VkIGJ5IHRoZSB0aGUgbGF0dGVydXNl
IA0KY2FzZS4NCj4gPiANCj4gPiBUaGVyZWZvcmUgdGhlIHdvcmtpbmcgZ3JvdXAgZGVjaWRlZCB0
byBmb2N1cyBvbiB0aGUgc2luZ2xlIHVzZSBjYXNlcw0KPiA+IG9mIHRoZSByZXZvY2F0aW9uIGJ5
IGNsaWVudHMuIFRoaXMgbWFrZXMgYSBsb3Qgb2Ygc2Vuc2Ugc2luY2UgdGhpcyANCj4gPiBpbnRl
cmZhY2UgaXMgbW9zdCBpbXBvcnRhbnQgd2l0aCByZXNwZWN0IHRvIGludGVyb3BlcmFiaWxpdHku
IA0KPiA+IA0KPiA+IEknbSBmb2N1c2luZyByaWdodCBub3cgb24gZmluaXNoaW5nIHRoaXMgZHJh
ZnQuIEFuZCB0aGUgb3BlbiBpc3N1ZXMgDQo+ID4gZGlzY3Vzc2VkIG9uIHRoZSBsaXN0IGluIHRo
ZSBsYXN0IGNvdXBsZSBvZiB3ZWVrcyBpbGx1c3RyYXRlIHRoYXQgDQo+ID4gZXZlbiB0aGlzIHBv
c2VzIGEgY29uc2lkZXJhYmxlIGFtb3VudCBvZiB3b3JrLiBTbyBJJ20gdmVyeSByZWx1Y3RhbnQN
Cj4gPiB0byBhZGQgc3VwcG9ydCBmb3IgYSB3aG9sZSBuZXcgdXNlIGNhc2UgYXQgdGhhdCBwb2lu
dCBvZiB0aGUgcHJvY2Vzcy4gDQo+ID4gDQo+ID4gSWYgeW91IGZlZWwgdGhpcyBpcyBhbiBpbXBv
cnRhbnQgdXNlIGNhc2Ugd29ydGggYW4gUkZDLCBkb24ndCANCj4gPiBoZXNpdGF0ZSB0byBwdWJs
aXNoIGEgbmV3IEktRC4gDQo+ID4gDQo+ID4gcmVnYXJkcywgDQo+ID4gVG9yc3Rlbi4gDQo+ID4g
DQo+ID4gQW0gMDYuMDIuMjAxMyB1bSAxNjozNyBzY2hyaWViIFByYWJhdGggU2lyaXdhcmRlbmEg
PHByYWJhdGhAd3NvMi5jb20+Og0KPiANCj4gPiANCj4gDQo+ID4gT24gV2VkLCBGZWIgNiwgMjAx
MyBhdCA5OjA0IFBNLCBUb2RkIFcgTGFpbmhhcnQgPGxhaW5oYXJ0QHVzLmlibS5jb20+IA0Kd3Jv
dGU6DQo+ID4gPiBSZXNvdXJjZSBvd25lciBuZWVkcyB0byBrbm93IHRoZSBjb25zdW1lciBrZXkg
KHJlcHJlc2VudHMgdGhlIA0KPiA+IE9BdXRoIENsaWVudCBhcHApICYgc2NvcGUgdG8gcmV2b2tl
IHRoZSBhY2Nlc3MgdG9rZW4gZm9yIGEgZ2l2ZW4gDQpjbGllbnQuIA0KPiANCj4gPiBJIHNlZSAt
IHlvdSdyZSBzYXlpbmcgdGhhdCByZXF1aXJpbmcgY2xpZW50IGNyZWRlbnRpYWxzIG9uIHRoZSBl
bmQgDQo+ID4gcG9pbnQgaXMgdGhlIHByb2JsZW0/IA0KPiA+IA0KPiA+IEluIGZhY3Qgd2hhdCBJ
IG1lYW50IHdhcyAtIHdoZW4gUk8gYXV0aG9yaXplcyB0aGUgYW4gYWNjZXNzIHRva2VuIA0KPiA+
IGZvciBjbGllbnQgZm9yIHBhcnRpY3VsYXIgc2NvcGUuIFRob3NlIGluZm9ybWF0aW9uIGFyZSBr
ZXB0IGF0IHRoZSBBUy4gDQoNCj4gPiANCj4gPiBOb3cgLSBpZiB0aGUgUk8gd2FudCB0byByZXZv
a2UgYWNjZXNzIGZyb20gdGhlIGNsaWVudCAtIHRoZSBSTyBuZWVkcw0KPiA+IHRvIGF1dGhlbnRp
Y2F0ZSBoaW0gc2VsZiB0byB0aGUgQVMgYW5kIHBhc3MgdGhlIGNvbnN1bWVyIGtleSBhbmQgdGhl
DQo+ID4gc2NvcGUuIFNvIEFTIGNhbiByZXZva2UgYWNjZXNzLiANCj4gPiANCj4gPiBUaGFua3Mg
JiByZWdhcmRzLCANCj4gPiAtUHJhYmF0aCANCj4gPiANCj4gPiANCj4gPiANCj4gPiANCj4gPiAN
Cj4gPiBUb2RkIExhaW5oYXJ0DQo+ID4gUmF0aW9uYWwgc29mdHdhcmUNCj4gPiBJQk0gQ29ycG9y
YXRpb24NCj4gPiA1NTAgS2luZyBTdHJlZXQsIExpdHRsZXRvbiwgTUEgMDE0NjAtMTI1MA0KPiA+
IDEtOTc4LTg5OS00NzA1DQo+ID4gMi0yNzYtNDcwNSAoVC9MKQ0KPiA+IGxhaW5oYXJ0QHVzLmli
bS5jb20gDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gDQo+IA0KPiA+IEZyb206ICAgICAg
ICBQcmFiYXRoIFNpcml3YXJkZW5hIDxwcmFiYXRoQHdzbzIuY29tPiANCj4gPiBUbzogICAgICAg
IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0cmUub3JnPiwgDQo+ID4gQ2M6ICAgICAgICAib2F1
dGhAaWV0Zi5vcmcgV0ciIDxvYXV0aEBpZXRmLm9yZz4gDQo+ID4gRGF0ZTogICAgICAgIDAyLzA2
LzIwMTMgMTA6MzEgQU0gDQo+ID4gU3ViamVjdDogICAgICAgIFJlOiBbT0FVVEgtV0ddIEEgcXVl
c3Rpb24gb24gdG9rZW4gcmV2b2NhdGlvbi4gDQo+ID4gU2VudCBieTogICAgICAgIG9hdXRoLWJv
dW5jZXNAaWV0Zi5vcmcgDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gDQoNCj4gPiBPbiBXZWQsIEZl
YiA2LCAyMDEzIGF0IDg6NDkgUE0sIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0cmUub3JnPiAN
Cndyb3RlOiANCj4gPiANCj4gPiBPbiAwMi8wNi8yMDEzIDEwOjEzIEFNLCBQcmFiYXRoIFNpcml3
YXJkZW5hIHdyb3RlOiANCj4gPiANCj4gPiANCj4gPiBPbiBXZWQsIEZlYiA2LCAyMDEzIGF0IDg6
MTkgUE0sIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0cmUub3JnPiANCndyb3RlOiANCj4gPiBU
aGVzZSBhcmUgZ2VuZXJhbGx5IGhhbmRsZWQgdGhyb3VnaCBhIHVzZXIgaW50ZXJmYWNlIHdoZXJl
IHRoZSBSTyBpcw0KPiA+IGF1dGhlbnRpY2F0ZWQgZGlyZWN0bHkgdG8gdGhlIEFTLCBhbmQgdGhl
cmUncyBub3QgbXVjaCBuZWVkIGZvciBhIA0KPiA+ICJwcm90b2NvbCIgaGVyZSwgaW4gcHJhY3Rp
Y2UuIA0KPiA+IA0KPiA+IFdoeSBkbyB5b3UgdGhpbmsgbGVhdmluZyBhY2Nlc3MgdG9rZW4gcmV2
b2NhdGlvbiBieSBSTyB0byBhIA0KPiA+IHByb3ByaWV0YXJ5IEFQSSBpcyBhIGdvb2QgcHJhY3Rp
Y2UgPyBJTU8gdGhpcyBhbiBlc3NlbnRpYWwgDQo+ID4gcmVxdWlyZW1lbnQgaW4gQVBJIHNlY3Vy
aXR5LiANCj4gPiBJIHRoaW5rIGl0IG1ha2VzIG1vcmUgc2Vuc2UgaW4gdGhlIHNhbWUgd2F5IHRo
YXQgaGF2aW5nIGEgDQo+ID4gInByb3ByaWV0YXJ5IiBVSS9BUEkgZm9yIG1hbmFnaW5nIHRoZSB1
c2VyIGNvbnNlbnQgbWFrZXMgc2Vuc2U6IA0KPiA+IHVubGVzcyB5b3UncmUgZG9pbmcgYSBmdWxs
eSBkeW5hbWljIGVuZC10by1lbmQgc3lzdGVtIGxpa2UgVU1BLCB0aGVuDQo+ID4gdGhlcmUncyBu
b3QgbXVjaCB2YWx1ZSBpbiB0cnlpbmcgdG8gc3F1ZWV6ZSBkaXNwYXJhdGUgc3lzdGVtcyBpbnRv
IA0KPiA+IHRoZSBzYW1lIG1vbGQsIHNpbmNlIHRoZXkgd29uJ3QgYmUgdGFsa2luZyB0byBlYWNo
IG90aGVyIGFueXdheS4gDQo+ID4gDQo+ID4gVGhpcyBpcyByZXF1aXJlZCBpbiBkaXN0cmlidXRl
ZCBzZXR1cCBmb3IgZWFjaCBBUEkgcGxhdGZvcm0gZnJvbSANCj4gPiBkaWZmZXJlbnQgdmVuZG9y
cyB0byBwZXJmb3JtIGluIGFuIGludGVyb3AgbWFubmVyLiANCj4gPiANCj4gPiANCj4gPiBBbmQg
c2luY2UgeW91IHJlZmVyIHRvIGl0IGFzIGFuICJBUEkiLCB3aGF0IHdpbGwgdGhlIFJPIGJlIHVz
aW5nIHRvIA0KPiA+IGNhbGwgdGhpcyBBUEk/IElzIHRoZXJlIGEgdG9rZW4gbWFuYWdlbWVudCBj
bGllbnQgdGhhdCdzIHNlcGFyYXRlIA0KPiA+IGZyb20gdGhlIE9BdXRoIGNsaWVudD8gDQo+ID4g
DQo+ID4gSSBkaWRuJ3QgZ2V0IHlvdXIgcXVlc3Rpb24gcmlnaHQuLi4gSWYgeW91IG1lYW50IHRo
ZSBob3cgdG8gaW52b2tlIA0KPiA+IHJldm9jYXRpb24gZW5kIHBvaW50LCB0aGUgdGhlIHJlc291
cmNlIG93bmVyIG5lZWRzIHRvIGtub3cgdGhlIA0KPiA+IGNvbnN1bWVyIGtleSAocmVwcmVzZW50
cyB0aGUgT0F1dGggQ2xpZW50IGFwcCkgJiBzY29wZSB0byByZXZva2UgdGhlDQo+ID4gYWNjZXNz
IHRva2VuIGZvciBhIGdpdmVuIGNsaWVudC4gDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gSU1ITyB0
b2tlbiByZXZvY2F0aW9uIGRvbmUgbXkgUk8gaXMgbW9yZSBwcmFjdGljYWwgdGhhbiB0b2tlbiAN
Cj4gPiByZXZvY2F0aW9uIGRvbmUgYnkgdGhlIENsaWVudC4gDQo+ID4gVGhleSdyZSBib3RoIHZh
bGlkIGJ1dCByZXF1aXJlIGRpZmZlcmVudCBraW5kcyBvZiBwcm90b2NvbHMgYW5kIA0KPiA+IGNv
bnNpZGVyYXRpb25zLiBUaGlzIHRva2VuIHJldm9jYXRpb24gZHJhZnQgaXMgbWVhbnQgdG8gc29s
dmUgb25lIA0KPiA+IHByb2JsZW0sIGFuZCB0aGF0IGRvZXNuJ3QgbWVhbiBpdCBjYW4gb3Igc2hv
dWxkIHNvbHZlIG90aGVyIA0KPiA+IHNlZW1pbmdseSByZWxhdGVkIHByb2JsZW1zLg0KPiA+IA0K
PiA+IElmIHlvdSB3b3VsZCBsaWtlIHRvIHNlZSB0aGUgUk8taW5pdGlhdGVkIHRva2VuIHJldm9j
YXRpb24gZ28gDQo+ID4gdGhyb3VnaCAobm90IGdyYW50IHJldm9jYXRpb24sIG1pbmQgeW91IC0t
IHRoYXQncyByZWxhdGVkLCBidXQgDQo+ID4gZGlmZmVyZW50KSwgdGhlbiBJIHdvdWxkIHN1Z2dl
c3QgdGhhdCB5b3Ugc3RhcnQgc3BlY2lmeWluZyBleGFjdGx5IA0KPiA+IGhvdyB0aGF0IHdvcmtz
LiBJIHByZWRpY3QgaXQgd2lsbCBiZSBwcm9ibGVtYXRpYyBpbiBwcmFjdGljZSwgDQo+ID4gdGhv
dWdoLCBhcyB0aGUgUk8gb2Z0ZW4gZG9lc24ndCBhY3R1YWxseSBoYXZlIGRpcmVjdCBhY2Nlc3Mg
dG8gdGhlIA0KPiA+IHRva2VuIGl0c2VsZi4gDQo+ID4gDQo+ID4gUmVzb3VyY2Ugb3duZXIgbmVl
ZHMgdG8ga25vdyB0aGUgY29uc3VtZXIga2V5IChyZXByZXNlbnRzIHRoZSBPQXV0aCANCj4gPiBD
bGllbnQgYXBwKSAmIHNjb3BlIHRvIHJldm9rZSB0aGUgYWNjZXNzIHRva2VuIGZvciBhIGdpdmVu
IGNsaWVudC4gDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gVGhlcmUgYXJlIGxhcmdlciBh
cHBsaWNhdGlvbnMsIGxpa2UgVU1BLCB0aGF0IGhhdmUgY2xpZW50IGFuZCBQUiANCj4gPiBwcm92
aXNpb25pbmcgdGhhdCB3b3VsZCBhbGxvdyBmb3IgdGhpcyB0byBiZSBtYW5hZ2VkIHNvbWV3aGF0
IA0KPiA+IHByb2dyYW1tYXRpY2FsbHksIGJ1dCBldmVuIGluIHRoYXQgY2FzZSB5b3UncmUgc3Rp
bGwgZ2VuZXJhbGx5IGRvaW5nDQo+ID4gdG9rZW4gcmV2b2NhdGlvbiBieSBhICJjbGllbnQiIGlu
IHNvbWUgZmFzaGlvbi4gSW4gVU1BLCB0aG91Z2gsIA0KPiA+IHNldmVyYWwgZGlmZmVyZW50IHBp
ZWNlcyBjYW4gcGxheSB0aGUgcm9sZSBvZiBhICJjbGllbnQiIGF0IA0KPiA+IGRpZmZlcmVudCBw
YXJ0cyBvZiB0aGUgcHJvY2Vzcy4NCj4gPiANCj4gPiBSZXZva2luZyBhIHNjb3BlIGlzIGEgd2hv
bGUgZGlmZmVyZW50IG1lc3MuIEdlbmVyYWxseSwgeW91J2Qgd2FudCB0bw0KPiA+IGp1c3QgcmV2
b2tlIGFuIGV4aXN0aW5nIHRva2VuIGFuZCBtYWtlIGEgbmV3IGF1dGhvcml6YXRpb24gZ3JhbnQg
DQo+ID4gd2l0aCBsb3dlciBhY2Nlc3MgaWYgeW91IGRvbid0IHdhbnQgdGhhdCBjbGllbnQgZ2V0
dGluZyB0aGF0IHNjb3BlIA0KPiA+IGFueW1vcmUuIElmIHlvdSBqdXN0IHdhbnQgdG8gZG93bnNj
b3BlIGZvciBhIHNpbmdsZSB0cmFuc2FjdGlvbiwgeW91DQo+ID4gY2FuIGFscmVhZHkgZG8gdGhh
dCB3aXRoIGVpdGhlciB0aGUgcmVmcmVzaCB0b2tlbiBvciB0b2tlbiBjaGFpbmluZyANCj4gPiBh
cHByb2FjaGVzLCBkZXBlbmRpbmcgb24gd2hlcmUgaW4gdGhlIHByb2Nlc3MgeW91IGFyZS4gVGhl
IGxhdHRlciBvZg0KPiA+IHRoZXNlIGFyZSBib3RoIGNsaWVudC1mb2N1c2VkLCB0aG91Z2gsIGFu
ZCB0aGUgUk8gZG9lc24ndCBoYXZlIGEgDQo+ID4gZGlyZWN0IGhhbmQgaW4gaXQgYXQgdGhpcyBw
b2ludC4gDQo+ID4gDQo+ID4gV2h5IGRvIHlvdSB0aGluayBpdCBhIG1lc3MuIElmIHlvdSByZXZv
a2UgdGhlIGVudGlyZSB0b2tlbiB0aGVuIA0KPiA+IENsaWVudCBuZWVkcyB0byBnbyB0aHJvdWdo
IHRoZSBjb21wbGV0ZSBPQXV0aCBmbG93IC0gYW5kIGFsc28gbmVlZHMgDQo+ID4gdG8gZ2V0IHRo
ZSB1c2VyIGNvbnNlbnQuIElmIFJPIGNhbiAgZG93bmdyYWRlIHRoZSBzY29wZSwgdGhlbiB3ZSAN
Cj4gPiByZXN0cmljdCBBUEkgYWNjZXNzIGJ5IHRoZSBjbGllbnQgYXQgUlMgZW5kIGFuZCBpdHMg
dHJhbnNwYXJlbnQgdG8gDQo+ID4gdGhlIGNsaWVudC4gDQo+ID4gDQo+ID4gDQo+ID4gRG93bmdy
YWRpbmcgdGhlIHNjb3BlIG9mIHRva2VucyBpbiB0aGUgd2lsZCBpcyBoYXJkbHkgdHJhbnNwYXJl
bnQgdG8NCj4gPiB0aGUgY2xpZW50IChzdHVmZiB0aGF0IGl0IGV4cGVjdHMgdG8gd29yayB3aWxs
IHN1ZGRlbmx5IHN0YXJ0IHRvIA0KPiA+IGZhaWwsIG1lYW5pbmcgdGhhdCBtb3N0IGNsaWVudHMg
d2lsbCB0aHJvdyBvdXQgdGhlIHRva2VuIGFuZCB0cnkgdG8gDQo+ID4gZ2V0IGEgbmV3IG9uZSks
IGFuZCBpbiBhIGRpc3RyaWJ1dGVkIHN5c3RlbSB5b3UndmUgZ290IHRvIHByb3BhZ2F0ZSANCj4g
PiB0aGF0IGNoYW5nZSB0byB0aGUgUlMuIElmIHlvdSBiYWtlIHRoZSBzY29wZXMgaW50byB0aGUg
dG9rZW4gaXRzZWxmIA0KPiA+ICh3aGljaCBtYW55IGRvKSB0aGVuIHlvdSBhY3R1YWxseSAqY2Fu
J3QqIGRvd25ncmFkZSBhIHNpbmdsZSB0b2tlbiwgDQphbnl3YXkuIA0KPiA+IA0KPiA+IFllcy4u
IHRoYXQgaXMgdGhlIGV4cGVjdGVkIGJlaGF2aW9yLiBJIG1lYW4gdGhlIHByb2Nlc3MgaXMgDQo+
ID4gdHJhbnNwYXJlbnQuIENsaWVudCB3aWxsIG5vdGljZSBhdCBydW50aW1lLiANCj4gPiANCj4g
PiBUaGFua3MgJiByZWdhcmRzLCANCj4gPiAtUHJhYmF0aCANCj4gPiANCj4gPiANCj4gPiAgLS0g
SnVzdGluIA0KPiA+IA0KPiA+IA0KPiA+IFRoYW5rcyAmIHJlZ2FyZHMsIA0KPiA+IC1QcmFiYXRo
IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+ICAtLSBKdXN0aW4gDQo+ID4gDQo+ID4gDQo+ID4gT24g
MDIvMDYvMjAxMyAwNDozNSBBTSwgUHJhYmF0aCBTaXJpd2FyZGVuYSB3cm90ZTogDQo+ID4gSSBh
bSBzb3JyeSBpZiB0aGlzIHdhcyBhbHJlYWR5IGRpc2N1c3NlZCBpbiB0aGlzIGxpc3QuLiANCj4g
PiANCj4gPiBMb29raW5nIGF0IFsxXSBpdCBvbmx5IHRhbGtzIGFib3V0IHJldm9raW5nIHRoZSBh
Y2Nlc3MgdG9rZW4gZnJvbSANCj4gdGhlIGNsaWVudC4gDQo+ID4gDQo+ID4gSG93IGFib3V0IHRo
ZSByZXNvdXJjZSBvd25lci4uPyANCj4gPiANCj4gPiBUaGVyZSBjYW4gYmUgY2FzZXMgd2hlcmUg
cmVzb3VyY2Ugb3duZXIgbmVlZHMgdG8gcmV2b2tlIGFuIA0KPiA+IGF1dGhvcml6ZWQgYWNjZXNz
IHRva2VuIGZyb20gYSBnaXZlbiBjbGllbnQuIE9yIHJldm9rZSBhbiBzY29wZS4uIA0KPiA+IA0K
PiA+IEhvdyBhcmUgd2UgZ29pbmcgdG8gYWRkcmVzcyB0aGVzZSByZXF1aXJlbWVudHMuLj8gVGhv
dWdodHMgDQphcHByZWNpYXRlZC4uLiANCj4gPiANCj4gPiBbMV0gaHR0cDovL3Rvb2xzLmlldGYu
b3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1yZXZvY2F0aW9uLTA0IA0KPiA+IA0KPiA+IC0tIA0K
PiA+IFRoYW5rcyAmIFJlZ2FyZHMsDQo+ID4gUHJhYmF0aCANCj4gPiANCj4gPiBNb2JpbGUgOiAr
OTQgNzEgODA5IDY3MzIgDQo+ID4gDQo+ID4gaHR0cDovL2Jsb2cuZmFjaWxlbG9naW4uY29tDQo+
ID4gaHR0cDovL1JhbXBhcnRGQVEuY29tIA0KPiA+IA0KPiA+IA0KPiA+IF9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gT0F1dGggbWFpbGluZyBsaXN0
DQo+ID4gT0F1dGhAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29hdXRoDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gLS0gDQo+ID4g
VGhhbmtzICYgUmVnYXJkcywNCj4gPiBQcmFiYXRoIA0KPiA+IA0KPiA+IE1vYmlsZSA6ICs5NCA3
MSA4MDkgNjczMiANCj4gPiANCj4gPiBodHRwOi8vYmxvZy5mYWNpbGVsb2dpbi5jb20NCj4gPiBo
dHRwOi8vUmFtcGFydEZBUS5jb20gDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gLS0gDQo+
ID4gVGhhbmtzICYgUmVnYXJkcywNCj4gPiBQcmFiYXRoIA0KPiA+IA0KPiA+IE1vYmlsZSA6ICs5
NCA3MSA4MDkgNjczMiANCj4gPiANCj4gPiBodHRwOi8vYmxvZy5mYWNpbGVsb2dpbi5jb20gDQo+
ID4gaHR0cDovL1JhbXBhcnRGQVEuY29tX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCj4gPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gPiBPQXV0aEBpZXRmLm9y
Zw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4gDQo+
ID4gDQo+IA0KPiA+IA0KPiA+IC0tIA0KPiA+IFRoYW5rcyAmIFJlZ2FyZHMsDQo+ID4gUHJhYmF0
aCANCj4gPiANCj4gPiBNb2JpbGUgOiArOTQgNzEgODA5IDY3MzIgDQo+ID4gDQo+ID4gaHR0cDov
L2Jsb2cuZmFjaWxlbG9naW4uY29tDQo+ID4gaHR0cDovL1JhbXBhcnRGQVEuY29tIA0KPiA+IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gT0F1dGgg
bWFpbGluZyBsaXN0DQo+ID4gT0F1dGhAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIA0KPiA+IA0KPiANCj4gPiANCj4gPiAtLSANCj4gPiBU
aGFua3MgJiBSZWdhcmRzLA0KPiA+IFByYWJhdGggDQo+ID4gDQo+ID4gTW9iaWxlIDogKzk0IDcx
IDgwOSA2NzMyIA0KPiA+IA0KPiA+IGh0dHA6Ly9ibG9nLmZhY2lsZWxvZ2luLmNvbQ0KPiA+IGh0
dHA6Ly9SYW1wYXJ0RkFRLmNvbV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQo+ID4gT0F1dGggbWFpbGluZyBsaXN0DQo+ID4gT0F1dGhAaWV0Zi5vcmcNCj4g
PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+IA0KDQo+IA0K
PiAtLSANCj4gVGhhbmtzICYgUmVnYXJkcywNCj4gUHJhYmF0aA0KPiANCj4gTW9iaWxlIDogKzk0
IDcxIDgwOSA2NzMyIA0KPiANCj4gaHR0cDovL2Jsb2cuZmFjaWxlbG9naW4uY29tDQo+IGh0dHA6
Ly9SYW1wYXJ0RkFRLmNvbQ0K
--=_alternative 00303F2748257B0B_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yPkR1cmluZyB0aGUgZm91ciBncmFudCB0eXBlcyBvZiBPYXV0aCw8
L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPiZuYnNwOyAxLiBhdXRob3JpemF0aW9uIGNvZGU6IFJP
IGtub3dzIHRoZSBhdXRob3JpemF0aW9uDQpjb2RlIHVwb24gd2hpY2ggYWNjZXNzLXRva2Vucy10
by1iZS1yZXZva2VkIGFyZSBpc3N1ZWQgJm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj4m
bmJzcDsgMi4gaW1wbGljaXRlIGZsb3c6IFJPIGtub3dzIHRoZSBhY2Nlc3MtdG9rZW5zLXRvLWJl
LXJldm9rZWQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPiZuYnNwOyAzLiBwYXNzd29yZCBhbmQg
Y2xpZW50IGNyZWRlbnRpYWwgdHlwZXM6IFJPIGhhcw0Kbm8gd2F5IG9mIGtub3dpbmcgYWNjZXNz
IHRva2Vucy4gJm5ic3A7IDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+U28sSU1PLCAm
bmJzcDtpdCBpcyBub3QgcHJvcGVyIGZvciBSTyB0byByZXZva2UgYW4gZWFjaA0KYWNjZXNzIHRv
a2VuIGluZGl2aWR1YWxseSw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPnJhdGhlciBpdCBjb3Vs
ZCByZXZva2Ugc29tZSBhY2Nlc3MgdG9rZW5zIGJ5IHNwZWNpZnlpbmcNCmNvbmRpdGlvbnMsIHN1
Y2ggYXMgY2xpZW50X2lkLCB0aW1lX3BlcmlvZCwgc2NvcGUgPC9mb250Pg0KPGJyPjxmb250IHNp
emU9Mj5Db21tZW50cz8gPC9mb250Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+UHJhYmF0
aCBTaXJpd2FyZGVuYSAmbHQ7cHJhYmF0aEB3c28yLmNvbSZndDsg0LTT2g0KMjAxMy0wMi0wNyAx
NToyNTowMjo8YnI+DQo8YnI+DQomZ3Q7IDxicj4NCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u
dCBzaXplPTI+Jmd0OyBPbiBUaHUsIEZlYiA3LCAyMDEzIGF0IDEyOjQ5IFBNLCAmbHQ7emhvdS5z
dWppbmdAenRlLmNvbS5jbiZndDsNCndyb3RlOjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz
aXplPTI+Jmd0OyA8YnI+DQomZ3Q7IEkgZ3Vlc3MgUk8gY291bGQgaW5pdGlhdGUgYWNjZXNzIHRv
a2VuIHJldm9jYXRpb24gZm9yIGEgY2xpZW50IGJ5DQo8YnI+DQomZ3Q7IGluY2x1ZGluZyBhdXRo
b3JpemF0aW9uIGNvZGUgaW4gdGhlIHJlcXVlc3QgdG8gQVMuIDxicj4NCiZndDsgQ29tbWVudHM/
IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFRoYXQg
Y3JlYXRlcyBhIGRlcGVuZGVuY3kgb24gdGhlIGdyYW50IHR5cGUuPC9mb250PjwvdHQ+DQo8YnI+
PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgVGhhbmtzICZhbXA7IHJlZ2FyZHMsPC9m
b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IC1QcmFiYXRoPC9mb250PjwvdHQ+
DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48
Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQom
Z3Q7IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcg0LTT2iAyMDEzLTAyLTA3IDAyOjMyOjI4Ojxicj4N
CiZndDsgPGJyPg0KJmd0OyAmZ3Q7IEhpIFRvcnN0ZW4sIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48
Zm9udCBzaXplPTI+Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBUaGFua3MgZm9yIHlvdXIgZmVl
ZGJhY2suLiBJIHdpbGwgc3VibWl0IGEgZHJhZnQuLi4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZn
dDsgJmd0OyBUaGFua3MgJmFtcDsgcmVnYXJkcywgPGJyPg0KJmd0OyAmZ3Q7IC1QcmFiYXRoPGJy
Pg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgT24gV2VkLCBGZWIgNiwgMjAxMyBhdCAxMTo1NSBQTSwg
VG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7PGJyPg0KJmd0OyB0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5l
dDxicj4NCiZndDsgJmd0OyAmZ3Q7IHdyb3RlOiA8YnI+DQomZ3Q7ICZndDsgSGkgUHJhYmF0aCwg
PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyB3ZSB0cmllZCB0byBhZGRyZXNzIGJvdGgg
dXNlIGNhc2VzIGluIHRoZSBmaXJzdCByZXZpc2lvbnMgb2YNCnRoZSA8YnI+DQomZ3Q7ICZndDsg
ZHJhZnQuIFRoZSBBUEkgd2FzIHdlbGwgc3VpdGVkIGZvciBjbGllbnQtZHJpdmVuIHJldm9jYXRp
b24gYnV0DQpub3QgPGJyPg0KJmd0OyAmZ3Q7IHRoZSByZXNvdXJjZSBvd25lciAtIGRyaXZlbiB1
c2UgY2FzZS4gVGhlcmUgYXJlIGRlZmluaXRlbHkgPGJyPg0KJmd0OyAmZ3Q7IGRpZmZlcmVuY2Vz
IHdpdGggcmVzcGVjdCB0byB0aGUgcHJvdG9jb2wgZGVzaWduLCBhdCBsZWFzdCByZWdhcmRpbmcN
Cjxicj4NCiZndDsgJmd0OyBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBvZiB0aGUg
cmVzcGVjdGl2ZSBhY3RvcnMuIFRoaXMNCm1hZGU8YnI+DQomZ3Q7ICZndDsgdGhlIHNwZWMgbW9y
ZSBjb21wbGV4IGFuZCBjYXVzZWQgYW1iaWd1aXRpZXMgYW5kIGNvbmZ1c2lvbi4gPGJyPg0KJmd0
OyAmZ3Q7IE1vcmVvdmVyLCB0aGUgd29ya2luZyBncm91cCBzZWVtZWQgbm90IGNvbnZpbmNlZCBi
eSB0aGUgdGhlIGxhdHRlcnVzZQ0KY2FzZS48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7
IFRoZXJlZm9yZSB0aGUgd29ya2luZyBncm91cCBkZWNpZGVkIHRvIGZvY3VzIG9uIHRoZSBzaW5n
bGUgdXNlDQpjYXNlczxicj4NCiZndDsgJmd0OyBvZiB0aGUgcmV2b2NhdGlvbiBieSBjbGllbnRz
LiBUaGlzIG1ha2VzIGEgbG90IG9mIHNlbnNlIHNpbmNlDQp0aGlzIDxicj4NCiZndDsgJmd0OyBp
bnRlcmZhY2UgaXMgbW9zdCBpbXBvcnRhbnQgd2l0aCByZXNwZWN0IHRvIGludGVyb3BlcmFiaWxp
dHkuDQo8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEknbSBmb2N1c2luZyByaWdodCBu
b3cgb24gZmluaXNoaW5nIHRoaXMgZHJhZnQuIEFuZCB0aGUgb3Blbg0KaXNzdWVzIDxicj4NCiZn
dDsgJmd0OyBkaXNjdXNzZWQgb24gdGhlIGxpc3QgaW4gdGhlIGxhc3QgY291cGxlIG9mIHdlZWtz
IGlsbHVzdHJhdGUNCnRoYXQgPGJyPg0KJmd0OyAmZ3Q7IGV2ZW4gdGhpcyBwb3NlcyBhIGNvbnNp
ZGVyYWJsZSBhbW91bnQgb2Ygd29yay4gU28gSSdtIHZlcnkgcmVsdWN0YW50PGJyPg0KJmd0OyAm
Z3Q7IHRvIGFkZCBzdXBwb3J0IGZvciBhIHdob2xlIG5ldyB1c2UgY2FzZSBhdCB0aGF0IHBvaW50
IG9mIHRoZQ0KcHJvY2Vzcy4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJZiB5b3Ug
ZmVlbCB0aGlzIGlzIGFuIGltcG9ydGFudCB1c2UgY2FzZSB3b3J0aCBhbiBSRkMsIGRvbid0DQo8
YnI+DQomZ3Q7ICZndDsgaGVzaXRhdGUgdG8gcHVibGlzaCBhIG5ldyBJLUQuIDxicj4NCiZndDsg
Jmd0OyA8YnI+DQomZ3Q7ICZndDsgcmVnYXJkcywgPGJyPg0KJmd0OyAmZ3Q7IFRvcnN0ZW4uIDxi
cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgQW0gMDYuMDIuMjAxMyB1bSAxNjozNyBzY2hy
aWViIFByYWJhdGggU2lyaXdhcmRlbmEgJmx0O3ByYWJhdGhAd3NvMi5jb20mZ3Q7Ojxicj4NCiZn
dDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IE9uIFdlZCwgRmVi
IDYsIDIwMTMgYXQgOTowNCBQTSwgVG9kZCBXIExhaW5oYXJ0ICZsdDtsYWluaGFydEB1cy5pYm0u
Y29tJmd0Ow0Kd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgUmVzb3VyY2Ugb3duZXIgbmVlZHMg
dG8ga25vdyB0aGUgY29uc3VtZXIga2V5IChyZXByZXNlbnRzDQp0aGUgPGJyPg0KJmd0OyAmZ3Q7
IE9BdXRoIENsaWVudCBhcHApICZhbXA7IHNjb3BlIHRvIHJldm9rZSB0aGUgYWNjZXNzIHRva2Vu
IGZvcg0KYSBnaXZlbiBjbGllbnQuICZuYnNwOzxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IEkg
c2VlIC0geW91J3JlIHNheWluZyB0aGF0IHJlcXVpcmluZyBjbGllbnQgY3JlZGVudGlhbHMgb24g
dGhlDQplbmQgPGJyPg0KJmd0OyAmZ3Q7IHBvaW50IGlzIHRoZSBwcm9ibGVtPyA8YnI+DQomZ3Q7
ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEluIGZhY3Qgd2hhdCBJIG1lYW50IHdhcyAtIHdoZW4gUk8g
YXV0aG9yaXplcyB0aGUgYW4gYWNjZXNzIHRva2VuDQo8YnI+DQomZ3Q7ICZndDsgZm9yIGNsaWVu
dCBmb3IgcGFydGljdWxhciBzY29wZS4gVGhvc2UgaW5mb3JtYXRpb24gYXJlIGtlcHQgYXQNCnRo
ZSBBUy4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBOb3cgLSBpZiB0aGUgUk8gd2Fu
dCB0byByZXZva2UgYWNjZXNzIGZyb20gdGhlIGNsaWVudCAtIHRoZSBSTw0KbmVlZHM8YnI+DQom
Z3Q7ICZndDsgdG8gYXV0aGVudGljYXRlIGhpbSBzZWxmIHRvIHRoZSBBUyBhbmQgcGFzcyB0aGUg
Y29uc3VtZXIga2V5DQphbmQgdGhlPGJyPg0KJmd0OyAmZ3Q7IHNjb3BlLiBTbyBBUyBjYW4gcmV2
b2tlIGFjY2Vzcy4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBUaGFua3MgJmFtcDsg
cmVnYXJkcywgPGJyPg0KJmd0OyAmZ3Q7IC1QcmFiYXRoIDxicj4NCiZndDsgJmd0OyAmbmJzcDsg
PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0
OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBUb2RkIExhaW5oYXJ0PGJyPg0KJmd0OyAmZ3Q7IFJhdGlv
bmFsIHNvZnR3YXJlPGJyPg0KJmd0OyAmZ3Q7IElCTSBDb3Jwb3JhdGlvbjxicj4NCiZndDsgJmd0
OyA1NTAgS2luZyBTdHJlZXQsIExpdHRsZXRvbiwgTUEgMDE0NjAtMTI1MDxicj4NCiZndDsgJmd0
OyAxLTk3OC04OTktNDcwNTxicj4NCiZndDsgJmd0OyAyLTI3Ni00NzA1IChUL0wpPGJyPg0KJmd0
OyAmZ3Q7IGxhaW5oYXJ0QHVzLmlibS5jb20gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0
OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQom
Z3Q7IDxicj4NCiZndDsgJmd0OyBGcm9tOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtQcmFi
YXRoIFNpcml3YXJkZW5hICZsdDtwcmFiYXRoQHdzbzIuY29tJmd0Ow0KPGJyPg0KJmd0OyAmZ3Q7
IFRvOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtKdXN0aW4gUmljaGVyICZsdDtqcmljaGVy
QG1pdHJlLm9yZyZndDssDQo8YnI+DQomZ3Q7ICZndDsgQ2M6ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyZxdW90O29hdXRoQGlldGYub3JnIFdHJnF1b3Q7DQombHQ7b2F1dGhAaWV0Zi5vcmcm
Z3Q7IDxicj4NCiZndDsgJmd0OyBEYXRlOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDswMi8w
Ni8yMDEzIDEwOjMxIEFNIDxicj4NCiZndDsgJmd0OyBTdWJqZWN0OiAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDtSZTogW09BVVRILVdHXSBBIHF1ZXN0aW9uDQpvbiB0b2tlbiByZXZvY2F0aW9u
LiA8YnI+DQomZ3Q7ICZndDsgU2VudCBieTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7b2F1
dGgtYm91bmNlc0BpZXRmLm9yZyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4N
CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm
b250IHNpemU9Mj4mZ3Q7ICZndDsgT24gV2VkLCBGZWIgNiwgMjAxMyBhdCA4OjQ5IFBNLCBKdXN0
aW4gUmljaGVyDQombHQ7anJpY2hlckBtaXRyZS5vcmcmZ3Q7IHdyb3RlOiA8YnI+DQomZ3Q7ICZn
dDsgPGJyPg0KJmd0OyAmZ3Q7IE9uIDAyLzA2LzIwMTMgMTA6MTMgQU0sIFByYWJhdGggU2lyaXdh
cmRlbmEgd3JvdGU6IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm
Z3Q7IE9uIFdlZCwgRmViIDYsIDIwMTMgYXQgODoxOSBQTSwgSnVzdGluIFJpY2hlciAmbHQ7anJp
Y2hlckBtaXRyZS5vcmcmZ3Q7DQp3cm90ZTogPGJyPg0KJmd0OyAmZ3Q7IFRoZXNlIGFyZSBnZW5l
cmFsbHkgaGFuZGxlZCB0aHJvdWdoIGEgdXNlciBpbnRlcmZhY2Ugd2hlcmUgdGhlDQpSTyBpczxi
cj4NCiZndDsgJmd0OyBhdXRoZW50aWNhdGVkIGRpcmVjdGx5IHRvIHRoZSBBUywgYW5kIHRoZXJl
J3Mgbm90IG11Y2ggbmVlZCBmb3INCmEgPGJyPg0KJmd0OyAmZ3Q7ICZxdW90O3Byb3RvY29sJnF1
b3Q7IGhlcmUsIGluIHByYWN0aWNlLiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFdo
eSBkbyB5b3UgdGhpbmsgbGVhdmluZyBhY2Nlc3MgdG9rZW4gcmV2b2NhdGlvbiBieSBSTyB0byBh
IDxicj4NCiZndDsgJmd0OyBwcm9wcmlldGFyeSBBUEkgaXMgYSBnb29kIHByYWN0aWNlID8gSU1P
IHRoaXMgYW4gZXNzZW50aWFsIDxicj4NCiZndDsgJmd0OyByZXF1aXJlbWVudCBpbiBBUEkgc2Vj
dXJpdHkuIDxicj4NCiZndDsgJmd0OyBJIHRoaW5rIGl0IG1ha2VzIG1vcmUgc2Vuc2UgaW4gdGhl
IHNhbWUgd2F5IHRoYXQgaGF2aW5nIGEgPGJyPg0KJmd0OyAmZ3Q7ICZxdW90O3Byb3ByaWV0YXJ5
JnF1b3Q7IFVJL0FQSSBmb3IgbWFuYWdpbmcgdGhlIHVzZXIgY29uc2VudA0KbWFrZXMgc2Vuc2U6
IDxicj4NCiZndDsgJmd0OyB1bmxlc3MgeW91J3JlIGRvaW5nIGEgZnVsbHkgZHluYW1pYyBlbmQt
dG8tZW5kIHN5c3RlbSBsaWtlIFVNQSwNCnRoZW48YnI+DQomZ3Q7ICZndDsgdGhlcmUncyBub3Qg
bXVjaCB2YWx1ZSBpbiB0cnlpbmcgdG8gc3F1ZWV6ZSBkaXNwYXJhdGUgc3lzdGVtcw0KaW50byA8
YnI+DQomZ3Q7ICZndDsgdGhlIHNhbWUgbW9sZCwgc2luY2UgdGhleSB3b24ndCBiZSB0YWxraW5n
IHRvIGVhY2ggb3RoZXIgYW55d2F5Lg0KPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBU
aGlzIGlzIHJlcXVpcmVkIGluIGRpc3RyaWJ1dGVkIHNldHVwIGZvciBlYWNoIEFQSSBwbGF0Zm9y
bSBmcm9tDQo8YnI+DQomZ3Q7ICZndDsgZGlmZmVyZW50IHZlbmRvcnMgdG8gcGVyZm9ybSBpbiBh
biBpbnRlcm9wIG1hbm5lci4gPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsg
PGJyPg0KJmd0OyAmZ3Q7IEFuZCBzaW5jZSB5b3UgcmVmZXIgdG8gaXQgYXMgYW4gJnF1b3Q7QVBJ
JnF1b3Q7LCB3aGF0IHdpbGwgdGhlDQpSTyBiZSB1c2luZyB0byA8YnI+DQomZ3Q7ICZndDsgY2Fs
bCB0aGlzIEFQST8gSXMgdGhlcmUgYSB0b2tlbiBtYW5hZ2VtZW50IGNsaWVudCB0aGF0J3Mgc2Vw
YXJhdGUNCjxicj4NCiZndDsgJmd0OyBmcm9tIHRoZSBPQXV0aCBjbGllbnQ/IDxicj4NCiZndDsg
Jmd0OyA8YnI+DQomZ3Q7ICZndDsgSSBkaWRuJ3QgZ2V0IHlvdXIgcXVlc3Rpb24gcmlnaHQuLi4g
SWYgeW91IG1lYW50IHRoZSBob3cgdG8gaW52b2tlDQo8YnI+DQomZ3Q7ICZndDsgcmV2b2NhdGlv
biBlbmQgcG9pbnQsIHRoZSB0aGUgcmVzb3VyY2Ugb3duZXIgbmVlZHMgdG8ga25vdyB0aGUNCjxi
cj4NCiZndDsgJmd0OyBjb25zdW1lciBrZXkgKHJlcHJlc2VudHMgdGhlIE9BdXRoIENsaWVudCBh
cHApICZhbXA7IHNjb3BlIHRvDQpyZXZva2UgdGhlPGJyPg0KJmd0OyAmZ3Q7IGFjY2VzcyB0b2tl
biBmb3IgYSBnaXZlbiBjbGllbnQuICZuYnNwOzxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn
dDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJTUhPIHRva2VuIHJldm9jYXRpb24g
ZG9uZSBteSBSTyBpcyBtb3JlIHByYWN0aWNhbCB0aGFuIHRva2VuDQo8YnI+DQomZ3Q7ICZndDsg
cmV2b2NhdGlvbiBkb25lIGJ5IHRoZSBDbGllbnQuIDxicj4NCiZndDsgJmd0OyBUaGV5J3JlIGJv
dGggdmFsaWQgYnV0IHJlcXVpcmUgZGlmZmVyZW50IGtpbmRzIG9mIHByb3RvY29scyBhbmQNCjxi
cj4NCiZndDsgJmd0OyBjb25zaWRlcmF0aW9ucy4gVGhpcyB0b2tlbiByZXZvY2F0aW9uIGRyYWZ0
IGlzIG1lYW50IHRvIHNvbHZlDQpvbmUgPGJyPg0KJmd0OyAmZ3Q7IHByb2JsZW0sIGFuZCB0aGF0
IGRvZXNuJ3QgbWVhbiBpdCBjYW4gb3Igc2hvdWxkIHNvbHZlIG90aGVyIDxicj4NCiZndDsgJmd0
OyBzZWVtaW5nbHkgcmVsYXRlZCBwcm9ibGVtcy48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm
Z3Q7IElmIHlvdSB3b3VsZCBsaWtlIHRvIHNlZSB0aGUgUk8taW5pdGlhdGVkIHRva2VuIHJldm9j
YXRpb24gZ28NCjxicj4NCiZndDsgJmd0OyB0aHJvdWdoIChub3QgZ3JhbnQgcmV2b2NhdGlvbiwg
bWluZCB5b3UgLS0gdGhhdCdzIHJlbGF0ZWQsIGJ1dA0KPGJyPg0KJmd0OyAmZ3Q7IGRpZmZlcmVu
dCksIHRoZW4gSSB3b3VsZCBzdWdnZXN0IHRoYXQgeW91IHN0YXJ0IHNwZWNpZnlpbmcgZXhhY3Rs
eQ0KPGJyPg0KJmd0OyAmZ3Q7IGhvdyB0aGF0IHdvcmtzLiBJIHByZWRpY3QgaXQgd2lsbCBiZSBw
cm9ibGVtYXRpYyBpbiBwcmFjdGljZSwNCjxicj4NCiZndDsgJmd0OyB0aG91Z2gsIGFzIHRoZSBS
TyBvZnRlbiBkb2Vzbid0IGFjdHVhbGx5IGhhdmUgZGlyZWN0IGFjY2VzcyB0bw0KdGhlIDxicj4N
CiZndDsgJmd0OyB0b2tlbiBpdHNlbGYuIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg
UmVzb3VyY2Ugb3duZXIgbmVlZHMgdG8ga25vdyB0aGUgY29uc3VtZXIga2V5IChyZXByZXNlbnRz
IHRoZQ0KT0F1dGggPGJyPg0KJmd0OyAmZ3Q7IENsaWVudCBhcHApICZhbXA7IHNjb3BlIHRvIHJl
dm9rZSB0aGUgYWNjZXNzIHRva2VuIGZvciBhIGdpdmVuDQpjbGllbnQuICZuYnNwOzxicj4NCiZn
dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7
ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyBUaGVyZSBhcmUgbGFyZ2VyIGFwcGxpY2F0aW9u
cywgbGlrZSBVTUEsIHRoYXQgaGF2ZSBjbGllbnQgYW5kDQpQUiA8YnI+DQomZ3Q7ICZndDsgcHJv
dmlzaW9uaW5nIHRoYXQgd291bGQgYWxsb3cgZm9yIHRoaXMgdG8gYmUgbWFuYWdlZCBzb21ld2hh
dA0KPGJyPg0KJmd0OyAmZ3Q7IHByb2dyYW1tYXRpY2FsbHksIGJ1dCBldmVuIGluIHRoYXQgY2Fz
ZSB5b3UncmUgc3RpbGwgZ2VuZXJhbGx5DQpkb2luZzxicj4NCiZndDsgJmd0OyB0b2tlbiByZXZv
Y2F0aW9uIGJ5IGEgJnF1b3Q7Y2xpZW50JnF1b3Q7IGluIHNvbWUgZmFzaGlvbi4gSW4NClVNQSwg
dGhvdWdoLCA8YnI+DQomZ3Q7ICZndDsgc2V2ZXJhbCBkaWZmZXJlbnQgcGllY2VzIGNhbiBwbGF5
IHRoZSByb2xlIG9mIGEgJnF1b3Q7Y2xpZW50JnF1b3Q7DQphdCA8YnI+DQomZ3Q7ICZndDsgZGlm
ZmVyZW50IHBhcnRzIG9mIHRoZSBwcm9jZXNzLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn
dDsgUmV2b2tpbmcgYSBzY29wZSBpcyBhIHdob2xlIGRpZmZlcmVudCBtZXNzLiBHZW5lcmFsbHks
IHlvdSdkDQp3YW50IHRvPGJyPg0KJmd0OyAmZ3Q7IGp1c3QgcmV2b2tlIGFuIGV4aXN0aW5nIHRv
a2VuIGFuZCBtYWtlIGEgbmV3IGF1dGhvcml6YXRpb24gZ3JhbnQNCjxicj4NCiZndDsgJmd0OyB3
aXRoIGxvd2VyIGFjY2VzcyBpZiB5b3UgZG9uJ3Qgd2FudCB0aGF0IGNsaWVudCBnZXR0aW5nIHRo
YXQNCnNjb3BlIDxicj4NCiZndDsgJmd0OyBhbnltb3JlLiBJZiB5b3UganVzdCB3YW50IHRvIGRv
d25zY29wZSBmb3IgYSBzaW5nbGUgdHJhbnNhY3Rpb24sDQp5b3U8YnI+DQomZ3Q7ICZndDsgY2Fu
IGFscmVhZHkgZG8gdGhhdCB3aXRoIGVpdGhlciB0aGUgcmVmcmVzaCB0b2tlbiBvciB0b2tlbiBj
aGFpbmluZw0KPGJyPg0KJmd0OyAmZ3Q7IGFwcHJvYWNoZXMsIGRlcGVuZGluZyBvbiB3aGVyZSBp
biB0aGUgcHJvY2VzcyB5b3UgYXJlLiBUaGUgbGF0dGVyDQpvZjxicj4NCiZndDsgJmd0OyB0aGVz
ZSBhcmUgYm90aCBjbGllbnQtZm9jdXNlZCwgdGhvdWdoLCBhbmQgdGhlIFJPIGRvZXNuJ3QgaGF2
ZQ0KYSA8YnI+DQomZ3Q7ICZndDsgZGlyZWN0IGhhbmQgaW4gaXQgYXQgdGhpcyBwb2ludC4gPGJy
Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBXaHkgZG8geW91IHRoaW5rIGl0IGEgbWVzcy4g
SWYgeW91IHJldm9rZSB0aGUgZW50aXJlIHRva2VuIHRoZW4NCjxicj4NCiZndDsgJmd0OyBDbGll
bnQgbmVlZHMgdG8gZ28gdGhyb3VnaCB0aGUgY29tcGxldGUgT0F1dGggZmxvdyAtIGFuZCBhbHNv
DQpuZWVkcyA8YnI+DQomZ3Q7ICZndDsgdG8gZ2V0IHRoZSB1c2VyIGNvbnNlbnQuIElmIFJPIGNh
biAmbmJzcDtkb3duZ3JhZGUgdGhlIHNjb3BlLA0KdGhlbiB3ZSA8YnI+DQomZ3Q7ICZndDsgcmVz
dHJpY3QgQVBJIGFjY2VzcyBieSB0aGUgY2xpZW50IGF0IFJTIGVuZCBhbmQgaXRzIHRyYW5zcGFy
ZW50DQp0byA8YnI+DQomZ3Q7ICZndDsgdGhlIGNsaWVudC4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4N
CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgRG93bmdyYWRpbmcgdGhlIHNjb3BlIG9mIHRva2Vu
cyBpbiB0aGUgd2lsZCBpcyBoYXJkbHkgdHJhbnNwYXJlbnQNCnRvPGJyPg0KJmd0OyAmZ3Q7IHRo
ZSBjbGllbnQgKHN0dWZmIHRoYXQgaXQgZXhwZWN0cyB0byB3b3JrIHdpbGwgc3VkZGVubHkgc3Rh
cnQNCnRvIDxicj4NCiZndDsgJmd0OyBmYWlsLCBtZWFuaW5nIHRoYXQgbW9zdCBjbGllbnRzIHdp
bGwgdGhyb3cgb3V0IHRoZSB0b2tlbiBhbmQNCnRyeSB0byA8YnI+DQomZ3Q7ICZndDsgZ2V0IGEg
bmV3IG9uZSksIGFuZCBpbiBhIGRpc3RyaWJ1dGVkIHN5c3RlbSB5b3UndmUgZ290IHRvIHByb3Bh
Z2F0ZQ0KPGJyPg0KJmd0OyAmZ3Q7IHRoYXQgY2hhbmdlIHRvIHRoZSBSUy4gSWYgeW91IGJha2Ug
dGhlIHNjb3BlcyBpbnRvIHRoZSB0b2tlbg0KaXRzZWxmIDxicj4NCiZndDsgJmd0OyAod2hpY2gg
bWFueSBkbykgdGhlbiB5b3UgYWN0dWFsbHkgKmNhbid0KiBkb3duZ3JhZGUgYSBzaW5nbGUNCnRv
a2VuLCBhbnl3YXkuIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgWWVzLi4gdGhhdCBp
cyB0aGUgZXhwZWN0ZWQgYmVoYXZpb3IuIEkgbWVhbiB0aGUgcHJvY2VzcyBpcyA8YnI+DQomZ3Q7
ICZndDsgdHJhbnNwYXJlbnQuIENsaWVudCB3aWxsIG5vdGljZSBhdCBydW50aW1lLiA8YnI+DQom
Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRoYW5rcyAmYW1wOyByZWdhcmRzLCA8YnI+DQomZ3Q7
ICZndDsgLVByYWJhdGggPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgPGJy
Pg0KJmd0OyAmZ3Q7ICZuYnNwOy0tIEp1c3RpbiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm
Z3Q7IDxicj4NCiZndDsgJmd0OyBUaGFua3MgJmFtcDsgcmVnYXJkcywgPGJyPg0KJmd0OyAmZ3Q7
IC1QcmFiYXRoIDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZn
dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7LS0gSnVzdGluIDxicj4NCiZndDsgJmd0OyA8
YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IE9uIDAyLzA2LzIwMTMgMDQ6MzUgQU0sIFBy
YWJhdGggU2lyaXdhcmRlbmEgd3JvdGU6IDxicj4NCiZndDsgJmd0OyBJIGFtIHNvcnJ5IGlmIHRo
aXMgd2FzIGFscmVhZHkgZGlzY3Vzc2VkIGluIHRoaXMgbGlzdC4uICZuYnNwOzxicj4NCiZndDsg
Jmd0OyA8YnI+DQomZ3Q7ICZndDsgTG9va2luZyBhdCBbMV0gaXQgb25seSB0YWxrcyBhYm91dCBy
ZXZva2luZyB0aGUgYWNjZXNzIHRva2VuDQpmcm9tIDxicj4NCiZndDsgdGhlIGNsaWVudC4gPGJy
Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBIb3cgYWJvdXQgdGhlIHJlc291cmNlIG93bmVy
Li4/IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhlcmUgY2FuIGJlIGNhc2VzIHdo
ZXJlIHJlc291cmNlIG93bmVyIG5lZWRzIHRvIHJldm9rZSBhbiA8YnI+DQomZ3Q7ICZndDsgYXV0
aG9yaXplZCBhY2Nlc3MgdG9rZW4gZnJvbSBhIGdpdmVuIGNsaWVudC4gT3IgcmV2b2tlIGFuIHNj
b3BlLi4NCjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSG93IGFyZSB3ZSBnb2luZyB0
byBhZGRyZXNzIHRoZXNlIHJlcXVpcmVtZW50cy4uPyBUaG91Z2h0cyBhcHByZWNpYXRlZC4uLg0K
PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBbMV0gaHR0cDovL3Rvb2xzLmlldGYub3Jn
L2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1yZXZvY2F0aW9uLTA0DQo8YnI+DQomZ3Q7ICZndDsgPGJy
Pg0KJmd0OyAmZ3Q7IC0tIDxicj4NCiZndDsgJmd0OyBUaGFua3MgJmFtcDsgUmVnYXJkcyw8YnI+
DQomZ3Q7ICZndDsgUHJhYmF0aCA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IE1vYmls
ZSA6ICs5NCA3MSA4MDkgNjczMiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IGh0dHA6
Ly9ibG9nLmZhY2lsZWxvZ2luLmNvbTxicj4NCiZndDsgJmd0OyBodHRwOi8vUmFtcGFydEZBUS5j
b20gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsg
T0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7IE9BdXRoQGlldGYub3JnPGJyPg0KJmd0
OyAmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8YnI+DQom
Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg
PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAtLSA8YnI+DQomZ3Q7ICZndDsgVGhhbmtz
ICZhbXA7IFJlZ2FyZHMsPGJyPg0KJmd0OyAmZ3Q7IFByYWJhdGggPGJyPg0KJmd0OyAmZ3Q7IDxi
cj4NCiZndDsgJmd0OyBNb2JpbGUgOiArOTQgNzEgODA5IDY3MzIgPGJyPg0KJmd0OyAmZ3Q7IDxi
cj4NCiZndDsgJmd0OyBodHRwOi8vYmxvZy5mYWNpbGVsb2dpbi5jb208YnI+DQomZ3Q7ICZndDsg
aHR0cDovL1JhbXBhcnRGQVEuY29tIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJy
Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgLS0gPGJyPg0KJmd0
OyAmZ3Q7IFRoYW5rcyAmYW1wOyBSZWdhcmRzLDxicj4NCiZndDsgJmd0OyBQcmFiYXRoIDxicj4N
CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgTW9iaWxlIDogKzk0IDcxIDgwOSA2NzMyIDxicj4N
CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgaHR0cDovL2Jsb2cuZmFjaWxlbG9naW4uY29tIDxi
cj4NCiZndDsgJmd0OyBodHRwOi8vUmFtcGFydEZBUS5jb21fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyBPQXV0aCBtYWlsaW5nIGxp
c3Q8YnI+DQomZ3Q7ICZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj4NCiZndDsgPGJyPg0KJmd0OyAm
Z3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAtLSA8YnI+DQom
Z3Q7ICZndDsgVGhhbmtzICZhbXA7IFJlZ2FyZHMsPGJyPg0KJmd0OyAmZ3Q7IFByYWJhdGggPGJy
Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBNb2JpbGUgOiArOTQgNzEgODA5IDY3MzIgPGJy
Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBodHRwOi8vYmxvZy5mYWNpbGVsb2dpbi5jb208
YnI+DQomZ3Q7ICZndDsgaHR0cDovL1JhbXBhcnRGQVEuY29tIDxicj4NCiZndDsgJmd0OyBfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0
OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+DQom
Z3Q7ICZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCA8YnI+
DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IC0t
IDxicj4NCiZndDsgJmd0OyBUaGFua3MgJmFtcDsgUmVnYXJkcyw8YnI+DQomZ3Q7ICZndDsgUHJh
YmF0aCA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IE1vYmlsZSA6ICs5NCA3MSA4MDkg
NjczMiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IGh0dHA6Ly9ibG9nLmZhY2lsZWxv
Z2luLmNvbTxicj4NCiZndDsgJmd0OyBodHRwOi8vUmFtcGFydEZBUS5jb21fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyBPQXV0aCBt
YWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsg
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvZm9udD48L3R0Pg0K
PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv
bnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAtLSA8YnI+DQomZ3Q7IFRoYW5rcyAmYW1wOyBSZWdh
cmRzLDxicj4NCiZndDsgUHJhYmF0aDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+
Jmd0OyA8YnI+DQomZ3Q7IE1vYmlsZSA6ICs5NCA3MSA4MDkgNjczMiA8YnI+DQomZ3Q7IDxicj4N
CiZndDsgaHR0cDovL2Jsb2cuZmFjaWxlbG9naW4uY29tPGJyPg0KJmd0OyBodHRwOi8vUmFtcGFy
dEZBUS5jb208L2ZvbnQ+PC90dD4NCg==
--=_alternative 00303F2748257B0B_=--

From hannes.tschofenig@gmx.net  Thu Feb  7 01:33:51 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B65F21F85A4 for ; Thu,  7 Feb 2013 01:33:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.094
X-Spam-Level: 
X-Spam-Status: No, score=-102.094 tagged_above=-999 required=5 tests=[AWL=0.506, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEHFjYXoxML1 for ; Thu,  7 Feb 2013 01:33:51 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id C320021F8599 for ; Thu,  7 Feb 2013 01:33:50 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.27]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0M8cOb-1Up0fO3x47-00wBVC for ; Thu, 07 Feb 2013 10:33:49 +0100
Received: (qmail 21682 invoked by uid 0); 7 Feb 2013 09:33:49 -0000
Received: from 194.251.119.197 by www038.gmx.net with HTTP; Thu, 07 Feb 2013 10:33:49 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Date: Thu, 07 Feb 2013 10:33:49 +0100
From: "Hannes Tschofenig" 
Message-ID: <20130207093349.51030@gmx.net>
MIME-Version: 1.0
To: oauth@ietf.org
X-Authenticated: #29516787
X-Flags: 0001
X-Mailer: WWW-Mail 6100 (Global Message Exchange)
X-Priority: 3
X-Provags-ID: V01U2FsdGVkX184R805wKo44wtjLC3TIcaCFC8KvZjxRqm+nUsPQY hk2kSNVB+Bpep4L0X5sW7zqnD+Cki9AE6m+g== 
Content-Transfer-Encoding: 8bit
X-GMX-UID: qhFhcYtyeSEqZJIAqXUhtEt+IGRvb4Ch
Subject: [OAUTH-WG] Agenda Topics for IETF#86
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Feb 2013 09:33:51 -0000

Hi all, 

if you plan to present your document at the next IETF meeting please drop us a note. 

We would like to start compiling the agenda.

Ciao
Hannes & Derek

From jricher@mitre.org  Thu Feb  7 06:59:36 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDF921F8735 for ; Thu,  7 Feb 2013 06:59:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.575
X-Spam-Level: 
X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.024,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3fJL5I8rvhb for ; Thu,  7 Feb 2013 06:59:35 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 32C7F21F84D5 for ; Thu,  7 Feb 2013 06:59:35 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7EBC45310862; Thu,  7 Feb 2013 09:59:34 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 70AFA531085F; Thu,  7 Feb 2013 09:59:34 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 7 Feb 2013 09:59:34 -0500
Message-ID: <5113C131.5000808@mitre.org>
Date: Thu, 7 Feb 2013 09:58:57 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Mike Jones 
References: <20130206201534.13236.6681.idtracker@ietfa.amsl.com> <5112BE73.2070003@mitre.org> <4E1F6AAD24975D4BA5B168042967394367418E35@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367418E35@TK5EX14MBXC284.redmond.corp.microsoft.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-05.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Feb 2013 14:59:36 -0000

Mike,

Thanks for reviewing the latest draft.

First, it's my understanding that the role of the editor is not merely 
to express the gestalt of the working group (though that's a very 
important part of it) but also to drive that discussion to it's best 
technical end. I put this revision together because it's easier to 
discuss things when there's actual text on the table. If it's just a 
suggested idea, I find that people tend to get very scared of imagined 
horrors that have little to do with the actual proposals. There's an air 
of "if we do something it's going to be the worst thing" that hang 
around as long as parts are still unknown.

So I took a step out on a limb and got things down on paper. I told 
people that I was going to do this the other day. [1] Since it's easy to 
roll back any changes that the working group doesn't want, and revisions 
are cheap, I'm not afraid to pull out things that make the WG cringe. 
But at least now we have something real, and not imagined, to cringe at.

That said, there have been several discussions about the changes that 
went into this revision. The original UMA draft from which this grew was 
much JSON based, though it didn't define actions beyond the initial 
registration. From the time I took over and moved it to form-based 
actions inspired by the OIDC registration draft, I've had people asking 
me why the registration endpoint wasn't a RESTful API: why didn't it use 
HTTP verbs, why wasn't it JSON-in/JSON-out, etc. My argument at the time 
was that OAuth wasn't RESTful (because it isn't), and that the 
parallelism with the rest of OAuth would be good for DynReg. But several 
people argued, several times now, that registration could be a really 
good place to do something different without breaking the expectations 
and flavor of the rest of the OAuth framework. I still hold that's it's 
*different*, but after I saw Nat's elegant rewrite of the OIDC 
registration spec [2], I was convinced that this could actually work in 
a reasonable, non-hackish manner.

And so I decided, as editor, to take the many discussions about this 
along with the best ideas and practices that I was aware of and put them 
into a document that we could discuss and use.

I welcome discussion on the document on its merits, and not the actions 
of its editor.

  -- Justin

[1] http://www.ietf.org/mail-archive/web/oauth/current/msg10690.html
[2] 
http://nat.sakimura.org/wp-content/uploads/2013/02/draft-openid-connect-registration-1_0.html

On 02/06/2013 09:09 PM, Mike Jones wrote:
> Hi Justin,
>
> Thanks for working to make progress on the OAuth Registration draft.  Reading through the changes, it seems to me that a number of changes were made that there wasn't yet working consensus for - in fact, some of which I don't recall being discussed by the working group at all.  These changes include:
>
>    - Splitting the registration endpoint into multiple endpoints
>    - Changing from form-encoded to JSON registration representation
>    - Adding Get and Delete operations
>    - Adding the Self URI concept and representation
>
> My point is separate from whether some of those changes might be good ideas.  (Some may be.)  I would hope that in the future, before changes are made to working group drafts, that sufficient time will be first be given to the working group to adequately discuss them and come to agreement on them.
>
> 				Thank you,
> 				-- Mike
>
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
> Sent: Wednesday, February 06, 2013 12:35 PM
> To: oauth@ietf.org
> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-05.txt
>
> Thanks to all of the discussion over the last few weeks and some key input from Nat Sakimura, Eve Maler, and others, I've put out a revision of the DynReg specification that is a major change from recent revisions, but actually brings it back closer to the original -01 draft.
> The "operation" parameter is now gone and there are instead several logical endpoints for different kinds of operations. These endpoints are communicated to the client through a well-defined link structure.
>
> It basically works like this:
>
> 1. client shows up at the Client Registration Endpoint, posts a JSON object with a few bits of metadata about itself (and potentially presents an Access Token that it got from some out of band process that acts as a "class registration" or "developer key", important to several known real-world use cases)
>
> 2. client gets back a JSON object filled with whatever metadata the server has about it, including a newly-minted client_id and (possibly) client_secret. The client also gets back a registration access token and a fully qualified URL that points to the "update endpoint". This url can take any form (the server can't count on the client being able to generate it from parts), but it's recommended that it follow a REST-style URL template of the form "https://server/registration_base_url/client_id".
>
> 3. client sends updates to this update URL, authenticated by the registration access token, by PUTting a JSON object with all of its parameters. Any fields the client leaves off the JSON object, the server leaves alone. Anything with a "null" value, the server deletes the value. The server remains free to override *any* field the client requests setting a particular value for. The client is not allowed to request a particular value for the client_secret or registration_access_token, for obvious reasons -- but see part 7 below.
>
> 4. The server responds back with the current state of the client as a JSON object, including any fields the server has provisioned on the client's behalf (defaults, for instance). Any fields the server has overridden, it currently MUST respond with. So if the client asks for
> "scope: A B C" and the server can only give it "scope: A B", then the server has to tell that to the client by including the field "scope: A B" in its response.
>
> 5. client can send an HTTP GET to the update URL to get its current state as a JSON object as in 4.
>
> 6. client can send an HTTP DELETE to the update URL to deprovision itself.
>
> 7. there's also a parallel endpoint for rotating the registration access token and client secret, since these are both security values that are provisioned by the server. There is some open debate of whether the client actually needs to be able to trigger this operation, or if the server should just do this as part of normal update/get requests to the update endpoint.
>
> It's a major functionality change on the wire, and there's still sawdust on the spec language. By going with a JSON-based data model and a RESTful update protocol, we're getting away from core OAuth patterns, but I think that ultimately this can be a good thing. There have been a few proposals that would go somewhere between what OAuth does on other endpoints and what a real RESTful system would do, but I didn't see much purpose in going half way when the results would end up *more* complicated.
>
> I request that everyone read it over to see if this will work for their use cases. The idea here remains that application protocols like OIDC and UMA would use this mechanism as-is with nearly all customizations in the client metadata table.
>
> I hope that this all actually makes sense...
>
>    -- Justin
>
> On 02/06/2013 03:15 PM, internet-drafts@ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>    This draft is a work item of the Web Authorization Protocol Working Group of the IETF.
>>
>> 	Title           : OAuth Dynamic Client Registration Protocol
>> 	Author(s)       : Justin Richer
>>                             John Bradley
>>                             Michael B. Jones
>>                             Maciej Machulak
>> 	Filename        : draft-ietf-oauth-dyn-reg-05.txt
>> 	Pages           : 21
>> 	Date            : 2013-02-06
>>
>> Abstract:
>>      This specification defines an endpoint and protocol for dynamic
>>      registration of OAuth Clients at an Authorization Server.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-05
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> 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

From jricher@mitre.org  Thu Feb  7 07:10:16 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B625321F853E for ; Thu,  7 Feb 2013 07:10:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.575
X-Spam-Level: 
X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.023,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYN+Znjgi8Yr for ; Thu,  7 Feb 2013 07:10:16 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C68B421F84CA for ; Thu,  7 Feb 2013 07:10:15 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B522143900EE; Thu,  7 Feb 2013 10:10:14 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id CB8391F1805; Thu,  7 Feb 2013 10:10:07 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 7 Feb 2013 10:10:07 -0500
Message-ID: <5113C3AA.1040701@mitre.org>
Date: Thu, 7 Feb 2013 10:09:30 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Prabath Siriwardena 
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com> <5112AE0B.1080501@mitre.org> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080203080402010103050601"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Feb 2013 15:10:16 -0000

--------------080203080402010103050601
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

"valid" might not be the best term, but it's meant to be a field where 
the server says "yes this token is still good" or "no this token isn't 
good anymore". We could instead do this with HTTP codes or something but 
I went with a pure JSON response.

  -- Justin

On 02/06/2013 10:47 PM, Prabath Siriwardena wrote:
> Hi Justin,
>
> I believe this is addressing one of the key missing part in OAuth 2.0...
>
> One question - I guess this was discussed already...
>
> In the spec - in the introspection response it has the attribute 
> "valid" - this is basically the validity of the token provided in the 
> request.
>
> Validation criteria depends on the token and well as token type ( 
> Bearer, MAC..).
>
> In the spec it seems like it's coupled with Bearer token type... But I 
> guess, by adding "token_type" to the request we can remove this 
> dependency.
>
> WDYT..?
>
> Thanks & regards,
> -Prabath
>
> On Thu, Feb 7, 2013 at 12:54 AM, Justin Richer  > wrote:
>
>     Updated introspection draft based on recent comments. Changes include:
>
>      - "scope" return parameter now follows RFC6749 format instead of
>     JSON array
>      - "subject" -> "sub", and "audience" -> "aud", to be parallel
>     with JWT claims
>      - clarified what happens if the authentication is bad
>
>      -- Justin
>
>
>     -------- Original Message --------
>     Subject: 	New Version Notification for
>     draft-richer-oauth-introspection-02.txt
>     Date: 	Wed, 6 Feb 2013 11:24:20 -0800
>     From: 	 
>     To: 	 
>
>
>
>     A new version of I-D, draft-richer-oauth-introspection-02.txt
>     has been successfully submitted by Justin Richer and posted to the
>     IETF repository.
>
>     Filename:	 draft-richer-oauth-introspection
>     Revision:	 02
>     Title:		 OAuth Token Introspection
>     Creation date:	 2013-02-06
>     WG ID:		 Individual Submission
>     Number of pages: 6
>     URL:http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
>     Status:http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
>     Htmlized:http://tools.ietf.org/html/draft-richer-oauth-introspection-02
>     Diff:http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02
>
>     Abstract:
>         This specification defines a method for a client or protected
>         resource to query an OAuth authorization server to determine meta-
>         information about an OAuth token.
>
>
>                                                                                        
>
>
>     The IETF Secretariat
>
>
>
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org 
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> -- 
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com

--------------080203080402010103050601
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

    "valid" might not be the best term, but it's meant to be a field
    where the server says "yes this token is still good" or "no this
    token isn't good anymore". We could instead do this with HTTP codes
    or something but I went with a pure JSON response.

     -- Justin

    On 02/06/2013 10:47 PM, Prabath
      Siriwardena wrote:

      Hi Justin,

      I believe this is addressing one of the key missing part in
        OAuth 2.0...

      One question - I guess this was discussed already...

      In the spec - in the introspection response it has the
        attribute "valid" - this is basically the validity of the token
        provided in the request.

      Validation criteria depends on the token and well as token
        type ( Bearer, MAC..).

      In the spec it seems like it's coupled with Bearer token
        type... But I guess, by adding "token_type" to the request we
        can remove this dependency.

      WDYT..?

      Thanks & regards,
      -Prabath 

        On Thu, Feb 7, 2013 at 12:54 AM, Justin
          Richer <jricher@mitre.org>
          wrote:

             Updated introspection
              draft based on recent comments. Changes include:

               - "scope" return parameter now follows RFC6749 format
              instead of JSON array

               - "subject" -> "sub", and "audience" -> "aud", to
              be parallel with JWT claims

               - clarified what happens if the authentication is bad

               -- Justin

                -------- Original Message --------

                      Subject: 
                      New Version Notification for
                        draft-richer-oauth-introspection-02.txt

                      Date: 
                      Wed, 6 Feb 2013 11:24:20 -0800

                      From: 
                      <internet-drafts@ietf.org>

                      To: 
                      <jricher@mitre.org>

                A new version of I-D, draft-richer-oauth-introspection-02.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 02
Title:		 OAuth Token Introspection
Creation date:	 2013-02-06
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.

The IETF Secretariat

            _______________________________________________

            OAuth mailing list

            OAuth@ietf.org

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

        -- 

        Thanks & Regards,

        Prabath

        Mobile : +94 71 809 6732 

          http://blog.facilelogin.com

          http://RampartFAQ.com

--------------080203080402010103050601--

From jricher@mitre.org  Thu Feb  7 08:06:53 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBE021F8751 for ; Thu,  7 Feb 2013 08:06:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.276
X-Spam-Level: 
X-Spam-Status: No, score=-6.276 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ee5EDRIj2rcy for ; Thu,  7 Feb 2013 08:06:46 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 26DAF21F874C for ; Thu,  7 Feb 2013 08:06:46 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 797731F0308; Thu,  7 Feb 2013 11:06:45 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 3DDC11F18AA; Thu,  7 Feb 2013 11:06:45 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 7 Feb 2013 11:06:44 -0500
Message-ID: <5113D0EF.9070806@mitre.org>
Date: Thu, 7 Feb 2013 11:06:07 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000004030707080301060508"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] A question on token revocation.
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Feb 2013 16:06:53 -0000

--------------000004030707080301060508
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

This, I think, points out that the RO is generally more concerned with 
revoking an authorization grant than a token itself, with the latter 
potentially encompassing several tokens. The revocation draft isn't 
really intended to solve that problem, as Torsten points out below.

  -- Justin

On 02/07/2013 03:46 AM, zhou.sujing@zte.com.cn wrote:
>
> During the four grant types of Oauth,
>   1. authorization code: RO knows the authorization code upon which 
> access-tokens-to-be-revoked are issued
>   2. implicite flow: RO knows the access-tokens-to-be-revoked
>   3. password and client credential types: RO has no way of knowing 
> access tokens.
>
> So,IMO,  it is not proper for RO to revoke an each access token 
> individually,
> rather it could revoke some access tokens by specifying conditions, 
> such as client_id, time_period, scope
> Comments?
>
> Prabath Siriwardena  ?? 2013-02-07 15:25:02:
>
> >
>
> > On Thu, Feb 7, 2013 at 12:49 PM,  wrote:
> >
> > I guess RO could initiate access token revocation for a client by
> > including authorization code in the request to AS.
> > Comments?
> >
> > That creates a dependency on the grant type.
> >
> > Thanks & regards,
> > -Prabath
> >
> >
> >
> >
> >
> > oauth-bounces@ietf.org ?? 2013-02-07 02:32:28:
> >
> > > Hi Torsten,
> > >
> > > Thanks for your feedback.. I will submit a draft...
> > >
> > > Thanks & regards,
> > > -Prabath
> >
> > > On Wed, Feb 6, 2013 at 11:55 PM, Torsten Lodderstedt <
> > torsten@lodderstedt.net
> > > > wrote:
> > > Hi Prabath,
> > >
> > > we tried to address both use cases in the first revisions of the
> > > draft. The API was well suited for client-driven revocation but not
> > > the resource owner - driven use case. There are definitely
> > > differences with respect to the protocol design, at least regarding
> > > authentication and authorization of the respective actors. This made
> > > the spec more complex and caused ambiguities and confusion.
> > > Moreover, the working group seemed not convinced by the the 
> latteruse case.
> > >
> > > Therefore the working group decided to focus on the single use cases
> > > of the revocation by clients. This makes a lot of sense since this
> > > interface is most important with respect to interoperability.
> > >
> > > I'm focusing right now on finishing this draft. And the open issues
> > > discussed on the list in the last couple of weeks illustrate that
> > > even this poses a considerable amount of work. So I'm very reluctant
> > > to add support for a whole new use case at that point of the process.
> > >
> > > If you feel this is an important use case worth an RFC, don't
> > > hesitate to publish a new I-D.
> > >
> > > regards,
> > > Torsten.
> > >
> > > Am 06.02.2013 um 16:37 schrieb Prabath Siriwardena :
> >
> > >
> >
> > > On Wed, Feb 6, 2013 at 9:04 PM, Todd W Lainhart 
>  wrote:
> > > > Resource owner needs to know the consumer key (represents the
> > > OAuth Client app) & scope to revoke the access token for a given 
> client.
> >
> > > I see - you're saying that requiring client credentials on the end
> > > point is the problem?
> > >
> > > In fact what I meant was - when RO authorizes the an access token
> > > for client for particular scope. Those information are kept at the 
> AS.
> > >
> > > Now - if the RO want to revoke access from the client - the RO needs
> > > to authenticate him self to the AS and pass the consumer key and the
> > > scope. So AS can revoke access.
> > >
> > > Thanks & regards,
> > > -Prabath
> > >
> > >
> > >
> > >
> > >
> > > Todd Lainhart
> > > Rational software
> > > IBM Corporation
> > > 550 King Street, Littleton, MA 01460-1250
> > > 1-978-899-4705
> > > 2-276-4705 (T/L)
> > > lainhart@us.ibm.com
> > >
> > >
> > >
> > >
> > >
> >
> > > From:        Prabath Siriwardena 
> > > To:        Justin Richer ,
> > > Cc:        "oauth@ietf.org WG" 
> > > Date:        02/06/2013 10:31 AM
> > > Subject:        Re: [OAUTH-WG] A question on token revocation.
> > > Sent by:        oauth-bounces@ietf.org
> > >
> > >
> > >
> > >
>
> > > On Wed, Feb 6, 2013 at 8:49 PM, Justin Richer  
> wrote:
> > >
> > > On 02/06/2013 10:13 AM, Prabath Siriwardena wrote:
> > >
> > >
> > > On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer  
> wrote:
> > > These are generally handled through a user interface where the RO is
> > > authenticated directly to the AS, and there's not much need for a
> > > "protocol" here, in practice.
> > >
> > > Why do you think leaving access token revocation by RO to a
> > > proprietary API is a good practice ? IMO this an essential
> > > requirement in API security.
> > > I think it makes more sense in the same way that having a
> > > "proprietary" UI/API for managing the user consent makes sense:
> > > unless you're doing a fully dynamic end-to-end system like UMA, then
> > > there's not much value in trying to squeeze disparate systems into
> > > the same mold, since they won't be talking to each other anyway.
> > >
> > > This is required in distributed setup for each API platform from
> > > different vendors to perform in an interop manner.
> > >
> > >
> > > And since you refer to it as an "API", what will the RO be using to
> > > call this API? Is there a token management client that's separate
> > > from the OAuth client?
> > >
> > > I didn't get your question right... If you meant the how to invoke
> > > revocation end point, the the resource owner needs to know the
> > > consumer key (represents the OAuth Client app) & scope to revoke the
> > > access token for a given client.
> > >
> > >
> > >
> > > IMHO token revocation done my RO is more practical than token
> > > revocation done by the Client.
> > > They're both valid but require different kinds of protocols and
> > > considerations. This token revocation draft is meant to solve one
> > > problem, and that doesn't mean it can or should solve other
> > > seemingly related problems.
> > >
> > > If you would like to see the RO-initiated token revocation go
> > > through (not grant revocation, mind you -- that's related, but
> > > different), then I would suggest that you start specifying exactly
> > > how that works. I predict it will be problematic in practice,
> > > though, as the RO often doesn't actually have direct access to the
> > > token itself.
> > >
> > > Resource owner needs to know the consumer key (represents the OAuth
> > > Client app) & scope to revoke the access token for a given client.
> > >
> > >
> > >
> > >
> > > There are larger applications, like UMA, that have client and PR
> > > provisioning that would allow for this to be managed somewhat
> > > programmatically, but even in that case you're still generally doing
> > > token revocation by a "client" in some fashion. In UMA, though,
> > > several different pieces can play the role of a "client" at
> > > different parts of the process.
> > >
> > > Revoking a scope is a whole different mess. Generally, you'd want to
> > > just revoke an existing token and make a new authorization grant
> > > with lower access if you don't want that client getting that scope
> > > anymore. If you just want to downscope for a single transaction, you
> > > can already do that with either the refresh token or token chaining
> > > approaches, depending on where in the process you are. The latter of
> > > these are both client-focused, though, and the RO doesn't have a
> > > direct hand in it at this point.
> > >
> > > Why do you think it a mess. If you revoke the entire token then
> > > Client needs to go through the complete OAuth flow - and also needs
> > > to get the user consent. If RO can  downgrade the scope, then we
> > > restrict API access by the client at RS end and its transparent to
> > > the client.
> > >
> > >
> > > Downgrading the scope of tokens in the wild is hardly transparent to
> > > the client (stuff that it expects to work will suddenly start to
> > > fail, meaning that most clients will throw out the token and try to
> > > get a new one), and in a distributed system you've got to propagate
> > > that change to the RS. If you bake the scopes into the token itself
> > > (which many do) then you actually *can't* downgrade a single 
> token, anyway.
> > >
> > > Yes.. that is the expected behavior. I mean the process is
> > > transparent. Client will notice at runtime.
> > >
> > > Thanks & regards,
> > > -Prabath
> > >
> > >
> > >  -- Justin
> > >
> > >
> > > Thanks & regards,
> > > -Prabath
> > >
> > >
> > >
> > >  -- Justin
> > >
> > >
> > > On 02/06/2013 04:35 AM, Prabath Siriwardena wrote:
> > > I am sorry if this was already discussed in this list..
> > >
> > > Looking at [1] it only talks about revoking the access token from
> > the client.
> > >
> > > How about the resource owner..?
> > >
> > > There can be cases where resource owner needs to revoke an
> > > authorized access token from a given client. Or revoke an scope..
> > >
> > > How are we going to address these requirements..? Thoughts 
> appreciated...
> > >
> > > [1] http://tools.ietf.org/html/draft-ietf-oauth-revocation-04
> > >
> > > --
> > > Thanks & Regards,
> > > Prabath
> > >
> > > Mobile : +94 71 809 6732
> > >
> > > http://blog.facilelogin.com
> > > http://RampartFAQ.com
> > >
> > >
> > > _______________________________________________
> > > OAuth mailing list
> > > OAuth@ietf.org
> > > https://www.ietf.org/mailman/listinfo/oauth
> > >
> > >
> > >
> > >
> > >
> > > --
> > > Thanks & Regards,
> > > Prabath
> > >
> > > Mobile : +94 71 809 6732
> > >
> > > http://blog.facilelogin.com
> > > http://RampartFAQ.com
> > >
> > >
> > >
> > >
> > > --
> > > Thanks & Regards,
> > > Prabath
> > >
> > > Mobile : +94 71 809 6732
> > >
> > > http://blog.facilelogin.com
> > > http://RampartFAQ.com_______________________________________________
> > > OAuth mailing list
> > > OAuth@ietf.org
> > > https://www.ietf.org/mailman/listinfo/oauth
> >
> > >
> >
> > >
> > > --
> > > Thanks & Regards,
> > > Prabath
> > >
> > > Mobile : +94 71 809 6732
> > >
> > > http://blog.facilelogin.com
> > > http://RampartFAQ.com
> > > _______________________________________________
> > > OAuth mailing list
> > > OAuth@ietf.org
> > > https://www.ietf.org/mailman/listinfo/oauth
> > >
> >
> > >
> > > --
> > > Thanks & Regards,
> > > Prabath
> > >
> > > Mobile : +94 71 809 6732
> > >
> > > http://blog.facilelogin.com
> > > http://RampartFAQ.com_______________________________________________
> > > OAuth mailing list
> > > OAuth@ietf.org
> > > https://www.ietf.org/mailman/listinfo/oauth
> >
>
> >
> > --
> > Thanks & Regards,
> > Prabath
> >
> > Mobile : +94 71 809 6732
> >
> > http://blog.facilelogin.com
> > http://RampartFAQ.com
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--------------000004030707080301060508
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

    This, I think, points out that the RO is generally more concerned
    with revoking an authorization grant than a token itself, with the
    latter potentially encompassing several tokens. The revocation draft
    isn't really intended to solve that problem, as Torsten points out
    below.

     -- Justin

    On 02/07/2013 03:46 AM,
      zhou.sujing@zte.com.cn wrote:

      During the four grant types of Oauth,

        1. authorization code: RO knows the authorization
        code upon which access-tokens-to-be-revoked are issued  

        2. implicite flow: RO knows the
        access-tokens-to-be-revoked

        3. password and client credential types: RO has
        no way of knowing access tokens.   

      So,IMO,  it is not proper for RO to revoke an each
        access token individually,

      rather it could revoke some access tokens by
        specifying
        conditions, such as client_id, time_period, scope 

      Comments? 

      Prabath Siriwardena <prabath@wso2.com> 写于
          2013-02-07 15:25:02:

          > 

      > On Thu, Feb 7, 2013 at 12:49 PM,
          <zhou.sujing@zte.com.cn>
          wrote:

      > 

          > I guess RO could initiate access token revocation for a
          client by

          > including authorization code in the request to AS. 

          > Comments? 

      > 

          > That creates a dependency on the grant type.

      > 

          > Thanks & regards,

      > -Prabath

      >  

      > 

          > 

          > 

          > 

          > oauth-bounces@ietf.org 写于 2013-02-07 02:32:28:

          > 

          > > Hi Torsten, 

      > > 

          > > Thanks for your feedback.. I will submit a draft...

          > > 

          > > Thanks & regards, 

          > > -Prabath

          > 

          > > On Wed, Feb 6, 2013 at 11:55 PM, Torsten Lodderstedt
          <

          > torsten@lodderstedt.net

          > > > wrote: 

          > > Hi Prabath, 

          > > 

          > > we tried to address both use cases in the first
          revisions of
          the 

          > > draft. The API was well suited for client-driven
          revocation but
          not 

          > > the resource owner - driven use case. There are
          definitely 

          > > differences with respect to the protocol design, at
          least regarding

          > > authentication and authorization of the respective
          actors. This
          made

          > > the spec more complex and caused ambiguities and
          confusion. 

          > > Moreover, the working group seemed not convinced by
          the the latteruse
          case.

          > > 

          > > Therefore the working group decided to focus on the
          single use
          cases

          > > of the revocation by clients. This makes a lot of
          sense since
          this 

          > > interface is most important with respect to
          interoperability.

          > > 

          > > I'm focusing right now on finishing this draft. And
          the open
          issues 

          > > discussed on the list in the last couple of weeks
          illustrate
          that 

          > > even this poses a considerable amount of work. So
          I'm very reluctant

          > > to add support for a whole new use case at that
          point of the
          process. 

          > > 

          > > If you feel this is an important use case worth an
          RFC, don't

          > > hesitate to publish a new I-D. 

          > > 

          > > regards, 

          > > Torsten. 

          > > 

          > > Am 06.02.2013 um 16:37 schrieb Prabath Siriwardena
          <prabath@wso2.com>:

          > 

          > > 

          > 

          > > On Wed, Feb 6, 2013 at 9:04 PM, Todd W Lainhart
          <lainhart@us.ibm.com>
          wrote:

          > > > Resource owner needs to know the consumer key
          (represents
          the 

          > > OAuth Client app) & scope to revoke the access
          token for
          a given client.  

          > 

          > > I see - you're saying that requiring client
          credentials on the
          end 

          > > point is the problem? 

          > > 

          > > In fact what I meant was - when RO authorizes the an
          access token

          > > for client for particular scope. Those information
          are kept at
          the AS. 

          > > 

          > > Now - if the RO want to revoke access from the
          client - the RO
          needs

          > > to authenticate him self to the AS and pass the
          consumer key
          and the

          > > scope. So AS can revoke access. 

          > > 

          > > Thanks & regards, 

          > > -Prabath 

          > >   

          > > 

          > > 

          > > 

          > > 

          > > Todd Lainhart

          > > Rational software

          > > IBM Corporation

          > > 550 King Street, Littleton, MA 01460-1250

          > > 1-978-899-4705

          > > 2-276-4705 (T/L)

          > > lainhart@us.ibm.com 

          > > 

          > > 

          > > 

          > > 

          > > 

          > 

          > > From:        Prabath Siriwardena
          <prabath@wso2.com>

          > > To:        Justin Richer <jricher@mitre.org>,

          > > Cc:        "oauth@ietf.org WG"
          <oauth@ietf.org> 

          > > Date:        02/06/2013 10:31 AM 

          > > Subject:        Re: [OAUTH-WG] A question
          on token revocation. 

          > > Sent by:        oauth-bounces@ietf.org 

          > > 

          > > 

          > > 

          > > 

      > > On Wed, Feb 6, 2013 at 8:49 PM,
          Justin Richer
          <jricher@mitre.org> wrote: 

          > > 

          > > On 02/06/2013 10:13 AM, Prabath Siriwardena wrote: 

          > > 

          > > 

          > > On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer
          <jricher@mitre.org>
          wrote: 

          > > These are generally handled through a user interface
          where the
          RO is

          > > authenticated directly to the AS, and there's not
          much need for
          a 

          > > "protocol" here, in practice. 

          > > 

          > > Why do you think leaving access token revocation by
          RO to a 

          > > proprietary API is a good practice ? IMO this an
          essential 

          > > requirement in API security. 

          > > I think it makes more sense in the same way that
          having a 

          > > "proprietary" UI/API for managing the user consent
          makes sense: 

          > > unless you're doing a fully dynamic end-to-end
          system like UMA,
          then

          > > there's not much value in trying to squeeze
          disparate systems
          into 

          > > the same mold, since they won't be talking to each
          other anyway.

          > > 

          > > This is required in distributed setup for each API
          platform from

          > > different vendors to perform in an interop manner. 

          > >   

          > > 

          > > And since you refer to it as an "API", what will the
          RO be using to 

          > > call this API? Is there a token management client
          that's separate

          > > from the OAuth client? 

          > > 

          > > I didn't get your question right... If you meant the
          how to invoke

          > > revocation end point, the the resource owner needs
          to know the

          > > consumer key (represents the OAuth Client app) &
          scope to
          revoke the

          > > access token for a given client.  

          > > 

          > > 

          > > 

          > > IMHO token revocation done my RO is more practical
          than token

          > > revocation done by the Client. 

          > > They're both valid but require different kinds of
          protocols and

          > > considerations. This token revocation draft is meant
          to solve
          one 

          > > problem, and that doesn't mean it can or should
          solve other 

          > > seemingly related problems.

          > > 

          > > If you would like to see the RO-initiated token
          revocation go

          > > through (not grant revocation, mind you -- that's
          related, but

          > > different), then I would suggest that you start
          specifying exactly

          > > how that works. I predict it will be problematic in
          practice,

          > > though, as the RO often doesn't actually have direct
          access to
          the 

          > > token itself. 

          > > 

          > > Resource owner needs to know the consumer key
          (represents the
          OAuth 

          > > Client app) & scope to revoke the access token
          for a given
          client.  

          > > 

          > >   

          > > 

          > >   

          > > There are larger applications, like UMA, that have
          client and
          PR 

          > > provisioning that would allow for this to be managed
          somewhat

          > > programmatically, but even in that case you're still
          generally
          doing

          > > token revocation by a "client" in some fashion. In
          UMA, though, 

          > > several different pieces can play the role of a
          "client"
          at 

          > > different parts of the process.

          > > 

          > > Revoking a scope is a whole different mess.
          Generally, you'd
          want to

          > > just revoke an existing token and make a new
          authorization grant

          > > with lower access if you don't want that client
          getting that
          scope 

          > > anymore. If you just want to downscope for a single
          transaction,
          you

          > > can already do that with either the refresh token or
          token chaining

          > > approaches, depending on where in the process you
          are. The latter
          of

          > > these are both client-focused, though, and the RO
          doesn't have
          a 

          > > direct hand in it at this point. 

          > > 

          > > Why do you think it a mess. If you revoke the entire
          token then

          > > Client needs to go through the complete OAuth flow -
          and also
          needs 

          > > to get the user consent. If RO can  downgrade the
          scope,
          then we 

          > > restrict API access by the client at RS end and its
          transparent
          to 

          > > the client. 

          > > 

          > > 

          > > Downgrading the scope of tokens in the wild is
          hardly transparent
          to

          > > the client (stuff that it expects to work will
          suddenly start
          to 

          > > fail, meaning that most clients will throw out the
          token and
          try to 

          > > get a new one), and in a distributed system you've
          got to propagate

          > > that change to the RS. If you bake the scopes into
          the token
          itself 

          > > (which many do) then you actually *can't* downgrade
          a single
          token, anyway. 

          > > 

          > > Yes.. that is the expected behavior. I mean the
          process is 

          > > transparent. Client will notice at runtime. 

          > > 

          > > Thanks & regards, 

          > > -Prabath 

          > >   

          > > 

          > >  -- Justin 

          > > 

          > > 

          > > Thanks & regards, 

          > > -Prabath 

          > >   

          > > 

          > > 

          > >  -- Justin 

          > > 

          > > 

          > > On 02/06/2013 04:35 AM, Prabath Siriwardena wrote: 

          > > I am sorry if this was already discussed in this
          list..  

          > > 

          > > Looking at [1] it only talks about revoking the
          access token
          from 

          > the client. 

          > > 

          > > How about the resource owner..? 

          > > 

          > > There can be cases where resource owner needs to
          revoke an 

          > > authorized access token from a given client. Or
          revoke an scope..

          > > 

          > > How are we going to address these requirements..?
          Thoughts appreciated...

          > > 

          > > [1]
          http://tools.ietf.org/html/draft-ietf-oauth-revocation-04

          > > 

          > > -- 

          > > Thanks & Regards,

          > > Prabath 

          > > 

          > > Mobile : +94 71 809 6732 

          > > 

          > > http://blog.facilelogin.com

          > > http://RampartFAQ.com 

          > > 

          > > 

          > > _______________________________________________

          > > OAuth mailing list

          > > OAuth@ietf.org

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

          > > 

          > > 

          > > 

          > > 

          > > 

          > > -- 

          > > Thanks & Regards,

          > > Prabath 

          > > 

          > > Mobile : +94 71 809 6732 

          > > 

          > > http://blog.facilelogin.com

          > > http://RampartFAQ.com 

          > > 

          > > 

          > > 

          > > 

          > > -- 

          > > Thanks & Regards,

          > > Prabath 

          > > 

          > > Mobile : +94 71 809 6732 

          > > 

          > > http://blog.facilelogin.com 

          > >
          http://RampartFAQ.com_______________________________________________

          > > OAuth mailing list

          > > OAuth@ietf.org

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

          > 

          > > 

          > 

          > > 

          > > -- 

          > > Thanks & Regards,

          > > Prabath 

          > > 

          > > Mobile : +94 71 809 6732 

          > > 

          > > http://blog.facilelogin.com

          > > http://RampartFAQ.com 

          > > _______________________________________________

          > > OAuth mailing list

          > > OAuth@ietf.org

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

          > > 

          > 

          > > 

          > > -- 

          > > Thanks & Regards,

          > > Prabath 

          > > 

          > > Mobile : +94 71 809 6732 

          > > 

          > > http://blog.facilelogin.com

          > >
          http://RampartFAQ.com_______________________________________________

          > > OAuth mailing list

          > > OAuth@ietf.org

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

      > 

      > 

          > -- 

          > Thanks & Regards,

          > Prabath

      > 

          > Mobile : +94 71 809 6732 

          > 

          > http://blog.facilelogin.com

          > http://RampartFAQ.com

      _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------000004030707080301060508--

From prabath@wso2.com  Thu Feb  7 08:26:31 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D78F21F842D for ; Thu,  7 Feb 2013 08:26:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.823
X-Spam-Level: 
X-Spam-Status: No, score=-2.823 tagged_above=-999 required=5 tests=[AWL=0.153,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMsHdUgBvhu1 for ; Thu,  7 Feb 2013 08:26:30 -0800 (PST)
Received: from mail-ee0-f50.google.com (mail-ee0-f50.google.com [74.125.83.50]) by ietfa.amsl.com (Postfix) with ESMTP id DAF8121F81FF for ; Thu,  7 Feb 2013 08:26:29 -0800 (PST)
Received: by mail-ee0-f50.google.com with SMTP id e51so1525136eek.23 for ; Thu, 07 Feb 2013 08:26:29 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=wXD/BolpUDUFKFZHli94v9GyyW6+VGdfjxFWfEZUIRU=; b=ggv4HxuGpE4HtmW1Yw30SU+HMGuMlbTQuRGlyLgvqyA1DD/EjP1fA6wNDVKfT5Jijo u3GkTjs30uNFRZPMFEuRAejjX7skCaRPAfLxAYXhkQjRbWhxPeFCHk7/bIEqB3gtztqL /UIgO4goN0SnmzNRQezwYjgHsE7xAl02BHm8bkHGHDmPd99do0BsTsRVjkErv2WBbx9o Pqgm8oi8MyH2GEnZpOXwvKpRbiO4SbCRkMRpRUzdqdI55qxGKOaK6pawn0TjNcVmmeAE 8bDhP0pzKIiby1j/ZmBofDdIXM3m/e43skP7ssHHa5O5wbGA61iJrYy6vlq8dYftF1Zv Xh0w==
MIME-Version: 1.0
X-Received: by 10.14.194.195 with SMTP id m43mr5409058een.44.1360254388588; Thu, 07 Feb 2013 08:26:28 -0800 (PST)
Received: by 10.223.175.134 with HTTP; Thu, 7 Feb 2013 08:26:28 -0800 (PST)
In-Reply-To: <5113C3AA.1040701@mitre.org>
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com> <5112AE0B.1080501@mitre.org>  <5113C3AA.1040701@mitre.org>
Date: Thu, 7 Feb 2013 21:56:28 +0530
Message-ID: 
From: Prabath Siriwardena 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=047d7b342c4ca2d27b04d524e790
X-Gm-Message-State: ALoCoQmtJDCEY0gxu6NAiKjg/2FxsP7TcUGKulxAmK4LrjX3yG92g94APqKK6h/OTwFhpk1QttX5
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Feb 2013 16:26:31 -0000

--047d7b342c4ca2d27b04d524e790
Content-Type: text/plain; charset=ISO-8859-1

Okay.. I was thinking this could be used as a way to validate the token as
well. BTW even in this case shouldn't communicate the type of token to AS?
For example in the case of SAML profile - it could be SAML token..

Thanks & regards,
-Prabath

On Thu, Feb 7, 2013 at 8:39 PM, Justin Richer  wrote:

>  "valid" might not be the best term, but it's meant to be a field where
> the server says "yes this token is still good" or "no this token isn't good
> anymore". We could instead do this with HTTP codes or something but I went
> with a pure JSON response.
>
>  -- Justin
>
>
> On 02/06/2013 10:47 PM, Prabath Siriwardena wrote:
>
> Hi Justin,
>
>  I believe this is addressing one of the key missing part in OAuth 2.0...
>
>  One question - I guess this was discussed already...
>
>  In the spec - in the introspection response it has the attribute "valid"
> - this is basically the validity of the token provided in the request.
>
>  Validation criteria depends on the token and well as token type (
> Bearer, MAC..).
>
>  In the spec it seems like it's coupled with Bearer token type... But I
> guess, by adding "token_type" to the request we can remove this dependency.
>
>  WDYT..?
>
>  Thanks & regards,
> -Prabath
>
> On Thu, Feb 7, 2013 at 12:54 AM, Justin Richer  wrote:
>
>>  Updated introspection draft based on recent comments. Changes include:
>>
>>  - "scope" return parameter now follows RFC6749 format instead of JSON
>> array
>>  - "subject" -> "sub", and "audience" -> "aud", to be parallel with JWT
>> claims
>>  - clarified what happens if the authentication is bad
>>
>>  -- Justin
>>
>>
>> -------- Original Message --------  Subject: New Version Notification
>> for draft-richer-oauth-introspection-02.txt  Date: Wed, 6 Feb 2013
>> 11:24:20 -0800  From:   To:
>>  
>>
>> A new version of I-D, draft-richer-oauth-introspection-02.txt
>> has been successfully submitted by Justin Richer and posted to the
>> IETF repository.
>>
>> Filename:	 draft-richer-oauth-introspection
>> Revision:	 02
>> Title:		 OAuth Token Introspection
>> Creation date:	 2013-02-06
>> WG ID:		 Individual Submission
>> Number of pages: 6
>> URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
>> Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
>> Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-02
>> Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02
>>
>> Abstract:
>>    This specification defines a method for a client or protected
>>    resource to query an OAuth authorization server to determine meta-
>>    information about an OAuth token.
>>
>>
>>
>>
>>
>> The IETF Secretariat
>>
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
>
>  --
> Thanks & Regards,
> Prabath
>
>  Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com
>
>
>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.com

--047d7b342c4ca2d27b04d524e790
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Okay.. I was thinking this could be used as a way to validate the token as =
well. BTW even in this case shouldn't communicate the type of token to =
AS? For example in the case of SAML profile - it could be SAML token..

Thanks & regards,
-Prabath

On Thu, Feb 7, 2013 at 8:39 PM, Justin Richer <jricher@mi=
tre.org> wrote:

 =20
   =20
 =20

    "valid" might not be the best term, but it's meant to be =
a field
    where the server says "yes this token is still good" or "=
;no this
    token isn't good anymore". We could instead do this with HTTP =
codes
    or something but I went with a pure JSON response.

    =A0-- Justin

    On 02/06/2013 10:47 PM, Prabath
      Siriwardena wrote:

     =20
      Hi Justin,

      I believe this is addressing one of the key missing part in
        OAuth 2.0...

      One question - I guess this was discussed already...

      In the spec - in the introspection response it has the
        attribute "valid" - this is basically the validity of the=
 token
        provided in the request.

      Validation=A0criteria depends on the token and well as token
        type ( Bearer, MAC..).

      In the spec it seems like it's coupled with Bearer token
        type... But I guess, by adding "token_type" to the reques=
t we
        can remove this dependency.

      WDYT..?

      Thanks & regards,
      -Prabath=A0

        On Thu, Feb 7, 2013 at 12:54 AM, Justin
          Richer <jricher@mitre.org>
          wrote:

             Updated introspectio=
n
              draft based on recent comments. Changes include:

              =A0- "scope" return parameter now follows RFC6749 f=
ormat
              instead of JSON array

              =A0- "subject" -> "sub", and "aud=
ience" -> "aud", to
              be parallel with JWT claims

              =A0- clarified what happens if the authentication is bad

              =A0-- Justin

                -------- Original Message --------

                      Subjec=
t: 
                      New Version Notification for
                        draft-richer-oauth-introspection-02.txt

                      Date: =

                      Wed, 6 Feb 2013 11:24:20 -0800

                      From: =

                      <internet-drafts@ietf.org>

                      To: 
                      <jricher@mitre.org>

                A new version of I-D, draft-richer-oauth-introspection=
-02.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 02
Title:		 OAuth Token Introspection
Creation date:	 2013-02-06
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/interne=
t-drafts/draft-richer-oauth-introspection-02.txt
Status:          http://datatracker.ietf.org/doc/draft-=
richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-=
oauth-introspection-02
Diff:            http://www.ietf.org/rfcdiff?url2=
=3Ddraft-richer-oauth-introspection-02

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.

                                                                           =
      =20

The IETF Secretariat

            _______________________________________________

            OAuth mailing list

            OAuth@ietf.=
org

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

        -- 

        Thanks & Regards,

        Prabath

        Mobile : +94 71 809 6732=A0

          http://=
blog.facilelogin.com

          http://Rampar=
tFAQ.com

-- 
Thanks &=
 Regards,
Prabath
Mobile : +94 71 809 6732=A0

=
http://blog.facil=
elogin.com

http://RampartFAQ.com

--047d7b342c4ca2d27b04d524e790--

From jricher@mitre.org  Thu Feb  7 09:01:13 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11E921F8786 for ; Thu,  7 Feb 2013 09:01:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.568
X-Spam-Level: 
X-Spam-Status: No, score=-6.568 tagged_above=-999 required=5 tests=[AWL=0.030,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eITFxFcuhM9W for ; Thu,  7 Feb 2013 09:01:12 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 552C221F87C3 for ; Thu,  7 Feb 2013 09:01:12 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B96851F185F; Thu,  7 Feb 2013 12:01:11 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 9FD211F1874; Thu,  7 Feb 2013 12:01:11 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 7 Feb 2013 12:01:11 -0500
Message-ID: <5113DDB2.7060805@mitre.org>
Date: Thu, 7 Feb 2013 12:00:34 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Prabath Siriwardena 
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com> <5112AE0B.1080501@mitre.org>  <5113C3AA.1040701@mitre.org> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090404040503090007010707"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Feb 2013 17:01:14 -0000

--------------090404040503090007010707
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

It validates the token, which would be either the token itself in the 
case of Bearer or the token "id" part of something more complex like 
MAC. It doesn't directly validate the usage of the token, that's still 
up to the PR to do that.

I nearly added a "token type" field in this draft, but held back because 
there are several kinds of "token type" that people talk about in OAuth. 
First, there's "Bearer" vs. "MAC" vs. "HOK", or what have you. Then 
within Bearer you have "JWT" or "SAML" or "unstructured blob". Then 
you've also got "access" vs. "refresh" and other flavors of token, like 
the id_token in OpenID Connect.

Thing is, the server running the introspection endpoint will probably 
know *all* of these. But should it tell the client? If so, which of the 
three, and what names should the fields be?

  -- Justin

On 02/07/2013 11:26 AM, Prabath Siriwardena wrote:
> Okay.. I was thinking this could be used as a way to validate the 
> token as well. BTW even in this case shouldn't communicate the type of 
> token to AS? For example in the case of SAML profile - it could be 
> SAML token..
>
> Thanks & regards,
> -Prabath
>
> On Thu, Feb 7, 2013 at 8:39 PM, Justin Richer  > wrote:
>
>     "valid" might not be the best term, but it's meant to be a field
>     where the server says "yes this token is still good" or "no this
>     token isn't good anymore". We could instead do this with HTTP
>     codes or something but I went with a pure JSON response.
>
>      -- Justin
>
>
>     On 02/06/2013 10:47 PM, Prabath Siriwardena wrote:
>>     Hi Justin,
>>
>>     I believe this is addressing one of the key missing part in OAuth
>>     2.0...
>>
>>     One question - I guess this was discussed already...
>>
>>     In the spec - in the introspection response it has the attribute
>>     "valid" - this is basically the validity of the token provided in
>>     the request.
>>
>>     Validation criteria depends on the token and well as token type (
>>     Bearer, MAC..).
>>
>>     In the spec it seems like it's coupled with Bearer token type...
>>     But I guess, by adding "token_type" to the request we can remove
>>     this dependency.
>>
>>     WDYT..?
>>
>>     Thanks & regards,
>>     -Prabath
>>
>>     On Thu, Feb 7, 2013 at 12:54 AM, Justin Richer >     > wrote:
>>
>>         Updated introspection draft based on recent comments. Changes
>>         include:
>>
>>          - "scope" return parameter now follows RFC6749 format
>>         instead of JSON array
>>          - "subject" -> "sub", and "audience" -> "aud", to be
>>         parallel with JWT claims
>>          - clarified what happens if the authentication is bad
>>
>>          -- Justin
>>
>>
>>         -------- Original Message --------
>>         Subject: 	New Version Notification for
>>         draft-richer-oauth-introspection-02.txt
>>         Date: 	Wed, 6 Feb 2013 11:24:20 -0800
>>         From: 	
>>         
>>         To: 	 
>>
>>
>>
>>         A new version of I-D, draft-richer-oauth-introspection-02.txt
>>         has been successfully submitted by Justin Richer and posted to the
>>         IETF repository.
>>
>>         Filename:	 draft-richer-oauth-introspection
>>         Revision:	 02
>>         Title:		 OAuth Token Introspection
>>         Creation date:	 2013-02-06
>>         WG ID:		 Individual Submission
>>         Number of pages: 6
>>         URL:http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
>>         Status:http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
>>         Htmlized:http://tools.ietf.org/html/draft-richer-oauth-introspection-02
>>         Diff:http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02
>>
>>         Abstract:
>>             This specification defines a method for a client or protected
>>             resource to query an OAuth authorization server to determine meta-
>>             information about an OAuth token.
>>
>>
>>                                                                                            
>>
>>
>>         The IETF Secretariat
>>
>>
>>
>>
>>         _______________________________________________
>>         OAuth mailing list
>>         OAuth@ietf.org 
>>         https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>>     -- 
>>     Thanks & Regards,
>>     Prabath
>>
>>     Mobile : +94 71 809 6732 
>>
>>     http://blog.facilelogin.com
>>     http://RampartFAQ.com
>
>
>
>
> -- 
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com

--------------090404040503090007010707
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

    It validates the token, which would be either the token itself in
    the case of Bearer or the token "id" part of something more complex
    like MAC. It doesn't directly validate the usage of the token,
    that's still up to the PR to do that.

    I nearly added a "token type" field in this draft, but held back
    because there are several kinds of "token type" that people talk
    about in OAuth. First, there's "Bearer" vs. "MAC" vs. "HOK", or what
    have you. Then within Bearer you have "JWT" or "SAML" or
    "unstructured blob". Then you've also got "access" vs. "refresh" and
    other flavors of token, like the id_token in OpenID Connect. 

    Thing is, the server running the introspection endpoint will
    probably know *all* of these. But should it tell the client? If so,
    which of the three, and what names should the fields be?

     -- Justin

    On 02/07/2013 11:26 AM, Prabath
      Siriwardena wrote:

      Okay.. I was thinking this could be used as a way to validate the
      token as well. BTW even in this case shouldn't communicate the
      type of token to AS? For example in the case of SAML profile - it
      could be SAML token..

      Thanks & regards,
      -Prabath

        On Thu, Feb 7, 2013 at 8:39 PM, Justin
          Richer <jricher@mitre.org>
          wrote:

             "valid" might not be
              the best term, but it's meant to be a field where the
              server says "yes this token is still good" or "no this
              token isn't good anymore". We could instead do this with
              HTTP codes or something but I went with a pure JSON
              response.

                   -- Justin

                  On 02/06/2013 10:47 PM, Prabath Siriwardena
                    wrote:

                   Hi Justin,

                    I believe this is addressing one of the key
                      missing part in OAuth 2.0...

                    One question - I guess this was discussed
                      already...

                    In the spec - in the introspection response it
                      has the attribute "valid" - this is basically the
                      validity of the token provided in the request.

                    Validation criteria depends on the token and
                      well as token type ( Bearer, MAC..).

                    In the spec it seems like it's coupled with
                      Bearer token type... But I guess, by adding
                      "token_type" to the request we can remove this
                      dependency.

                    WDYT..?

                    Thanks & regards,
                    -Prabath 

                      On Thu, Feb 7, 2013 at
                        12:54 AM, Justin Richer <jricher@mitre.org>
                        wrote:

                           Updated
                            introspection draft based on recent
                            comments. Changes include:

                             - "scope" return parameter now follows
                            RFC6749 format instead of JSON array

                             - "subject" -> "sub", and "audience"
                            -> "aud", to be parallel with JWT claims

                             - clarified what happens if the
                            authentication is bad

                             -- Justin

                              -------- Original Message --------

                                    Subject: 
                                    New Version Notification for
                                      draft-richer-oauth-introspection-02.txt

                                    Date: 
                                    Wed, 6 Feb 2013 11:24:20 -0800

                                    From: 
                                    <internet-drafts@ietf.org>

                                    To: 
                                    <jricher@mitre.org>

                              A new version of I-D, draft-richer-oauth-introspection-02.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 02
Title:		 OAuth Token Introspection
Creation date:	 2013-02-06
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.

The IETF Secretariat

_______________________________________________

                          OAuth mailing list

                          OAuth@ietf.org

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

                      -- 

                      Thanks & Regards,

                      Prabath

                      Mobile : +94 71
                          809 6732 

                        http://blog.facilelogin.com

                        http://RampartFAQ.com

        -- 

        Thanks & Regards,

        Prabath

        Mobile : +94 71 809 6732 

          http://blog.facilelogin.com

          http://RampartFAQ.com

--------------090404040503090007010707--

From zhou.sujing@zte.com.cn  Thu Feb  7 16:05:28 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40FD21F89E8 for ; Thu,  7 Feb 2013 16:05:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.095
X-Spam-Level: 
X-Spam-Status: No, score=-98.095 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n90mOgExFt+S for ; Thu,  7 Feb 2013 16:05:27 -0800 (PST)
Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1998D21F89E1 for ; Thu,  7 Feb 2013 16:05:26 -0800 (PST)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 341D73D0BD0; Fri,  8 Feb 2013 08:03:47 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id r18055Be044951; Fri, 8 Feb 2013 08:05:05 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: <5113D0EF.9070806@mitre.org>
To: Justin Richer 
MIME-Version: 1.0
X-KeepSent: 113436E9:A88FFC54-48257B0C:000054CA; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: zhou.sujing@zte.com.cn
Date: Fri, 8 Feb 2013 08:04:51 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-02-08 08:04:59, Serialize complete at 2013-02-08 08:04:59
Content-Type: multipart/alternative; boundary="=_alternative 00007F2448257B0C_="
X-MAIL: mse02.zte.com.cn r18055Be044951
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] A question on token revocation.
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Feb 2013 00:05:29 -0000

This is a multipart message in MIME format.
--=_alternative 00007F2448257B0C_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

QnV0IHdoYXQgaXMgdGhlIG1vdGl2YXRpb24gZm9yIGEgbWFsaWNvdXMgY2xpZW50IHRvIHJlcXVl
c3QgdG8gcmV2b2tlIA0KcmVtYWluaW5nIGFjY2VzcyB0b2tlbnM/DQoNCg0KSnVzdGluIFJpY2hl
ciA8anJpY2hlckBtaXRyZS5vcmc+INC009ogMjAxMy0wMi0wOCAwMDowNjowNzoNCg0KPiBUaGlz
LCBJIHRoaW5rLCBwb2ludHMgb3V0IHRoYXQgdGhlIFJPIGlzIGdlbmVyYWxseSBtb3JlIGNvbmNl
cm5lZCANCj4gd2l0aCByZXZva2luZyBhbiBhdXRob3JpemF0aW9uIGdyYW50IHRoYW4gYSB0b2tl
biBpdHNlbGYsIHdpdGggdGhlIA0KPiBsYXR0ZXIgcG90ZW50aWFsbHkgZW5jb21wYXNzaW5nIHNl
dmVyYWwgdG9rZW5zLiBUaGUgcmV2b2NhdGlvbiBkcmFmdA0KPiBpc24ndCByZWFsbHkgaW50ZW5k
ZWQgdG8gc29sdmUgdGhhdCBwcm9ibGVtLCBhcyBUb3JzdGVuIHBvaW50cyBvdXQgDQpiZWxvdy4N
Cj4gDQo+ICAtLSBKdXN0aW4NCg0KPiBPbiAwMi8wNy8yMDEzIDAzOjQ2IEFNLCB6aG91LnN1amlu
Z0B6dGUuY29tLmNuIHdyb3RlOg0KPiANCj4gRHVyaW5nIHRoZSBmb3VyIGdyYW50IHR5cGVzIG9m
IE9hdXRoLCANCj4gICAxLiBhdXRob3JpemF0aW9uIGNvZGU6IFJPIGtub3dzIHRoZSBhdXRob3Jp
emF0aW9uIGNvZGUgdXBvbiB3aGljaCANCj4gYWNjZXNzLXRva2Vucy10by1iZS1yZXZva2VkIGFy
ZSBpc3N1ZWQgDQo+ICAgMi4gaW1wbGljaXRlIGZsb3c6IFJPIGtub3dzIHRoZSBhY2Nlc3MtdG9r
ZW5zLXRvLWJlLXJldm9rZWQgDQo+ICAgMy4gcGFzc3dvcmQgYW5kIGNsaWVudCBjcmVkZW50aWFs
IHR5cGVzOiBSTyBoYXMgbm8gd2F5IG9mIGtub3dpbmcgDQo+IGFjY2VzcyB0b2tlbnMuIA0KPiAN
Cj4gU28sSU1PLCAgaXQgaXMgbm90IHByb3BlciBmb3IgUk8gdG8gcmV2b2tlIGFuIGVhY2ggYWNj
ZXNzIHRva2VuIA0KaW5kaXZpZHVhbGx5LA0KPiByYXRoZXIgaXQgY291bGQgcmV2b2tlIHNvbWUg
YWNjZXNzIHRva2VucyBieSBzcGVjaWZ5aW5nIGNvbmRpdGlvbnMsIA0KPiBzdWNoIGFzIGNsaWVu
dF9pZCwgdGltZV9wZXJpb2QsIHNjb3BlIA0KPiBDb21tZW50cz8gDQo+IA0KPiBQcmFiYXRoIFNp
cml3YXJkZW5hIDxwcmFiYXRoQHdzbzIuY29tPiDQtNPaIDIwMTMtMDItMDcgMTU6MjU6MDI6DQo+
IA0KPiA+IA0KPiANCj4gPiBPbiBUaHUsIEZlYiA3LCAyMDEzIGF0IDEyOjQ5IFBNLCA8emhvdS5z
dWppbmdAenRlLmNvbS5jbj4gd3JvdGU6IA0KPiA+IA0KPiA+IEkgZ3Vlc3MgUk8gY291bGQgaW5p
dGlhdGUgYWNjZXNzIHRva2VuIHJldm9jYXRpb24gZm9yIGEgY2xpZW50IGJ5IA0KPiA+IGluY2x1
ZGluZyBhdXRob3JpemF0aW9uIGNvZGUgaW4gdGhlIHJlcXVlc3QgdG8gQVMuIA0KPiA+IENvbW1l
bnRzPyANCj4gPiANCj4gPiBUaGF0IGNyZWF0ZXMgYSBkZXBlbmRlbmN5IG9uIHRoZSBncmFudCB0
eXBlLiANCj4gPiANCj4gPiBUaGFua3MgJiByZWdhcmRzLCANCj4gPiAtUHJhYmF0aCANCj4gPiAN
Cj4gPiANCj4gPiANCj4gPiANCj4gPiANCj4gPiBvYXV0aC1ib3VuY2VzQGlldGYub3JnINC009og
MjAxMy0wMi0wNyAwMjozMjoyODoNCj4gPiANCj4gPiA+IEhpIFRvcnN0ZW4sIA0KPiA+ID4gDQo+
ID4gPiBUaGFua3MgZm9yIHlvdXIgZmVlZGJhY2suLiBJIHdpbGwgc3VibWl0IGEgZHJhZnQuLi4g
DQo+ID4gPiANCj4gPiA+IFRoYW5rcyAmIHJlZ2FyZHMsIA0KPiA+ID4gLVByYWJhdGgNCj4gPiAN
Cj4gPiA+IE9uIFdlZCwgRmViIDYsIDIwMTMgYXQgMTE6NTUgUE0sIFRvcnN0ZW4gTG9kZGVyc3Rl
ZHQgPA0KPiA+IHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0DQo+ID4gPiA+IHdyb3RlOiANCj4gPiA+
IEhpIFByYWJhdGgsIA0KPiA+ID4gDQo+ID4gPiB3ZSB0cmllZCB0byBhZGRyZXNzIGJvdGggdXNl
IGNhc2VzIGluIHRoZSBmaXJzdCByZXZpc2lvbnMgb2YgdGhlIA0KPiA+ID4gZHJhZnQuIFRoZSBB
UEkgd2FzIHdlbGwgc3VpdGVkIGZvciBjbGllbnQtZHJpdmVuIHJldm9jYXRpb24gYnV0IG5vdCAN
Cj4gPiA+IHRoZSByZXNvdXJjZSBvd25lciAtIGRyaXZlbiB1c2UgY2FzZS4gVGhlcmUgYXJlIGRl
ZmluaXRlbHkgDQo+ID4gPiBkaWZmZXJlbmNlcyB3aXRoIHJlc3BlY3QgdG8gdGhlIHByb3RvY29s
IGRlc2lnbiwgYXQgbGVhc3QgcmVnYXJkaW5nIA0KPiA+ID4gYXV0aGVudGljYXRpb24gYW5kIGF1
dGhvcml6YXRpb24gb2YgdGhlIHJlc3BlY3RpdmUgYWN0b3JzLiBUaGlzIG1hZGUNCj4gPiA+IHRo
ZSBzcGVjIG1vcmUgY29tcGxleCBhbmQgY2F1c2VkIGFtYmlndWl0aWVzIGFuZCBjb25mdXNpb24u
IA0KPiA+ID4gTW9yZW92ZXIsIHRoZSB3b3JraW5nIGdyb3VwIHNlZW1lZCBub3QgY29udmluY2Vk
IGJ5IHRoZSB0aGUgDQo+IGxhdHRlcnVzZSBjYXNlLg0KPiA+ID4gDQo+ID4gPiBUaGVyZWZvcmUg
dGhlIHdvcmtpbmcgZ3JvdXAgZGVjaWRlZCB0byBmb2N1cyBvbiB0aGUgc2luZ2xlIHVzZSBjYXNl
cw0KPiA+ID4gb2YgdGhlIHJldm9jYXRpb24gYnkgY2xpZW50cy4gVGhpcyBtYWtlcyBhIGxvdCBv
ZiBzZW5zZSBzaW5jZSB0aGlzIA0KPiA+ID4gaW50ZXJmYWNlIGlzIG1vc3QgaW1wb3J0YW50IHdp
dGggcmVzcGVjdCB0byBpbnRlcm9wZXJhYmlsaXR5LiANCj4gPiA+IA0KPiA+ID4gSSdtIGZvY3Vz
aW5nIHJpZ2h0IG5vdyBvbiBmaW5pc2hpbmcgdGhpcyBkcmFmdC4gQW5kIHRoZSBvcGVuIGlzc3Vl
cyANCj4gPiA+IGRpc2N1c3NlZCBvbiB0aGUgbGlzdCBpbiB0aGUgbGFzdCBjb3VwbGUgb2Ygd2Vl
a3MgaWxsdXN0cmF0ZSB0aGF0IA0KPiA+ID4gZXZlbiB0aGlzIHBvc2VzIGEgY29uc2lkZXJhYmxl
IGFtb3VudCBvZiB3b3JrLiBTbyBJJ20gdmVyeSByZWx1Y3RhbnQNCj4gPiA+IHRvIGFkZCBzdXBw
b3J0IGZvciBhIHdob2xlIG5ldyB1c2UgY2FzZSBhdCB0aGF0IHBvaW50IG9mIHRoZSANCnByb2Nl
c3MuIA0KPiA+ID4gDQo+ID4gPiBJZiB5b3UgZmVlbCB0aGlzIGlzIGFuIGltcG9ydGFudCB1c2Ug
Y2FzZSB3b3J0aCBhbiBSRkMsIGRvbid0IA0KPiA+ID4gaGVzaXRhdGUgdG8gcHVibGlzaCBhIG5l
dyBJLUQuIA0KPiA+ID4gDQo+ID4gPiByZWdhcmRzLCANCj4gPiA+IFRvcnN0ZW4uIA0KPiA+ID4g
DQo+ID4gPiBBbSAwNi4wMi4yMDEzIHVtIDE2OjM3IHNjaHJpZWIgUHJhYmF0aCBTaXJpd2FyZGVu
YSANCjxwcmFiYXRoQHdzbzIuY29tPjoNCj4gPiANCj4gPiA+IA0KPiA+IA0KPiA+ID4gT24gV2Vk
LCBGZWIgNiwgMjAxMyBhdCA5OjA0IFBNLCBUb2RkIFcgTGFpbmhhcnQgDQo8bGFpbmhhcnRAdXMu
aWJtLmNvbT4NCj4gd3JvdGU6DQo+ID4gPiA+IFJlc291cmNlIG93bmVyIG5lZWRzIHRvIGtub3cg
dGhlIGNvbnN1bWVyIGtleSAocmVwcmVzZW50cyB0aGUgDQo+ID4gPiBPQXV0aCBDbGllbnQgYXBw
KSAmIHNjb3BlIHRvIHJldm9rZSB0aGUgYWNjZXNzIHRva2VuIGZvciBhIA0KZ2l2ZW5jbGllbnQu
IA0KPiA+IA0KPiA+ID4gSSBzZWUgLSB5b3UncmUgc2F5aW5nIHRoYXQgcmVxdWlyaW5nIGNsaWVu
dCBjcmVkZW50aWFscyBvbiB0aGUgZW5kIA0KPiA+ID4gcG9pbnQgaXMgdGhlIHByb2JsZW0/IA0K
PiA+ID4gDQo+ID4gPiBJbiBmYWN0IHdoYXQgSSBtZWFudCB3YXMgLSB3aGVuIFJPIGF1dGhvcml6
ZXMgdGhlIGFuIGFjY2VzcyB0b2tlbiANCj4gPiA+IGZvciBjbGllbnQgZm9yIHBhcnRpY3VsYXIg
c2NvcGUuIFRob3NlIGluZm9ybWF0aW9uIGFyZSBrZXB0IGF0IHRoZSANCkFTLiANCj4gPiA+IA0K
PiA+ID4gTm93IC0gaWYgdGhlIFJPIHdhbnQgdG8gcmV2b2tlIGFjY2VzcyBmcm9tIHRoZSBjbGll
bnQgLSB0aGUgUk8gbmVlZHMNCj4gPiA+IHRvIGF1dGhlbnRpY2F0ZSBoaW0gc2VsZiB0byB0aGUg
QVMgYW5kIHBhc3MgdGhlIGNvbnN1bWVyIGtleSBhbmQgdGhlDQo+ID4gPiBzY29wZS4gU28gQVMg
Y2FuIHJldm9rZSBhY2Nlc3MuIA0KPiA+ID4gDQo+ID4gPiBUaGFua3MgJiByZWdhcmRzLCANCj4g
PiA+IC1QcmFiYXRoIA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiANCj4g
PiA+IFRvZGQgTGFpbmhhcnQNCj4gPiA+IFJhdGlvbmFsIHNvZnR3YXJlDQo+ID4gPiBJQk0gQ29y
cG9yYXRpb24NCj4gPiA+IDU1MCBLaW5nIFN0cmVldCwgTGl0dGxldG9uLCBNQSAwMTQ2MC0xMjUw
DQo+ID4gPiAxLTk3OC04OTktNDcwNQ0KPiA+ID4gMi0yNzYtNDcwNSAoVC9MKQ0KPiA+ID4gbGFp
bmhhcnRAdXMuaWJtLmNvbSANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4g
DQo+ID4gDQo+ID4gPiBGcm9tOiAgICAgICAgUHJhYmF0aCBTaXJpd2FyZGVuYSA8cHJhYmF0aEB3
c28yLmNvbT4gDQo+ID4gPiBUbzogICAgICAgIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0cmUu
b3JnPiwgDQo+ID4gPiBDYzogICAgICAgICJvYXV0aEBpZXRmLm9yZyBXRyIgPG9hdXRoQGlldGYu
b3JnPiANCj4gPiA+IERhdGU6ICAgICAgICAwMi8wNi8yMDEzIDEwOjMxIEFNIA0KPiA+ID4gU3Vi
amVjdDogICAgICAgIFJlOiBbT0FVVEgtV0ddIEEgcXVlc3Rpb24gb24gdG9rZW4gcmV2b2NhdGlv
bi4gDQo+ID4gPiBTZW50IGJ5OiAgICAgICAgb2F1dGgtYm91bmNlc0BpZXRmLm9yZyANCj4gPiA+
IA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IA0KPiANCj4gPiA+IE9uIFdlZCwgRmViIDYsIDIwMTMg
YXQgODo0OSBQTSwgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXRyZS5vcmc+IA0Kd3JvdGU6IA0K
PiA+ID4gDQo+ID4gPiBPbiAwMi8wNi8yMDEzIDEwOjEzIEFNLCBQcmFiYXRoIFNpcml3YXJkZW5h
IHdyb3RlOiANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiBPbiBXZWQsIEZlYiA2LCAyMDEzIGF0IDg6
MTkgUE0sIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0cmUub3JnPiANCndyb3RlOiANCj4gPiA+
IFRoZXNlIGFyZSBnZW5lcmFsbHkgaGFuZGxlZCB0aHJvdWdoIGEgdXNlciBpbnRlcmZhY2Ugd2hl
cmUgdGhlIFJPIGlzDQo+ID4gPiBhdXRoZW50aWNhdGVkIGRpcmVjdGx5IHRvIHRoZSBBUywgYW5k
IHRoZXJlJ3Mgbm90IG11Y2ggbmVlZCBmb3IgYSANCj4gPiA+ICJwcm90b2NvbCIgaGVyZSwgaW4g
cHJhY3RpY2UuIA0KPiA+ID4gDQo+ID4gPiBXaHkgZG8geW91IHRoaW5rIGxlYXZpbmcgYWNjZXNz
IHRva2VuIHJldm9jYXRpb24gYnkgUk8gdG8gYSANCj4gPiA+IHByb3ByaWV0YXJ5IEFQSSBpcyBh
IGdvb2QgcHJhY3RpY2UgPyBJTU8gdGhpcyBhbiBlc3NlbnRpYWwgDQo+ID4gPiByZXF1aXJlbWVu
dCBpbiBBUEkgc2VjdXJpdHkuIA0KPiA+ID4gSSB0aGluayBpdCBtYWtlcyBtb3JlIHNlbnNlIGlu
IHRoZSBzYW1lIHdheSB0aGF0IGhhdmluZyBhIA0KPiA+ID4gInByb3ByaWV0YXJ5IiBVSS9BUEkg
Zm9yIG1hbmFnaW5nIHRoZSB1c2VyIGNvbnNlbnQgbWFrZXMgc2Vuc2U6IA0KPiA+ID4gdW5sZXNz
IHlvdSdyZSBkb2luZyBhIGZ1bGx5IGR5bmFtaWMgZW5kLXRvLWVuZCBzeXN0ZW0gbGlrZSBVTUEs
IHRoZW4NCj4gPiA+IHRoZXJlJ3Mgbm90IG11Y2ggdmFsdWUgaW4gdHJ5aW5nIHRvIHNxdWVlemUg
ZGlzcGFyYXRlIHN5c3RlbXMgaW50byANCj4gPiA+IHRoZSBzYW1lIG1vbGQsIHNpbmNlIHRoZXkg
d29uJ3QgYmUgdGFsa2luZyB0byBlYWNoIG90aGVyIGFueXdheS4gDQo+ID4gPiANCj4gPiA+IFRo
aXMgaXMgcmVxdWlyZWQgaW4gZGlzdHJpYnV0ZWQgc2V0dXAgZm9yIGVhY2ggQVBJIHBsYXRmb3Jt
IGZyb20gDQo+ID4gPiBkaWZmZXJlbnQgdmVuZG9ycyB0byBwZXJmb3JtIGluIGFuIGludGVyb3Ag
bWFubmVyLiANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiBBbmQgc2luY2UgeW91IHJlZmVyIHRvIGl0
IGFzIGFuICJBUEkiLCB3aGF0IHdpbGwgdGhlIFJPIGJlIHVzaW5nIHRvIA0KPiA+ID4gY2FsbCB0
aGlzIEFQST8gSXMgdGhlcmUgYSB0b2tlbiBtYW5hZ2VtZW50IGNsaWVudCB0aGF0J3Mgc2VwYXJh
dGUgDQo+ID4gPiBmcm9tIHRoZSBPQXV0aCBjbGllbnQ/IA0KPiA+ID4gDQo+ID4gPiBJIGRpZG4n
dCBnZXQgeW91ciBxdWVzdGlvbiByaWdodC4uLiBJZiB5b3UgbWVhbnQgdGhlIGhvdyB0byBpbnZv
a2UgDQo+ID4gPiByZXZvY2F0aW9uIGVuZCBwb2ludCwgdGhlIHRoZSByZXNvdXJjZSBvd25lciBu
ZWVkcyB0byBrbm93IHRoZSANCj4gPiA+IGNvbnN1bWVyIGtleSAocmVwcmVzZW50cyB0aGUgT0F1
dGggQ2xpZW50IGFwcCkgJiBzY29wZSB0byByZXZva2UgdGhlDQo+ID4gPiBhY2Nlc3MgdG9rZW4g
Zm9yIGEgZ2l2ZW4gY2xpZW50LiANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IElNSE8g
dG9rZW4gcmV2b2NhdGlvbiBkb25lIG15IFJPIGlzIG1vcmUgcHJhY3RpY2FsIHRoYW4gdG9rZW4g
DQo+ID4gPiByZXZvY2F0aW9uIGRvbmUgYnkgdGhlIENsaWVudC4gDQo+ID4gPiBUaGV5J3JlIGJv
dGggdmFsaWQgYnV0IHJlcXVpcmUgZGlmZmVyZW50IGtpbmRzIG9mIHByb3RvY29scyBhbmQgDQo+
ID4gPiBjb25zaWRlcmF0aW9ucy4gVGhpcyB0b2tlbiByZXZvY2F0aW9uIGRyYWZ0IGlzIG1lYW50
IHRvIHNvbHZlIG9uZSANCj4gPiA+IHByb2JsZW0sIGFuZCB0aGF0IGRvZXNuJ3QgbWVhbiBpdCBj
YW4gb3Igc2hvdWxkIHNvbHZlIG90aGVyIA0KPiA+ID4gc2VlbWluZ2x5IHJlbGF0ZWQgcHJvYmxl
bXMuDQo+ID4gPiANCj4gPiA+IElmIHlvdSB3b3VsZCBsaWtlIHRvIHNlZSB0aGUgUk8taW5pdGlh
dGVkIHRva2VuIHJldm9jYXRpb24gZ28gDQo+ID4gPiB0aHJvdWdoIChub3QgZ3JhbnQgcmV2b2Nh
dGlvbiwgbWluZCB5b3UgLS0gdGhhdCdzIHJlbGF0ZWQsIGJ1dCANCj4gPiA+IGRpZmZlcmVudCks
IHRoZW4gSSB3b3VsZCBzdWdnZXN0IHRoYXQgeW91IHN0YXJ0IHNwZWNpZnlpbmcgZXhhY3RseSAN
Cj4gPiA+IGhvdyB0aGF0IHdvcmtzLiBJIHByZWRpY3QgaXQgd2lsbCBiZSBwcm9ibGVtYXRpYyBp
biBwcmFjdGljZSwgDQo+ID4gPiB0aG91Z2gsIGFzIHRoZSBSTyBvZnRlbiBkb2Vzbid0IGFjdHVh
bGx5IGhhdmUgZGlyZWN0IGFjY2VzcyB0byB0aGUgDQo+ID4gPiB0b2tlbiBpdHNlbGYuIA0KPiA+
ID4gDQo+ID4gPiBSZXNvdXJjZSBvd25lciBuZWVkcyB0byBrbm93IHRoZSBjb25zdW1lciBrZXkg
KHJlcHJlc2VudHMgdGhlIE9BdXRoIA0KPiA+ID4gQ2xpZW50IGFwcCkgJiBzY29wZSB0byByZXZv
a2UgdGhlIGFjY2VzcyB0b2tlbiBmb3IgYSBnaXZlbiBjbGllbnQuIA0KPiA+ID4gDQo+ID4gPiAN
Cj4gPiA+IA0KPiA+ID4gDQo+ID4gPiBUaGVyZSBhcmUgbGFyZ2VyIGFwcGxpY2F0aW9ucywgbGlr
ZSBVTUEsIHRoYXQgaGF2ZSBjbGllbnQgYW5kIFBSIA0KPiA+ID4gcHJvdmlzaW9uaW5nIHRoYXQg
d291bGQgYWxsb3cgZm9yIHRoaXMgdG8gYmUgbWFuYWdlZCBzb21ld2hhdCANCj4gPiA+IHByb2dy
YW1tYXRpY2FsbHksIGJ1dCBldmVuIGluIHRoYXQgY2FzZSB5b3UncmUgc3RpbGwgZ2VuZXJhbGx5
IGRvaW5nDQo+ID4gPiB0b2tlbiByZXZvY2F0aW9uIGJ5IGEgImNsaWVudCIgaW4gc29tZSBmYXNo
aW9uLiBJbiBVTUEsIHRob3VnaCwgDQo+ID4gPiBzZXZlcmFsIGRpZmZlcmVudCBwaWVjZXMgY2Fu
IHBsYXkgdGhlIHJvbGUgb2YgYSAiY2xpZW50IiBhdCANCj4gPiA+IGRpZmZlcmVudCBwYXJ0cyBv
ZiB0aGUgcHJvY2Vzcy4NCj4gPiA+IA0KPiA+ID4gUmV2b2tpbmcgYSBzY29wZSBpcyBhIHdob2xl
IGRpZmZlcmVudCBtZXNzLiBHZW5lcmFsbHksIHlvdSdkIHdhbnQgdG8NCj4gPiA+IGp1c3QgcmV2
b2tlIGFuIGV4aXN0aW5nIHRva2VuIGFuZCBtYWtlIGEgbmV3IGF1dGhvcml6YXRpb24gZ3JhbnQg
DQo+ID4gPiB3aXRoIGxvd2VyIGFjY2VzcyBpZiB5b3UgZG9uJ3Qgd2FudCB0aGF0IGNsaWVudCBn
ZXR0aW5nIHRoYXQgc2NvcGUgDQo+ID4gPiBhbnltb3JlLiBJZiB5b3UganVzdCB3YW50IHRvIGRv
d25zY29wZSBmb3IgYSBzaW5nbGUgdHJhbnNhY3Rpb24sIHlvdQ0KPiA+ID4gY2FuIGFscmVhZHkg
ZG8gdGhhdCB3aXRoIGVpdGhlciB0aGUgcmVmcmVzaCB0b2tlbiBvciB0b2tlbiBjaGFpbmluZyAN
Cj4gPiA+IGFwcHJvYWNoZXMsIGRlcGVuZGluZyBvbiB3aGVyZSBpbiB0aGUgcHJvY2VzcyB5b3Ug
YXJlLiBUaGUgbGF0dGVyIG9mDQo+ID4gPiB0aGVzZSBhcmUgYm90aCBjbGllbnQtZm9jdXNlZCwg
dGhvdWdoLCBhbmQgdGhlIFJPIGRvZXNuJ3QgaGF2ZSBhIA0KPiA+ID4gZGlyZWN0IGhhbmQgaW4g
aXQgYXQgdGhpcyBwb2ludC4gDQo+ID4gPiANCj4gPiA+IFdoeSBkbyB5b3UgdGhpbmsgaXQgYSBt
ZXNzLiBJZiB5b3UgcmV2b2tlIHRoZSBlbnRpcmUgdG9rZW4gdGhlbiANCj4gPiA+IENsaWVudCBu
ZWVkcyB0byBnbyB0aHJvdWdoIHRoZSBjb21wbGV0ZSBPQXV0aCBmbG93IC0gYW5kIGFsc28gbmVl
ZHMgDQo+ID4gPiB0byBnZXQgdGhlIHVzZXIgY29uc2VudC4gSWYgUk8gY2FuICBkb3duZ3JhZGUg
dGhlIHNjb3BlLCB0aGVuIHdlIA0KPiA+ID4gcmVzdHJpY3QgQVBJIGFjY2VzcyBieSB0aGUgY2xp
ZW50IGF0IFJTIGVuZCBhbmQgaXRzIHRyYW5zcGFyZW50IHRvIA0KPiA+ID4gdGhlIGNsaWVudC4g
DQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gRG93bmdyYWRpbmcgdGhlIHNjb3BlIG9mIHRva2VucyBp
biB0aGUgd2lsZCBpcyBoYXJkbHkgdHJhbnNwYXJlbnQgdG8NCj4gPiA+IHRoZSBjbGllbnQgKHN0
dWZmIHRoYXQgaXQgZXhwZWN0cyB0byB3b3JrIHdpbGwgc3VkZGVubHkgc3RhcnQgdG8gDQo+ID4g
PiBmYWlsLCBtZWFuaW5nIHRoYXQgbW9zdCBjbGllbnRzIHdpbGwgdGhyb3cgb3V0IHRoZSB0b2tl
biBhbmQgdHJ5IHRvIA0KPiA+ID4gZ2V0IGEgbmV3IG9uZSksIGFuZCBpbiBhIGRpc3RyaWJ1dGVk
IHN5c3RlbSB5b3UndmUgZ290IHRvIHByb3BhZ2F0ZSANCj4gPiA+IHRoYXQgY2hhbmdlIHRvIHRo
ZSBSUy4gSWYgeW91IGJha2UgdGhlIHNjb3BlcyBpbnRvIHRoZSB0b2tlbiBpdHNlbGYgDQo+ID4g
PiAod2hpY2ggbWFueSBkbykgdGhlbiB5b3UgYWN0dWFsbHkgKmNhbid0KiBkb3duZ3JhZGUgYSBz
aW5nbGUgDQo+IHRva2VuLCBhbnl3YXkuIA0KPiA+ID4gDQo+ID4gPiBZZXMuLiB0aGF0IGlzIHRo
ZSBleHBlY3RlZCBiZWhhdmlvci4gSSBtZWFuIHRoZSBwcm9jZXNzIGlzIA0KPiA+ID4gdHJhbnNw
YXJlbnQuIENsaWVudCB3aWxsIG5vdGljZSBhdCBydW50aW1lLiANCj4gPiA+IA0KPiA+ID4gVGhh
bmtzICYgcmVnYXJkcywgDQo+ID4gPiAtUHJhYmF0aCANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiAg
LS0gSnVzdGluIA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IFRoYW5rcyAmIHJlZ2FyZHMsIA0KPiA+
ID4gLVByYWJhdGggDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiAgLS0gSnVzdGluIA0K
PiA+ID4gDQo+ID4gPiANCj4gPiA+IE9uIDAyLzA2LzIwMTMgMDQ6MzUgQU0sIFByYWJhdGggU2ly
aXdhcmRlbmEgd3JvdGU6IA0KPiA+ID4gSSBhbSBzb3JyeSBpZiB0aGlzIHdhcyBhbHJlYWR5IGRp
c2N1c3NlZCBpbiB0aGlzIGxpc3QuLiANCj4gPiA+IA0KPiA+ID4gTG9va2luZyBhdCBbMV0gaXQg
b25seSB0YWxrcyBhYm91dCByZXZva2luZyB0aGUgYWNjZXNzIHRva2VuIGZyb20gDQo+ID4gdGhl
IGNsaWVudC4gDQo+ID4gPiANCj4gPiA+IEhvdyBhYm91dCB0aGUgcmVzb3VyY2Ugb3duZXIuLj8g
DQo+ID4gPiANCj4gPiA+IFRoZXJlIGNhbiBiZSBjYXNlcyB3aGVyZSByZXNvdXJjZSBvd25lciBu
ZWVkcyB0byByZXZva2UgYW4gDQo+ID4gPiBhdXRob3JpemVkIGFjY2VzcyB0b2tlbiBmcm9tIGEg
Z2l2ZW4gY2xpZW50LiBPciByZXZva2UgYW4gc2NvcGUuLiANCj4gPiA+IA0KPiA+ID4gSG93IGFy
ZSB3ZSBnb2luZyB0byBhZGRyZXNzIHRoZXNlIHJlcXVpcmVtZW50cy4uPyBUaG91Z2h0cyANCmFw
cHJlY2lhdGVkLi4uIA0KPiA+ID4gDQo+ID4gPiBbMV0gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0
bWwvZHJhZnQtaWV0Zi1vYXV0aC1yZXZvY2F0aW9uLTA0IA0KPiA+ID4gDQo+ID4gPiAtLSANCj4g
PiA+IFRoYW5rcyAmIFJlZ2FyZHMsDQo+ID4gPiBQcmFiYXRoIA0KPiA+ID4gDQo+ID4gPiBNb2Jp
bGUgOiArOTQgNzEgODA5IDY3MzIgDQo+ID4gPiANCj4gPiA+IGh0dHA6Ly9ibG9nLmZhY2lsZWxv
Z2luLmNvbQ0KPiA+ID4gaHR0cDovL1JhbXBhcnRGQVEuY29tIA0KPiA+ID4gDQo+ID4gPiANCj4g
PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4g
PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gPiA+IE9BdXRoQGlldGYub3JnDQo+ID4gPiBodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+ID4gPiANCj4gPiA+IA0KPiA+
ID4gDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gLS0gDQo+ID4gPiBUaGFua3MgJiBSZWdhcmRzLA0K
PiA+ID4gUHJhYmF0aCANCj4gPiA+IA0KPiA+ID4gTW9iaWxlIDogKzk0IDcxIDgwOSA2NzMyIA0K
PiA+ID4gDQo+ID4gPiBodHRwOi8vYmxvZy5mYWNpbGVsb2dpbi5jb20NCj4gPiA+IGh0dHA6Ly9S
YW1wYXJ0RkFRLmNvbSANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gLS0g
DQo+ID4gPiBUaGFua3MgJiBSZWdhcmRzLA0KPiA+ID4gUHJhYmF0aCANCj4gPiA+IA0KPiA+ID4g
TW9iaWxlIDogKzk0IDcxIDgwOSA2NzMyIA0KPiA+ID4gDQo+ID4gPiBodHRwOi8vYmxvZy5mYWNp
bGVsb2dpbi5jb20gDQo+ID4gPiBodHRwOi8vUmFtcGFydEZBUS5jb21fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gT0F1dGggbWFpbGluZyBsaXN0
DQo+ID4gPiBPQXV0aEBpZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aA0KPiA+IA0KPiA+ID4gDQo+ID4gDQo+ID4gPiANCj4gPiA+IC0tIA0K
PiA+ID4gVGhhbmtzICYgUmVnYXJkcywNCj4gPiA+IFByYWJhdGggDQo+ID4gPiANCj4gPiA+IE1v
YmlsZSA6ICs5NCA3MSA4MDkgNjczMiANCj4gPiA+IA0KPiA+ID4gaHR0cDovL2Jsb2cuZmFjaWxl
bG9naW4uY29tDQo+ID4gPiBodHRwOi8vUmFtcGFydEZBUS5jb20gDQo+ID4gPiBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gT0F1dGggbWFpbGlu
ZyBsaXN0DQo+ID4gPiBPQXV0aEBpZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vYXV0aCANCj4gPiA+IA0KPiA+IA0KPiA+ID4gDQo+ID4gPiAtLSAN
Cj4gPiA+IFRoYW5rcyAmIFJlZ2FyZHMsDQo+ID4gPiBQcmFiYXRoIA0KPiA+ID4gDQo+ID4gPiBN
b2JpbGUgOiArOTQgNzEgODA5IDY3MzIgDQo+ID4gPiANCj4gPiA+IGh0dHA6Ly9ibG9nLmZhY2ls
ZWxvZ2luLmNvbQ0KPiA+ID4gaHR0cDovL1JhbXBhcnRGQVEuY29tX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IE9BdXRoIG1haWxpbmcgbGlzdA0K
PiA+ID4gT0F1dGhAaWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vb2F1dGggDQo+ID4gDQo+IA0KPiA+IA0KPiA+IC0tIA0KPiA+IFRoYW5rcyAmIFJl
Z2FyZHMsDQo+ID4gUHJhYmF0aCANCj4gPiANCj4gPiBNb2JpbGUgOiArOTQgNzEgODA5IDY3MzIg
DQo+ID4gDQo+ID4gaHR0cDovL2Jsb2cuZmFjaWxlbG9naW4uY29tDQo+ID4gaHR0cDovL1JhbXBh
cnRGQVEuY29tIA0KDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQo+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9yZw0KPiBodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg==
--=_alternative 00007F2448257B0C_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJ1dCB3aGF0IGlzIHRoZSBtb3Rp
dmF0aW9uIGZvciBhIG1hbGljb3VzDQpjbGllbnQgdG8gcmVxdWVzdCB0byByZXZva2UgcmVtYWlu
aW5nIGFjY2VzcyB0b2tlbnM/PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXpl
PTI+SnVzdGluIFJpY2hlciAmbHQ7anJpY2hlckBtaXRyZS5vcmcmZ3Q7INC009ogMjAxMy0wMi0w
OA0KMDA6MDY6MDc6PGJyPg0KPGJyPg0KJmd0OyBUaGlzLCBJIHRoaW5rLCBwb2ludHMgb3V0IHRo
YXQgdGhlIFJPIGlzIGdlbmVyYWxseSBtb3JlIGNvbmNlcm5lZA0KPGJyPg0KJmd0OyB3aXRoIHJl
dm9raW5nIGFuIGF1dGhvcml6YXRpb24gZ3JhbnQgdGhhbiBhIHRva2VuIGl0c2VsZiwgd2l0aCB0
aGUNCjxicj4NCiZndDsgbGF0dGVyIHBvdGVudGlhbGx5IGVuY29tcGFzc2luZyBzZXZlcmFsIHRv
a2Vucy4gVGhlIHJldm9jYXRpb24gZHJhZnQ8YnI+DQomZ3Q7IGlzbid0IHJlYWxseSBpbnRlbmRl
ZCB0byBzb2x2ZSB0aGF0IHByb2JsZW0sIGFzIFRvcnN0ZW4gcG9pbnRzIG91dA0KYmVsb3cuPGJy
Pg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOy0tIEp1c3Rpbjxicj4NCjwvZm9udD48L3R0Pg0KPGJy
Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyBPbiAwMi8wNy8yMDEzIDAzOjQ2IEFNLCB6aG91LnN1amlu
Z0B6dGUuY29tLmNuDQp3cm90ZTo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn
dDsgPGJyPg0KJmd0OyBEdXJpbmcgdGhlIGZvdXIgZ3JhbnQgdHlwZXMgb2YgT2F1dGgsIDxicj4N
CiZndDsgJm5ic3A7IDEuIGF1dGhvcml6YXRpb24gY29kZTogUk8ga25vd3MgdGhlIGF1dGhvcml6
YXRpb24gY29kZSB1cG9uDQp3aGljaCA8YnI+DQomZ3Q7IGFjY2Vzcy10b2tlbnMtdG8tYmUtcmV2
b2tlZCBhcmUgaXNzdWVkICZuYnNwOyA8YnI+DQomZ3Q7ICZuYnNwOyAyLiBpbXBsaWNpdGUgZmxv
dzogUk8ga25vd3MgdGhlIGFjY2Vzcy10b2tlbnMtdG8tYmUtcmV2b2tlZA0KPGJyPg0KJmd0OyAm
bmJzcDsgMy4gcGFzc3dvcmQgYW5kIGNsaWVudCBjcmVkZW50aWFsIHR5cGVzOiBSTyBoYXMgbm8g
d2F5IG9mIGtub3dpbmcNCjxicj4NCiZndDsgYWNjZXNzIHRva2Vucy4gJm5ic3A7IDxicj4NCiZn
dDsgPGJyPg0KJmd0OyBTbyxJTU8sICZuYnNwO2l0IGlzIG5vdCBwcm9wZXIgZm9yIFJPIHRvIHJl
dm9rZSBhbiBlYWNoIGFjY2VzcyB0b2tlbg0KaW5kaXZpZHVhbGx5LDxicj4NCiZndDsgcmF0aGVy
IGl0IGNvdWxkIHJldm9rZSBzb21lIGFjY2VzcyB0b2tlbnMgYnkgc3BlY2lmeWluZyBjb25kaXRp
b25zLA0KPGJyPg0KJmd0OyBzdWNoIGFzIGNsaWVudF9pZCwgdGltZV9wZXJpb2QsIHNjb3BlIDxi
cj4NCiZndDsgQ29tbWVudHM/IDxicj4NCiZndDsgPGJyPg0KJmd0OyBQcmFiYXRoIFNpcml3YXJk
ZW5hICZsdDtwcmFiYXRoQHdzbzIuY29tJmd0OyDQtNPaIDIwMTMtMDItMDcgMTU6MjU6MDI6PGJy
Pg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgT24gVGh1
LCBGZWIgNywgMjAxMyBhdCAxMjo0OSBQTSwgJmx0O3pob3Uuc3VqaW5nQHp0ZS5jb20uY24mZ3Q7
DQp3cm90ZTogPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJIGd1ZXNzIFJPIGNvdWxk
IGluaXRpYXRlIGFjY2VzcyB0b2tlbiByZXZvY2F0aW9uIGZvciBhIGNsaWVudA0KYnkgPGJyPg0K
Jmd0OyAmZ3Q7IGluY2x1ZGluZyBhdXRob3JpemF0aW9uIGNvZGUgaW4gdGhlIHJlcXVlc3QgdG8g
QVMuIDxicj4NCiZndDsgJmd0OyBDb21tZW50cz8gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsg
Jmd0OyBUaGF0IGNyZWF0ZXMgYSBkZXBlbmRlbmN5IG9uIHRoZSBncmFudCB0eXBlLiA8YnI+DQom
Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRoYW5rcyAmYW1wOyByZWdhcmRzLCA8YnI+DQomZ3Q7
ICZndDsgLVByYWJhdGggPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgPGJy
Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm
Z3Q7IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcg0LTT2iAyMDEzLTAyLTA3IDAyOjMyOjI4Ojxicj4N
CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBIaSBUb3JzdGVuLCA8YnI+DQomZ3Q7ICZn
dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBUaGFua3MgZm9yIHlvdXIgZmVlZGJhY2suLiBJ
IHdpbGwgc3VibWl0IGEgZHJhZnQuLi4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAm
Z3Q7ICZndDsgVGhhbmtzICZhbXA7IHJlZ2FyZHMsIDxicj4NCiZndDsgJmd0OyAmZ3Q7IC1QcmFi
YXRoPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IE9uIFdlZCwgRmViIDYsIDIw
MTMgYXQgMTE6NTUgUE0sIFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0Ozxicj4NCiZndDsgJmd0OyB0
b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgd3JvdGU6IDxi
cj4NCiZndDsgJmd0OyAmZ3Q7IEhpIFByYWJhdGgsIDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4N
CiZndDsgJmd0OyAmZ3Q7IHdlIHRyaWVkIHRvIGFkZHJlc3MgYm90aCB1c2UgY2FzZXMgaW4gdGhl
IGZpcnN0IHJldmlzaW9ucw0Kb2YgdGhlIDxicj4NCiZndDsgJmd0OyAmZ3Q7IGRyYWZ0LiBUaGUg
QVBJIHdhcyB3ZWxsIHN1aXRlZCBmb3IgY2xpZW50LWRyaXZlbiByZXZvY2F0aW9uDQpidXQgbm90
IDxicj4NCiZndDsgJmd0OyAmZ3Q7IHRoZSByZXNvdXJjZSBvd25lciAtIGRyaXZlbiB1c2UgY2Fz
ZS4gVGhlcmUgYXJlIGRlZmluaXRlbHkNCjxicj4NCiZndDsgJmd0OyAmZ3Q7IGRpZmZlcmVuY2Vz
IHdpdGggcmVzcGVjdCB0byB0aGUgcHJvdG9jb2wgZGVzaWduLCBhdCBsZWFzdA0KcmVnYXJkaW5n
IDxicj4NCiZndDsgJmd0OyAmZ3Q7IGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIG9m
IHRoZSByZXNwZWN0aXZlIGFjdG9ycy4NClRoaXMgbWFkZTxicj4NCiZndDsgJmd0OyAmZ3Q7IHRo
ZSBzcGVjIG1vcmUgY29tcGxleCBhbmQgY2F1c2VkIGFtYmlndWl0aWVzIGFuZCBjb25mdXNpb24u
DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyBNb3Jlb3ZlciwgdGhlIHdvcmtpbmcgZ3JvdXAgc2VlbWVk
IG5vdCBjb252aW5jZWQgYnkgdGhlDQp0aGUgPGJyPg0KJmd0OyBsYXR0ZXJ1c2UgY2FzZS48YnI+
DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBUaGVyZWZvcmUgdGhlIHdvcmtp
bmcgZ3JvdXAgZGVjaWRlZCB0byBmb2N1cyBvbiB0aGUgc2luZ2xlDQp1c2UgY2FzZXM8YnI+DQom
Z3Q7ICZndDsgJmd0OyBvZiB0aGUgcmV2b2NhdGlvbiBieSBjbGllbnRzLiBUaGlzIG1ha2VzIGEg
bG90IG9mIHNlbnNlDQpzaW5jZSB0aGlzIDxicj4NCiZndDsgJmd0OyAmZ3Q7IGludGVyZmFjZSBp
cyBtb3N0IGltcG9ydGFudCB3aXRoIHJlc3BlY3QgdG8gaW50ZXJvcGVyYWJpbGl0eS4NCjxicj4N
CiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEknbSBmb2N1c2luZyByaWdodCBu
b3cgb24gZmluaXNoaW5nIHRoaXMgZHJhZnQuIEFuZCB0aGUNCm9wZW4gaXNzdWVzIDxicj4NCiZn
dDsgJmd0OyAmZ3Q7IGRpc2N1c3NlZCBvbiB0aGUgbGlzdCBpbiB0aGUgbGFzdCBjb3VwbGUgb2Yg
d2Vla3MgaWxsdXN0cmF0ZQ0KdGhhdCA8YnI+DQomZ3Q7ICZndDsgJmd0OyBldmVuIHRoaXMgcG9z
ZXMgYSBjb25zaWRlcmFibGUgYW1vdW50IG9mIHdvcmsuIFNvIEknbSB2ZXJ5DQpyZWx1Y3RhbnQ8
YnI+DQomZ3Q7ICZndDsgJmd0OyB0byBhZGQgc3VwcG9ydCBmb3IgYSB3aG9sZSBuZXcgdXNlIGNh
c2UgYXQgdGhhdCBwb2ludCBvZg0KdGhlIHByb2Nlc3MuIDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxi
cj4NCiZndDsgJmd0OyAmZ3Q7IElmIHlvdSBmZWVsIHRoaXMgaXMgYW4gaW1wb3J0YW50IHVzZSBj
YXNlIHdvcnRoIGFuIFJGQywNCmRvbid0IDxicj4NCiZndDsgJmd0OyAmZ3Q7IGhlc2l0YXRlIHRv
IHB1Ymxpc2ggYSBuZXcgSS1ELiA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg
Jmd0OyByZWdhcmRzLCA8YnI+DQomZ3Q7ICZndDsgJmd0OyBUb3JzdGVuLiA8YnI+DQomZ3Q7ICZn
dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBBbSAwNi4wMi4yMDEzIHVtIDE2OjM3IHNjaHJp
ZWIgUHJhYmF0aCBTaXJpd2FyZGVuYSAmbHQ7cHJhYmF0aEB3c28yLmNvbSZndDs6PGJyPg0KJmd0
OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn
dDsgJmd0OyBPbiBXZWQsIEZlYiA2LCAyMDEzIGF0IDk6MDQgUE0sIFRvZGQgVyBMYWluaGFydCAm
bHQ7bGFpbmhhcnRAdXMuaWJtLmNvbSZndDs8YnI+DQomZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0
OyAmZ3Q7ICZndDsgUmVzb3VyY2Ugb3duZXIgbmVlZHMgdG8ga25vdyB0aGUgY29uc3VtZXIga2V5
IChyZXByZXNlbnRzDQp0aGUgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgT0F1dGggQ2xpZW50IGFwcCkg
JmFtcDsgc2NvcGUgdG8gcmV2b2tlIHRoZSBhY2Nlc3MgdG9rZW4NCmZvciBhIGdpdmVuY2xpZW50
LiAmbmJzcDs8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgSSBzZWUgLSB5b3Un
cmUgc2F5aW5nIHRoYXQgcmVxdWlyaW5nIGNsaWVudCBjcmVkZW50aWFscw0Kb24gdGhlIGVuZCA8
YnI+DQomZ3Q7ICZndDsgJmd0OyBwb2ludCBpcyB0aGUgcHJvYmxlbT8gPGJyPg0KJmd0OyAmZ3Q7
ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgSW4gZmFjdCB3aGF0IEkgbWVhbnQgd2FzIC0gd2hl
biBSTyBhdXRob3JpemVzIHRoZSBhbiBhY2Nlc3MNCnRva2VuIDxicj4NCiZndDsgJmd0OyAmZ3Q7
IGZvciBjbGllbnQgZm9yIHBhcnRpY3VsYXIgc2NvcGUuIFRob3NlIGluZm9ybWF0aW9uIGFyZSBr
ZXB0DQphdCB0aGUgQVMuIDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7
IE5vdyAtIGlmIHRoZSBSTyB3YW50IHRvIHJldm9rZSBhY2Nlc3MgZnJvbSB0aGUgY2xpZW50IC0N
CnRoZSBSTyBuZWVkczxicj4NCiZndDsgJmd0OyAmZ3Q7IHRvIGF1dGhlbnRpY2F0ZSBoaW0gc2Vs
ZiB0byB0aGUgQVMgYW5kIHBhc3MgdGhlIGNvbnN1bWVyDQprZXkgYW5kIHRoZTxicj4NCiZndDsg
Jmd0OyAmZ3Q7IHNjb3BlLiBTbyBBUyBjYW4gcmV2b2tlIGFjY2Vzcy4gPGJyPg0KJmd0OyAmZ3Q7
ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhhbmtzICZhbXA7IHJlZ2FyZHMsIDxicj4NCiZn
dDsgJmd0OyAmZ3Q7IC1QcmFiYXRoIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQom
Z3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8
YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBUb2RkIExhaW5oYXJ0PGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgUmF0aW9uYWwgc29mdHdhcmU8YnI+DQomZ3Q7ICZndDsgJmd0OyBJ
Qk0gQ29ycG9yYXRpb248YnI+DQomZ3Q7ICZndDsgJmd0OyA1NTAgS2luZyBTdHJlZXQsIExpdHRs
ZXRvbiwgTUEgMDE0NjAtMTI1MDxicj4NCiZndDsgJmd0OyAmZ3Q7IDEtOTc4LTg5OS00NzA1PGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgMi0yNzYtNDcwNSAoVC9MKTxicj4NCiZndDsgJmd0OyAmZ3Q7IGxh
aW5oYXJ0QHVzLmlibS5jb20gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAm
Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEZyb206ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwO1ByYWJhdGggU2lyaXdhcmRlbmEgJmx0O3ByYWJhdGhAd3Nv
Mi5jb20mZ3Q7DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyBUbzogJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7SnVzdGluIFJpY2hlciAmbHQ7anJpY2hlckBtaXRyZS5vcmcmZ3Q7LA0KPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgQ2M6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O29hdXRoQGll
dGYub3JnIFdHJnF1b3Q7DQombHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7IDxicj4NCiZndDsgJmd0OyAm
Z3Q7IERhdGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzAyLzA2LzIwMTMgMTA6MzEgQU0g
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgU3ViamVjdDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
UmU6IFtPQVVUSC1XR10gQSBxdWVzdGlvbg0Kb24gdG9rZW4gcmV2b2NhdGlvbi4gPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgU2VudCBieTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7b2F1dGgtYm91
bmNlc0BpZXRmLm9yZw0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyA8YnI+
DQomZ3Q7ICZndDsgJmd0OyBPbiBXZWQsIEZlYiA2LCAyMDEzIGF0IDg6NDkgUE0sIEp1c3RpbiBS
aWNoZXIgJmx0O2pyaWNoZXJAbWl0cmUub3JnJmd0Ow0Kd3JvdGU6IDxicj4NCiZndDsgJmd0OyAm
Z3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IE9uIDAyLzA2LzIwMTMgMTA6MTMgQU0sIFByYWJhdGgg
U2lyaXdhcmRlbmEgd3JvdGU6IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAm
Z3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IE9uIFdlZCwgRmViIDYsIDIwMTMgYXQgODoxOSBQTSwg
SnVzdGluIFJpY2hlciAmbHQ7anJpY2hlckBtaXRyZS5vcmcmZ3Q7DQp3cm90ZTogPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgVGhlc2UgYXJlIGdlbmVyYWxseSBoYW5kbGVkIHRocm91Z2ggYSB1c2VyIGlu
dGVyZmFjZSB3aGVyZQ0KdGhlIFJPIGlzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgYXV0aGVudGljYXRl
ZCBkaXJlY3RseSB0byB0aGUgQVMsIGFuZCB0aGVyZSdzIG5vdCBtdWNoIG5lZWQNCmZvciBhIDxi
cj4NCiZndDsgJmd0OyAmZ3Q7ICZxdW90O3Byb3RvY29sJnF1b3Q7IGhlcmUsIGluIHByYWN0aWNl
LiA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBXaHkgZG8geW91IHRo
aW5rIGxlYXZpbmcgYWNjZXNzIHRva2VuIHJldm9jYXRpb24gYnkgUk8gdG8NCmEgPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgcHJvcHJpZXRhcnkgQVBJIGlzIGEgZ29vZCBwcmFjdGljZSA/IElNTyB0aGlz
IGFuIGVzc2VudGlhbA0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsgcmVxdWlyZW1lbnQgaW4gQVBJIHNl
Y3VyaXR5LiA8YnI+DQomZ3Q7ICZndDsgJmd0OyBJIHRoaW5rIGl0IG1ha2VzIG1vcmUgc2Vuc2Ug
aW4gdGhlIHNhbWUgd2F5IHRoYXQgaGF2aW5nDQphIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZxdW90
O3Byb3ByaWV0YXJ5JnF1b3Q7IFVJL0FQSSBmb3IgbWFuYWdpbmcgdGhlIHVzZXIgY29uc2VudA0K
bWFrZXMgc2Vuc2U6IDxicj4NCiZndDsgJmd0OyAmZ3Q7IHVubGVzcyB5b3UncmUgZG9pbmcgYSBm
dWxseSBkeW5hbWljIGVuZC10by1lbmQgc3lzdGVtIGxpa2UNClVNQSwgdGhlbjxicj4NCiZndDsg
Jmd0OyAmZ3Q7IHRoZXJlJ3Mgbm90IG11Y2ggdmFsdWUgaW4gdHJ5aW5nIHRvIHNxdWVlemUgZGlz
cGFyYXRlIHN5c3RlbXMNCmludG8gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdGhlIHNhbWUgbW9sZCwg
c2luY2UgdGhleSB3b24ndCBiZSB0YWxraW5nIHRvIGVhY2ggb3RoZXINCmFueXdheS4gPGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhpcyBpcyByZXF1aXJlZCBpbiBk
aXN0cmlidXRlZCBzZXR1cCBmb3IgZWFjaCBBUEkgcGxhdGZvcm0NCmZyb20gPGJyPg0KJmd0OyAm
Z3Q7ICZndDsgZGlmZmVyZW50IHZlbmRvcnMgdG8gcGVyZm9ybSBpbiBhbiBpbnRlcm9wIG1hbm5l
ci4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4N
CiZndDsgJmd0OyAmZ3Q7IEFuZCBzaW5jZSB5b3UgcmVmZXIgdG8gaXQgYXMgYW4gJnF1b3Q7QVBJ
JnF1b3Q7LCB3aGF0IHdpbGwNCnRoZSBSTyBiZSB1c2luZyB0byA8YnI+DQomZ3Q7ICZndDsgJmd0
OyBjYWxsIHRoaXMgQVBJPyBJcyB0aGVyZSBhIHRva2VuIG1hbmFnZW1lbnQgY2xpZW50IHRoYXQn
cw0Kc2VwYXJhdGUgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZnJvbSB0aGUgT0F1dGggY2xpZW50PyA8
YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBJIGRpZG4ndCBnZXQgeW91
ciBxdWVzdGlvbiByaWdodC4uLiBJZiB5b3UgbWVhbnQgdGhlIGhvdw0KdG8gaW52b2tlIDxicj4N
CiZndDsgJmd0OyAmZ3Q7IHJldm9jYXRpb24gZW5kIHBvaW50LCB0aGUgdGhlIHJlc291cmNlIG93
bmVyIG5lZWRzIHRvIGtub3cNCnRoZSA8YnI+DQomZ3Q7ICZndDsgJmd0OyBjb25zdW1lciBrZXkg
KHJlcHJlc2VudHMgdGhlIE9BdXRoIENsaWVudCBhcHApICZhbXA7IHNjb3BlDQp0byByZXZva2Ug
dGhlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgYWNjZXNzIHRva2VuIGZvciBhIGdpdmVuIGNsaWVudC4g
Jm5ic3A7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgSU1ITyB0b2tlbiByZXZvY2F0aW9uIGRv
bmUgbXkgUk8gaXMgbW9yZSBwcmFjdGljYWwgdGhhbg0KdG9rZW4gPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgcmV2b2NhdGlvbiBkb25lIGJ5IHRoZSBDbGllbnQuIDxicj4NCiZndDsgJmd0OyAmZ3Q7IFRo
ZXkncmUgYm90aCB2YWxpZCBidXQgcmVxdWlyZSBkaWZmZXJlbnQga2luZHMgb2YgcHJvdG9jb2xz
DQphbmQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgY29uc2lkZXJhdGlvbnMuIFRoaXMgdG9rZW4gcmV2
b2NhdGlvbiBkcmFmdCBpcyBtZWFudCB0bw0Kc29sdmUgb25lIDxicj4NCiZndDsgJmd0OyAmZ3Q7
IHByb2JsZW0sIGFuZCB0aGF0IGRvZXNuJ3QgbWVhbiBpdCBjYW4gb3Igc2hvdWxkIHNvbHZlIG90
aGVyDQo8YnI+DQomZ3Q7ICZndDsgJmd0OyBzZWVtaW5nbHkgcmVsYXRlZCBwcm9ibGVtcy48YnI+
DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBJZiB5b3Ugd291bGQgbGlrZSB0
byBzZWUgdGhlIFJPLWluaXRpYXRlZCB0b2tlbiByZXZvY2F0aW9uDQpnbyA8YnI+DQomZ3Q7ICZn
dDsgJmd0OyB0aHJvdWdoIChub3QgZ3JhbnQgcmV2b2NhdGlvbiwgbWluZCB5b3UgLS0gdGhhdCdz
IHJlbGF0ZWQsDQpidXQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZGlmZmVyZW50KSwgdGhlbiBJIHdv
dWxkIHN1Z2dlc3QgdGhhdCB5b3Ugc3RhcnQgc3BlY2lmeWluZw0KZXhhY3RseSA8YnI+DQomZ3Q7
ICZndDsgJmd0OyBob3cgdGhhdCB3b3Jrcy4gSSBwcmVkaWN0IGl0IHdpbGwgYmUgcHJvYmxlbWF0
aWMgaW4gcHJhY3RpY2UsDQo8YnI+DQomZ3Q7ICZndDsgJmd0OyB0aG91Z2gsIGFzIHRoZSBSTyBv
ZnRlbiBkb2Vzbid0IGFjdHVhbGx5IGhhdmUgZGlyZWN0IGFjY2Vzcw0KdG8gdGhlIDxicj4NCiZn
dDsgJmd0OyAmZ3Q7IHRva2VuIGl0c2VsZi4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgUmVzb3VyY2Ugb3duZXIgbmVlZHMgdG8ga25vdyB0aGUgY29uc3VtZXIga2V5
IChyZXByZXNlbnRzDQp0aGUgT0F1dGggPGJyPg0KJmd0OyAmZ3Q7ICZndDsgQ2xpZW50IGFwcCkg
JmFtcDsgc2NvcGUgdG8gcmV2b2tlIHRoZSBhY2Nlc3MgdG9rZW4gZm9yIGENCmdpdmVuIGNsaWVu
dC4gJm5ic3A7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7
IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQom
Z3Q7ICZndDsgJmd0OyBUaGVyZSBhcmUgbGFyZ2VyIGFwcGxpY2F0aW9ucywgbGlrZSBVTUEsIHRo
YXQgaGF2ZSBjbGllbnQNCmFuZCBQUiA8YnI+DQomZ3Q7ICZndDsgJmd0OyBwcm92aXNpb25pbmcg
dGhhdCB3b3VsZCBhbGxvdyBmb3IgdGhpcyB0byBiZSBtYW5hZ2VkIHNvbWV3aGF0DQo8YnI+DQom
Z3Q7ICZndDsgJmd0OyBwcm9ncmFtbWF0aWNhbGx5LCBidXQgZXZlbiBpbiB0aGF0IGNhc2UgeW91
J3JlIHN0aWxsIGdlbmVyYWxseQ0KZG9pbmc8YnI+DQomZ3Q7ICZndDsgJmd0OyB0b2tlbiByZXZv
Y2F0aW9uIGJ5IGEgJnF1b3Q7Y2xpZW50JnF1b3Q7IGluIHNvbWUgZmFzaGlvbi4NCkluIFVNQSwg
dGhvdWdoLCA8YnI+DQomZ3Q7ICZndDsgJmd0OyBzZXZlcmFsIGRpZmZlcmVudCBwaWVjZXMgY2Fu
IHBsYXkgdGhlIHJvbGUgb2YgYSAmcXVvdDtjbGllbnQmcXVvdDsNCmF0IDxicj4NCiZndDsgJmd0
OyAmZ3Q7IGRpZmZlcmVudCBwYXJ0cyBvZiB0aGUgcHJvY2Vzcy48YnI+DQomZ3Q7ICZndDsgJmd0
OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBSZXZva2luZyBhIHNjb3BlIGlzIGEgd2hvbGUgZGlmZmVy
ZW50IG1lc3MuIEdlbmVyYWxseSwgeW91J2QNCndhbnQgdG88YnI+DQomZ3Q7ICZndDsgJmd0OyBq
dXN0IHJldm9rZSBhbiBleGlzdGluZyB0b2tlbiBhbmQgbWFrZSBhIG5ldyBhdXRob3JpemF0aW9u
DQpncmFudCA8YnI+DQomZ3Q7ICZndDsgJmd0OyB3aXRoIGxvd2VyIGFjY2VzcyBpZiB5b3UgZG9u
J3Qgd2FudCB0aGF0IGNsaWVudCBnZXR0aW5nDQp0aGF0IHNjb3BlIDxicj4NCiZndDsgJmd0OyAm
Z3Q7IGFueW1vcmUuIElmIHlvdSBqdXN0IHdhbnQgdG8gZG93bnNjb3BlIGZvciBhIHNpbmdsZSB0
cmFuc2FjdGlvbiwNCnlvdTxicj4NCiZndDsgJmd0OyAmZ3Q7IGNhbiBhbHJlYWR5IGRvIHRoYXQg
d2l0aCBlaXRoZXIgdGhlIHJlZnJlc2ggdG9rZW4gb3IgdG9rZW4NCmNoYWluaW5nIDxicj4NCiZn
dDsgJmd0OyAmZ3Q7IGFwcHJvYWNoZXMsIGRlcGVuZGluZyBvbiB3aGVyZSBpbiB0aGUgcHJvY2Vz
cyB5b3UgYXJlLiBUaGUNCmxhdHRlciBvZjxicj4NCiZndDsgJmd0OyAmZ3Q7IHRoZXNlIGFyZSBi
b3RoIGNsaWVudC1mb2N1c2VkLCB0aG91Z2gsIGFuZCB0aGUgUk8gZG9lc24ndA0KaGF2ZSBhIDxi
cj4NCiZndDsgJmd0OyAmZ3Q7IGRpcmVjdCBoYW5kIGluIGl0IGF0IHRoaXMgcG9pbnQuIDxicj4N
CiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IFdoeSBkbyB5b3UgdGhpbmsgaXQg
YSBtZXNzLiBJZiB5b3UgcmV2b2tlIHRoZSBlbnRpcmUgdG9rZW4NCnRoZW4gPGJyPg0KJmd0OyAm
Z3Q7ICZndDsgQ2xpZW50IG5lZWRzIHRvIGdvIHRocm91Z2ggdGhlIGNvbXBsZXRlIE9BdXRoIGZs
b3cgLSBhbmQNCmFsc28gbmVlZHMgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdG8gZ2V0IHRoZSB1c2Vy
IGNvbnNlbnQuIElmIFJPIGNhbiAmbmJzcDtkb3duZ3JhZGUgdGhlIHNjb3BlLA0KdGhlbiB3ZSA8
YnI+DQomZ3Q7ICZndDsgJmd0OyByZXN0cmljdCBBUEkgYWNjZXNzIGJ5IHRoZSBjbGllbnQgYXQg
UlMgZW5kIGFuZCBpdHMgdHJhbnNwYXJlbnQNCnRvIDxicj4NCiZndDsgJmd0OyAmZ3Q7IHRoZSBj
bGllbnQuIDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZn
dDsgJmd0OyAmZ3Q7IERvd25ncmFkaW5nIHRoZSBzY29wZSBvZiB0b2tlbnMgaW4gdGhlIHdpbGQg
aXMgaGFyZGx5IHRyYW5zcGFyZW50DQp0bzxicj4NCiZndDsgJmd0OyAmZ3Q7IHRoZSBjbGllbnQg
KHN0dWZmIHRoYXQgaXQgZXhwZWN0cyB0byB3b3JrIHdpbGwgc3VkZGVubHkNCnN0YXJ0IHRvIDxi
cj4NCiZndDsgJmd0OyAmZ3Q7IGZhaWwsIG1lYW5pbmcgdGhhdCBtb3N0IGNsaWVudHMgd2lsbCB0
aHJvdyBvdXQgdGhlIHRva2VuDQphbmQgdHJ5IHRvIDxicj4NCiZndDsgJmd0OyAmZ3Q7IGdldCBh
IG5ldyBvbmUpLCBhbmQgaW4gYSBkaXN0cmlidXRlZCBzeXN0ZW0geW91J3ZlIGdvdCB0bw0KcHJv
cGFnYXRlIDxicj4NCiZndDsgJmd0OyAmZ3Q7IHRoYXQgY2hhbmdlIHRvIHRoZSBSUy4gSWYgeW91
IGJha2UgdGhlIHNjb3BlcyBpbnRvIHRoZSB0b2tlbg0KaXRzZWxmIDxicj4NCiZndDsgJmd0OyAm
Z3Q7ICh3aGljaCBtYW55IGRvKSB0aGVuIHlvdSBhY3R1YWxseSAqY2FuJ3QqIGRvd25ncmFkZSBh
IHNpbmdsZQ0KPGJyPg0KJmd0OyB0b2tlbiwgYW55d2F5LiA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8
YnI+DQomZ3Q7ICZndDsgJmd0OyBZZXMuLiB0aGF0IGlzIHRoZSBleHBlY3RlZCBiZWhhdmlvci4g
SSBtZWFuIHRoZSBwcm9jZXNzDQppcyA8YnI+DQomZ3Q7ICZndDsgJmd0OyB0cmFuc3BhcmVudC4g
Q2xpZW50IHdpbGwgbm90aWNlIGF0IHJ1bnRpbWUuIDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4N
CiZndDsgJmd0OyAmZ3Q7IFRoYW5rcyAmYW1wOyByZWdhcmRzLCA8YnI+DQomZ3Q7ICZndDsgJmd0
OyAtUHJhYmF0aCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7LS0gSnVzdGluIDxicj4NCiZndDsgJmd0OyAm
Z3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IFRoYW5rcyAmYW1w
OyByZWdhcmRzLCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAtUHJhYmF0aCA8YnI+DQomZ3Q7ICZndDsg
Jmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7LS0gSnVzdGluIDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxi
cj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IE9uIDAyLzA2LzIwMTMgMDQ6
MzUgQU0sIFByYWJhdGggU2lyaXdhcmRlbmEgd3JvdGU6IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEkg
YW0gc29ycnkgaWYgdGhpcyB3YXMgYWxyZWFkeSBkaXNjdXNzZWQgaW4gdGhpcyBsaXN0Li4NCiZu
YnNwOzxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IExvb2tpbmcgYXQg
WzFdIGl0IG9ubHkgdGFsa3MgYWJvdXQgcmV2b2tpbmcgdGhlIGFjY2VzcyB0b2tlbg0KZnJvbSA8
YnI+DQomZ3Q7ICZndDsgdGhlIGNsaWVudC4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgSG93IGFib3V0IHRoZSByZXNvdXJjZSBvd25lci4uPyA8YnI+DQomZ3Q7ICZn
dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBUaGVyZSBjYW4gYmUgY2FzZXMgd2hlcmUgcmVz
b3VyY2Ugb3duZXIgbmVlZHMgdG8gcmV2b2tlDQphbiA8YnI+DQomZ3Q7ICZndDsgJmd0OyBhdXRo
b3JpemVkIGFjY2VzcyB0b2tlbiBmcm9tIGEgZ2l2ZW4gY2xpZW50LiBPciByZXZva2UgYW4NCnNj
b3BlLi4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgSG93IGFyZSB3
ZSBnb2luZyB0byBhZGRyZXNzIHRoZXNlIHJlcXVpcmVtZW50cy4uPyBUaG91Z2h0cw0KYXBwcmVj
aWF0ZWQuLi4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgWzFdIGh0
dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtcmV2b2NhdGlvbi0wNA0K
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgLS0gPGJyPg0KJmd0OyAm
Z3Q7ICZndDsgVGhhbmtzICZhbXA7IFJlZ2FyZHMsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgUHJhYmF0
aCA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBNb2JpbGUgOiArOTQg
NzEgODA5IDY3MzIgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaHR0
cDovL2Jsb2cuZmFjaWxlbG9naW4uY29tPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaHR0cDovL1JhbXBh
cnRGQVEuY29tIDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4N
CiZndDsgJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fPGJyPg0KJmd0OyAmZ3Q7ICZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAm
Z3Q7ICZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgJmd0OyBodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgLS0gPGJyPg0KJmd0OyAm
Z3Q7ICZndDsgVGhhbmtzICZhbXA7IFJlZ2FyZHMsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgUHJhYmF0
aCA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBNb2JpbGUgOiArOTQg
NzEgODA5IDY3MzIgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaHR0
cDovL2Jsb2cuZmFjaWxlbG9naW4uY29tPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaHR0cDovL1JhbXBh
cnRGQVEuY29tIDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4N
CiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7
IC0tIDxicj4NCiZndDsgJmd0OyAmZ3Q7IFRoYW5rcyAmYW1wOyBSZWdhcmRzLDxicj4NCiZndDsg
Jmd0OyAmZ3Q7IFByYWJhdGggPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgTW9iaWxlIDogKzk0IDcxIDgwOSA2NzMyIDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZn
dDsgJmd0OyAmZ3Q7IGh0dHA6Ly9ibG9nLmZhY2lsZWxvZ2luLmNvbSA8YnI+DQomZ3Q7ICZndDsg
Jmd0OyBodHRwOi8vUmFtcGFydEZBUS5jb21fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyAmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxi
cj4NCiZndDsgJmd0OyAmZ3Q7IE9BdXRoQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj4NCiZndDsgJmd0OyA8
YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgLS0gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhhbmtzICZhbXA7
IFJlZ2FyZHMsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgUHJhYmF0aCA8YnI+DQomZ3Q7ICZndDsgJmd0
OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBNb2JpbGUgOiArOTQgNzEgODA5IDY3MzIgPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaHR0cDovL2Jsb2cuZmFjaWxlbG9naW4u
Y29tPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaHR0cDovL1JhbXBhcnRGQVEuY29tIDxicj4NCiZndDsg
Jmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgT0F1dGhAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgJmd0OyBodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsg
Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAtLSA8YnI+DQom
Z3Q7ICZndDsgJmd0OyBUaGFua3MgJmFtcDsgUmVnYXJkcyw8YnI+DQomZ3Q7ICZndDsgJmd0OyBQ
cmFiYXRoIDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IE1vYmlsZSA6
ICs5NCA3MSA4MDkgNjczMiA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0
OyBodHRwOi8vYmxvZy5mYWNpbGVsb2dpbi5jb208YnI+DQomZ3Q7ICZndDsgJmd0OyBodHRwOi8v
UmFtcGFydEZBUS5jb21fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXzxicj4NCiZndDsgJmd0OyAmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0
OyAmZ3Q7IE9BdXRoQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyA8
YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IC0tIDxicj4NCiZndDsgJmd0OyBUaGFua3Mg
JmFtcDsgUmVnYXJkcyw8YnI+DQomZ3Q7ICZndDsgUHJhYmF0aCA8YnI+DQomZ3Q7ICZndDsgPGJy
Pg0KJmd0OyAmZ3Q7IE1vYmlsZSA6ICs5NCA3MSA4MDkgNjczMiA8YnI+DQomZ3Q7ICZndDsgPGJy
Pg0KJmd0OyAmZ3Q7IGh0dHA6Ly9ibG9nLmZhY2lsZWxvZ2luLmNvbTxicj4NCiZndDsgJmd0OyBo
dHRwOi8vUmFtcGFydEZBUS5jb20gPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp
emU9Mj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
PGJyPg0KJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IE9BdXRoQGlldGYub3JnPGJy
Pg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyPg0K
PC9mb250PjwvdHQ+DQo=
--=_alternative 00007F2448257B0C_=--

From prabath@wso2.com  Thu Feb  7 21:51:04 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F96321F88E4 for ; Thu,  7 Feb 2013 21:51:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.84
X-Spam-Level: 
X-Spam-Status: No, score=-2.84 tagged_above=-999 required=5 tests=[AWL=0.136,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4UuyJ+V5HLP for ; Thu,  7 Feb 2013 21:51:03 -0800 (PST)
Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5AD21F8D1F for ; Thu,  7 Feb 2013 21:51:01 -0800 (PST)
Received: by mail-ee0-f48.google.com with SMTP id t10so1858683eei.21 for ; Thu, 07 Feb 2013 21:51:00 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=ezOwYD3kvEMMgN7gixMIRl7fdmAKW58PQm1RTTfQKlc=; b=R/KH621BFhDalvsZpGAGNQrcO2NU24mLZh+B9wol53H3l9mNQW5ITHdliQDvN0YVFc yqHawIl506KqBg3WNyJpPBeDU06FeyUHkP9nU4SP8UEq5rTCk4MdzfyDQbi87+yjp/kn kWjDsZkoK6mW5f/hWU4fzCbLSbQpr67dld94XnGYdVvhZMqWGfy1rpifNPU23U2FNSu6 DXtGXYFBqkbh5zmlrKO4Wnze3LQlzJF+Xt0A0ORRrVi76kHZmdg0mmH1yMT3zq1D7NFO FyYtcvcZshJzM9o5Uz6/r15uAX5jmAp0zcycTpcdnRp7fglXPMRJdLsKNlh/F5R8s2QX N7MQ==
MIME-Version: 1.0
X-Received: by 10.14.202.197 with SMTP id d45mr12645073eeo.1.1360302660692; Thu, 07 Feb 2013 21:51:00 -0800 (PST)
Received: by 10.223.194.134 with HTTP; Thu, 7 Feb 2013 21:51:00 -0800 (PST)
In-Reply-To: <5113DDB2.7060805@mitre.org>
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com> <5112AE0B.1080501@mitre.org>  <5113C3AA.1040701@mitre.org>  <5113DDB2.7060805@mitre.org>
Date: Fri, 8 Feb 2013 11:21:00 +0530
Message-ID: 
From: Prabath Siriwardena 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=047d7b343b06e0aaaf04d53024df
X-Gm-Message-State: ALoCoQkrW1scWZVAO0fPMRY52F1JS2nyROoWVYJMxywbCqntDvqFZlPnOLyuVtfEZgmFj/FajOmH
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Feb 2013 05:51:04 -0000

--047d7b343b06e0aaaf04d53024df
Content-Type: text/plain; charset=ISO-8859-1

Hi Justin,

I have couple of questions related to "valid" parameter...

This endpoint can be invoked by the Resource Server in runtime...

In that case what is exactly meant by the "resource_id" in request ?

IMO a token to be valid depends on set of criteria based on it's type..

For a Bearer token..

1. Token should not be expired
2. Token should not be revoked.
3. The scope the token issued should match with the scope required for the
resource.

For a MAC token...

1. Token not expired (mac id)
2. Token should not be revoked
3. The scope the token issued should match with the scope required for the
resource.
4. HMAC check should be valid

There are similar conditions for SAML bearer too..

Thanks & regards,
-Prabath

On Thu, Feb 7, 2013 at 10:30 PM, Justin Richer  wrote:

>  It validates the token, which would be either the token itself in the
> case of Bearer or the token "id" part of something more complex like MAC.
> It doesn't directly validate the usage of the token, that's still up to the
> PR to do that.
>
> I nearly added a "token type" field in this draft, but held back because
> there are several kinds of "token type" that people talk about in OAuth.
> First, there's "Bearer" vs. "MAC" vs. "HOK", or what have you. Then within
> Bearer you have "JWT" or "SAML" or "unstructured blob". Then you've also
> got "access" vs. "refresh" and other flavors of token, like the id_token in
> OpenID Connect.
>
> Thing is, the server running the introspection endpoint will probably know
> *all* of these. But should it tell the client? If so, which of the three,
> and what names should the fields be?
>
>  -- Justin
>
>
> On 02/07/2013 11:26 AM, Prabath Siriwardena wrote:
>
> Okay.. I was thinking this could be used as a way to validate the token as
> well. BTW even in this case shouldn't communicate the type of token to AS?
> For example in the case of SAML profile - it could be SAML token..
>
>  Thanks & regards,
> -Prabath
>
> On Thu, Feb 7, 2013 at 8:39 PM, Justin Richer  wrote:
>
>>  "valid" might not be the best term, but it's meant to be a field where
>> the server says "yes this token is still good" or "no this token isn't good
>> anymore". We could instead do this with HTTP codes or something but I went
>> with a pure JSON response.
>>
>>  -- Justin
>>
>>
>> On 02/06/2013 10:47 PM, Prabath Siriwardena wrote:
>>
>> Hi Justin,
>>
>>  I believe this is addressing one of the key missing part in OAuth 2.0...
>>
>>  One question - I guess this was discussed already...
>>
>>  In the spec - in the introspection response it has the attribute
>> "valid" - this is basically the validity of the token provided in the
>> request.
>>
>>  Validation criteria depends on the token and well as token type (
>> Bearer, MAC..).
>>
>>  In the spec it seems like it's coupled with Bearer token type... But I
>> guess, by adding "token_type" to the request we can remove this dependency.
>>
>>  WDYT..?
>>
>>  Thanks & regards,
>> -Prabath
>>
>> On Thu, Feb 7, 2013 at 12:54 AM, Justin Richer  wrote:
>>
>>>  Updated introspection draft based on recent comments. Changes include:
>>>
>>>  - "scope" return parameter now follows RFC6749 format instead of JSON
>>> array
>>>  - "subject" -> "sub", and "audience" -> "aud", to be parallel with JWT
>>> claims
>>>  - clarified what happens if the authentication is bad
>>>
>>>  -- Justin
>>>
>>>
>>> -------- Original Message --------  Subject: New Version Notification
>>> for draft-richer-oauth-introspection-02.txt  Date: Wed, 6 Feb 2013
>>> 11:24:20 -0800  From:   To:
>>>  
>>>
>>> A new version of I-D, draft-richer-oauth-introspection-02.txt
>>> has been successfully submitted by Justin Richer and posted to the
>>> IETF repository.
>>>
>>> Filename:	 draft-richer-oauth-introspection
>>> Revision:	 02
>>> Title:		 OAuth Token Introspection
>>> Creation date:	 2013-02-06
>>> WG ID:		 Individual Submission
>>> Number of pages: 6
>>> URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
>>> Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
>>> Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-02
>>> Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02
>>>
>>> Abstract:
>>>    This specification defines a method for a client or protected
>>>    resource to query an OAuth authorization server to determine meta-
>>>    information about an OAuth token.
>>>
>>>
>>>
>>>
>>>
>>> The IETF Secretariat
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>
>>
>>  --
>> Thanks & Regards,
>> Prabath
>>
>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>
>> http://blog.facilelogin.com
>> http://RampartFAQ.com
>>
>>
>>
>
>
>  --
> Thanks & Regards,
> Prabath
>
>  Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com
>
>
>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.com

--047d7b343b06e0aaaf04d53024df
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi=A0Justin,
I have couple of questions related to "=
;valid" parameter...

This endpoint can be inv=
oked by the Resource Server in runtime...

In that =
case what is exactly meant by the "resource_id" in request ?

IMO a token to be valid depends on set of criteria base=
d on it's type..

For a Bearer token..

1. Token should not be expired
2. Token should n=
ot be revoked.
3. The scope the token issued should match with the scope required for=
 the resource.

For a MAC token...

1. Token not expired (mac id)
2. Token should not be rev=
oked
3. The scope the token issued should match with the scope required for=
 the resource.
4. HMAC check should be valid

=
There are similar conditions for SAML bearer too..

Thanks & regards,
-Prabath

=
On Thu, Feb 7, 2013 at 10:30 PM, Justin Richer <=
span dir=3D"ltr"><jricher@mitre.org> wrote:

 =20
   =20
 =20

    It validates the token, which would be either the token itself in
    the case of Bearer or the token "id" part of something more c=
omplex
    like MAC. It doesn't directly validate the usage of the token,
    that's still up to the PR to do that.

    I nearly added a "token type" field in this draft, but held b=
ack
    because there are several kinds of "token type" that people t=
alk
    about in OAuth. First, there's "Bearer" vs. "MAC&quo=
t; vs. "HOK", or what
    have you. Then within Bearer you have "JWT" or "SAML&quo=
t; or
    "unstructured blob". Then you've also got "access&qu=
ot; vs. "refresh" and
    other flavors of token, like the id_token in OpenID Connect. 

    Thing is, the server running the introspection endpoint will
    probably know *all* of these. But should it tell the client? If so,
    which of the three, and what names should the fields be?

    =A0-- Justin

    On 02/07/2013 11:26 AM, Prabath
      Siriwardena wrote:

     =20
      Okay.. I was thinking this could be used as a way to validate the
      token as well. BTW even in this case shouldn't communicate the
      type of token to AS? For example in the case of SAML profile - it
      could be SAML token..

      Thanks & regards,
      -Prabath

        On Thu, Feb 7, 2013 at 8:39 PM, Justin
          Richer <jricher@mitre.org>
          wrote:

             "valid" mi=
ght not be
              the best term, but it's meant to be a field where the
              server says "yes this token is still good" or "=
;no this
              token isn't good anymore". We could instead do this =
with
              HTTP codes or something but I went with a pure JSON
              response.

                  =A0-- Justin

                  On 02/06/2013 10:47 PM, Prabath Siriwardena
                    wrote:

                   Hi Justin,

                    I believe this is addressing one of the key
                      missing part in OAuth 2.0...

                    One question - I guess this was discussed
                      already...

                    In the spec - in the introspection response it
                      has the attribute "valid" - this is basical=
ly the
                      validity of the token provided in the request.

                    Validation=A0criteria depends on the token and
                      well as token type ( Bearer, MAC..).

                    In the spec it seems like it's coupled with
                      Bearer token type... But I guess, by adding
                      "token_type" to the request we can remove t=
his
                      dependency.

                    WDYT..?

                    Thanks & regards,
                    -Prabath=A0

                      On Thu, Feb 7, 2013 at
                        12:54 AM, Justin Richer <jricher@mitre.org>=

                        wrote:

                           Update=
d
                            introspection draft based on recent
                            comments. Changes include:

                            =A0- "scope" return parameter now fol=
lows
                            RFC6749 format instead of JSON array

                            =A0- "subject" -> "sub",=
 and "audience"
                            -> "aud", to be parallel with JWT =
claims

                            =A0- clarified what happens if the
                            authentication is bad

                            =A0-- Justin

                              -------- Original Message --------

                                    Subject: 
                                    New Version Notification for
                                      draft-richer-oauth-introspection-02.t=
xt

                                    Date: 
                                    Wed, 6 Feb 2013 11:24:20 -0800

                                    From: 
                                    <internet-drafts@ietf.org>

                                    To: 
                                    <jricher@mitre.org>

                              A new version of I-D, draft-richer-oauth=
-introspection-02.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 02
Title:		 OAuth Token Introspection
Creation date:	 2013-02-06
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/interne=
t-drafts/draft-richer-oauth-introspection-02.txt
Status:          http://datatracker.ietf.org/doc/draft-=
richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-=
oauth-introspection-02
Diff:            http://www.ietf.org/rfcdiff?url2=
=3Ddraft-richer-oauth-introspection-02

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.

                                                                           =
      =20

The IETF Secretariat

_______________________________________________

                          OAuth mailing list

                          OAuth@ietf.org

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

                      -- 

                      Thanks & Regards,

                      Prabath

                      Mobile : +94 71
                          809 6732=A0

                        http://blog.facilelogin.com

                        http://RampartFAQ.com

        -- 

        Thanks & Regards,

        Prabath

        Mobile : +94 71 809 6732=A0

          http://=
blog.facilelogin.com

          http://Rampar=
tFAQ.com

-- 
Thanks &=
 Regards,
Prabath
Mobile : +94 71 809 6732=A0

=
http://blog.facil=
elogin.com

http://RampartFAQ.com

--047d7b343b06e0aaaf04d53024df--

From eve@xmlgrrl.com  Thu Feb  7 21:54:55 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26AC321F8943 for ; Thu,  7 Feb 2013 21:54:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.692
X-Spam-Level: 
X-Spam-Status: No, score=-0.692 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pVzgRTbR4YA for ; Thu,  7 Feb 2013 21:54:54 -0800 (PST)
Received: from mail.promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id B56CE21F8921 for ; Thu,  7 Feb 2013 21:54:53 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.promanage-inc.com (Postfix) with ESMTP id EFFE4B1DA53; Thu,  7 Feb 2013 21:54:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at promanage-inc.com
Received: from mail.promanage-inc.com ([127.0.0.1]) by localhost (greendome.promanage-inc.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-HV67u4KnIh; Thu,  7 Feb 2013 21:54:48 -0800 (PST)
Received: from [192.168.0.28] (s01060026f3e16488.vc.shawcable.net [24.84.235.32]) by mail.promanage-inc.com (Postfix) with ESMTPSA id 22380B1DA3A; Thu,  7 Feb 2013 21:54:48 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_EDEA92BF-EA0E-409C-A2AD-98C7DB184394"
From: Eve Maler 
In-Reply-To: <5113DDB2.7060805@mitre.org>
Date: Thu, 7 Feb 2013 21:54:46 -0800
Message-Id: <7E230B91-90A5-45B1-B306-5ED07B60AF8E@xmlgrrl.com>
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com> <5112AE0B.1080501@mitre.org>  <5113C3AA.1040701@mitre.org>  <5113DDB2.7060805@mitre.org>
To: Justin Richer 
X-Mailer: Apple Mail (2.1499)
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] New Version Notification for draft-richer-oauth-introspection-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Feb 2013 05:54:55 -0000

--Apple-Mail=_EDEA92BF-EA0E-409C-A2AD-98C7DB184394
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

This discussion seems to take one step into the territory that I think =
of as "deep" AS/RS communications. Solving token introspection all by =
itself means that a whole bunch of stuff must have been settled out of =
band/statically/in proprietary fashion. It's for this reason that UMA =
spec'd out "deep" communications, calling out to the token introspection =
spec for one "shallow" piece. The additional pieces include:

- Machine-readable AS config data that specifies the token profiles it =
supports (in this case, an UMA "requesting party token" profile that =
participates in its unique "get a token/use a token" flows)
- An MTI token profile
- An extensible mechanism for defining token profiles
- An extensible mechanism for requiring, allowing, and/or disallowing =
use of the token introspection endpoint for token profiles other than =
the MTI one

UMA calls the data associated with the token "authorization data". The =
spec always says "associated with", and not "contained within", since =
then it covers both structured and "artifact" token use cases. I've been =
thinking for some time that it would be useful to characterize token =
types/profiles along two axes: the format of the data and whether the =
data is locally accessible to the RS (e.g. through verifying a signature =
or decrypting a blob or whatever) vs. must be retrieved from the AS at =
run time by dereferencing an artifact. Justin, your note below hints at =
both of these.

I'm a bit wary of spec'ing some of the "deep" pieces in the token =
introspection spec unless we take a global view of what may really be =
required.

	Eve

On 7 Feb 2013, at 9:00 AM, Justin Richer  wrote:

> It validates the token, which would be either the token itself in the =
case of Bearer or the token "id" part of something more complex like =
MAC. It doesn't directly validate the usage of the token, that's still =
up to the PR to do that.
>=20
> I nearly added a "token type" field in this draft, but held back =
because there are several kinds of "token type" that people talk about =
in OAuth. First, there's "Bearer" vs. "MAC" vs. "HOK", or what have you. =
Then within Bearer you have "JWT" or "SAML" or "unstructured blob". Then =
you've also got "access" vs. "refresh" and other flavors of token, like =
the id_token in OpenID Connect.=20
>=20
> Thing is, the server running the introspection endpoint will probably =
know *all* of these. But should it tell the client? If so, which of the =
three, and what names should the fields be?
>=20
>  -- Justin
>=20
> On 02/07/2013 11:26 AM, Prabath Siriwardena wrote:
>> Okay.. I was thinking this could be used as a way to validate the =
token as well. BTW even in this case shouldn't communicate the type of =
token to AS? For example in the case of SAML profile - it could be SAML =
token..
>>=20
>> Thanks & regards,
>> -Prabath
>>=20
>> On Thu, Feb 7, 2013 at 8:39 PM, Justin Richer  =
wrote:
>> "valid" might not be the best term, but it's meant to be a field =
where the server says "yes this token is still good" or "no this token =
isn't good anymore". We could instead do this with HTTP codes or =
something but I went with a pure JSON response.
>>=20
>>  -- Justin
>>=20
>>=20
>> On 02/06/2013 10:47 PM, Prabath Siriwardena wrote:
>>> Hi Justin,
>>>=20
>>> I believe this is addressing one of the key missing part in OAuth =
2.0...
>>>=20
>>> One question - I guess this was discussed already...
>>>=20
>>> In the spec - in the introspection response it has the attribute =
"valid" - this is basically the validity of the token provided in the =
request.
>>>=20
>>> Validation criteria depends on the token and well as token type ( =
Bearer, MAC..).
>>>=20
>>> In the spec it seems like it's coupled with Bearer token type... But =
I guess, by adding "token_type" to the request we can remove this =
dependency.
>>>=20
>>> WDYT..?
>>>=20
>>> Thanks & regards,
>>> -Prabath=20
>>>=20
>>> On Thu, Feb 7, 2013 at 12:54 AM, Justin Richer  =
wrote:
>>> Updated introspection draft based on recent comments. Changes =
include:
>>>=20
>>>  - "scope" return parameter now follows RFC6749 format instead of =
JSON array
>>>  - "subject" -> "sub", and "audience" -> "aud", to be parallel with =
JWT claims
>>>  - clarified what happens if the authentication is bad
>>>=20
>>>  -- Justin
>>>=20
>>>=20
>>> -------- Original Message --------
>>> Subject:	New Version Notification for =
draft-richer-oauth-introspection-02.txt
>>> Date:	Wed, 6 Feb 2013 11:24:20 -0800
>>> From:	
>>> To:	
>>>=20
>>> A new version of I-D, draft-richer-oauth-introspection-02.txt
>>> has been successfully submitted by Justin Richer and posted to the
>>> IETF repository.
>>>=20
>>> Filename:	 draft-richer-oauth-introspection
>>> Revision:	 02
>>> Title:		 OAuth Token Introspection
>>> Creation date:	 2013-02-06
>>> WG ID:		 Individual Submission
>>> Number of pages: 6
>>> URL:             =
http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.tx=
t
>>> Status:          =
http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
>>> Htmlized:        =
http://tools.ietf.org/html/draft-richer-oauth-introspection-02
>>> Diff:            =
http://www.ietf.org/rfcdiff?url2=3Ddraft-richer-oauth-introspection-02
>>>=20
>>> Abstract:
>>>    This specification defines a method for a client or protected
>>>    resource to query an OAuth authorization server to determine =
meta-
>>>    information about an OAuth token.
>>>=20
>>>=20
>>>                                                                      =
            =20
>>>=20
>>>=20
>>> The IETF Secretariat
>>>=20
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>>=20
>>>=20
>>>=20
>>> --=20
>>> Thanks & Regards,
>>> Prabath
>>>=20
>>> Mobile : +94 71 809 6732=20
>>>=20
>>> http://blog.facilelogin.com
>>> http://RampartFAQ.com
>>=20
>>=20
>>=20
>>=20
>> --=20
>> Thanks & Regards,
>> Prabath
>>=20
>> Mobile : +94 71 809 6732=20
>>=20
>> http://blog.facilelogin.com
>> http://RampartFAQ.com
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl

--Apple-Mail=_EDEA92BF-EA0E-409C-A2AD-98C7DB184394
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

- Machine-readable AS config data that =
specifies the token profiles it supports (in this case, an UMA =
"requesting party token" profile that participates in its unique "get a =
token/use a token" flows)
- An MTI token profile
- =
An extensible mechanism for defining token profiles
- An =
extensible mechanism for requiring, allowing, and/or disallowing use of =
the token introspection endpoint for token profiles other than the MTI =
one

UMA calls the data associated with the =
token "authorization data". The spec always says "associated with", and =
not "contained within", since then it covers both structured and =
"artifact" token use cases. I've been thinking for some time that it =
would be useful to characterize token types/profiles along two axes: the =
format of the data and whether the data is locally accessible to the RS =
(e.g. through verifying a signature or decrypting a blob or whatever) =
vs. must be retrieved from the AS at run time by dereferencing an =
artifact. Justin, your note below hints at both of =
these.

I'm a bit wary of spec'ing some of the =
"deep" pieces in the token introspection spec unless we take a global =
view of what may really be required.

	=
Eve

On 7 Feb 2013, =
at 9:00 AM, Justin Richer <jricher@mitre.org> =
wrote:

 =20

 =20

    It validates the token, which would be either the token itself in
    the case of Bearer or the token "id" part of something more complex
    like MAC. It doesn't directly validate the usage of the token,
    that's still up to the PR to do that.

    I nearly added a "token type" field in this draft, but held back
    because there are several kinds of "token type" that people talk
    about in OAuth. First, there's "Bearer" vs. "MAC" vs. "HOK", or what
    have you. Then within Bearer you have "JWT" or "SAML" or
    "unstructured blob". Then you've also got "access" vs. "refresh" and
    other flavors of token, like the id_token in OpenID Connect. 

    Thing is, the server running the introspection endpoint will
    probably know *all* of these. But should it tell the client? If so,
    which of the three, and what names should the fields be?

     -- Justin

    On 02/07/2013 11:26 AM, Prabath
      Siriwardena wrote:

      Okay.. I was thinking this could be used as a way to validate the
      token as well. BTW even in this case shouldn't communicate the
      type of token to AS? For example in the case of SAML profile - it
      could be SAML token..

      Thanks & regards,
      -Prabath

        On Thu, Feb 7, 2013 at 8:39 PM, =
Justin
          Richer <jricher@mitre.org>
          wrote:

             "valid" might not =
be
              the best term, but it's meant to be a field where the
              server says "yes this token is still good" or "no this
              token isn't good anymore". We could instead do this with
              HTTP codes or something but I went with a pure JSON
              response.
=

                   -- Justin

                  On 02/06/2013 10:47 PM, Prabath Siriwardena
                    wrote:

                   Hi Justin,

                    I believe this is addressing one of the key
                      missing part in OAuth 2.0...

                    One question - I guess this was discussed
                      already...

                    In the spec - in the introspection response it
                      has the attribute "valid" - this is basically the
                      validity of the token provided in the =
request.

                    Validation criteria depends on the token =
and
                      well as token type ( Bearer, MAC..).

                    In the spec it seems like it's coupled with
                      Bearer token type... But I guess, by adding
                      "token_type" to the request we can remove this
                      dependency.

                    WDYT..?

                    Thanks & regards,
                    -Prabath 

                      On Thu, Feb 7, 2013 at
                        12:54 AM, Justin Richer <jricher@mitre.org>
                        wrote:

                           =
Updated
                            introspection draft based on recent
                            comments. Changes include:

                             - "scope" return parameter now follows
                            RFC6749 format instead of JSON array

                             - "subject" -> "sub", and =
"audience"
                            -> "aud", to be parallel with JWT =
claims

                             - clarified what happens if the
                            authentication is bad

                             -- Justin

                              -------- Original Message --------

                                    Subject: 
                                    New Version Notification for
                                      =
draft-richer-oauth-introspection-02.txt

                                    Date: 
                                    Wed, 6 Feb 2013 11:24:20 =
-0800

                                    From: 
                                    <internet-drafts@ietf.org>

                                    To: 
                                    <jricher@mitre.org>

                              A new version of I-D, =
draft-richer-oauth-introspection-02.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 02
Title:		 OAuth Token Introspection
Creation date:	 2013-02-06
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-i=
ntrospection-02.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-intro=
spection
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspect=
ion-02
Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-richer-oauth-in=
trospection-02

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.

                                                                         =
        =20

The IETF Secretariat

_______________________________________________

                          OAuth mailing list

                          OAuth@ietf.org

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

                      -- 

                      Thanks & Regards,

                      Prabath

                      Mobile : +94 71
                          809 6732 

                        http://blog.facilelogin.com

                        http://RampartFAQ.com

        -- 

        Thanks & Regards,

        Prabath

        Mobile : +94 71 809 6732 

          http://blog.facilelogin.com

          http://RampartFAQ.com

_______________________________________________
OAuth mailing =
list
OAuth@ietf.org
https://www.ietf.org/=
mailman/listinfo/oauth

Eve Maler       =
                    =
       http://www.xmlgrrl.com/blog
+1=
 425 345 6756                 =
        http://www.twitter.com/xmlgrrl=

=

--Apple-Mail=_EDEA92BF-EA0E-409C-A2AD-98C7DB184394--

From hannes.tschofenig@gmx.net  Thu Feb  7 23:47:12 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C912F21F8971 for ; Thu,  7 Feb 2013 23:47:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.835
X-Spam-Level: 
X-Spam-Status: No, score=-101.835 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PA+ShbeOTnO for ; Thu,  7 Feb 2013 23:47:12 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id AA54B21F895B for ; Thu,  7 Feb 2013 23:47:11 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.19]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0LwTpp-1V0k8A3nx9-018JjR for ; Fri, 08 Feb 2013 08:47:09 +0100
Received: (qmail invoked by alias); 08 Feb 2013 07:47:09 -0000
Received: from unknown (EHLO [10.255.135.8]) [194.251.119.201] by mail.gmx.net (mp019) with SMTP; 08 Feb 2013 08:47:09 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18TOINlQJ0TYF5s1eHehaRdNRwRmqNSsNKShMZ7l+ NvBV9aArfPGbrG
From: Hannes Tschofenig 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Fri, 8 Feb 2013 09:47:05 +0200
Message-Id: 
To: IETF oauth WG 
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Subject: [OAUTH-WG] Reminder: Design Team Conference Call - Feb. 11th at 1pm EST
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Feb 2013 07:47:13 -0000

We are using John's/Nat's conference bridge again:
https://www3.gotomeeting.com/join/695548174 

From asanso@adobe.com  Fri Feb  8 01:16:10 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3DA21F86AA for ; Fri,  8 Feb 2013 01:16:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.598
X-Spam-Level: 
X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sRWwDFdqM78 for ; Fri,  8 Feb 2013 01:16:08 -0800 (PST)
Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id 18DBA21F85D7 for ; Fri,  8 Feb 2013 01:16:05 -0800 (PST)
Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKURTCVeiuQYrMXHGYJQ0HUSd2WddCZ7BO@postini.com; Fri, 08 Feb 2013 01:16:07 PST
Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r189G4C9014800; Fri, 8 Feb 2013 01:16:04 -0800 (PST)
Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id r189FpXQ001684; Fri, 8 Feb 2013 01:16:03 -0800 (PST)
Received: from eurcas01.eur.adobe.com (10.128.4.27) by nacas03.corp.adobe.com (10.8.189.121) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 8 Feb 2013 01:15:57 -0800
Received: from eurmbx01.eur.adobe.com ([10.128.4.32]) by eurcas01.eur.adobe.com ([10.128.4.27]) with mapi; Fri, 8 Feb 2013 09:15:55 +0000
From: Antonio Sanso 
To: Prabath Siriwardena 
Date: Fri, 8 Feb 2013 09:15:53 +0000
Thread-Topic: [OAUTH-WG] Does Facebook login OAuth 2.0 compatible ?
Thread-Index: Ac4F3OWI8QeEnqbASlm5YQQvO0zdeQ==
Message-ID: <12A74B80-1846-4F98-AFB6-7FC305EB050B@adobe.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_12A74B8018464F98AFB67FC305EB050Badobecom_"
MIME-Version: 1.0
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Does Facebook login OAuth 2.0 compatible ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Feb 2013 09:16:10 -0000

--_000_12A74B8018464F98AFB67FC305EB050Badobecom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Prabath,

As long as I know Facebook implement OAuth 2.0 draft 10 (so a pretty old ve=
rsion of the spec).
The RFC was based on draft 31.

Regards

Antonio

On Feb 5, 2013, at 5:54 PM, Prabath Siriwardena wrote:

Here are some references that I found they do not.. thoughts appreciated...

1. https://developers.facebook.com/docs/howtos/login/login-as-app/
2. https://developers.facebook.com/docs/howtos/login/extending-tokens/
3. https://developers.facebook.com/docs/howtos/login/login-as-page/

Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.com
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--_000_12A74B8018464F98AFB67FC305EB050Badobecom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Prabath,

As long as I know Facebook implement OAuth 2.0 draft 10 (so a pr=
etty old version of the spec).The RFC was based on draft 31.

Regards

Antonio

=

On Feb 5, 2013, at 5:54 PM, Prabath Siriwardena wrote:
Here =
are some references that I found they do not.. thoughts appreciated...=

1. https://developers.facebook.com/docs/howtos/login/l=
ogin-as-app/
2. https://developers.facebook.com/docs/howtos/login/extendi=
ng-tokens/
3. https://developers.facebook.com/docs/how=
tos/login/login-as-page/

Thanks & Regards,
Prabath
Mobile :=
 +94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/=
mailman/listinfo/oauth

=

--_000_12A74B8018464F98AFB67FC305EB050Badobecom_--

From hannes.tschofenig@gmx.net  Mon Feb 11 09:28:57 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FD321F883C for ; Mon, 11 Feb 2013 09:28:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.472
X-Spam-Level: 
X-Spam-Status: No, score=-102.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R29NLCbdALew for ; Mon, 11 Feb 2013 09:28:56 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 79EF721F8826 for ; Mon, 11 Feb 2013 09:28:56 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.20]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MhOyy-1UImnt2bJq-00Ma2q for ; Mon, 11 Feb 2013 18:28:55 +0100
Received: (qmail invoked by alias); 11 Feb 2013 17:28:55 -0000
Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.100]) [88.115.219.140] by mail.gmx.net (mp020) with SMTP; 11 Feb 2013 18:28:55 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19h0X4OYvthpTS+JtV3VwI9z5HQCFQ33WqSF1qKkn hH5RkEw1J/mrcr
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Hannes Tschofenig 
In-Reply-To: <5112BE73.2070003@mitre.org>
Date: Mon, 11 Feb 2013 19:28:53 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <5FDE6412-5892-4840-935A-20A8A3BC49A0@gmx.net>
References: <20130206201534.13236.6681.idtracker@ietfa.amsl.com> <5112BE73.2070003@mitre.org>
To: Justin Richer 
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-05.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Feb 2013 17:28:57 -0000

Hi Justin,=20

just one comment on this specific issue:=20

On Feb 6, 2013, at 10:34 PM, Justin Richer wrote:

> 1. client shows up at the Client Registration Endpoint, posts a JSON =
object with a few bits of metadata about itself (and potentially =
presents an Access Token that it got from some out of band process that =
acts as a "class registration" or "developer key", important to several =
known real-world use cases)

The starting point of the dynamic registry document was that the client =
does not yet have some secret with the authorization server and for that =
reason it does all this dance.=20
Now, you write that it may have some "developer key" (which is sort of =
similar to what the client id/client secret is).=20

That cannot be right.=20

Ciao
Hannes
=20=

From ve7jtb@ve7jtb.com  Mon Feb 11 09:40:12 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C9221F867B for ; Mon, 11 Feb 2013 09:40:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.36
X-Spam-Level: 
X-Spam-Status: No, score=-1.36 tagged_above=-999 required=5 tests=[AWL=-2.038,  BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888,  RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNp7PlQCTrXT for ; Mon, 11 Feb 2013 09:40:11 -0800 (PST)
Received: from mail-gg0-x22d.google.com (gg-in-x022d.1e100.net [IPv6:2607:f8b0:4002:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 6D94121F865B for ; Mon, 11 Feb 2013 09:40:11 -0800 (PST)
Received: by mail-gg0-f173.google.com with SMTP id b6so731906ggm.18 for ; Mon, 11 Feb 2013 09:40:10 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=LoEmFd/z28kLnZ/UtkAE9xa9J7QAE6moXUORpLskJsM=; b=B241svJ74w4ELKxLjX4DAGv7IRghDWaLtw0eoBdZqg6+XK4Eqh6LvjyDY2zAuy9dES OCDY/c8rpTJzMO6rbghzJ8uInOpTam4jec6pyQaQjjo5ezF9y4OD2zsJAiAVVzx8PA1A JmS+W2JWeIv+ReNX9l/teXU49kVEoXs/6FRc13Nd52xhLHXyUeUELeViOwu0toNHd74g jIaTXqTH2IpKqQTOw7tVY+y+XD/Owm7vUoLqyKKPAknPujrCsFDlfBN+ZIWIocgFOYbb EhhmXbcasDWafjj+DJZgOeRtv0KbLz0DLa9rqQ8hPK6gosE3y7kCq1iwA9pVVdM5sMi4 LZOw==
X-Received: by 10.236.131.232 with SMTP id m68mr18676967yhi.100.1360604410825;  Mon, 11 Feb 2013 09:40:10 -0800 (PST)
Received: from [192.168.1.213] (190-20-50-112.baf.movistar.cl. [190.20.50.112]) by mx.google.com with ESMTPS id d19sm37032518anm.18.2013.02.11.09.40.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Feb 2013 09:40:08 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <5FDE6412-5892-4840-935A-20A8A3BC49A0@gmx.net>
Date: Mon, 11 Feb 2013 14:40:03 -0300
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20130206201534.13236.6681.idtracker@ietfa.amsl.com> <5112BE73.2070003@mitre.org> <5FDE6412-5892-4840-935A-20A8A3BC49A0@gmx.net>
To: Hannes Tschofenig 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQkkCCH9hQi6Ou0vD3rsLkCuTpZ2cHI59DGl1XdKYf8+lN6OwU4lJPHNnZIkTu2hWqdEc+fg
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-05.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Feb 2013 17:40:12 -0000

The client may have a developer key which is a bearer token.   How it =
gets it is out of scope,  however we do see in the real world developer =
portals where developers establish accounts and get keys/tokens for =
creating clients.

Depending on the IdP this master token could be issued to a native app =
and then used to create separate client IDs for each instance.

The spec allows a client to have a token for registering or arrive =
without it.    Like OAuth punted on how the client gets a ID and secret, =
we are punting on how the developer gets its initial token if it is =
required.

There are real use cases for this in API management.   It would be nice =
if those systems could leverage this spec rather than being forced to =
create something different.

John B.

On 2013-02-11, at 2:28 PM, Hannes Tschofenig  =
wrote:

> Hi Justin,=20
>=20
> just one comment on this specific issue:=20
>=20
> On Feb 6, 2013, at 10:34 PM, Justin Richer wrote:
>=20
>> 1. client shows up at the Client Registration Endpoint, posts a JSON =
object with a few bits of metadata about itself (and potentially =
presents an Access Token that it got from some out of band process that =
acts as a "class registration" or "developer key", important to several =
known real-world use cases)
>=20
> The starting point of the dynamic registry document was that the =
client does not yet have some secret with the authorization server and =
for that reason it does all this dance.=20
> Now, you write that it may have some "developer key" (which is sort of =
similar to what the client id/client secret is).=20
>=20
> That cannot be right.=20
>=20
> Ciao
> Hannes
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From jricher@mitre.org  Mon Feb 11 13:11:23 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870A221F8972 for ; Mon, 11 Feb 2013 13:11:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.57
X-Spam-Level: 
X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.029,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRXKVFjMA91c for ; Mon, 11 Feb 2013 13:11:23 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id E475D21F8915 for ; Mon, 11 Feb 2013 13:11:22 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 52ED953116A2 for ; Mon, 11 Feb 2013 16:11:22 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 47A7453116A0 for ; Mon, 11 Feb 2013 16:11:22 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 11 Feb 2013 16:11:22 -0500
Message-ID: <51195E50.1080103@mitre.org>
Date: Mon, 11 Feb 2013 16:10:40 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: "oauth@ietf.org" 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.58]
Subject: [OAUTH-WG] Recent changes to Registration
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Feb 2013 21:11:23 -0000

As many of you saw, last week I published a draft of the OAuth Dynamic 
Client Registration spec [1] that made some fairly serious changes to 
how the protocol works. It was my intent to distill many threads of 
conversation here on the list into a full, workable protocol with a 
concrete document that we could discuss. I believe that what I published 
did that, but I certainly don't think that all of our work and 
discussion is done. It wasn't my intent to surprise people with the 
draft (apparently I really did!), nor was it my intent to simply dictate 
where the spec was going without any input from the working group.

So to move the discussion forward in a very deliberate fashion, I'm 
going to be starting a number of new threads for discussion on 
particular changes and components to this spec so that we can discuss 
things and decide as a working group what the best courses of action 
are. I'll lay out what the issues are, what -05 says today, what the 
options are as I see them, and we I think can go from there. The topics 
will be:

  - JSON Encoding
  - Endpoint Definition (& operation parameter)
  - HAL _links structure and client self-URL
  - RESTful client lifecycle management
  - Client secret rotation

If you want to talk about the overall design and philosophy of the 
Registration document, just reply to this email.

Of course, all of these interrelate in various ways, and everything must 
be taken in the overall context, but I'm hoping that by splitting things 
up this way we can focus the conversations better. I welcome all 
constructive discussion, debate, and input. As an editor, I am 
particularly grateful for anyone who wants to provide actual text for 
inclusion in the document itself, and any pointers to implemented code 
for any of this.

The deadline for IETF86 is two weeks from now, and I want to have a 
version -06 or greater that incorporates all of the comments from these 
threads by then.

  -- Justin

[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05

From jricher@mitre.org  Mon Feb 11 13:15:13 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED87C21F8887 for ; Mon, 11 Feb 2013 13:15:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.57
X-Spam-Level: 
X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.029,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeyfO3ob9Kpx for ; Mon, 11 Feb 2013 13:15:13 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id EAD8321F886D for ; Mon, 11 Feb 2013 13:15:12 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 72976531051E for ; Mon, 11 Feb 2013 16:15:12 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 4C6501F1406 for ; Mon, 11 Feb 2013 16:15:12 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 11 Feb 2013 16:15:12 -0500
Message-ID: <51195F36.6040705@mitre.org>
Date: Mon, 11 Feb 2013 16:14:30 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: "oauth@ietf.org" 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.58]
Subject: [OAUTH-WG] Registration: RESTful client lifecycle management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Feb 2013 21:15:14 -0000

Draft -05 of OAuth Dynamic Client Registration [1] defines several 
operations that the client can take on its behalf as part of the 
registration process. These boil down to the basic CRUD operations that 
you find in many APIs: Create, Read, Update, Delete. Draft -00 defined 
only the "Create" operation, draft -01 through -04 added the "Update" 
operation, switched using the "operation=" parameter.

Following several suggestions to do so on the list, the -05 draft 
defines these operations in terms of a RESTful API for the client. Namely:

  - HTTP POST to registration endpoint => Create (register) a new client
  - HTTP PUT to update endpoint (with registration_access_token) => 
Update the registered information for this client
  - HTTP GET to update endpoint (with registration_access_token) => read 
the registered information for this client
  - HTTP DELETE to update endpoint (with registration_access_token) => 
Delete (unregister/de-provision) this client

The two main issues at stake here are: the addition of the READ and 
DELETE methods, and the use of HTTP verbs following a RESTful design 
philosophy.

Pro:
  - RESTful APIs (with HTTP verbs to differentiate functionality) are 
the norm today
  - Full lifecycle management is common and is going to be expected by 
many users of this protocol in the wild

Cons:
  - Update semantics are still under debate (full replace? patch?)
  - Somewhat increased complexity on the server to support all operations
  - Client has to understand all HTTP verbs for full access (though 
plain registration is just POST)

Alternatives include using an operational switch parameter (like the old 
drafts), defining separate endpoints for every action, or doing all 
operations on a single endpoint using verbs to switch.

  -- Justin

[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05

From jricher@mitre.org  Mon Feb 11 13:15:17 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096D721F8992 for ; Mon, 11 Feb 2013 13:15:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.571
X-Spam-Level: 
X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.028,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Raa2HB9MLSCP for ; Mon, 11 Feb 2013 13:15:16 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6452121F8887 for ; Mon, 11 Feb 2013 13:15:16 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8073C53105FC for ; Mon, 11 Feb 2013 16:15:15 -0500 (EST)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 2DE52531051F for ; Mon, 11 Feb 2013 16:15:15 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 11 Feb 2013 16:15:14 -0500
Message-ID: <51195F39.3040809@mitre.org>
Date: Mon, 11 Feb 2013 16:14:33 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: "oauth@ietf.org" 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.58]
Subject: [OAUTH-WG] Registration: Endpoint Definition (& operation parameter)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Feb 2013 21:15:17 -0000

Draft -05 of OAuth Dynamic Client Registration [1] defines three 
fundamental operations that a client can undertake: Client Registration, 
Client Update, and Secret Rotation. Each of these actions needs to be 
differentiated *somehow* by the client and server as part of the 
protocol. Draft -00 defined only the "register" operation, drafts -01 
through -04 made use of an "operation" parameter on a single endpoint, 
which brought up a long discussion on the list on whether or not that 
was an appropriate design. Draft -05 did away with the definition of the 
"operation" parameter on a single endpoint and instead opted for 
separating the base functionality into three different endpoints.

Pro:
  - Closer to RESTful semantics of having one URL for creation and 
another URL for management of an item (eg, most REST APIs use /object 
for creation and /object/object_id for manipulation)
  - The rest of OAuth (and its extensions) defines separate endpoints 
for different actions (Authorization, Token, Revocation, Introspection) 
as opposed to a single endpoint with a mode-switch parameter
  - Client doesn't have to generate a URL string for different endpoints 
by combining parameters with a base URL

Con:
  - Not quite exactly RESTful as the spec doesn't dictate the client_id 
be part of the update or rotate URL (though and implementor's note 
suggests this)
  - Client has to track different URLs for different actions
  - Server must be able to differentiate actions based on these 
different URLs.

Alternatives include using different HTTP verbs (see other thread) or 
defining an operational switch parameter, like older drafts, on a single 
endpoint URL. Another suggested alternative is to look for the presence 
of certain parameters, such as client_id or the registration access 
token, to indicate that a different operation is requested.

There's also question of whether the Secret Rotation action needs to 
have its own endpoint, or if it can be collapsed into one of the others. 
It has been suggested off-list that the secret rotation should never be 
initiated by the Client but instead the client should simply request its 
latest secret from the server through the update (or read) semantics.

  -- Justin

[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05

From jricher@mitre.org  Mon Feb 11 13:15:18 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD48421F886D for ; Mon, 11 Feb 2013 13:15:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.572
X-Spam-Level: 
X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pq3DUHUMSS9T for ; Mon, 11 Feb 2013 13:15:18 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3583221F8992 for ; Mon, 11 Feb 2013 13:15:18 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B8EA61F27EB for ; Mon, 11 Feb 2013 16:15:17 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 9397C1F0785 for ; Mon, 11 Feb 2013 16:15:17 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 11 Feb 2013 16:15:17 -0500
Message-ID: <51195F3B.1010701@mitre.org>
Date: Mon, 11 Feb 2013 16:14:35 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: "oauth@ietf.org" 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.58]
Subject: [OAUTH-WG] Registration: JSON Encoded Input
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Feb 2013 21:15:18 -0000

Draft -05 of OAuth Dynamic Client Registration [1] switched from a 
form-encoded input that had been used by drafts -01 through -04 to a 
JSON encoded input that was used originally in -00. Note that all 
versions keep JSON-encoded output from all operations.

Pro:
  - JSON gives us a rich data structure so that things such as lists, 
numbers, nulls, and objects can be represented natively
  - Allows for parallelism between the input to the endpoint and output 
from the endpoint, reducing possible translation errors between the two
  - JSON specifies UTF8 encoding for all strings, forms may have many 
different encodings
  - JSON has minimal character escaping required for most strings, forms 
require escaping for common characters such as space, slash, comma, etc.

Con:
  - the rest of OAuth is form-in/JSON-out
  - nothing else in OAuth requires the Client to create a JSON object, 
merely to parse one
  - form-in/JSON-out is a very widely established pattern on the web today
  - Client information (client_name, client_id, etc.) is conflated with 
access information (registration_access_token, _links, expires_at, etc.) 
in root level of the same JSON object, leaving the client to decide what 
needs to (can?) be sent back to the server for update operations.

Alternatives include any number of data encoding schemes, including form 
(like the old drafts), XML, ASN.1, etc.

  -- Justin

[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05

From jricher@mitre.org  Mon Feb 11 13:15:20 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE58821F8A96 for ; Mon, 11 Feb 2013 13:15:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.572
X-Spam-Level: 
X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yerRcV4f4rNg for ; Mon, 11 Feb 2013 13:15:20 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFDD21F886D for ; Mon, 11 Feb 2013 13:15:20 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9A91C1F1406 for ; Mon, 11 Feb 2013 16:15:19 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 5C1A11F13F3 for ; Mon, 11 Feb 2013 16:15:19 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 11 Feb 2013 16:15:19 -0500
Message-ID: <51195F3D.1050006@mitre.org>
Date: Mon, 11 Feb 2013 16:14:37 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: "oauth@ietf.org" 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.58]
Subject: [OAUTH-WG] Registration: HAL _links structure and client self-URL
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Feb 2013 21:15:21 -0000

Draft -05 of OAuth Dynamic Client Registration [1] returns a URL pointer 
for the client to perform update and secret rotation actions. This 
functionality arose from discussions on the list about moving towards a 
more RESTful pattern, and Nat Sakimura proposed this approach in the 
OpenID Connect Working Group. This URL may be distinct from the Client 
Registration Endpoint URL, but draft -05 makes no promises as to its 
content, form, or structure, though it does contain implementor's notes 
on possible methods.

Two questions arise from this change:
  - The semantics of returning the client manipulation URL
  - The syntax (derived from HAL for JSON [2], an individual I-D 
submission)

On semantics:

Pro:
  - The server has flexibility on how to define the "update" endpoint, 
sending all clients to one URL, sending different clients to different 
URLs, or sending clients to a URL with a baked-in query parameter
  - The client can take the URL as-is and use it for all management 
operations (ie, it doesn't have to generate or compose the URL based on 
component parts)

Con:
  - The client must remember one more piece of information from the 
server at runtime if it wants to do manipulation and management of 
itself at the server (in addition to client_id, client_secret, 
registration_access_token, and others)

Alternatives include specifying a URL pattern for the server to use and 
all clients to follow, specifying a query parameter for the update 
action, and specifying a separate endpoint entirely and using the 
presence of items such as client_id and the registration access token to 
differentiate the requests. Note that *all* of these alternatives can be 
accommodated using the semantics described above, with the same actions 
on the client's part.

On syntax:

Pro:
  - Follows the designs of RFC5988 for link relations
  - The HAL format is general, and allows for all kinds of other 
information to be placed inside the _links structure
  - Allows for full use of the JSON object to specify advanced 
operations on the returned endpoint if desired

Con:
  - The rest of OAuth doesn't follow link relation guidelines (though 
it's been brought up)
  - The HAL format is general, and allows for all kinds of other 
information to be placed inside the _links structure
  - The HAL-JSON document is an expired individual I-D, and it's unclear 
what wider adoption looks like right now

Alternatives include returning the URL as a separate data member 
(registration_update_url), using HTTP headers, or using JSON Schema.

  -- Justin

[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
[2] http://tools.ietf.org/html/draft-kelly-json-hal-03

From jricher@mitre.org  Mon Feb 11 13:15:22 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C3D21F8AAD for ; Mon, 11 Feb 2013 13:15:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.573
X-Spam-Level: 
X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKzBvbaQ80AL for ; Mon, 11 Feb 2013 13:15:22 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4A13E21F890D for ; Mon, 11 Feb 2013 13:15:22 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D75E91F1418 for ; Mon, 11 Feb 2013 16:15:21 -0500 (EST)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id AD42C1F0785 for ; Mon, 11 Feb 2013 16:15:21 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 11 Feb 2013 16:15:21 -0500
Message-ID: <51195F3F.7000704@mitre.org>
Date: Mon, 11 Feb 2013 16:14:39 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: "oauth@ietf.org" 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.58]
Subject: [OAUTH-WG] Registration: Client secret rotation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Feb 2013 21:15:22 -0000

Draft -05 of OAuth Dynamic Client Registration [1] defines a means of 
the client requesting a new client_secret (if applicable) and a new 
registration_access_token. Client secrets MAY expire after some period 
of time, and this method allows for a refresh of that secret. Draft -00 
defined no such operation, drafts -01 through -04 defined this operation 
in terms of the operation=rotate_secret parameter, and draft -05 defines 
it through a secondary endpoint, the Client Secret Rotation Endpoint. 
This raises several questions:

  - Should the client be allowed to request rotation of its secret?
  - Would a client ever take this action of its own accord?
  - Can a server rotate the secret of the client without the client 
asking? (This seems to be an obvious "yes")

Alternatives that keep this functionality include defining the 
rotate_secret operation in terms of an HTTP verb, a query parameter, or 
separate endpoint. Alternatively, we could drop the rotate_secret 
operation all together. If we do this, we have to decide if the client 
secret can still expire. If it can, then we need a way for the client to 
get this new secret through a means that doesn't require it to request a 
change in secret, such as sending it back as part of the client READ 
operation (see other thread on RESTful verbs).

  -- Justin

[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05

From prabath@wso2.com  Mon Feb 11 13:30:20 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5128421F8678 for ; Mon, 11 Feb 2013 13:30:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.562
X-Spam-Level: 
X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.414,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUTLP1HsHF-L for ; Mon, 11 Feb 2013 13:30:18 -0800 (PST)
Received: from mail-ea0-f169.google.com (mail-ea0-f169.google.com [209.85.215.169]) by ietfa.amsl.com (Postfix) with ESMTP id 7715621F8645 for ; Mon, 11 Feb 2013 13:30:11 -0800 (PST)
Received: by mail-ea0-f169.google.com with SMTP id d13so2945016eaa.0 for ; Mon, 11 Feb 2013 13:30:10 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=CFr7wF37V6h/r4OqgeEfX897OAp2AJX1ulU9FyLnllQ=; b=DIzylLjVaT8CYdiS51FnzQXRwtuybq5KZpOw1V/q6Gx41ORf/YKG+AwZnxi7/7uymr RzH9a6eOv3BJoqkO7i9KxeBvew9s+t7DMnIO25QLc2uKuYAbHlDmq//uKefiouLyzzzC DMFsrqjpMilKf7WXzWqQRr96ue5Er6/hAZ0B8xs58J64+Ua/i10MSakeIpYFCbhicqfI 7GhuQzKRJpiiXcqBk7LKQ3H+iwhNzZZStoVd9Fmb29jhTLWdIrsqFStJKZgk0acbNqA0 IeWUu9g6FGMHW9tXi8I9GOxtGQq5X6tbNHr1rYJVi+4KZ0S8JoTdVS8e07qsAc6hKep6 +bMQ==
MIME-Version: 1.0
X-Received: by 10.14.224.137 with SMTP id x9mr54668724eep.11.1360618210042; Mon, 11 Feb 2013 13:30:10 -0800 (PST)
Received: by 10.223.146.76 with HTTP; Mon, 11 Feb 2013 13:30:09 -0800 (PST)
In-Reply-To: 
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com> <5112AE0B.1080501@mitre.org>  <5113C3AA.1040701@mitre.org>  <5113DDB2.7060805@mitre.org> 
Date: Tue, 12 Feb 2013 03:00:09 +0530
Message-ID: 
From: Prabath Siriwardena 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=047d7b66f28115a29904d5799d74
X-Gm-Message-State: ALoCoQmfm92svEliwz57J84OySp2H3n5Nj9w7KPXIj3GAm1hHsYWFRtdX+7rcpdINEidz+JvDlR7
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Feb 2013 21:30:20 -0000

--047d7b66f28115a29904d5799d74
Content-Type: text/plain; charset=ISO-8859-1

Hi Justin,

Any thoughts on the following...

Thanks & regards,
-Prabath

On Fri, Feb 8, 2013 at 11:21 AM, Prabath Siriwardena wrote:

> Hi Justin,
>
> I have couple of questions related to "valid" parameter...
>
> This endpoint can be invoked by the Resource Server in runtime...
>
> In that case what is exactly meant by the "resource_id" in request ?
>
> IMO a token to be valid depends on set of criteria based on it's type..
>
> For a Bearer token..
>
> 1. Token should not be expired
> 2. Token should not be revoked.
> 3. The scope the token issued should match with the scope required for the
> resource.
>
> For a MAC token...
>
> 1. Token not expired (mac id)
> 2. Token should not be revoked
> 3. The scope the token issued should match with the scope required for the
> resource.
> 4. HMAC check should be valid
>
> There are similar conditions for SAML bearer too..
>
> Thanks & regards,
> -Prabath
>
>
> On Thu, Feb 7, 2013 at 10:30 PM, Justin Richer  wrote:
>
>>  It validates the token, which would be either the token itself in the
>> case of Bearer or the token "id" part of something more complex like MAC.
>> It doesn't directly validate the usage of the token, that's still up to the
>> PR to do that.
>>
>> I nearly added a "token type" field in this draft, but held back because
>> there are several kinds of "token type" that people talk about in OAuth.
>> First, there's "Bearer" vs. "MAC" vs. "HOK", or what have you. Then within
>> Bearer you have "JWT" or "SAML" or "unstructured blob". Then you've also
>> got "access" vs. "refresh" and other flavors of token, like the id_token in
>> OpenID Connect.
>>
>> Thing is, the server running the introspection endpoint will probably
>> know *all* of these. But should it tell the client? If so, which of the
>> three, and what names should the fields be?
>>
>>  -- Justin
>>
>>
>> On 02/07/2013 11:26 AM, Prabath Siriwardena wrote:
>>
>> Okay.. I was thinking this could be used as a way to validate the token
>> as well. BTW even in this case shouldn't communicate the type of token to
>> AS? For example in the case of SAML profile - it could be SAML token..
>>
>>  Thanks & regards,
>> -Prabath
>>
>> On Thu, Feb 7, 2013 at 8:39 PM, Justin Richer  wrote:
>>
>>>  "valid" might not be the best term, but it's meant to be a field where
>>> the server says "yes this token is still good" or "no this token isn't good
>>> anymore". We could instead do this with HTTP codes or something but I went
>>> with a pure JSON response.
>>>
>>>  -- Justin
>>>
>>>
>>> On 02/06/2013 10:47 PM, Prabath Siriwardena wrote:
>>>
>>> Hi Justin,
>>>
>>>  I believe this is addressing one of the key missing part in OAuth
>>> 2.0...
>>>
>>>  One question - I guess this was discussed already...
>>>
>>>  In the spec - in the introspection response it has the attribute
>>> "valid" - this is basically the validity of the token provided in the
>>> request.
>>>
>>>  Validation criteria depends on the token and well as token type (
>>> Bearer, MAC..).
>>>
>>>  In the spec it seems like it's coupled with Bearer token type... But I
>>> guess, by adding "token_type" to the request we can remove this dependency.
>>>
>>>  WDYT..?
>>>
>>>  Thanks & regards,
>>> -Prabath
>>>
>>> On Thu, Feb 7, 2013 at 12:54 AM, Justin Richer wrote:
>>>
>>>>  Updated introspection draft based on recent comments. Changes include:
>>>>
>>>>  - "scope" return parameter now follows RFC6749 format instead of JSON
>>>> array
>>>>  - "subject" -> "sub", and "audience" -> "aud", to be parallel with JWT
>>>> claims
>>>>  - clarified what happens if the authentication is bad
>>>>
>>>>  -- Justin
>>>>
>>>>
>>>> -------- Original Message --------  Subject: New Version Notification
>>>> for draft-richer-oauth-introspection-02.txt  Date: Wed, 6 Feb 2013
>>>> 11:24:20 -0800  From:   To:
>>>>  
>>>>
>>>> A new version of I-D, draft-richer-oauth-introspection-02.txt
>>>> has been successfully submitted by Justin Richer and posted to the
>>>> IETF repository.
>>>>
>>>> Filename:	 draft-richer-oauth-introspection
>>>> Revision:	 02
>>>> Title:		 OAuth Token Introspection
>>>> Creation date:	 2013-02-06
>>>> WG ID:		 Individual Submission
>>>> Number of pages: 6
>>>> URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
>>>> Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
>>>> Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-02
>>>> Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02
>>>>
>>>> Abstract:
>>>>    This specification defines a method for a client or protected
>>>>    resource to query an OAuth authorization server to determine meta-
>>>>    information about an OAuth token.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> The IETF Secretariat
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>
>>>
>>>  --
>>> Thanks & Regards,
>>> Prabath
>>>
>>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>>
>>> http://blog.facilelogin.com
>>> http://RampartFAQ.com
>>>
>>>
>>>
>>
>>
>>  --
>> Thanks & Regards,
>> Prabath
>>
>>  Mobile : +94 71 809 6732
>>
>> http://blog.facilelogin.com
>> http://RampartFAQ.com
>>
>>
>>
>
>
> --
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com
>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.com

--047d7b66f28115a29904d5799d74
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Justin,
Any thoughts on the following...
Thanks & regards,
-Prabath

On Fri, Feb 8, 2013 at 11:21 AM, Prabath Siriwardena <prabath@=
wso2.com> wrote:

Hi=A0Justin,
I have coupl=
e of questions related to "valid" parameter...

This endpoint can be invoked by the Resource Server in runtime...
In that case what is exactly meant by the "resour=
ce_id" in request ?

IMO a token to be valid depends on set of criteria base=
d on it's type..

For a Bearer token..

1. Token should not be expired
2. Token should n=
ot be revoked.

3. The scope the token issued should match with the scope required for=
 the resource.

For a MAC token...

1. Token not expired (mac id)
2. Token should not be rev=
oked

3. The scope the token issued should match with the scope required for=
 the resource.
4. HMAC check should be valid

=
There are similar conditions for SAML bearer too..

Thanks & regards,
-Prabath

On Thu, =
Feb 7, 2013 at 10:30 PM, Justin Richer <jricher@mitre.org> w=
rote:

 =20
   =20
 =20

    It validates the token, which would be either the token itself in
    the case of Bearer or the token "id" part of something more c=
omplex
    like MAC. It doesn't directly validate the usage of the token,
    that's still up to the PR to do that.

    I nearly added a "token type" field in this draft, but held b=
ack
    because there are several kinds of "token type" that people t=
alk
    about in OAuth. First, there's "Bearer" vs. "MAC&quo=
t; vs. "HOK", or what
    have you. Then within Bearer you have "JWT" or "SAML&quo=
t; or
    "unstructured blob". Then you've also got "access&qu=
ot; vs. "refresh" and
    other flavors of token, like the id_token in OpenID Connect. 

    Thing is, the server running the introspection endpoint will
    probably know *all* of these. But should it tell the client? If so,
    which of the three, and what names should the fields be?

    =A0-- Justin

    On 02/07/2013 11:26 AM, Prabath
      Siriwardena wrote:

     =20
      Okay.. I was thinking this could be used as a way to validate the
      token as well. BTW even in this case shouldn't communicate the
      type of token to AS? For example in the case of SAML profile - it
      could be SAML token..

      Thanks & regards,
      -Prabath

        On Thu, Feb 7, 2013 at 8:39 PM, Justin
          Richer <jricher@mitre.org>
          wrote:

             "valid" mi=
ght not be
              the best term, but it's meant to be a field where the
              server says "yes this token is still good" or "=
;no this
              token isn't good anymore". We could instead do this =
with
              HTTP codes or something but I went with a pure JSON
              response.

                  =A0-- Justin

                  On 02/06/2013 10:47 PM, Prabath Siriwardena
                    wrote:

                   Hi Justin,

                    I believe this is addressing one of the key
                      missing part in OAuth 2.0...

                    One question - I guess this was discussed
                      already...

                    In the spec - in the introspection response it
                      has the attribute "valid" - this is basical=
ly the
                      validity of the token provided in the request.

                    Validation=A0criteria depends on the token and
                      well as token type ( Bearer, MAC..).

                    In the spec it seems like it's coupled with
                      Bearer token type... But I guess, by adding
                      "token_type" to the request we can remove t=
his
                      dependency.

                    WDYT..?

                    Thanks & regards,
                    -Prabath=A0

                      On Thu, Feb 7, 2013 at
                        12:54 AM, Justin Richer <jricher@mitre.org>=

                        wrote:

                           Update=
d
                            introspection draft based on recent
                            comments. Changes include:

                            =A0- "scope" return parameter now fol=
lows
                            RFC6749 format instead of JSON array

                            =A0- "subject" -> "sub",=
 and "audience"
                            -> "aud", to be parallel with JWT =
claims

                            =A0- clarified what happens if the
                            authentication is bad

                            =A0-- Justin

                              -------- Original Message --------

                                    Subject: 
                                    New Version Notification for
                                      draft-richer-oauth-introspection-02.t=
xt

                                    Date: 
                                    Wed, 6 Feb 2013 11:24:20 -0800

                                    From: 
                                    <internet-drafts@ietf.org>

                                    To: 
                                    <jricher@mitre.org>

                              A new version of I-D, draft-richer-oauth=
-introspection-02.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 02
Title:		 OAuth Token Introspection
Creation date:	 2013-02-06
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/interne=
t-drafts/draft-richer-oauth-introspection-02.txt
Status:          http://datatracker.ietf.org/doc/draft-=
richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-=
oauth-introspection-02
Diff:            http://www.ietf.org/rfcdiff?url2=
=3Ddraft-richer-oauth-introspection-02

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.

                                                                           =
      =20

The IETF Secretariat

_______________________________________________

                          OAuth mailing list

                          OAuth@ietf.org

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

                      -- 

                      Thanks & Regards,

                      Prabath

                      Mobile : +94 71
                          809 6732=A0

                        http://blog.facilelogin.com

                        http://RampartFAQ.com

        -- 

        Thanks & Regards,

        Prabath

        Mobile : +94 71 809 6732=A0

          http://=
blog.facilelogin.com

          http://Rampar=
tFAQ.com

-- 
Thanks &=
 Regards,
Prabath
Mobile : +94 71 809 6732=
=A0

http://blog.f=
acilelogin.com

http://RampartFAQ.com

-- 
=
Thanks & Regards,
Prabath
Mobile : +94 71 809 673=
2=A0

http:=
//blog.facilelogin.com

http://RampartFAQ.com

--047d7b66f28115a29904d5799d74--

From jricher@mitre.org  Mon Feb 11 13:50:29 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEA921F87FD for ; Mon, 11 Feb 2013 13:50:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.573
X-Spam-Level: 
X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.025,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7i6mekmV1qJi for ; Mon, 11 Feb 2013 13:50:27 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id A8D2E21F869B for ; Mon, 11 Feb 2013 13:50:26 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1647B53105B4; Mon, 11 Feb 2013 16:50:26 -0500 (EST)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id E28731F13DC; Mon, 11 Feb 2013 16:50:25 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 11 Feb 2013 16:50:25 -0500
Message-ID: <51196777.6000502@mitre.org>
Date: Mon, 11 Feb 2013 16:49:43 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Prabath Siriwardena 
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com> <5112AE0B.1080501@mitre.org>  <5113C3AA.1040701@mitre.org>  <5113DDB2.7060805@mitre.org> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040108080707050504020200"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Feb 2013 21:50:29 -0000

--------------040108080707050504020200
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

On 02/08/2013 12:51 AM, Prabath Siriwardena wrote:
> Hi Justin,
>
> I have couple of questions related to "valid" parameter...
>
> This endpoint can be invoked by the Resource Server in runtime...

That's correct.

>
> In that case what is exactly meant by the "resource_id" in request ?

The resource_id field is a service-specific string that basically lets 
the resource server provide some context to the request to the auth 
server. There have been some other suggestions like client IP address, 
but I wanted to put this one in because it seemed to be a common theme. 
The client is trying to do *something* with the token, after all, and 
the rights, permissions, and metadata associated with the token could 
change based on that. Since the Introspection endpoint is all about 
getting that metadata back to the PR, this seemed like a good idea.

>
> IMO a token to be valid depends on set of criteria based on it's type..
>
> For a Bearer token..
>
> 1. Token should not be expired
> 2. Token should not be revoked.
> 3. The scope the token issued should match with the scope required for 
> the resource.
>
> For a MAC token...
>
> 1. Token not expired (mac id)
> 2. Token should not be revoked
> 3. The scope the token issued should match with the scope required for 
> the resource.
> 4. HMAC check should be valid
>
> There are similar conditions for SAML bearer too..

This isn't really true. The SAML bearer token is fully self-contained 
and doesn't change based on other parameters in the message, unlike MAC. 
Same with JWT. When it hands a SAML or JWT token to the AS, the PR has 
given *everything* the server needs to check that token's validity and use.

MAC signatures change with every message, and they're done across 
several components of the HTTP message. Therefor, the HMAC check for MAC 
style tokens will still need to be done by the protected resource. 
Introspection would help in the case that the signature validated just 
fine, but the token might have expired. Or you need to know what scopes 
apply. Introspection isn't to fully validate the call to the protected 
resource -- if that were the case, the PR would have to send some kind 
of encapsulated version of the original request. Otherwise, the AS won't 
have all of the information it needs to check the MAC.

I think what you're describing is ultimately *not* what the 
introspection endpoint is intended to do. If that's unclear from the 
document, can you please suggest text that would help clear the use case 
up? I wouldn't want it to be ambiguous.

  -- Justin

>
> Thanks & regards,
> -Prabath
>
>
> On Thu, Feb 7, 2013 at 10:30 PM, Justin Richer  > wrote:
>
>     It validates the token, which would be either the token itself in
>     the case of Bearer or the token "id" part of something more
>     complex like MAC. It doesn't directly validate the usage of the
>     token, that's still up to the PR to do that.
>
>     I nearly added a "token type" field in this draft, but held back
>     because there are several kinds of "token type" that people talk
>     about in OAuth. First, there's "Bearer" vs. "MAC" vs. "HOK", or
>     what have you. Then within Bearer you have "JWT" or "SAML" or
>     "unstructured blob". Then you've also got "access" vs. "refresh"
>     and other flavors of token, like the id_token in OpenID Connect.
>
>     Thing is, the server running the introspection endpoint will
>     probably know *all* of these. But should it tell the client? If
>     so, which of the three, and what names should the fields be?
>
>      -- Justin
>
>
>     On 02/07/2013 11:26 AM, Prabath Siriwardena wrote:
>>     Okay.. I was thinking this could be used as a way to validate the
>>     token as well. BTW even in this case shouldn't communicate the
>>     type of token to AS? For example in the case of SAML profile - it
>>     could be SAML token..
>>
>>     Thanks & regards,
>>     -Prabath
>>
>>     On Thu, Feb 7, 2013 at 8:39 PM, Justin Richer >     > wrote:
>>
>>         "valid" might not be the best term, but it's meant to be a
>>         field where the server says "yes this token is still good" or
>>         "no this token isn't good anymore". We could instead do this
>>         with HTTP codes or something but I went with a pure JSON
>>         response.
>>
>>          -- Justin
>>
>>
>>         On 02/06/2013 10:47 PM, Prabath Siriwardena wrote:
>>>         Hi Justin,
>>>
>>>         I believe this is addressing one of the key missing part in
>>>         OAuth 2.0...
>>>
>>>         One question - I guess this was discussed already...
>>>
>>>         In the spec - in the introspection response it has the
>>>         attribute "valid" - this is basically the validity of the
>>>         token provided in the request.
>>>
>>>         Validation criteria depends on the token and well as token
>>>         type ( Bearer, MAC..).
>>>
>>>         In the spec it seems like it's coupled with Bearer token
>>>         type... But I guess, by adding "token_type" to the request
>>>         we can remove this dependency.
>>>
>>>         WDYT..?
>>>
>>>         Thanks & regards,
>>>         -Prabath
>>>
>>>         On Thu, Feb 7, 2013 at 12:54 AM, Justin Richer
>>>         > wrote:
>>>
>>>             Updated introspection draft based on recent comments.
>>>             Changes include:
>>>
>>>              - "scope" return parameter now follows RFC6749 format
>>>             instead of JSON array
>>>              - "subject" -> "sub", and "audience" -> "aud", to be
>>>             parallel with JWT claims
>>>              - clarified what happens if the authentication is bad
>>>
>>>              -- Justin
>>>
>>>
>>>             -------- Original Message --------
>>>             Subject: 	New Version Notification for
>>>             draft-richer-oauth-introspection-02.txt
>>>             Date: 	Wed, 6 Feb 2013 11:24:20 -0800
>>>             From: 	
>>>             
>>>             To: 	 
>>>
>>>
>>>
>>>             A new version of I-D, draft-richer-oauth-introspection-02.txt
>>>             has been successfully submitted by Justin Richer and posted to the
>>>             IETF repository.
>>>
>>>             Filename:	 draft-richer-oauth-introspection
>>>             Revision:	 02
>>>             Title:		 OAuth Token Introspection
>>>             Creation date:	 2013-02-06
>>>             WG ID:		 Individual Submission
>>>             Number of pages: 6
>>>             URL:http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
>>>             Status:http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
>>>             Htmlized:http://tools.ietf.org/html/draft-richer-oauth-introspection-02
>>>             Diff:http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02
>>>
>>>             Abstract:
>>>                 This specification defines a method for a client or protected
>>>                 resource to query an OAuth authorization server to determine meta-
>>>                 information about an OAuth token.
>>>
>>>
>>>                                                                                                
>>>
>>>
>>>             The IETF Secretariat
>>>
>>>
>>>
>>>
>>>             _______________________________________________
>>>             OAuth mailing list
>>>             OAuth@ietf.org 
>>>             https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>>
>>>         -- 
>>>         Thanks & Regards,
>>>         Prabath
>>>
>>>         Mobile : +94 71 809 6732 
>>>
>>>         http://blog.facilelogin.com
>>>         http://RampartFAQ.com
>>
>>
>>
>>
>>     -- 
>>     Thanks & Regards,
>>     Prabath
>>
>>     Mobile : +94 71 809 6732 
>>
>>     http://blog.facilelogin.com
>>     http://RampartFAQ.com
>
>
>
>
> -- 
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com

--------------040108080707050504020200
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

    On 02/08/2013 12:51 AM, Prabath
      Siriwardena wrote:

      Hi Justin,

      I have couple of questions related to "valid" parameter...

      This endpoint can be invoked by the Resource Server in
        runtime...

    That's correct.

      In that case what is exactly meant by the "resource_id" in
        request ?

    The resource_id field is a service-specific string that basically
    lets the resource server provide some context to the request to the
    auth server. There have been some other suggestions like client IP
    address, but I wanted to put this one in because it seemed to be a
    common theme. The client is trying to do *something* with the token,
    after all, and the rights, permissions, and metadata associated with
    the token could change based on that. Since the Introspection
    endpoint is all about getting that metadata back to the PR, this
    seemed like a good idea.

      IMO a token to be valid depends on set of criteria based on
        it's type..

      For a Bearer token..

      1. Token should not be expired
      2. Token should not be revoked.
      3. The scope the token issued should match with the scope
        required for the resource.

      For a MAC token...

      1. Token not expired (mac id)
      2. Token should not be revoked
      3. The scope the token issued should match with the scope
        required for the resource.
      4. HMAC check should be valid

      There are similar conditions for SAML bearer too..

    This isn't really true. The SAML bearer token is fully
    self-contained and doesn't change based on other parameters in the
    message, unlike MAC. Same with JWT. When it hands a SAML or JWT
    token to the AS, the PR has given *everything* the server needs to
    check that token's validity and use. 

    MAC signatures change with every message, and they're done across
    several components of the HTTP message. Therefor, the HMAC check for
    MAC style tokens will still need to be done by the protected
    resource. Introspection would help in the case that the signature
    validated just fine, but the token might have expired. Or you need
    to know what scopes apply. Introspection isn't to fully validate the
    call to the protected resource -- if that were the case, the PR
    would have to send some kind of encapsulated version of the original
    request. Otherwise, the AS won't have all of the information it
    needs to check the MAC.

    I think what you're describing is ultimately *not* what the
    introspection endpoint is intended to do. If that's unclear from the
    document, can you please suggest text that would help clear the use
    case up? I wouldn't want it to be ambiguous.

     -- Justin

      Thanks & regards,
      -Prabath

        On Thu, Feb 7, 2013 at 10:30 PM, Justin
          Richer <jricher@mitre.org>
          wrote:

             It validates the
              token, which would be either the token itself in the case
              of Bearer or the token "id" part of something more complex
              like MAC. It doesn't directly validate the usage of the
              token, that's still up to the PR to do that.

              I nearly added a "token type" field in this draft, but
              held back because there are several kinds of "token type"
              that people talk about in OAuth. First, there's "Bearer"
              vs. "MAC" vs. "HOK", or what have you. Then within Bearer
              you have "JWT" or "SAML" or "unstructured blob". Then
              you've also got "access" vs. "refresh" and other flavors
              of token, like the id_token in OpenID Connect. 

              Thing is, the server running the introspection endpoint
              will probably know *all* of these. But should it tell the
              client? If so, which of the three, and what names should
              the fields be?

                   -- Justin

                  On 02/07/2013 11:26 AM, Prabath Siriwardena
                    wrote:

                   Okay.. I was thinking this
                    could be used as a way to validate the token as
                    well. BTW even in this case shouldn't communicate
                    the type of token to AS? For example in the case of
                    SAML profile - it could be SAML token..

                    Thanks & regards,
                    -Prabath

                      On Thu, Feb 7, 2013 at
                        8:39 PM, Justin Richer <jricher@mitre.org>
                        wrote:

                           "valid"
                            might not be the best term, but it's meant
                            to be a field where the server says "yes
                            this token is still good" or "no this token
                            isn't good anymore". We could instead do
                            this with HTTP codes or something but I went
                            with a pure JSON response.

                                 -- Justin

                                On 02/06/2013 10:47 PM, Prabath
                                  Siriwardena wrote:

                                 Hi Justin,

                                  I believe this is addressing one
                                    of the key missing part in OAuth
                                    2.0...

                                  One question - I guess this was
                                    discussed already...

                                  In the spec - in the
                                    introspection response it has the
                                    attribute "valid" - this is
                                    basically the validity of the token
                                    provided in the request.

                                  Validation criteria depends on
                                    the token and well as token type (
                                    Bearer, MAC..).

                                  In the spec it seems like it's
                                    coupled with Bearer token type...
                                    But I guess, by adding "token_type"
                                    to the request we can remove this
                                    dependency.

                                  WDYT..?

                                  Thanks & regards,
                                  -Prabath 

                                    On Thu, Feb
                                      7, 2013 at 12:54 AM, Justin Richer
                                      <jricher@mitre.org>
                                      wrote:

                                         Updated
                                          introspection draft based on
                                          recent comments. Changes
                                          include:

                                           - "scope" return parameter
                                          now follows RFC6749 format
                                          instead of JSON array

                                           - "subject" -> "sub", and
                                          "audience" -> "aud", to be
                                          parallel with JWT claims

                                           - clarified what happens if
                                          the authentication is bad

                                           -- Justin

                                            -------- Original Message
                                            --------

                                                  Subject:

                                                  New Version
                                                    Notification for
                                                    draft-richer-oauth-introspection-02.txt

                                                  Date:

                                                  Wed, 6 Feb 2013
                                                    11:24:20 -0800

                                                  From:

                                                  <internet-drafts@ietf.org>

                                                  To:

                                                  <jricher@mitre.org>

                                            A new version of I-D, draft-richer-oauth-introspection-02.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 02
Title:		 OAuth Token Introspection
Creation date:	 2013-02-06
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.

The IETF Secretariat

_______________________________________________

                                        OAuth mailing list

                                        OAuth@ietf.org

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

                                    -- 

                                    Thanks & Regards,

                                    Prabath

                                    Mobile : +94 71 809 6732 

                                      http://blog.facilelogin.com

                                      http://RampartFAQ.com

                      -- 

                      Thanks & Regards,

                      Prabath

                      Mobile : +94 71
                          809 6732 

                        http://blog.facilelogin.com

                        http://RampartFAQ.com

        -- 

        Thanks & Regards,

        Prabath

        Mobile : +94 71 809 6732 

          http://blog.facilelogin.com

          http://RampartFAQ.com

--------------040108080707050504020200--

From prabath@wso2.com  Mon Feb 11 13:56:29 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71B921F87BA for ; Mon, 11 Feb 2013 13:56:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.854
X-Spam-Level: 
X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=0.123,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egKuSOGlgf-i for ; Mon, 11 Feb 2013 13:56:28 -0800 (PST)
Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA6B21F8790 for ; Mon, 11 Feb 2013 13:56:27 -0800 (PST)
Received: by mail-ee0-f41.google.com with SMTP id c13so3387001eek.14 for ; Mon, 11 Feb 2013 13:56:26 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=onpX+HV5clttdcw6N43H5cepzCW1QNFvuwFQDYC50F8=; b=X8GbRIpOa27BKCJjCnfBmKNMLz1WUUxBf5wIzbjOVFRV1SWybBqIvXbkhkmW1rTvn/ KE0nD0AEInLnZOB8ecsF81H0JMRiQ7xkwTifsWcCejxRrUdxPu629s0OPY5wUw9gTbsg NNiYo9KV/3OCD/IKEG6q7flASqsUjG7wLwvI4R3T0Lr0qc9+qaehh0kVzqd6Nb43mTtW Whm/QltCYpkxpJ65pRiOpExZo1FXTm107HYxeGDTgYIvzjcPvBn9DGARaitLnFwWd2VH ZtoQN+eR+snsOc/EWXxkDNbPDoUBC4x0P12JcMHHYK0WTD69EQyUGDtknzFSCCqFT7n7 oVRA==
MIME-Version: 1.0
X-Received: by 10.14.182.137 with SMTP id o9mr19296890eem.13.1360619786304; Mon, 11 Feb 2013 13:56:26 -0800 (PST)
Received: by 10.223.146.76 with HTTP; Mon, 11 Feb 2013 13:56:26 -0800 (PST)
In-Reply-To: <51196777.6000502@mitre.org>
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com> <5112AE0B.1080501@mitre.org>  <5113C3AA.1040701@mitre.org>  <5113DDB2.7060805@mitre.org>  <51196777.6000502@mitre.org>
Date: Tue, 12 Feb 2013 03:26:26 +0530
Message-ID: 
From: Prabath Siriwardena 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=047d7b343f60097bfd04d579fbad
X-Gm-Message-State: ALoCoQlSDLaNLBzXKv55YUNhoRFk65mzkmRPxwwQK3rsfpRBhw2gfnOB3a66yuGZWzkXGDIFV2Oq
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Feb 2013 21:56:29 -0000

--047d7b343f60097bfd04d579fbad
Content-Type: text/plain; charset=ISO-8859-1

I guess confusion is with 'valid' parameter is in the response..

I thought this will be helpful to standardize the communication between
Resource Server and the Authorization Server..

I would suggest we completely remove "valid" from the response - or define
it much clearly..

May be can add "revoked" with a boolean attribute..

Thanks & regards,
-Prabath

On Tue, Feb 12, 2013 at 3:19 AM, Justin Richer  wrote:

>
> On 02/08/2013 12:51 AM, Prabath Siriwardena wrote:
>
> Hi Justin,
>
>  I have couple of questions related to "valid" parameter...
>
>  This endpoint can be invoked by the Resource Server in runtime...
>
>
> That's correct.
>
>
>
>  In that case what is exactly meant by the "resource_id" in request ?
>
>
> The resource_id field is a service-specific string that basically lets the
> resource server provide some context to the request to the auth server.
> There have been some other suggestions like client IP address, but I wanted
> to put this one in because it seemed to be a common theme. The client is
> trying to do *something* with the token, after all, and the rights,
> permissions, and metadata associated with the token could change based on
> that. Since the Introspection endpoint is all about getting that metadata
> back to the PR, this seemed like a good idea.
>
>
>
>  IMO a token to be valid depends on set of criteria based on it's type..
>
>  For a Bearer token..
>
>  1. Token should not be expired
> 2. Token should not be revoked.
> 3. The scope the token issued should match with the scope required for the
> resource.
>
>  For a MAC token...
>
>  1. Token not expired (mac id)
> 2. Token should not be revoked
> 3. The scope the token issued should match with the scope required for the
> resource.
> 4. HMAC check should be valid
>
>  There are similar conditions for SAML bearer too..
>
>
> This isn't really true. The SAML bearer token is fully self-contained and
> doesn't change based on other parameters in the message, unlike MAC. Same
> with JWT. When it hands a SAML or JWT token to the AS, the PR has given
> *everything* the server needs to check that token's validity and use.
>
> MAC signatures change with every message, and they're done across several
> components of the HTTP message. Therefor, the HMAC check for MAC style
> tokens will still need to be done by the protected resource. Introspection
> would help in the case that the signature validated just fine, but the
> token might have expired. Or you need to know what scopes apply.
> Introspection isn't to fully validate the call to the protected resource --
> if that were the case, the PR would have to send some kind of encapsulated
> version of the original request. Otherwise, the AS won't have all of the
> information it needs to check the MAC.
>
>
> I think what you're describing is ultimately *not* what the introspection
> endpoint is intended to do. If that's unclear from the document, can you
> please suggest text that would help clear the use case up? I wouldn't want
> it to be ambiguous.
>
>  -- Justin
>
>
>
>  Thanks & regards,
> -Prabath
>
>
> On Thu, Feb 7, 2013 at 10:30 PM, Justin Richer  wrote:
>
>>  It validates the token, which would be either the token itself in the
>> case of Bearer or the token "id" part of something more complex like MAC.
>> It doesn't directly validate the usage of the token, that's still up to the
>> PR to do that.
>>
>> I nearly added a "token type" field in this draft, but held back because
>> there are several kinds of "token type" that people talk about in OAuth.
>> First, there's "Bearer" vs. "MAC" vs. "HOK", or what have you. Then within
>> Bearer you have "JWT" or "SAML" or "unstructured blob". Then you've also
>> got "access" vs. "refresh" and other flavors of token, like the id_token in
>> OpenID Connect.
>>
>> Thing is, the server running the introspection endpoint will probably
>> know *all* of these. But should it tell the client? If so, which of the
>> three, and what names should the fields be?
>>
>>  -- Justin
>>
>>
>> On 02/07/2013 11:26 AM, Prabath Siriwardena wrote:
>>
>> Okay.. I was thinking this could be used as a way to validate the token
>> as well. BTW even in this case shouldn't communicate the type of token to
>> AS? For example in the case of SAML profile - it could be SAML token..
>>
>>  Thanks & regards,
>> -Prabath
>>
>> On Thu, Feb 7, 2013 at 8:39 PM, Justin Richer  wrote:
>>
>>>  "valid" might not be the best term, but it's meant to be a field where
>>> the server says "yes this token is still good" or "no this token isn't good
>>> anymore". We could instead do this with HTTP codes or something but I went
>>> with a pure JSON response.
>>>
>>>  -- Justin
>>>
>>>
>>> On 02/06/2013 10:47 PM, Prabath Siriwardena wrote:
>>>
>>> Hi Justin,
>>>
>>>  I believe this is addressing one of the key missing part in OAuth
>>> 2.0...
>>>
>>>  One question - I guess this was discussed already...
>>>
>>>  In the spec - in the introspection response it has the attribute
>>> "valid" - this is basically the validity of the token provided in the
>>> request.
>>>
>>>  Validation criteria depends on the token and well as token type (
>>> Bearer, MAC..).
>>>
>>>  In the spec it seems like it's coupled with Bearer token type... But I
>>> guess, by adding "token_type" to the request we can remove this dependency.
>>>
>>>  WDYT..?
>>>
>>>  Thanks & regards,
>>> -Prabath
>>>
>>> On Thu, Feb 7, 2013 at 12:54 AM, Justin Richer wrote:
>>>
>>>>  Updated introspection draft based on recent comments. Changes include:
>>>>
>>>>  - "scope" return parameter now follows RFC6749 format instead of JSON
>>>> array
>>>>  - "subject" -> "sub", and "audience" -> "aud", to be parallel with JWT
>>>> claims
>>>>  - clarified what happens if the authentication is bad
>>>>
>>>>  -- Justin
>>>>
>>>>
>>>> -------- Original Message --------  Subject: New Version Notification
>>>> for draft-richer-oauth-introspection-02.txt  Date: Wed, 6 Feb 2013
>>>> 11:24:20 -0800  From:   To:
>>>>  
>>>>
>>>> A new version of I-D, draft-richer-oauth-introspection-02.txt
>>>> has been successfully submitted by Justin Richer and posted to the
>>>> IETF repository.
>>>>
>>>> Filename:	 draft-richer-oauth-introspection
>>>> Revision:	 02
>>>> Title:		 OAuth Token Introspection
>>>> Creation date:	 2013-02-06
>>>> WG ID:		 Individual Submission
>>>> Number of pages: 6
>>>> URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
>>>> Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
>>>> Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-02
>>>> Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02
>>>>
>>>> Abstract:
>>>>    This specification defines a method for a client or protected
>>>>    resource to query an OAuth authorization server to determine meta-
>>>>    information about an OAuth token.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> The IETF Secretariat
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>
>>>
>>>  --
>>> Thanks & Regards,
>>> Prabath
>>>
>>>  Mobile : +94 71 809 6732
>>>
>>> http://blog.facilelogin.com
>>> http://RampartFAQ.com
>>>
>>>
>>>
>>
>>
>>  --
>> Thanks & Regards,
>> Prabath
>>
>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>
>> http://blog.facilelogin.com
>> http://RampartFAQ.com
>>
>>
>>
>
>
>  --
> Thanks & Regards,
> Prabath
>
>  Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com
>
>
>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.com

--047d7b343f60097bfd04d579fbad
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I guess confusion is with 'valid' parameter is in the response..
I thought this will be helpful to=A0standardize=A0the comm=
unication between Resource Server and the Authorization Server..
=

I would suggest we completely remove "valid" from the =
response - or define it much clearly..

May be can =
add "revoked" with a boolean attribute..

Thanks & regards,
-Prabath

On Tue, Feb 12, 2013 at 3:19 AM, Justin Richer <<=
a href=3D"mailto:jricher@mitre.org" target=3D"_blank">jricher@mitre.org=
> wrote:

 =20
   =20
 =20

    On 02/08/2013 12:51 AM, Prabath
      Siriwardena wrote:

     =20
      Hi=A0Justin,

      I have couple of questions related to "valid" paramete=
r...

      This endpoint can be invoked by the Resource Server in
        runtime...

    That's correct.

      In that case what is exactly meant by the "resource_id"=
; in
        request ?

    The resource_id field is a service-specific string that basically
    lets the resource server provide some context to the request to the
    auth server. There have been some other suggestions like client IP
    address, but I wanted to put this one in because it seemed to be a
    common theme. The client is trying to do *something* with the token,
    after all, and the rights, permissions, and metadata associated with
    the token could change based on that. Since the Introspection
    endpoint is all about getting that metadata back to the PR, this
    seemed like a good idea.

      IMO a token to be valid depends on set of criteria based on
        it's type..

      For a Bearer token..

      1. Token should not be expired
      2. Token should not be revoked.
      3. The scope the token issued should match with the scope
        required for the resource.

      For a MAC token...

      1. Token not expired (mac id)
      2. Token should not be revoked
      3. The scope the token issued should match with the scope
        required for the resource.
      4. HMAC check should be valid

      There are similar conditions for SAML bearer too..

    This isn't really true. The SAML bearer token is fully
    self-contained and doesn't change based on other parameters in the
    message, unlike MAC. Same with JWT. When it hands a SAML or JWT
    token to the AS, the PR has given *everything* the server needs to
    check that token's validity and use. 

    MAC signatures change with every message, and they're done across
    several components of the HTTP message. Therefor, the HMAC check for
    MAC style tokens will still need to be done by the protected
    resource. Introspection would help in the case that the signature
    validated just fine, but the token might have expired. Or you need
    to know what scopes apply. Introspection isn't to fully validate th=
e
    call to the protected resource -- if that were the case, the PR
    would have to send some kind of encapsulated version of the original
    request. Otherwise, the AS won't have all of the information it
    needs to check the MAC.

    I think what you're describing is ultimately *not* what the
    introspection endpoint is intended to do. If that's unclear from th=
e
    document, can you please suggest text that would help clear the use
    case up? I wouldn't want it to be ambiguous.=

    =A0-- Justin

      Thanks & regards,
      -Prabath

        On Thu, Feb 7, 2013 at 10:30 PM, Justin
          Richer <jricher@mitre.org>
          wrote:

             It validates the
              token, which would be either the token itself in the case
              of Bearer or the token "id" part of something more =
complex
              like MAC. It doesn't directly validate the usage of the
              token, that's still up to the PR to do that.

              I nearly added a "token type" field in this draft, =
but
              held back because there are several kinds of "token type=
"
              that people talk about in OAuth. First, there's "Bea=
rer"
              vs. "MAC" vs. "HOK", or what have you. Th=
en within Bearer
              you have "JWT" or "SAML" or "unstruc=
tured blob". Then
              you've also got "access" vs. "refresh"=
; and other flavors
              of token, like the id_token in OpenID Connect. 

              Thing is, the server running the introspection endpoint
              will probably know *all* of these. But should it tell the
              client? If so, which of the three, and what names should
              the fields be?

                  =A0-- Justin

                  On 02/07/2013 11:26 AM, Prabath Siriwardena
                    wrote:

                   Okay.. I was thinking this
                    could be used as a way to validate the token as
                    well. BTW even in this case shouldn't communicate
                    the type of token to AS? For example in the case of
                    SAML profile - it could be SAML token..

                    Thanks & regards,
                    -Prabath

                      On Thu, Feb 7, 2013 at
                        8:39 PM, Justin Richer <jricher@mitre.org><=
/span>
                        wrote:

                           "=
valid"
                            might not be the best term, but it's meant
                            to be a field where the server says "yes
                            this token is still good" or "no this=
 token
                            isn't good anymore". We could instead =
do
                            this with HTTP codes or something but I went
                            with a pure JSON response.

                                =A0-- Justin

                                On 02/06/2013 10:47 PM, Prabath
                                  Siriwardena wrote:

                                 Hi Justin,

                                  I believe this is addressing one
                                    of the key missing part in OAuth
                                    2.0...

                                  One question - I guess this was
                                    discussed already...

                                  In the spec - in the
                                    introspection response it has the
                                    attribute "valid" - this is
                                    basically the validity of the token
                                    provided in the request.

                                  Validation=A0criteria depends on
                                    the token and well as token type (
                                    Bearer, MAC..).

                                  In the spec it seems like it's
                                    coupled with Bearer token type...
                                    But I guess, by adding "token_type=
"
                                    to the request we can remove this
                                    dependency.

                                  WDYT..?

                                  Thanks & regards,
                                  -Prabath=A0

                                    On Thu, Feb
                                      7, 2013 at 12:54 AM, Justin Richer
                                      <jricher@mitre.org>
                                      wrote:

                                         Updated
                                          introspection draft based on
                                          recent comments. Changes
                                          include:

                                          =A0- "scope" return par=
ameter
                                          now follows RFC6749 format
                                          instead of JSON array

                                          =A0- "subject" -> &q=
uot;sub", and
                                          "audience" -> "=
aud", to be
                                          parallel with JWT claims

                                          =A0- clarified what happens if
                                          the authentication is bad

                                          =A0-- Justin

                                            -------- Original Message
                                            --------

                                                  Subject:

                                                  New Version
                                                    Notification for
                                                    draft-richer-oauth-intr=
ospection-02.txt

                                                  Date:

                                                  Wed, 6 Feb 2013
                                                    11:24:20 -0800

                                                  From:

                                                  <internet-drafts@ietf.org>

                                                  To:

                                                  <jricher@mitre.org>

                                            A new version of I-D, draf=
t-richer-oauth-introspection-02.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 02
Title:		 OAuth Token Introspection
Creation date:	 2013-02-06
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/interne=
t-drafts/draft-richer-oauth-introspection-02.txt
Status:          http://datatracker.ietf.org/doc/draft-=
richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-=
oauth-introspection-02
Diff:            http://www.ietf.org/rfcdiff?url2=
=3Ddraft-richer-oauth-introspection-02

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.

                                                                           =
      =20

The IETF Secretariat

_______________________________________________

                                        OAuth mailing list

                                        OAuth@ietf.org

                                        https://www.ietf.org/mailman/listinf=
o/oauth

                                    -- 

                                    Thanks & Regards,

                                    Prabath

                                    Mobile : +94 71 809 6732=
=A0

                                      http://blog.facilelogin.com

                                      http://RampartFAQ.com

                      -- 

                      Thanks & Regards,

                      Prabath

                      Mobile : +94 71
                          809 6732=A0

                        http://blog.facilelogin.com

                        http://RampartFAQ.com

        -- 

        Thanks & Regards,

        Prabath

        Mobile : +94 71 809 6732=A0

          http://=
blog.facilelogin.com

          http://Rampar=
tFAQ.com

-- 
Thanks &=
 Regards,
Prabath
Mobile : +94 71 809 6732=A0

=
http://blog.facil=
elogin.com

http://RampartFAQ.com

--047d7b343f60097bfd04d579fbad--

From richard@maymount.com  Mon Feb 11 15:34:05 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E8721F8713 for ; Mon, 11 Feb 2013 15:34:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.202
X-Spam-Level: 
X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jq4C+oIvXrMp for ; Mon, 11 Feb 2013 15:34:02 -0800 (PST)
Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with SMTP id A05C921F869A for ; Mon, 11 Feb 2013 15:34:02 -0800 (PST)
Received: from mail-pa0-f72.google.com ([209.85.220.72]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKURl/6r8czQIbrBDvsC55ZbgdZ9G4XJFQ@postini.com; Mon, 11 Feb 2013 15:34:02 PST
Received: by mail-pa0-f72.google.com with SMTP id bh2so5539278pad.7 for ; Mon, 11 Feb 2013 15:34:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=maymount.com; s=google; h=x-received:x-received:references:mime-version:in-reply-to :content-type:content-transfer-encoding:message-id:cc:x-mailer:from :subject:date:to; bh=0rqCpDouw2di/adh7cM1ACd66xqj9ISeSH1jw+A37bE=; b=ZrzkHlY6ont2gGwXqZzFI9KT5kd2IEufGtp6t4uNCW+vERzPUzToapaaIGXGBzbq4+ 6QD8hO8V+Rars2mpZ+2+Er59alrO2O7QNQyv902tvjBICHX0aXHN6ecFp0mpDBSyPMgq EfuwsA+8nv/0nTCL00cW14wwD4YRuNDZNPNp0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:references:mime-version:in-reply-to :content-type:content-transfer-encoding:message-id:cc:x-mailer:from :subject:date:to:x-gm-message-state; bh=0rqCpDouw2di/adh7cM1ACd66xqj9ISeSH1jw+A37bE=; b=QQeM6doKmcQLKC0jkdHuJCQBpdj8lipir5H+qluaQ3Y+XFnp3l2W9cLgeJr0EVLsBA vN05ZQTEoL6dcNZBOnD6GkLhKH4U/w7XmBmFlqUyIEAGY6bTO5w7Uvv+Nc/SdhaNjOnm A5A87ru8D+jGo1qRJTwwthg299VNz4hSDA7koNNAjVkAv0WD+jwlDDB3Xv49H/ENU0rq uucR6GNV9EwDUTdZWzVbQ15sLjRlDQVg8cMFlhhjUd38BzdrXb2kUAijdpSF4rs2XsqA ulL3eyuW4jCNTrB5d2pQ8uKXR4bHBxH01mzQHKoa3pbhnO6HImz3I72X0l+HGpTTzXYE tc7Q==
X-Received: by 10.66.83.8 with SMTP id m8mr45778031pay.40.1360625641915; Mon, 11 Feb 2013 15:34:01 -0800 (PST)
X-Received: by 10.66.83.8 with SMTP id m8mr45777984pay.40.1360625641583; Mon, 11 Feb 2013 15:34:01 -0800 (PST)
Received: from [192.168.1.3] (21.sub-70-199-236.myvzw.com. [70.199.236.21]) by mx.google.com with ESMTPS id q4sm69990403paz.20.2013.02.11.15.33.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Feb 2013 15:34:00 -0800 (PST)
References: <51195F3D.1050006@mitre.org>
Mime-Version: 1.0 (1.0)
In-Reply-To: <51195F3D.1050006@mitre.org>
Content-Type: multipart/alternative; boundary=Apple-Mail-91D5C7D2-AB17-4371-B356-E59A10085065
Content-Transfer-Encoding: 7bit
Message-Id: <222C28CB-7F6F-4BC3-8692-40404C2DC2D3@maymount.com>
X-Mailer: iPad Mail (10B141)
From: Richard Harrington 
Date: Mon, 11 Feb 2013 15:33:58 -0800
To: Justin Richer 
X-Gm-Message-State: ALoCoQkP4FXdrGmFhT+wxINfNByL6S7f+61+22iaYLaTzcqb1l3qAPP19nt3SH65CveNM8rSlv7xa6J795ya83tzLs8Y/YFifDVdVnWO6Zgb+bpRiwqbuhQKDmGbLambstz7AsX0SqR64AhgwCUGcyO/844VLIJGcw==
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Feb 2013 23:34:05 -0000

--Apple-Mail-91D5C7D2-AB17-4371-B356-E59A10085065
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Since the request is an HTTP POST and a resource is created (http://www.w3.o=
rg/Protocols/rfc2616/rfc2616-sec9.html#sec9.5) the response should be an HTT=
P 201 Created (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.=
2.2) which is supposed to include the location of the newly created resource=
.

This is a good pattern to follow since, as you say, it does provide flexibil=
ity.

On Feb 11, 2013, at 1:14 PM, Justin Richer  wrote:

> Draft -05 of OAuth Dynamic Client Registration [1] returns a URL pointer f=
or the client to perform update and secret rotation actions. This functional=
ity arose from discussions on the list about moving towards a more RESTful p=
attern, and Nat Sakimura proposed this approach in the OpenID Connect Workin=
g Group. This URL may be distinct from the Client Registration Endpoint URL,=
 but draft -05 makes no promises as to its content, form, or structure, thou=
gh it does contain implementor's notes on possible methods.
>=20
> Two questions arise from this change:
> - The semantics of returning the client manipulation URL
> - The syntax (derived from HAL for JSON [2], an individual I-D submission)=

>=20
> On semantics:
>=20
> Pro:
> - The server has flexibility on how to define the "update" endpoint, sendi=
ng all clients to one URL, sending different clients to different URLs, or s=
ending clients to a URL with a baked-in query parameter
> - The client can take the URL as-is and use it for all management operatio=
ns (ie, it doesn't have to generate or compose the URL based on component pa=
rts)
>=20
> Con:
> - The client must remember one more piece of information from the server a=
t runtime if it wants to do manipulation and management of itself at the ser=
ver (in addition to client_id, client_secret, registration_access_token, and=
 others)
>=20
> Alternatives include specifying a URL pattern for the server to use and al=
l clients to follow, specifying a query parameter for the update action, and=
 specifying a separate endpoint entirely and using the presence of items suc=
h as client_id and the registration access token to differentiate the reques=
ts. Note that *all* of these alternatives can be accommodated using the sema=
ntics described above, with the same actions on the client's part.
>=20
>=20
> On syntax:
>=20
> Pro:
> - Follows the designs of RFC5988 for link relations
> - The HAL format is general, and allows for all kinds of other information=
 to be placed inside the _links structure
> - Allows for full use of the JSON object to specify advanced operations on=
 the returned endpoint if desired
>=20
> Con:
> - The rest of OAuth doesn't follow link relation guidelines (though it's b=
een brought up)
> - The HAL format is general, and allows for all kinds of other information=
 to be placed inside the _links structure
> - The HAL-JSON document is an expired individual I-D, and it's unclear wha=
t wider adoption looks like right now
>=20
> Alternatives include returning the URL as a separate data member (registra=
tion_update_url), using HTTP headers, or using JSON Schema.
>=20
> -- Justin
>=20
>=20
>=20
> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
> [2] http://tools.ietf.org/html/draft-kelly-json-hal-03
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-91D5C7D2-AB17-4371-B356-E59A10085065
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Since the request is an HTTP POST and a=
 resource is created (http://www.w3.org/Protocols/rfc2616/rfc=
2616-sec9.html#sec9.5) the response should=
 be an HTTP 201 Created (http://www.w3.org/Pr=
otocols/rfc2616/rfc2616-sec10.html#sec10.2.2) which is supposed to include the location of the newly created resource.=

T=
his is a good pattern to follow since, as you say, it does provide flexibili=
ty.

jricher@mitre.org> wrote:
Draft -05 of OAuth Dynamic Clien=
t Registration [1] returns a URL pointer for the client to perform update an=
d secret rotation actions. This functionality arose from discussions on the l=
ist about moving towards a more RESTful pattern, and Nat Sakimura proposed t=
his approach in the OpenID Connect Working Group. This URL may be distinct f=
rom the Client Registration Endpoint URL, but draft -05 makes no promises as=
 to its content, form, or structure, though it does contain implementor's no=
tes on possible methods.

Two questions aris=
e from this change:
 - The semantics of returning the client=
 manipulation URL
 - The syntax (derived from HAL for JSON [=
2], an individual I-D submission)

On semant=
ics:

Pro:
 - The server has=
 flexibility on how to define the "update" endpoint, sending all clients to o=
ne URL, sending different clients to different URLs, or sending clients to a=
 URL with a baked-in query parameter
 - The client can take t=
he URL as-is and use it for all management operations (ie, it doesn't have t=
o generate or compose the URL based on component parts)

Con:
 - The client must remember one more piece=
 of information from the server at runtime if it wants to do manipulation an=
d management of itself at the server (in addition to client_id, client_secre=
t, registration_access_token, and others)

A=
lternatives include specifying a URL pattern for the server to use and all c=
lients to follow, specifying a query parameter for the update action, and sp=
ecifying a separate endpoint entirely and using the presence of items such a=
s client_id and the registration access token to differentiate the requests.=
 Note that *all* of these alternatives can be accommodated using the semanti=
cs described above, with the same actions on the client's part.

On syntax:

=
Pro:
 - Follows the designs of RFC5988 for link relati=
ons
 - The HAL format is general, and allows for all kinds o=
f other information to be placed inside the _links structure
 - Allows for full use of the JSON object to specify advanced operations on=
 the returned endpoint if desired

Con:
 - The rest of OAuth doesn't follow link relation guidelines (th=
ough it's been brought up)
 - The HAL format is general, and=
 allows for all kinds of other information to be placed inside the _links st=
ructure
 - The HAL-JSON document is an expired individual I-=
D, and it's unclear what wider adoption looks like right now

Alternatives include returning the URL as a separate data m=
ember (registration_update_url), using HTTP headers, or using JSON Schema.

 -- Justin

=

[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn=
-reg-05
[2] http://tools.ietf.org/html/draft-kelly-json-hal-03
_______________________________________________
OAuth mailing list
OAuth=
@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
=

--Apple-Mail-91D5C7D2-AB17-4371-B356-E59A10085065--

From richard@maymount.com  Mon Feb 11 17:02:32 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0E821F881D for ; Mon, 11 Feb 2013 17:02:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.202
X-Spam-Level: 
X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SU9gxbzFDvvZ for ; Mon, 11 Feb 2013 17:02:31 -0800 (PST)
Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with SMTP id BA68F21F87B9 for ; Mon, 11 Feb 2013 17:02:30 -0800 (PST)
Received: from mail-pa0-f70.google.com ([209.85.220.70]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKURmUpePoUWQUdw0ZafjSA/qeiaEqlfTf@postini.com; Mon, 11 Feb 2013 17:02:30 PST
Received: by mail-pa0-f70.google.com with SMTP id kp1so5586008pab.5 for ; Mon, 11 Feb 2013 17:02:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=maymount.com; s=google; h=x-received:x-received:references:mime-version:in-reply-to :content-type:content-transfer-encoding:message-id:cc:x-mailer:from :subject:date:to; bh=hc13t3TfHvkmGMTtMZNzb6cAKtbAoYcvVAImlQaw7Lg=; b=JLntID4S342Qx5kCcx25Hf9kscky1Wp7biy9FGVwQxElcQD+K5ydAAYFc8pimsqnf+ wOVWLrzS/HY+Vppz3KrFCz5tMw0AL/p2lJ7caZXYRUAuZWEQbHBhrClduPsdpmx9rIht /T6wywFLTZPAi3rE19chnsPy7Ob5atkRwHyFk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:references:mime-version:in-reply-to :content-type:content-transfer-encoding:message-id:cc:x-mailer:from :subject:date:to:x-gm-message-state; bh=hc13t3TfHvkmGMTtMZNzb6cAKtbAoYcvVAImlQaw7Lg=; b=GBYrilmdSFXYPvugmkjyRvHtz7cSyxDJNLUBIHNMqgYz9XZmCPgh1gv6HxuDl6Xf86 elQrUPNkKems51jTGdkBwVOiJ/RG/Fv3tw/gUkmTfyGHTcVAvZOcoAYEIlqonuVICE5J XySPaUtpETDWqF6WpaSxzEA7YNrt5orluFTI8GHnhHQE9mOYEEpJtMsa30e0rq6mBJZN BrZK7kVWQX0Br4nWUcr1w0y7Ki9JYVTQfLqpLWqK8oCpZNfe9tEQc/5m0spDGOTu2Dcw 9s+mL6n5UdZq1YjCstDgEINS/Vtm5DyZukB0xE9Rp5ifM65HAUIGgCRi0x9lyXBwCOei ESIw==
X-Received: by 10.66.82.200 with SMTP id k8mr46432976pay.56.1360630949843; Mon, 11 Feb 2013 17:02:29 -0800 (PST)
X-Received: by 10.66.82.200 with SMTP id k8mr46432932pay.56.1360630949491; Mon, 11 Feb 2013 17:02:29 -0800 (PST)
Received: from [192.168.0.17] (c-67-183-80-15.hsd1.wa.comcast.net. [67.183.80.15]) by mx.google.com with ESMTPS id g2sm14655586pav.2.2013.02.11.17.02.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Feb 2013 17:02:28 -0800 (PST)
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com> <5112AE0B.1080501@mitre.org>  <5113C3AA.1040701@mitre.org>  <5113DDB2.7060805@mitre.org>  <51196777.6000502@mitre.org> 
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: multipart/alternative; boundary=Apple-Mail-08DD9270-46F8-460D-9FAF-F98161A4D6F8
Content-Transfer-Encoding: 7bit
Message-Id: 
X-Mailer: iPad Mail (10B141)
From: Richard Harrington 
Date: Mon, 11 Feb 2013 17:02:23 -0800
To: Prabath Siriwardena 
X-Gm-Message-State: ALoCoQkJUC/sajcCkxZTU6DeB/SF60xgAS7EWAqGoBNmLx2+QIOeNmMAed59XkEdrzOasx1wJvLosMEqzyClUWsfl8M2yL4s95lsYgHOxLRiTOF+3376b1DlOXyG4DUJs8B9PmI4fyBKldPhNHoc4FrkHDjOcV0LOg==
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 01:02:32 -0000

--Apple-Mail-08DD9270-46F8-460D-9FAF-F98161A4D6F8
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Have you considered "status" instead of "valid"?  It could have values like "=
active", "expired", and "revoked".

Is it worthwhile including the status of the client also?  For example, a cl=
ient application could be disabled, temporarily or permanently, and thus dis=
abling its access tokens as well.

On Feb 11, 2013, at 1:56 PM, Prabath Siriwardena  wrote:

> I guess confusion is with 'valid' parameter is in the response..
>=20
> I thought this will be helpful to standardize the communication between Re=
source Server and the Authorization Server..
>=20
> I would suggest we completely remove "valid" from the response - or define=
 it much clearly..
>=20
> May be can add "revoked" with a boolean attribute..
>=20
> Thanks & regards,
> -Prabath
>=20
> On Tue, Feb 12, 2013 at 3:19 AM, Justin Richer  wrote:
>>=20
>> On 02/08/2013 12:51 AM, Prabath Siriwardena wrote:
>>> Hi Justin,
>>>=20
>>> I have couple of questions related to "valid" parameter...
>>>=20
>>> This endpoint can be invoked by the Resource Server in runtime...
>>=20
>> That's correct.
>>=20
>>=20
>>>=20
>>> In that case what is exactly meant by the "resource_id" in request ?
>>=20
>> The resource_id field is a service-specific string that basically lets th=
e resource server provide some context to the request to the auth server. Th=
ere have been some other suggestions like client IP address, but I wanted to=
 put this one in because it seemed to be a common theme. The client is tryin=
g to do *something* with the token, after all, and the rights, permissions, a=
nd metadata associated with the token could change based on that. Since the I=
ntrospection endpoint is all about getting that metadata back to the PR, thi=
s seemed like a good idea.
>>=20
>>=20
>>>=20
>>> IMO a token to be valid depends on set of criteria based on it's type..
>>>=20
>>> For a Bearer token..
>>>=20
>>> 1. Token should not be expired
>>> 2. Token should not be revoked.
>>> 3. The scope the token issued should match with the scope required for t=
he resource.
>>>=20
>>> For a MAC token...
>>>=20
>>> 1. Token not expired (mac id)
>>> 2. Token should not be revoked
>>> 3. The scope the token issued should match with the scope required for t=
he resource.
>>> 4. HMAC check should be valid
>>>=20
>>> There are similar conditions for SAML bearer too..
>>=20
>> This isn't really true. The SAML bearer token is fully self-contained and=
 doesn't change based on other parameters in the message, unlike MAC. Same w=
ith JWT. When it hands a SAML or JWT token to the AS, the PR has given *ever=
ything* the server needs to check that token's validity and use.=20
>>=20
>> MAC signatures change with every message, and they're done across several=
 components of the HTTP message. Therefor, the HMAC check for MAC style toke=
ns will still need to be done by the protected resource. Introspection would=
 help in the case that the signature validated just fine, but the token migh=
t have expired. Or you need to know what scopes apply. Introspection isn't t=
o fully validate the call to the protected resource -- if that were the case=
, the PR would have to send some kind of encapsulated version of the origina=
l request. Otherwise, the AS won't have all of the information it needs to c=
heck the MAC.
>>=20
>>=20
>> I think what you're describing is ultimately *not* what the introspection=
 endpoint is intended to do. If that's unclear from the document, can you pl=
ease suggest text that would help clear the use case up? I wouldn't want it t=
o be ambiguous.
>>=20
>>  -- Justin
>>=20
>>=20
>>>=20
>>> Thanks & regards,
>>> -Prabath
>>>=20
>>>=20
>>> On Thu, Feb 7, 2013 at 10:30 PM, Justin Richer  wrote=
:
>>>> It validates the token, which would be either the token itself in the c=
ase of Bearer or the token "id" part of something more complex like MAC. It d=
oesn't directly validate the usage of the token, that's still up to the PR t=
o do that.
>>>>=20
>>>> I nearly added a "token type" field in this draft, but held back becaus=
e there are several kinds of "token type" that people talk about in OAuth. Fi=
rst, there's "Bearer" vs. "MAC" vs. "HOK", or what have you. Then within Bea=
rer you have "JWT" or "SAML" or "unstructured blob". Then you've also got "a=
ccess" vs. "refresh" and other flavors of token, like the id_token in OpenID=
 Connect.=20
>>>>=20
>>>> Thing is, the server running the introspection endpoint will probably k=
now *all* of these. But should it tell the client? If so, which of the three=
, and what names should the fields be?
>>>>=20
>>>>  -- Justin
>>>>=20
>>>>=20
>>>> On 02/07/2013 11:26 AM, Prabath Siriwardena wrote:
>>>>> Okay.. I was thinking this could be used as a way to validate the toke=
n as well. BTW even in this case shouldn't communicate the type of token to A=
S? For example in the case of SAML profile - it could be SAML token..
>>>>>=20
>>>>> Thanks & regards,
>>>>> -Prabath
>>>>>=20
>>>>> On Thu, Feb 7, 2013 at 8:39 PM, Justin Richer  wrot=
e:
>>>>>> "valid" might not be the best term, but it's meant to be a field wher=
e the server says "yes this token is still good" or "no this token isn't goo=
d anymore". We could instead do this with HTTP codes or something but I went=
 with a pure JSON response.
>>>>>>=20
>>>>>>  -- Justin
>>>>>>=20
>>>>>>=20
>>>>>> On 02/06/2013 10:47 PM, Prabath Siriwardena wrote:
>>>>>>> Hi Justin,
>>>>>>>=20
>>>>>>> I believe this is addressing one of the key missing part in OAuth 2.=
0...
>>>>>>>=20
>>>>>>> One question - I guess this was discussed already...
>>>>>>>=20
>>>>>>> In the spec - in the introspection response it has the attribute "va=
lid" - this is basically the validity of the token provided in the request.
>>>>>>>=20
>>>>>>> Validation criteria depends on the token and well as token type ( Be=
arer, MAC..).
>>>>>>>=20
>>>>>>> In the spec it seems like it's coupled with Bearer token type... But=
 I guess, by adding "token_type" to the request we can remove this dependenc=
y.
>>>>>>>=20
>>>>>>> WDYT..?
>>>>>>>=20
>>>>>>> Thanks & regards,
>>>>>>> -Prabath=20
>>>>>>>=20
>>>>>>> On Thu, Feb 7, 2013 at 12:54 AM, Justin Richer  w=
rote:
>>>>>>>> Updated introspection draft based on recent comments. Changes inclu=
de:
>>>>>>>>=20
>>>>>>>>  - "scope" return parameter now follows RFC6749 format instead of J=
SON array
>>>>>>>>  - "subject" -> "sub", and "audience" -> "aud", to be parallel with=
 JWT claims
>>>>>>>>  - clarified what happens if the authentication is bad
>>>>>>>>=20
>>>>>>>>  -- Justin
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> -------- Original Message --------
>>>>>>>> Subject:	New Version Notification for draft-richer-oauth-int=
rospection-02.txt
>>>>>>>> Date:	Wed, 6 Feb 2013 11:24:20 -0800
>>>>>>>> From:	
>>>>>>>> To:	
>>>>>>>>=20
>>>>>>>> A new version of I-D, draft-richer-oauth-introspection-02.txt
>>>>>>>> has been successfully submitted by Justin Richer and posted to the
>>>>>>>> IETF repository.
>>>>>>>>=20
>>>>>>>> Filename:	 draft-richer-oauth-introspection
>>>>>>>> Revision:	 02
>>>>>>>> Title:		 OAuth Token Introspection
>>>>>>>> Creation date:	 2013-02-06
>>>>>>>> WG ID:		 Individual Submission
>>>>>>>> Number of pages: 6
>>>>>>>> URL:             http://www.ietf.org/internet-drafts/draft-richer-o=
auth-introspection-02.txt
>>>>>>>> Status:          http://datatracker.ietf.org/doc/draft-richer-oauth=
-introspection
>>>>>>>> Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-intr=
ospection-02
>>>>>>>> Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-richer-oa=
uth-introspection-02
>>>>>>>>=20
>>>>>>>> Abstract:
>>>>>>>>    This specification defines a method for a client or protected
>>>>>>>>    resource to query an OAuth authorization server to determine met=
a-
>>>>>>>>    information about an OAuth token.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>                                                                    =
              =20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> The IETF Secretariat
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> OAuth mailing list
>>>>>>>> OAuth@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> --=20
>>>>>>> Thanks & Regards,
>>>>>>> Prabath
>>>>>>>=20
>>>>>>> Mobile : +94 71 809 6732=20
>>>>>>>=20
>>>>>>> http://blog.facilelogin.com
>>>>>>> http://RampartFAQ.com
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> --=20
>>>>> Thanks & Regards,
>>>>> Prabath
>>>>>=20
>>>>> Mobile : +94 71 809 6732=20
>>>>>=20
>>>>> http://blog.facilelogin.com
>>>>> http://RampartFAQ.com
>>>=20
>>>=20
>>>=20
>>> --=20
>>> Thanks & Regards,
>>> Prabath
>>>=20
>>> Mobile : +94 71 809 6732=20
>>>=20
>>> http://blog.facilelogin.com
>>> http://RampartFAQ.com
>=20
>=20
>=20
> --=20
> Thanks & Regards,
> Prabath
>=20
> Mobile : +94 71 809 6732=20
>=20
> http://blog.facilelogin.com
> http://RampartFAQ.com
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-08DD9270-46F8-460D-9FAF-F98161A4D6F8
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit

Have you considered "status" instead of "valid"?  It could have values like "active", "expired", and "revoked".

Is it worthwhile including the status of the client also?  For example, a client application could be disabled, temporarily or permanently, and thus disabling its access tokens as well.

On Feb 11, 2013, at 1:56 PM, Prabath Siriwardena <prabath@wso2.com> wrote:

I guess confusion is with 'valid' parameter is in the response..
I thought this will be helpful to standardize the communication between Resource Server and the Authorization Server..

I would suggest we completely remove "valid" from the response - or define it much clearly..

May be can add "revoked" with a boolean attribute..

Thanks & regards,
-Prabath

On Tue, Feb 12, 2013 at 3:19 AM, Justin Richer <jricher@mitre.org> wrote:

    On 02/08/2013 12:51 AM, Prabath
      Siriwardena wrote:

      Hi Justin,

      I have couple of questions related to "valid" parameter...

      This endpoint can be invoked by the Resource Server in
        runtime...

    That's correct.

      In that case what is exactly meant by the "resource_id" in
        request ?

    The resource_id field is a service-specific string that basically
    lets the resource server provide some context to the request to the
    auth server. There have been some other suggestions like client IP
    address, but I wanted to put this one in because it seemed to be a
    common theme. The client is trying to do *something* with the token,
    after all, and the rights, permissions, and metadata associated with
    the token could change based on that. Since the Introspection
    endpoint is all about getting that metadata back to the PR, this
    seemed like a good idea.

      IMO a token to be valid depends on set of criteria based on
        it's type..

      For a Bearer token..

      1. Token should not be expired
      2. Token should not be revoked.
      3. The scope the token issued should match with the scope
        required for the resource.

      For a MAC token...

      1. Token not expired (mac id)
      2. Token should not be revoked
      3. The scope the token issued should match with the scope
        required for the resource.
      4. HMAC check should be valid

      There are similar conditions for SAML bearer too..

    This isn't really true. The SAML bearer token is fully
    self-contained and doesn't change based on other parameters in the
    message, unlike MAC. Same with JWT. When it hands a SAML or JWT
    token to the AS, the PR has given *everything* the server needs to
    check that token's validity and use. 

    MAC signatures change with every message, and they're done across
    several components of the HTTP message. Therefor, the HMAC check for
    MAC style tokens will still need to be done by the protected
    resource. Introspection would help in the case that the signature
    validated just fine, but the token might have expired. Or you need
    to know what scopes apply. Introspection isn't to fully validate the
    call to the protected resource -- if that were the case, the PR
    would have to send some kind of encapsulated version of the original
    request. Otherwise, the AS won't have all of the information it
    needs to check the MAC.

    I think what you're describing is ultimately *not* what the
    introspection endpoint is intended to do. If that's unclear from the
    document, can you please suggest text that would help clear the use
    case up? I wouldn't want it to be ambiguous.

     -- Justin

      Thanks & regards,
      -Prabath

        On Thu, Feb 7, 2013 at 10:30 PM, Justin
          Richer <jricher@mitre.org>
          wrote:

             It validates the
              token, which would be either the token itself in the case
              of Bearer or the token "id" part of something more complex
              like MAC. It doesn't directly validate the usage of the
              token, that's still up to the PR to do that.

              I nearly added a "token type" field in this draft, but
              held back because there are several kinds of "token type"
              that people talk about in OAuth. First, there's "Bearer"
              vs. "MAC" vs. "HOK", or what have you. Then within Bearer
              you have "JWT" or "SAML" or "unstructured blob". Then
              you've also got "access" vs. "refresh" and other flavors
              of token, like the id_token in OpenID Connect. 

              Thing is, the server running the introspection endpoint
              will probably know *all* of these. But should it tell the
              client? If so, which of the three, and what names should
              the fields be?

                   -- Justin

                  On 02/07/2013 11:26 AM, Prabath Siriwardena
                    wrote:

                   Okay.. I was thinking this
                    could be used as a way to validate the token as
                    well. BTW even in this case shouldn't communicate
                    the type of token to AS? For example in the case of
                    SAML profile - it could be SAML token..

                    Thanks & regards,
                    -Prabath

                      On Thu, Feb 7, 2013 at
                        8:39 PM, Justin Richer <jricher@mitre.org>
                        wrote:

                           "valid"
                            might not be the best term, but it's meant
                            to be a field where the server says "yes
                            this token is still good" or "no this token
                            isn't good anymore". We could instead do
                            this with HTTP codes or something but I went
                            with a pure JSON response.

                                 -- Justin

                                On 02/06/2013 10:47 PM, Prabath
                                  Siriwardena wrote:

                                 Hi Justin,

                                  I believe this is addressing one
                                    of the key missing part in OAuth
                                    2.0...

                                  One question - I guess this was
                                    discussed already...

                                  In the spec - in the
                                    introspection response it has the
                                    attribute "valid" - this is
                                    basically the validity of the token
                                    provided in the request.

                                  Validation criteria depends on
                                    the token and well as token type (
                                    Bearer, MAC..).

                                  In the spec it seems like it's
                                    coupled with Bearer token type...
                                    But I guess, by adding "token_type"
                                    to the request we can remove this
                                    dependency.

                                  WDYT..?

                                  Thanks & regards,
                                  -Prabath 

                                    On Thu, Feb
                                      7, 2013 at 12:54 AM, Justin Richer
                                      <jricher@mitre.org>
                                      wrote:

                                         Updated
                                          introspection draft based on
                                          recent comments. Changes
                                          include:

                                           - "scope" return parameter
                                          now follows RFC6749 format
                                          instead of JSON array

                                           - "subject" -> "sub", and
                                          "audience" -> "aud", to be
                                          parallel with JWT claims

                                           - clarified what happens if
                                          the authentication is bad

                                           -- Justin

                                            -------- Original Message
                                            --------

                                                  Subject:

                                                  New Version
                                                    Notification for
                                                    draft-richer-oauth-introspection-02.txt

                                                  Date:

                                                  Wed, 6 Feb 2013
                                                    11:24:20 -0800

                                                  From:

                                                  <internet-drafts@ietf.org>

                                                  To:

                                                  <jricher@mitre.org>

                                            A new version of I-D, draft-richer-oauth-introspection-02.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 02
Title:		 OAuth Token Introspection
Creation date:	 2013-02-06
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.

The IETF Secretariat

_______________________________________________

                                        OAuth mailing list

                                        OAuth@ietf.org

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

                                    -- 

                                    Thanks & Regards,

                                    Prabath

                                    Mobile : +94 71 809 6732 

                                      http://blog.facilelogin.com

                                      http://RampartFAQ.com

                      -- 

                      Thanks & Regards,

                      Prabath

                      Mobile : +94 71
                          809 6732 

                        http://blog.facilelogin.com

                        http://RampartFAQ.com

        -- 

        Thanks & Regards,

        Prabath

        Mobile : +94 71 809 6732 

          http://blog.facilelogin.com

          http://RampartFAQ.com

-- 
Thanks & Regards,
Prabath
Mobile : +94 71 809 6732 

http://blog.facilelogin.com

http://RampartFAQ.com

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-08DD9270-46F8-460D-9FAF-F98161A4D6F8--

From Michael.Jones@microsoft.com  Mon Feb 11 17:13:00 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3ED21F86CE for ; Mon, 11 Feb 2013 17:13:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Level: 
X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpvIotiM3zTe for ; Mon, 11 Feb 2013 17:12:59 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7F72E21F85AE for ; Mon, 11 Feb 2013 17:12:59 -0800 (PST)
Received: from BY2FFO11FD011.protection.gbl (10.1.15.202) by BY2FFO11HUB029.protection.gbl (10.1.14.114) with Microsoft SMTP Server (TLS) id 15.0.620.12; Tue, 12 Feb 2013 01:12:57 +0000
Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD011.mail.protection.outlook.com (10.1.14.129) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Tue, 12 Feb 2013 01:12:57 +0000
Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.232]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Tue, 12 Feb 2013 01:12:53 +0000
From: Mike Jones 
To: Justin Richer , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Registration: HAL _links structure and client self-URL
Thread-Index: AQHOCJz95koRvM6/ckWHt+2WoBlYzJh1aMDA
Date: Tue, 12 Feb 2013 01:12:52 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436743E33D@TK5EX14MBXC285.redmond.corp.microsoft.com>
References: <51195F3D.1050006@mitre.org>
In-Reply-To: <51195F3D.1050006@mitre.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.76]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(55885001)(199002)(189002)(13464002)(53806001)(31966008)(51856001)(79102001)(54316002)(54356001)(80022001)(77982001)(49866001)(4396001)(47736001)(50466001)(50986001)(66066001)(16406001)(59766001)(5343635001)(56776001)(63696002)(76482001)(23726001)(5343655001)(65816001)(20776003)(47776003)(46406002)(46102001)(33656001)(55846006)(47446002)(56816002)(47976001)(74662001)(74502001)(15202345001)(44976002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB029; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0755F54DD9
Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 01:13:00 -0000

It seems like significant overkill, bordering on silliness, to use the synt=
ax
  _links: {
    "self": {
      "href":
          "https://server.example.com/register/s6BhdRkqt3"
      }
  }
to represent a value that could be more straightforwardly represented as:
  "registration_access_url": "https://server.example.com/register/s6BhdRkqt=
3"

Even some of the advocates for it have called it "pedantic".  I believe tha=
t most developers would have less charitable things to say about it, and wo=
uld wonder why we're trying to foist needless complexity on them.

I'll also point out that this syntax is based upon an expired individual su=
bmission draft http://tools.ietf.org/html/draft-kelly-json-hal-03 that is n=
ot in any working group.  I don't believe we should take a dependence on th=
is draft or this syntax.

Occam's razor says that this isn't needed.

				-- Mike

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J=
ustin Richer
Sent: Monday, February 11, 2013 1:15 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Registration: HAL _links structure and client self-URL

Draft -05 of OAuth Dynamic Client Registration [1] returns a URL pointer fo=
r the client to perform update and secret rotation actions. This functional=
ity arose from discussions on the list about moving towards a more RESTful =
pattern, and Nat Sakimura proposed this approach in the OpenID Connect Work=
ing Group. This URL may be distinct from the Client Registration Endpoint U=
RL, but draft -05 makes no promises as to its content, form, or structure, =
though it does contain implementor's notes on possible methods.

Two questions arise from this change:
  - The semantics of returning the client manipulation URL
  - The syntax (derived from HAL for JSON [2], an individual I-D
submission)

On semantics:

Pro:
  - The server has flexibility on how to define the "update" endpoint, send=
ing all clients to one URL, sending different clients to different URLs, or=
 sending clients to a URL with a baked-in query parameter
  - The client can take the URL as-is and use it for all management operati=
ons (ie, it doesn't have to generate or compose the URL based on component =
parts)

Con:
  - The client must remember one more piece of information from the server =
at runtime if it wants to do manipulation and management of itself at the s=
erver (in addition to client_id, client_secret, registration_access_token, =
and others)

Alternatives include specifying a URL pattern for the server to use and all=
 clients to follow, specifying a query parameter for the update action, and=
 specifying a separate endpoint entirely and using the presence of items su=
ch as client_id and the registration access token to differentiate the requ=
ests. Note that *all* of these alternatives can be accommodated using the s=
emantics described above, with the same actions on the client's part.

On syntax:

Pro:
  - Follows the designs of RFC5988 for link relations
  - The HAL format is general, and allows for all kinds of other informatio=
n to be placed inside the _links structure
  - Allows for full use of the JSON object to specify advanced operations o=
n the returned endpoint if desired

Con:
  - The rest of OAuth doesn't follow link relation guidelines (though it's =
been brought up)
  - The HAL format is general, and allows for all kinds of other informatio=
n to be placed inside the _links structure
  - The HAL-JSON document is an expired individual I-D, and it's unclear wh=
at wider adoption looks like right now

Alternatives include returning the URL as a separate data member (registrat=
ion_update_url), using HTTP headers, or using JSON Schema.

  -- Justin

[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
[2] http://tools.ietf.org/html/draft-kelly-json-hal-03
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

From Michael.Jones@microsoft.com  Mon Feb 11 17:19:49 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1026E21F8767 for ; Mon, 11 Feb 2013 17:19:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Level: 
X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gj3HIotFXtpt for ; Mon, 11 Feb 2013 17:19:48 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1FBCC21F875C for ; Mon, 11 Feb 2013 17:19:47 -0800 (PST)
Received: from BY2FFO11FD006.protection.gbl (10.1.15.202) by BY2FFO11HUB014.protection.gbl (10.1.14.86) with Microsoft SMTP Server (TLS) id 15.0.620.12; Tue, 12 Feb 2013 01:19:46 +0000
Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD006.mail.protection.outlook.com (10.1.14.127) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Tue, 12 Feb 2013 01:19:45 +0000
Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.232]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Tue, 12 Feb 2013 01:18:39 +0000
From: Mike Jones 
To: Justin Richer , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Registration: Client secret rotation
Thread-Index: AQHOCJ0LDzoQT/UaG0SbLONUo4RclZh1a0HA
Date: Tue, 12 Feb 2013 01:18:39 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436743E371@TK5EX14MBXC285.redmond.corp.microsoft.com>
References: <51195F3F.7000704@mitre.org>
In-Reply-To: <51195F3F.7000704@mitre.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.76]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(55885001)(199002)(189002)(13464002)(63696002)(47446002)(47776003)(20776003)(53806001)(54316002)(76482001)(46102001)(46406002)(79102001)(65816001)(33656001)(44976002)(16406001)(80022001)(54356001)(56816002)(55846006)(5343655001)(51856001)(31966008)(66066001)(74662001)(4396001)(49866001)(23726001)(15202345001)(47736001)(50986001)(50466001)(47976001)(56776001)(74502001)(59766001)(77982001)(219293001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB014; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0755F54DD9
Subject: Re: [OAUTH-WG] Registration: Client secret rotation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 01:19:49 -0000

The rotate_secret operation was added to OpenID Connect Registration as a w=
orkaround to the fact that registration updates used to be authenticated us=
ing the client secret, so it seemed overly dangerous to have an update oper=
ation potentially return an updated secret and have the secret be lost due =
to communication problems - leaving the client stranded.  Since then, regis=
tration was changed to use a bearer token to authenticate update operations=
, and so this failure mode can't occur anymore.  It was an omission not to =
have deleted the unneeded operation then.

It's been deleted from OpenID Connect Registration and should likewise be d=
eleted from OAuth registration, since it is unneeded.  If a new client secr=
et is needed, there's nothing stopping the registration server from returni=
ng it in the result of an update operation.

				-- Mike

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J=
ustin Richer
Sent: Monday, February 11, 2013 1:15 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Registration: Client secret rotation

Draft -05 of OAuth Dynamic Client Registration [1] defines a means of the c=
lient requesting a new client_secret (if applicable) and a new registration=
_access_token. Client secrets MAY expire after some period of time, and thi=
s method allows for a refresh of that secret. Draft -00 defined no such ope=
ration, drafts -01 through -04 defined this operation in terms of the opera=
tion=3Drotate_secret parameter, and draft -05 defines it through a secondar=
y endpoint, the Client Secret Rotation Endpoint.=20
This raises several questions:

  - Should the client be allowed to request rotation of its secret?
  - Would a client ever take this action of its own accord?
  - Can a server rotate the secret of the client without the client asking?=
 (This seems to be an obvious "yes")

Alternatives that keep this functionality include defining the rotate_secre=
t operation in terms of an HTTP verb, a query parameter, or separate endpoi=
nt. Alternatively, we could drop the rotate_secret operation all together. =
If we do this, we have to decide if the client secret can still expire. If =
it can, then we need a way for the client to get this new secret through a =
means that doesn't require it to request a change in secret, such as sendin=
g it back as part of the client READ operation (see other thread on RESTful=
 verbs).

  -- Justin

[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

From Michael.Jones@microsoft.com  Mon Feb 11 17:26:43 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD0321F8767 for ; Mon, 11 Feb 2013 17:26:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Level: 
X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qU0qv8awwhGV for ; Mon, 11 Feb 2013 17:26:42 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.27]) by ietfa.amsl.com (Postfix) with ESMTP id 671A521F8756 for ; Mon, 11 Feb 2013 17:26:42 -0800 (PST)
Received: from BL2FFO11FD020.protection.gbl (10.173.161.201) by BL2FFO11HUB029.protection.gbl (10.173.161.53) with Microsoft SMTP Server (TLS) id 15.0.620.12; Tue, 12 Feb 2013 01:26:40 +0000
Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD020.mail.protection.outlook.com (10.173.161.38) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Tue, 12 Feb 2013 01:26:39 +0000
Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.232]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Tue, 12 Feb 2013 01:26:17 +0000
From: Mike Jones 
To: Justin Richer , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Registration: Endpoint Definition (& operation parameter)
Thread-Index: AQHOCJz1W98y3MnRnUubf+tH6SXawJh1bN2Q
Date: Tue, 12 Feb 2013 01:26:16 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436743E3DD@TK5EX14MBXC285.redmond.corp.microsoft.com>
References: <51195F39.3040809@mitre.org>
In-Reply-To: <51195F39.3040809@mitre.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.76]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464002)(199002)(189002)(55885001)(377454001)(51856001)(59766001)(46102001)(77982001)(63696002)(80022001)(74502001)(15202345001)(5343655001)(50466001)(53806001)(56776001)(50986001)(47776003)(55846006)(79102001)(74662001)(31966008)(47976001)(4396001)(54316002)(49866001)(47736001)(46406002)(33656001)(20776003)(76482001)(44976002)(23726001)(66066001)(47446002)(54356001)(65816001)(16406001)(56816002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB029; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0755F54DD9
Subject: Re: [OAUTH-WG] Registration: Endpoint Definition (& operation parameter)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 01:26:43 -0000

At most, there should be two endpoints - creation and management - for a cl=
ient, but the protocol should be structured such that they *can* be at the =
same URL, if the server so chooses.  A simple way to accomplish this is to =
require that the client_id value be provided as an input parameter on updat=
e operations.  Then for implementations that use a single endpoint, they ca=
n distinguish "create" and "update" operations on the management endpoint b=
y the presence or absence of the client_id value.

If you want to have separate endpoints and don't need the client_id because=
 you have somehow encoded it into the management endpoint URL, that's fine.=
  It still can serve as a useful cross-check that the client (or an attacke=
r) is requesting a change to a client that matches the bearer token used.  =
But including it is necessary for implementations that want to use a single=
 registration endpoint, rather than having a proliferation of per-client en=
dpoints.

BTW, just for the record, OAuth 2.0 uses the same endpoint for initial acce=
ss token requests and requests for refreshed access tokens - with the opera=
tions being distinguished by whether a refresh_token parameter is present. =
 So there's a useful OAuth precedent for doing things this way.

				-- Mike

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J=
ustin Richer
Sent: Monday, February 11, 2013 1:15 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Registration: Endpoint Definition (& operation paramete=
r)

Draft -05 of OAuth Dynamic Client Registration [1] defines three fundamenta=
l operations that a client can undertake: Client Registration, Client Updat=
e, and Secret Rotation. Each of these actions needs to be differentiated *s=
omehow* by the client and server as part of the protocol. Draft -00 defined=
 only the "register" operation, drafts -01 through -04 made use of an "oper=
ation" parameter on a single endpoint, which brought up a long discussion o=
n the list on whether or not that was an appropriate design. Draft -05 did =
away with the definition of the "operation" parameter on a single endpoint =
and instead opted for separating the base functionality into three differen=
t endpoints.

Pro:
  - Closer to RESTful semantics of having one URL for creation and another =
URL for management of an item (eg, most REST APIs use /object for creation =
and /object/object_id for manipulation)
  - The rest of OAuth (and its extensions) defines separate endpoints for d=
ifferent actions (Authorization, Token, Revocation, Introspection) as oppos=
ed to a single endpoint with a mode-switch parameter
  - Client doesn't have to generate a URL string for different endpoints by=
 combining parameters with a base URL

Con:
  - Not quite exactly RESTful as the spec doesn't dictate the client_id=20
be part of the update or rotate URL (though and implementor's note=20
suggests this)
  - Client has to track different URLs for different actions
  - Server must be able to differentiate actions based on these=20
different URLs.

Alternatives include using different HTTP verbs (see other thread) or=20
defining an operational switch parameter, like older drafts, on a single=20
endpoint URL. Another suggested alternative is to look for the presence=20
of certain parameters, such as client_id or the registration access=20
token, to indicate that a different operation is requested.

There's also question of whether the Secret Rotation action needs to=20
have its own endpoint, or if it can be collapsed into one of the others.=20
It has been suggested off-list that the secret rotation should never be=20
initiated by the Client but instead the client should simply request its=20
latest secret from the server through the update (or read) semantics.

  -- Justin

[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

From Michael.Jones@microsoft.com  Mon Feb 11 17:32:09 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9DE21F87A3 for ; Mon, 11 Feb 2013 17:32:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Level: 
X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-2xkepYov4E for ; Mon, 11 Feb 2013 17:32:08 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.25]) by ietfa.amsl.com (Postfix) with ESMTP id 633F521F8767 for ; Mon, 11 Feb 2013 17:32:08 -0800 (PST)
Received: from BL2FFO11FD012.protection.gbl (10.173.161.204) by BL2FFO11HUB030.protection.gbl (10.173.161.54) with Microsoft SMTP Server (TLS) id 15.0.620.12; Tue, 12 Feb 2013 01:32:07 +0000
Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD012.mail.protection.outlook.com (10.173.161.18) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Tue, 12 Feb 2013 01:32:06 +0000
Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.232]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Tue, 12 Feb 2013 01:31:20 +0000
From: Mike Jones 
To: Justin Richer , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Registration: RESTful client lifecycle management
Thread-Index: AQHOCJzxVGwYODuh3UmktcEEXHrfK5h1buhg
Date: Tue, 12 Feb 2013 01:31:20 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436743E41B@TK5EX14MBXC285.redmond.corp.microsoft.com>
References: <51195F36.6040705@mitre.org>
In-Reply-To: <51195F36.6040705@mitre.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.76]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(377454001)(13464002)(55885001)(47776003)(23726001)(46406002)(44976002)(51856001)(77982001)(5343655001)(74502001)(74662001)(47446002)(80022001)(59766001)(33656001)(53806001)(15202345001)(20776003)(54356001)(63696002)(76482001)(50466001)(47976001)(50986001)(49866001)(54316002)(56776001)(4396001)(55846006)(31966008)(47736001)(56816002)(46102001)(16406001)(79102001)(66066001)(65816001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB030; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0755F54DD9
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 01:32:09 -0000

I'm fine with the use of the different verbs, provided that the client_id i=
s present to distinguish between "register" and "update" operations for imp=
lementations that want to use it in that matter, as I'd previously written.=
  (*Your* implementation is free to not use this value, if you so choose, b=
ut it's useful for many.)

If that's not acceptable, then we should restore the "operation" parameter.

I will add that "register" should be the only required operation.  It's fin=
e to support others if needed in a particular context, but enabling registr=
ation of clients shouldn't require servers to also support changing them, g=
etting state about them, and deleting them.

				-- Mike

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J=
ustin Richer
Sent: Monday, February 11, 2013 1:15 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Registration: RESTful client lifecycle management

Draft -05 of OAuth Dynamic Client Registration [1] defines several operatio=
ns that the client can take on its behalf as part of the registration proce=
ss. These boil down to the basic CRUD operations that you find in many APIs=
: Create, Read, Update, Delete. Draft -00 defined only the "Create" operati=
on, draft -01 through -04 added the "Update"=20
operation, switched using the "operation=3D" parameter.

Following several suggestions to do so on the list, the -05 draft defines t=
hese operations in terms of a RESTful API for the client. Namely:

  - HTTP POST to registration endpoint =3D> Create (register) a new client
  - HTTP PUT to update endpoint (with registration_access_token) =3D> Updat=
e the registered information for this client
  - HTTP GET to update endpoint (with registration_access_token) =3D> read =
the registered information for this client
  - HTTP DELETE to update endpoint (with registration_access_token) =3D> De=
lete (unregister/de-provision) this client

The two main issues at stake here are: the addition of the READ and DELETE =
methods, and the use of HTTP verbs following a RESTful design philosophy.

Pro:
  - RESTful APIs (with HTTP verbs to differentiate functionality) are the n=
orm today
  - Full lifecycle management is common and is going to be expected by many=
 users of this protocol in the wild

Cons:
  - Update semantics are still under debate (full replace? patch?)
  - Somewhat increased complexity on the server to support all operations
  - Client has to understand all HTTP verbs for full access (though plain r=
egistration is just POST)

Alternatives include using an operational switch parameter (like the old=20
drafts), defining separate endpoints for every action, or doing all=20
operations on a single endpoint using verbs to switch.

  -- Justin

[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

From Michael.Jones@microsoft.com  Mon Feb 11 17:41:07 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F3121F86F2 for ; Mon, 11 Feb 2013 17:41:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.591
X-Spam-Level: 
X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrA+rfe3eBO9 for ; Mon, 11 Feb 2013 17:41:05 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.25]) by ietfa.amsl.com (Postfix) with ESMTP id EEFE121F86FA for ; Mon, 11 Feb 2013 17:41:01 -0800 (PST)
Received: from BL2FFO11FD020.protection.gbl (10.173.161.202) by BL2FFO11HUB037.protection.gbl (10.173.160.241) with Microsoft SMTP Server (TLS) id 15.0.620.12; Tue, 12 Feb 2013 01:40:59 +0000
Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD020.mail.protection.outlook.com (10.173.161.38) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Tue, 12 Feb 2013 01:40:59 +0000
Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.232]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0318.003; Tue, 12 Feb 2013 01:40:34 +0000
From: Mike Jones 
To: Justin Richer , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Recent changes to Registration
Thread-Index: AQHOCJxgG8ZC9nZAa0Shh+TKiEhAeJh1cG1A
Date: Tue, 12 Feb 2013 01:40:33 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436743E467@TK5EX14MBXC285.redmond.corp.microsoft.com>
References: <51195E50.1080103@mitre.org>
In-Reply-To: <51195E50.1080103@mitre.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.76]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(164054002)(52604002)(377454001)(189002)(199002)(13464002)(46406002)(77982001)(20776003)(51856001)(66066001)(56776001)(47776003)(54316002)(4396001)(63696002)(55846006)(65816001)(59766001)(76482001)(5343655001)(74502001)(80022001)(49866001)(50986001)(74662001)(47976001)(15202345001)(31966008)(53806001)(46102001)(56816002)(47446002)(33656001)(47736001)(50466001)(79102001)(54356001)(23726001)(16406001)(44976002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB037; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0755F54DD9
Subject: Re: [OAUTH-WG] Recent changes to Registration
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 01:41:07 -0000

Thanks for having these conversations, Justin.  It will be interesting to s=
ee how they go.

As a co-editor, given that I was surprised that these numerous breaking cha=
nges were checked in without me or the other editors being given a chance t=
o review them first, or for adequate discussion of them to occur by the wor=
king group, I would request that the default action for any of the changes =
made for which there isn't obvious consensus to keep be to back those break=
ing changes out before the submission deadline in two weeks.  Then we can s=
tart clean and only add changes once it's clear that doing so improves cons=
ensus.  (Obviously if a change appears to have been clearly accepted by the=
 working group, there's no reason to remove it.)

				Thanks,
				-- Mike

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J=
ustin Richer
Sent: Monday, February 11, 2013 1:11 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Recent changes to Registration

As many of you saw, last week I published a draft of the OAuth Dynamic Clie=
nt Registration spec [1] that made some fairly serious changes to how the p=
rotocol works. It was my intent to distill many threads of conversation her=
e on the list into a full, workable protocol with a concrete document that =
we could discuss. I believe that what I published did that, but I certainly=
 don't think that all of our work and discussion is done. It wasn't my inte=
nt to surprise people with the draft (apparently I really did!), nor was it=
 my intent to simply dictate where the spec was going without any input fro=
m the working group.

So to move the discussion forward in a very deliberate fashion, I'm going t=
o be starting a number of new threads for discussion on particular changes =
and components to this spec so that we can discuss things and decide as a w=
orking group what the best courses of action are. I'll lay out what the iss=
ues are, what -05 says today, what the options are as I see them, and we I =
think can go from there. The topics will be:

  - JSON Encoding
  - Endpoint Definition (& operation parameter)
  - HAL _links structure and client self-URL
  - RESTful client lifecycle management
  - Client secret rotation

If you want to talk about the overall design and philosophy of the Registra=
tion document, just reply to this email.

Of course, all of these interrelate in various ways, and everything must be=
 taken in the overall context, but I'm hoping that by splitting things up t=
his way we can focus the conversations better. I welcome all constructive d=
iscussion, debate, and input. As an editor, I am particularly grateful for =
anyone who wants to provide actual text for inclusion in the document itsel=
f, and any pointers to implemented code for any of this.

The deadline for IETF86 is two weeks from now, and I want to have a version=
 -06 or greater that incorporates all of the comments from these threads by=
 then.

  -- Justin

[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

From ve7jtb@ve7jtb.com  Mon Feb 11 17:42:35 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02CCC21F86F5 for ; Mon, 11 Feb 2013 17:42:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.788
X-Spam-Level: 
X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[AWL=0.211,  BAYES_00=-2.599, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zfwbL2xasGC for ; Mon, 11 Feb 2013 17:42:34 -0800 (PST)
Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id 21D9621F86F2 for ; Mon, 11 Feb 2013 17:42:34 -0800 (PST)
Received: by mail-qa0-f54.google.com with SMTP id hg5so1446407qab.13 for ; Mon, 11 Feb 2013 17:42:33 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=j5cFxkHY6NPM/uG3JYLWRXN6mRzfkGjDTio+ThQj7p8=; b=gBdYbI71ra/gSMmQDY9T7pJpmhw6BqXPblJIf1CsHlG/bGzIoHZovWKjyscoqCH8NQ 9P8RP1xf4YxJQ1sUtmledPG5r+2houGKkgpUA/PPMv3qKrg6qEhxB7K5guHPgBjkyW/U lbJQYopCGQXPAZKQtDkLyhwSBD2uinyzuy+O443l1TGbX0eo3tUCIRcCW6Qdgl2QLTUt zQnGoMi0n5zltTDgwZg+3xV1eDvLTqLquudsSQvmZl5rkAAm+rptSvRvgFI7Af4udpfS 0NqxD5+9wKko6zpIPrBYwu8IemOlhx4neZCEI+2XE/OgSpAdb2AnvnUeSIXo3kK782HU qklA==
X-Received: by 10.229.179.18 with SMTP id bo18mr1485794qcb.24.1360633353595; Mon, 11 Feb 2013 17:42:33 -0800 (PST)
Received: from [192.168.1.213] (190-20-23-212.baf.movistar.cl. [190.20.23.212]) by mx.google.com with ESMTPS id o5sm16097763qao.12.2013.02.11.17.42.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Feb 2013 17:42:32 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436743E371@TK5EX14MBXC285.redmond.corp.microsoft.com>
Date: Mon, 11 Feb 2013 22:42:30 -0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <7FB7A108-EA9E-429A-BD86-7E09EA206748@ve7jtb.com>
References: <51195F3F.7000704@mitre.org> <4E1F6AAD24975D4BA5B16804296739436743E371@TK5EX14MBXC285.redmond.corp.microsoft.com>
To: Mike Jones 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQnyDFNc+3AM04ZALzESxO3uUPL0FZ8FL50frURe8DUDOxWADZUTFAaxQD+jP1OH/zUPbGkb
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: Client secret rotation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 01:42:35 -0000

OAuth doesn't say anything about client secrets other than they are =
provisioned in a magic realm outside the OAuth spec (Getting in the mood =
for the next IETF).

Rotating client secrets was something I made up for connect because it =
seemed like a good idea at the time given that someone breaking in to =
the registration endpoint could take over a connection.

We later separated the authentication to the token endpoint from the =
registration endpoint,in what I think was a good move.

It is sort of up to the authorization server to make decisions about =
rotating client secrets, I expect that in the real world a client would =
try access ing the token endpoint and get back a invalid_client error =
response and then heck it's registration to see if the client_secret has =
changed.

I suppose that a client could request rotating its secret if it thinks =
it has been compromised,  however the compromiser is more likely to =
quickly change the secret to lock out the legitimate clients before the =
good one notices.    I think the client wanting to rotate is enough of a =
edge case that it could deal with it out of band.

Letting the server rotate the client secret according to what ever =
policy it decides is best is probably safest.

We didn't have anything for rotating the access token.  I suspect that =
rotating it under the clients control is going to create as many =
problems as it solves.

If you want to rotate it,  make it a refresh token that is issues and =
use OAuth to provide access tokens from the token endpoint.   Creating a =
new endpoint to duplicate existing OAuth functionality is overkill.

John B.
On 2013-02-11, at 10:18 PM, Mike Jones  =
wrote:

> The rotate_secret operation was added to OpenID Connect Registration =
as a workaround to the fact that registration updates used to be =
authenticated using the client secret, so it seemed overly dangerous to =
have an update operation potentially return an updated secret and have =
the secret be lost due to communication problems - leaving the client =
stranded.  Since then, registration was changed to use a bearer token to =
authenticate update operations, and so this failure mode can't occur =
anymore.  It was an omission not to have deleted the unneeded operation =
then.
>=20
> It's been deleted from OpenID Connect Registration and should likewise =
be deleted from OAuth registration, since it is unneeded.  If a new =
client secret is needed, there's nothing stopping the registration =
server from returning it in the result of an update operation.
>=20
> 				-- Mike
>=20
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf =
Of Justin Richer
> Sent: Monday, February 11, 2013 1:15 PM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Registration: Client secret rotation
>=20
> Draft -05 of OAuth Dynamic Client Registration [1] defines a means of =
the client requesting a new client_secret (if applicable) and a new =
registration_access_token. Client secrets MAY expire after some period =
of time, and this method allows for a refresh of that secret. Draft -00 =
defined no such operation, drafts -01 through -04 defined this operation =
in terms of the operation=3Drotate_secret parameter, and draft -05 =
defines it through a secondary endpoint, the Client Secret Rotation =
Endpoint.=20
> This raises several questions:
>=20
>  - Should the client be allowed to request rotation of its secret?
>  - Would a client ever take this action of its own accord?
>  - Can a server rotate the secret of the client without the client =
asking? (This seems to be an obvious "yes")
>=20
> Alternatives that keep this functionality include defining the =
rotate_secret operation in terms of an HTTP verb, a query parameter, or =
separate endpoint. Alternatively, we could drop the rotate_secret =
operation all together. If we do this, we have to decide if the client =
secret can still expire. If it can, then we need a way for the client to =
get this new secret through a means that doesn't require it to request a =
change in secret, such as sending it back as part of the client READ =
operation (see other thread on RESTful verbs).
>=20
>  -- Justin
>=20
>=20
> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
> _______________________________________________
> 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

From ve7jtb@ve7jtb.com  Mon Feb 11 17:51:57 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03F5121F876E for ; Mon, 11 Feb 2013 17:51:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.111
X-Spam-Level: 
X-Spam-Status: No, score=-3.111 tagged_above=-999 required=5 tests=[AWL=0.488,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mKhQT41GG69 for ; Mon, 11 Feb 2013 17:51:53 -0800 (PST)
Received: from mail-qe0-f41.google.com (mail-qe0-f41.google.com [209.85.128.41]) by ietfa.amsl.com (Postfix) with ESMTP id 10D1721F8632 for ; Mon, 11 Feb 2013 17:51:52 -0800 (PST)
Received: by mail-qe0-f41.google.com with SMTP id 7so2896686qeb.28 for ; Mon, 11 Feb 2013 17:51:51 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=8+25BVOMsBQX7EfSecgQpEuIz8yg7kkW9uxeXXgxpOs=; b=h2jB/sJtNpIjPMXu5oxAG36S+WULyWh2IqsS0Cc/mXcfcGptlKKhYjIA5tRm+DUaut sL844bpjVS0WnevIIXGP3QNb8ueRD39hhj+PIzH/hPE4J4a9gkgRkO7gsNdTqQJuj9UF dT5zt2y9SQ2Zlg36VhP+ejaYqPsfoPgzvZVMBzLb6WrakUBjIDUgmcRk05JDGCzHSEwI 1Ghjw/60++dE4nGKSfyCav9Wz8zoB5p4LfKKaPb5HRxVyYAwcDvVdrA22dQ1Tkngc07B XRZ0eV4mxMZwOl4Nd5hhOy0v7n3TfAYogo25kpYlT9KWNSmkMkfcpz07Udkijg5B6FyT 9+gA==
X-Received: by 10.224.96.4 with SMTP id f4mr6312646qan.79.1360633911438; Mon, 11 Feb 2013 17:51:51 -0800 (PST)
Received: from [192.168.1.213] (190-20-23-212.baf.movistar.cl. [190.20.23.212]) by mx.google.com with ESMTPS id u8sm15383037qeu.2.2013.02.11.17.51.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Feb 2013 17:51:49 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <51195F36.6040705@mitre.org>
Date: Mon, 11 Feb 2013 22:51:46 -0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com>
References: <51195F36.6040705@mitre.org>
To: Justin Richer 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQlWoW+sXC1GMu517bzjBCugE3F4ByNtuKMHAh0itnM7IGpW2/Uk8v6MGuLzQE2/mQbIZW22
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 01:51:57 -0000

I would always include the client_id on update.

I think it is also us full to have other tokens used at the update =
endpoint.  I can see the master token used to update all the clients it =
has registered as part of API management.=20
Relying on the registration_access_token is probably a design that will =
cause trouble down the road.

I think GET and POST are relatively clear.   I don't know about =
expelling PUT to developers.  I think POST with a client_id to a =
(separate discussion) update_uri works without restricting it to PUT.

I think DELETE needs to be better understood.   I think a status that =
can be set for client lifecycle is better than letting a client delete a =
entry.   =20
In some cases there will be more than one instance of a client and =
letting them know they have been turned off for a reason is better than =
making there registration disappear. =20
So for the moment I would levee out DELETE.

John B.

On 2013-02-11, at 6:14 PM, Justin Richer  wrote:

> Draft -05 of OAuth Dynamic Client Registration [1] defines several =
operations that the client can take on its behalf as part of the =
registration process. These boil down to the basic CRUD operations that =
you find in many APIs: Create, Read, Update, Delete. Draft -00 defined =
only the "Create" operation, draft -01 through -04 added the "Update" =
operation, switched using the "operation=3D" parameter.
>=20
> Following several suggestions to do so on the list, the -05 draft =
defines these operations in terms of a RESTful API for the client. =
Namely:
>=20
> - HTTP POST to registration endpoint =3D> Create (register) a new =
client
> - HTTP PUT to update endpoint (with registration_access_token) =3D> =
Update the registered information for this client
> - HTTP GET to update endpoint (with registration_access_token) =3D> =
read the registered information for this client
> - HTTP DELETE to update endpoint (with registration_access_token) =3D> =
Delete (unregister/de-provision) this client
>=20
> The two main issues at stake here are: the addition of the READ and =
DELETE methods, and the use of HTTP verbs following a RESTful design =
philosophy.
>=20
> Pro:
> - RESTful APIs (with HTTP verbs to differentiate functionality) are =
the norm today
> - Full lifecycle management is common and is going to be expected by =
many users of this protocol in the wild
>=20
> Cons:
> - Update semantics are still under debate (full replace? patch?)
> - Somewhat increased complexity on the server to support all =
operations
> - Client has to understand all HTTP verbs for full access (though =
plain registration is just POST)
>=20
>=20
> Alternatives include using an operational switch parameter (like the =
old drafts), defining separate endpoints for every action, or doing all =
operations on a single endpoint using verbs to switch.
>=20
> -- Justin
>=20
> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From torsten@lodderstedt.net  Mon Feb 11 23:17:27 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA7A121F8C3C for ; Mon, 11 Feb 2013 23:17:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.234
X-Spam-Level: 
X-Spam-Status: No, score=-0.234 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQ6MBFqAjO6P for ; Mon, 11 Feb 2013 23:17:26 -0800 (PST)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7511621F8C74 for ; Mon, 11 Feb 2013 23:17:26 -0800 (PST)
Received: from [80.187.107.6] (helo=[192.168.44.16]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1U5A7F-0008NM-KN; Tue, 12 Feb 2013 08:17:23 +0100
References: <51195F39.3040809@mitre.org> <4E1F6AAD24975D4BA5B16804296739436743E3DD@TK5EX14MBXC285.redmond.corp.microsoft.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436743E3DD@TK5EX14MBXC285.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: 
X-Mailer: iPad Mail (10B141)
From: Torsten Lodderstedt 
Date: Tue, 12 Feb 2013 08:17:13 +0100
To: Mike Jones 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: Endpoint Definition (& operation parameter)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 07:17:27 -0000

Hi Mike,

why do you think the protocol should allow to have two endpoints on the same=
 URL? Even the core spec does not allow to map tokens and authorization endp=
oint to the same URL.

Regards,
Torsten.

Am 12.02.2013 um 02:26 schrieb Mike Jones :

> At most, there should be two endpoints - creation and management - for a c=
lient, but the protocol should be structured such that they *can* be at the s=
ame URL, if the server so chooses.  A simple way to accomplish this is to re=
quire that the client_id value be provided as an input parameter on update o=
perations.  Then for implementations that use a single endpoint, they can di=
stinguish "create" and "update" operations on the management endpoint by the=
 presence or absence of the client_id value.
>=20
> If you want to have separate endpoints and don't need the client_id becaus=
e you have somehow encoded it into the management endpoint URL, that's fine.=
  It still can serve as a useful cross-check that the client (or an attacker=
) is requesting a change to a client that matches the bearer token used.  Bu=
t including it is necessary for implementations that want to use a single re=
gistration endpoint, rather than having a proliferation of per-client endpoi=
nts.
>=20
> BTW, just for the record, OAuth 2.0 uses the same endpoint for initial acc=
ess token requests and requests for refreshed access tokens - with the opera=
tions being distinguished by whether a refresh_token parameter is present.  S=
o there's a useful OAuth precedent for doing things this way.
>=20
>                -- Mike
>=20
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J=
ustin Richer
> Sent: Monday, February 11, 2013 1:15 PM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Registration: Endpoint Definition (& operation paramet=
er)
>=20
> Draft -05 of OAuth Dynamic Client Registration [1] defines three fundament=
al operations that a client can undertake: Client Registration, Client Updat=
e, and Secret Rotation. Each of these actions needs to be differentiated *so=
mehow* by the client and server as part of the protocol. Draft -00 defined o=
nly the "register" operation, drafts -01 through -04 made use of an "operati=
on" parameter on a single endpoint, which brought up a long discussion on th=
e list on whether or not that was an appropriate design. Draft -05 did away w=
ith the definition of the "operation" parameter on a single endpoint and ins=
tead opted for separating the base functionality into three different endpoi=
nts.
>=20
> Pro:
>  - Closer to RESTful semantics of having one URL for creation and another U=
RL for management of an item (eg, most REST APIs use /object for creation an=
d /object/object_id for manipulation)
>  - The rest of OAuth (and its extensions) defines separate endpoints for d=
ifferent actions (Authorization, Token, Revocation, Introspection) as oppose=
d to a single endpoint with a mode-switch parameter
>  - Client doesn't have to generate a URL string for different endpoints by=
 combining parameters with a base URL
>=20
> Con:
>  - Not quite exactly RESTful as the spec doesn't dictate the client_id=20
> be part of the update or rotate URL (though and implementor's note=20
> suggests this)
>  - Client has to track different URLs for different actions
>  - Server must be able to differentiate actions based on these=20
> different URLs.
>=20
> Alternatives include using different HTTP verbs (see other thread) or=20
> defining an operational switch parameter, like older drafts, on a single=20=

> endpoint URL. Another suggested alternative is to look for the presence=20=

> of certain parameters, such as client_id or the registration access=20
> token, to indicate that a different operation is requested.
>=20
> There's also question of whether the Secret Rotation action needs to=20
> have its own endpoint, or if it can be collapsed into one of the others.=20=

> It has been suggested off-list that the secret rotation should never be=20=

> initiated by the Client but instead the client should simply request its=20=

> latest secret from the server through the update (or read) semantics.
>=20
>  -- Justin
>=20
> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
> _______________________________________________
> 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

From torsten@lodderstedt.net  Mon Feb 11 23:23:56 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F2821F8C57 for ; Mon, 11 Feb 2013 23:23:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.234
X-Spam-Level: 
X-Spam-Status: No, score=-0.234 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TX0e4uYmIlHq for ; Mon, 11 Feb 2013 23:23:55 -0800 (PST)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.32]) by ietfa.amsl.com (Postfix) with ESMTP id 572D821F8C55 for ; Mon, 11 Feb 2013 23:23:55 -0800 (PST)
Received: from [80.187.107.6] (helo=[192.168.44.16]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1U5ADY-0006NG-GE; Tue, 12 Feb 2013 08:23:52 +0100
References: <51195F36.6040705@mitre.org> <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <80727F20-A830-4778-B11C-D45389310646@lodderstedt.net>
X-Mailer: iPad Mail (10B141)
From: Torsten Lodderstedt 
Date: Tue, 12 Feb 2013 08:23:49 +0100
To: John Bradley 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 07:23:56 -0000

+1 for always including the client_id=20

As John pointed out, there could be different entities updating client data.=
 Then one has to distinguish the resource and the credential.

Am 12.02.2013 um 02:51 schrieb John Bradley :

> I would always include the client_id on update.
>=20
> I think it is also us full to have other tokens used at the update endpoin=
t.  I can see the master token used to update all the clients it has registe=
red as part of API management.=20
> Relying on the registration_access_token is probably a design that will ca=
use trouble down the road.
>=20
> I think GET and POST are relatively clear.   I don't know about expelling P=
UT to developers.  I think POST with a client_id to a (separate discussion) u=
pdate_uri works without restricting it to PUT.
>=20
> I think DELETE needs to be better understood.   I think a status that can b=
e set for client lifecycle is better than letting a client delete a entry.  =
 =20
> In some cases there will be more than one instance of a client and letting=
 them know they have been turned off for a reason is better than making ther=
e registration disappear. =20
> So for the moment I would levee out DELETE.
>=20
> John B.
>=20
> On 2013-02-11, at 6:14 PM, Justin Richer  wrote:
>=20
>> Draft -05 of OAuth Dynamic Client Registration [1] defines several operat=
ions that the client can take on its behalf as part of the registration proc=
ess. These boil down to the basic CRUD operations that you find in many APIs=
: Create, Read, Update, Delete. Draft -00 defined only the "Create" operatio=
n, draft -01 through -04 added the "Update" operation, switched using the "o=
peration=3D" parameter.
>>=20
>> Following several suggestions to do so on the list, the -05 draft defines=
 these operations in terms of a RESTful API for the client. Namely:
>>=20
>> - HTTP POST to registration endpoint =3D> Create (register) a new client
>> - HTTP PUT to update endpoint (with registration_access_token) =3D> Updat=
e the registered information for this client
>> - HTTP GET to update endpoint (with registration_access_token) =3D> read t=
he registered information for this client
>> - HTTP DELETE to update endpoint (with registration_access_token) =3D> De=
lete (unregister/de-provision) this client
>>=20
>> The two main issues at stake here are: the addition of the READ and DELET=
E methods, and the use of HTTP verbs following a RESTful design philosophy.
>>=20
>> Pro:
>> - RESTful APIs (with HTTP verbs to differentiate functionality) are the n=
orm today
>> - Full lifecycle management is common and is going to be expected by many=
 users of this protocol in the wild
>>=20
>> Cons:
>> - Update semantics are still under debate (full replace? patch?)
>> - Somewhat increased complexity on the server to support all operations
>> - Client has to understand all HTTP verbs for full access (though plain r=
egistration is just POST)
>>=20
>>=20
>> Alternatives include using an operational switch parameter (like the old d=
rafts), defining separate endpoints for every action, or doing all operation=
s on a single endpoint using verbs to switch.
>>=20
>> -- Justin
>>=20
>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From hannes.tschofenig@gmx.net  Tue Feb 12 01:10:36 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3359321F8C84 for ; Tue, 12 Feb 2013 01:10:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.97
X-Spam-Level: 
X-Spam-Status: No, score=-100.97 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbY4O6Y3pdG6 for ; Tue, 12 Feb 2013 01:10:31 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id B474C21F8C7D for ; Tue, 12 Feb 2013 01:10:30 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.35]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MW5It-1UPOPM3MLZ-00XIdD for ; Tue, 12 Feb 2013 10:10:29 +0100
Received: (qmail invoked by alias); 12 Feb 2013 09:10:29 -0000
Received: from unknown (EHLO [10.255.128.222]) [194.251.119.201] by mail.gmx.net (mp035) with SMTP; 12 Feb 2013 10:10:29 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18DrWsRaMoDCW7Ho7LaCN4og5bA9aNUONqvlp3WVd qORaUF55RUerIU
From: Hannes Tschofenig 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Tue, 12 Feb 2013 11:10:27 +0200
Message-Id: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net>
To: IETF oauth WG 
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Subject: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 09:10:36 -0000

Here are my notes.=20

Participants:

* John Bradley
* Derek Atkins
* Phil Hunt
* Prateek Mishra
* Hannes Tschofenig
* Mike Jones
* Antonio Sanso
* Justin Richer

Notes:=20

My slides are available here: =
http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt

Slide #2 summarizes earlier discussions during the conference calls.=20

-- HTTP vs. JSON

Phil noted that he does not like to use the MAC Token draft as a =
starting point because it does not re-use any of the work done in the =
JOSE working group and in particular all the libraries that are =
available today. He mentioned that earlier attempts to write the MAC =
Token code lead to problems for implementers.=20

Justin responded that he does not agree with using JSON as a transport =
mechanism since this would replicate a SOAP style.=20

Phil noted that he wants to send JSON but the signature shall be =
computed over the HTTP header field.=20

-- Flexibility for the keyed message digest computation

=46rom earlier discussion it was clear that the conference call =
participants wanted more flexibility regarding the keyed message digest =
computation. For this purpose Hannes presented the DKIM based approach, =
which allows selective header fields to be included in the digest. This =
is shown in slide #4.=20

After some discussion the conference call participants thought that this =
would meet their needs. Further investigations would still be useful to =
determine the degree of failed HMAC calculations due to HTTP proxies =
modifying the content.=20

-- Key Distribution

Hannes presented the open issue regarding the choice of key =
distribution. Slides #6-#8 present three techniques and Hannes asked for =
feedback regarding the preferred style. Justin and others didn't see the =
need to decide on one mechanism - they wanted to keep the choice open. =
Derek indicated that this will not be an acceptable approach. Since the =
resource server and the authorization server may, in the OAuth 2.0 =
framework, be entities produced by different vendors there is an =
interoperability need. Justin responded that he disagrees and that the =
resource server needs to understand the access token and referred to the =
recent draft submission for the token introspection endpoint. Derek =
indicated that the resource server has to understand the content of the =
access token and the token introspection endpoint just pushes the =
problem around: the resource server has to send the access token to the =
authorization server and then the resource server gets the result back =
(which he then again needs to understand) in order to make a meaningful =
authorization decision.=20

Everyone agreed that the client must receive the session key from the =
authorization server and that this approach has to be standardized. It =
was also agreed that this is a common approach among all three key =
distribution mechanisms.

Hannes asked the participants to think about their preference.=20

The questions regarding key naming and the indication for the intended =
resource server the client wants to talk to have been postponed.=20
=20
Ciao
Hannes

From hannes.tschofenig@gmx.net  Tue Feb 12 01:14:14 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE0521F8C97 for ; Tue, 12 Feb 2013 01:14:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.91
X-Spam-Level: 
X-Spam-Status: No, score=-100.91 tagged_above=-999 required=5 tests=[AWL=-0.890, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gym6iVmNce1c for ; Tue, 12 Feb 2013 01:14:13 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id BBE9521F8447 for ; Tue, 12 Feb 2013 01:14:12 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.16]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Lmxbm-1UZ33H1yNY-00h5KI for ; Tue, 12 Feb 2013 10:14:11 +0100
Received: (qmail invoked by alias); 12 Feb 2013 09:14:11 -0000
Received: from unknown (EHLO [10.255.128.222]) [194.251.119.201] by mail.gmx.net (mp016) with SMTP; 12 Feb 2013 10:14:11 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18Ntu8wXm8Ndg0WFr0QExS1d9TvqaSfybs4WBuIRw 0P3XEO9BUqRwXA
From: Hannes Tschofenig 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Tue, 12 Feb 2013 11:14:10 +0200
Message-Id: 
To: IETF oauth WG 
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Subject: [OAUTH-WG] Draft IETF#86 Agenda
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 09:14:14 -0000

Hi all,=20

I just wanted to let you know that the draft agenda for the upcoming =
IETF meeting is available here:
https://datatracker.ietf.org/meeting/86/agenda.txt

There are two OAuth sessions:

* MONDAY, March 11, 2013
1540-1710  Afternoon Session II

* THURSDAY, March 14, 2013
1740-1840  Afternoon Session III

I was also told that there will be an OpenID Connect gathering on Sunday =
afternoon.=20

Additionally, there are various other security-related sessions that you =
may find useful, such as JOSE, TLS, or KITTEN.=20

Ciao
Hannes

From wmills_92105@yahoo.com  Tue Feb 12 01:27:32 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9358721F8BFD for ; Tue, 12 Feb 2013 01:27:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.193
X-Spam-Level: 
X-Spam-Status: No, score=-2.193 tagged_above=-999 required=5 tests=[AWL=0.405,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3N30lWJV79aT for ; Tue, 12 Feb 2013 01:27:31 -0800 (PST)
Received: from nm20-vm1.bullet.mail.ne1.yahoo.com (nm20-vm1.bullet.mail.ne1.yahoo.com [98.138.91.21]) by ietfa.amsl.com (Postfix) with ESMTP id F271A21F8CA1 for ; Tue, 12 Feb 2013 01:27:30 -0800 (PST)
Received: from [98.138.90.57] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 12 Feb 2013 09:27:30 -0000
Received: from [98.138.87.3] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 12 Feb 2013 09:27:30 -0000
Received: from [127.0.0.1] by omp1003.mail.ne1.yahoo.com with NNFMP; 12 Feb 2013 09:27:30 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 442931.33684.bm@omp1003.mail.ne1.yahoo.com
Received: (qmail 64395 invoked by uid 60001); 12 Feb 2013 09:27:30 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360661250; bh=WVewlGkLVC+vAEDH8z77yilg31R9rox7/DlCgoKVDhk=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=JW/VhcbK8QHO0wCsSuUCiOAOWuBoDgwQ4RgKWBRBiUTzr3RNJIzpKrGjgoM0clhq0Nz1M6ae8kSv90uxENRUjfEJsVH66NqLAM1TK75NFzNjLnBgqK45AbD79yirueJzYtFfMZh+bNLWl9lnXS+wuiSdctRaxNaT2PyZyDcxCxc=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=TnEMSAL74QJvTBz+62tsx1lBnjZ8gLQTC314ZrL5vXPjp3bCRvA0vvNEZmX6U7AtuR4ujMxKCg4Z5PVCqnhPxPDQQE9AzqB3PppPo2XpEnMSVMhqxJDeqGWappdElv43Uz32XOpq533y5vYeo2axK2ARS2cQLFo16qTTNmaM93E=;
X-YMail-OSG: g8Wfp9AVM1mOr4nwLPQdPQyZ9wQtZIcrp1qyfLVM_Ua4R6B VkvolakChmDkVUyaISrxVWL.yLK7GBsVw_S4huXrcsr61oW9DrLVbupYyAxJ l2313qs4ypaPxycOOibh0LDiiKKtRg36DImzPoraNrhNw7ObykSPruItnDYw RFCUEGYAkStq1ZLTaodc6Gx7CbciG38TKhqfhyvDJP9z2F_0ky17dfoGfw3Z ps6q_.mUnOQnSIPWLit48CRCLGHZq.dCKYYZfwGzz12.H2BKpe.Jcouur2m6 LOn0OT8UO43wZ.agF3l1BRypPVxK9G_Ebj60AYPfPWR1tCp.X.Il4g5mSazz K.tEpa60yWVBexG459kyQZzwZGjsrMV6QnRiPXmfFEGD1.qrwszMLODSW98T LRMO4so3bZxaJWg8pV89T93mlfkXTm7idTueZG6hT0FXuFo3N54BelqnujHd swQ9PX04YXRQZ4PNqm7sDkApHKa6znWJe9Hq_M_M8OFfPfIDZojSQC8Wi9cS vBOD0YHPFwU6LIK3o0YTdxSDiOjY1zDlgSNULEJIC7JddrQk2qj3noHD1Y3E QwAxVb4ccVGZ7XzBZxT0dEOZiXnsHyCT.yyM_kzRoRuqPssugFZcXWsD_Yai GceD5LKWLuHUQnHaei0seEnCn8tI-
Received: from [209.131.62.115] by web31803.mail.mud.yahoo.com via HTTP; Tue, 12 Feb 2013 01:27:29 PST
X-Rocket-MIMEInfo: 001.001, SXMga2V5IGRpc3RyaWJ1dGlvbiBob3cgQVMgYW5kIFBSIHNoYXJlIGtleXMgwqBmb3IgdG9rZW4gZW5jcnlwdGlvbi9kZWNyeXB0aW9uIG9yIHNwZWNpZmljYWxseSBhYm91dCB0aGUga2V5cyBmb3IgdGhlIEhPSyB0b2tlbnM_CgpGb3IgdGhlIE1BQyB0b2tlbiBzcGVjLCBJIGRvbid0IGFjdHVhbGx5IGNhcmUgd2hldGhlciB3ZSB1c2UgSlNPTiBvciBub3csIGJ1dCBJJ20gaW4gZnVsbCBhZ3JlZW1lbnQgdGhhdCB3ZSBkbyBOT1QgZHVwbGljYXRlIGFueSBIVFRQIGluZm8gaW50byB0aGUgSlNPTi4gwqBKdXMBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.133.508
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net>
Message-ID: <1360661249.62997.YahooMailNeo@web31803.mail.mud.yahoo.com>
Date: Tue, 12 Feb 2013 01:27:29 -0800 (PST)
From: William Mills 
To: Hannes Tschofenig , IETF oauth WG 
In-Reply-To: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="1502656925-992005796-1360661249=:62997"
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 09:27:32 -0000

--1502656925-992005796-1360661249=:62997
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Is key distribution how AS and PR share keys =A0for token encryption/decryp=
tion or specifically about the keys for the HOK tokens?=0A=0AFor the MAC to=
ken spec, I don't actually care whether we use JSON or now, but I'm in full=
 agreement that we do NOT duplicate any HTTP info into the JSON. =A0Just si=
gnatures of that stuff.=0A=0A=0A________________________________=0A From: H=
annes Tschofenig =0ATo: IETF oauth WG  =0ASent: Tuesday, February 12, 2013 1:10 AM=0ASubject: [OAUTH-WG] Mi=
nutes from the OAuth Design Team Conference Call - 11th February 2013=0A =
=0AHere are my notes. =0A=0AParticipants:=0A=0A* John Bradley=0A* Derek Atk=
ins=0A* Phil Hunt=0A* Prateek Mishra=0A* Hannes Tschofenig=0A* Mike Jones=
=0A* Antonio Sanso=0A* Justin Richer=0A=0ANotes: =0A=0AMy slides are availa=
ble here: http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt=0A=0A=
Slide #2 summarizes earlier discussions during the conference calls. =0A=0A=
-- HTTP vs. JSON=0A=0APhil noted that he does not like to use the MAC Token=
 draft as a starting point because it does not re-use any of the work done =
in the JOSE working group and in particular all the libraries that are avai=
lable today. He mentioned that earlier attempts to write the MAC Token code=
 lead to problems for implementers. =0A=0AJustin responded that he does not=
 agree with using JSON as a transport mechanism since this would replicate =
a SOAP style. =0A=0APhil noted that he wants to send JSON but the signature=
 shall be computed over the HTTP header field. =0A=0A-- Flexibility for the=
 keyed message digest computation=0A=0AFrom earlier discussion it was clear=
 that the conference call participants wanted more flexibility regarding th=
e keyed message digest computation. For this purpose Hannes presented the D=
KIM based approach, which allows selective header fields to be included in =
the digest. This is shown in slide #4. =0A=0AAfter some discussion the conf=
erence call participants thought that this would meet their needs. Further =
investigations would still be useful to determine the degree of failed HMAC=
 calculations due to HTTP proxies modifying the content. =0A=0A-- Key Distr=
ibution=0A=0AHannes presented the open issue regarding the choice of key di=
stribution. Slides #6-#8 present three techniques and Hannes asked for feed=
back regarding the preferred style. Justin and others didn't see the need t=
o decide on one mechanism - they wanted to keep the choice open. Derek indi=
cated that this will not be an acceptable approach. Since the resource serv=
er and the authorization server may, in the OAuth 2.0 framework, be entitie=
s produced by different vendors there is an interoperability need. Justin r=
esponded that he disagrees and that the resource server needs to understand=
 the access token and referred to the recent draft submission for the token=
 introspection endpoint. Derek indicated that the resource server has to un=
derstand the content of the access token and the token introspection endpoi=
nt just pushes the problem around: the resource server has to send the acce=
ss token to the authorization server and then the resource server gets the =
result
 back (which he then a=0Again needs to understand) in order to make a meani=
ngful authorization decision. =0A=0AEveryone agreed that the client must re=
ceive the session key from the authorization server and that this approach =
has to be standardized. It was also agreed that this is a common approach a=
mong all three key distribution mechanisms.=0A=0AHannes asked the participa=
nts to think about their preference. =0A=0AThe questions regarding key nami=
ng and the indication for the intended resource server the client wants to =
talk to have been postponed. =0A=0ACiao=0AHannes=0A=0A=0A__________________=
_____________________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps=
://www.ietf.org/mailman/listinfo/oauth
--1502656925-992005796-1360661249=:62997
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Is key distribution how AS and PR share keys  for token encryption/d=
ecryption or specifically about the keys for the HOK tokens?
For the MA=
C token spec, I don't actually care whether we use JSON or now, but I'm in =
full agreement that we do NOT duplicate any HTTP info into the JSON.  =
Just signatures of that stuff.

     =

  From: Han=
nes Tschofenig <hannes.tschofenig@gmx.net>
 To: IETF oauth WG <oauth@ietf.org> 
 Sent: Tuesday, February 12, =
2013 1:10 AM
 Subject: =
[OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th Februa=
ry 2013

=0AHere are my notes. 

Participants:<=
br>
* John Bradley
* Derek Atkins
* Phil Hunt
* Prateek Mishra<=
br>* Hannes Tschofenig
* Mike Jones
* Antonio Sanso
* Justin Riche=
r

Notes: 

My slides are available here: http://www.tschofenig=
.priv.at/OAuth2-Security-11Feb2013.ppt

Slide #2 summarizes earlier d=
iscussions during the conference calls. 

-- HTTP vs. JSON

Phi=
l noted that he does not like to use the MAC Token draft as a starting poin=
t because it does not re-use any of the work done in the JOSE working group=
 and in particular all the libraries that are available today. He mentioned=
 that earlier attempts to write the MAC Token code lead to problems for imp=
lementers. 

Justin responded that he does not agree with using JSON =
as a transport mechanism since this would replicate a SOAP style. 

P=
hil noted that he wants to send JSON but the signature shall be computed ov=
er the HTTP header field.

-- Flexibility for the keyed message digest computation

Fro=
m earlier discussion it was clear that the conference call participants wan=
ted more flexibility regarding the keyed message digest computation. For th=
is purpose Hannes presented the DKIM based approach, which allows selective=
 header fields to be included in the digest. This is shown in slide #4. 
After some discussion the conference call participants thought that th=
is would meet their needs. Further investigations would still be useful to =
determine the degree of failed HMAC calculations due to HTTP proxies modify=
ing the content. 

-- Key Distribution

Hannes presented the op=
en issue regarding the choice of key distribution. Slides #6-#8 present thr=
ee techniques and Hannes asked for feedback regarding the preferred style. =
Justin and others didn't see the need to decide on one mechanism - they wan=
ted to keep the choice open. Derek indicated that this will not be
 an acceptable approach. Since the resource server and the authorization se=
rver may, in the OAuth 2.0 framework, be entities produced by different ven=
dors there is an interoperability need. Justin responded that he disagrees =
and that the resource server needs to understand the access token and refer=
red to the recent draft submission for the token introspection endpoint. De=
rek indicated that the resource server has to understand the content of the=
 access token and the token introspection endpoint just pushes the problem =
around: the resource server has to send the access token to the authorizati=
on server and then the resource server gets the result back (which he then =
a
 gain needs to understand) in order to make a meaningful authorization=
 decision. 

Everyone agreed that the client must receive the session=
 key from the authorization server and that this approach has to be standar=
dized. It was also agreed that this is a common approach among all
 three key distribution mechanisms.

Hannes asked the participants to=
 think about their preference. 

The questions regarding key naming a=
nd the indication for the intended resource server the client wants to talk=
 to have been postponed. 

Ciao
Hannes

_______________=
________________________________
OAuth mailing list
OAuth@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/oauth

--1502656925-992005796-1360661249=:62997--

From hannes.tschofenig@gmx.net  Tue Feb 12 01:44:30 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB9E21F8BFD for ; Tue, 12 Feb 2013 01:44:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.858
X-Spam-Level: 
X-Spam-Status: No, score=-100.858 tagged_above=-999 required=5 tests=[AWL=-0.838, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmKW-8mZC9bX for ; Tue, 12 Feb 2013 01:44:29 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF2F21F8BF6 for ; Tue, 12 Feb 2013 01:44:29 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.24]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Lnmkr-1UYlKV2jWx-00hw3S for ; Tue, 12 Feb 2013 10:44:28 +0100
Received: (qmail invoked by alias); 12 Feb 2013 09:44:28 -0000
Received: from unknown (EHLO [10.255.128.222]) [194.251.119.201] by mail.gmx.net (mp024) with SMTP; 12 Feb 2013 10:44:28 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX199HhA5C9B9cmbbgZ6fZyopit28cl0WxuRzzXnaCE K1VNRHJr5SexI3
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Hannes Tschofenig 
In-Reply-To: <1360661249.62997.YahooMailNeo@web31803.mail.mud.yahoo.com>
Date: Tue, 12 Feb 2013 11:44:27 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <103117A9-0922-4E1A-AC73-D2914743046C@gmx.net>
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net> <1360661249.62997.YahooMailNeo@web31803.mail.mud.yahoo.com>
To: William Mills 
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 09:44:30 -0000

Hi Bill,=20

On Feb 12, 2013, at 11:27 AM, William Mills wrote:

> Is key distribution how AS and PR share keys  for token =
encryption/decryption or specifically about the keys for the HOK tokens?
>=20
In order for the client to compute the keyed message digest it needs to =
have the session key. This session key is sent from the authorization =
server to the client and everyone on the call agreed that this has to be =
standardized.=20

The resource server who receives the message from the client also needs =
to have the session key to verify the message. How the resource server =
obtains this session key was subject for some discussion on the call. I =
presented three different ways of how the resource server is able to =
obtain that key. We have to decide on one mandatory-to-implement =
mechanism. The open issue is which one?=20
=20
> For the MAC token spec, I don't actually care whether we use JSON or =
now, but I'm in full agreement that we do NOT duplicate any HTTP info =
into the JSON.  Just signatures of that stuff.
>=20
I believe the folks on the call also agreed with you on that aspect that =
the content of the HTTP message should not be replicated in the JSON =
payload itself.=20

Ciao
Hannes

> From: Hannes Tschofenig 
> To: IETF oauth WG =20
> Sent: Tuesday, February 12, 2013 1:10 AM
> Subject: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call =
- 11th February 2013
>=20
> Here are my notes.=20
>=20
> Participants:
>=20
> * John Bradley
> * Derek Atkins
> * Phil Hunt
> * Prateek Mishra
> * Hannes Tschofenig
> * Mike Jones
> * Antonio Sanso
> * Justin Richer
>=20
> Notes:=20
>=20
> My slides are available here: =
http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
>=20
> Slide #2 summarizes earlier discussions during the conference calls.=20=

>=20
> -- HTTP vs. JSON
>=20
> Phil noted that he does not like to use the MAC Token draft as a =
starting point because it does not re-use any of the work done in the =
JOSE working group and in particular all the libraries that are =
available today. He mentioned that earlier attempts to write the MAC =
Token code lead to problems for implementers.=20
>=20
> Justin responded that he does not agree with using JSON as a transport =
mechanism since this would replicate a SOAP style.=20
>=20
> Phil noted that he wants to send JSON but the signature shall be =
computed over the HTTP header field.=20
>=20
> -- Flexibility for the keyed message digest computation
>=20
> =46rom earlier discussion it was clear that the conference call =
participants wanted more flexibility regarding the keyed message digest =
computation. For this purpose Hannes presented the DKIM based approach, =
which allows selective header fields to be included in the digest. This =
is shown in slide #4.=20
>=20
> After some discussion the conference call participants thought that =
this would meet their needs. Further investigations would still be =
useful to determine the degree of failed HMAC calculations due to HTTP =
proxies modifying the content.=20
>=20
> -- Key Distribution
>=20
> Hannes presented the open issue regarding the choice of key =
distribution. Slides #6-#8 present three techniques and Hannes asked for =
feedback regarding the preferred style. Justin and others didn't see the =
need to decide on one mechanism - they wanted to keep the choice open. =
Derek indicated that this will not be an acceptable approach. Since the =
resource server and the authorization server may, in the OAuth 2.0 =
framework, be entities produced by different vendors there is an =
interoperability need. Justin responded that he disagrees and that the =
resource server needs to understand the access token and referred to the =
recent draft submission for the token introspection endpoint. Derek =
indicated that the resource server has to understand the content of the =
access token and the token introspection endpoint just pushes the =
problem around: the resource server has to send the access token to the =
authorization server and then the resource server gets the result back =
(which he then a
> gain needs to understand) in order to make a meaningful authorization =
decision.=20
>=20
> Everyone agreed that the client must receive the session key from the =
authorization server and that this approach has to be standardized. It =
was also agreed that this is a common approach among all three key =
distribution mechanisms.
>=20
> Hannes asked the participants to think about their preference.=20
>=20
> The questions regarding key naming and the indication for the intended =
resource server the client wants to talk to have been postponed.=20
>=20
> Ciao
> Hannes
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20

From wmills_92105@yahoo.com  Tue Feb 12 02:07:06 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C8421F8B3B for ; Tue, 12 Feb 2013 02:07:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.234
X-Spam-Level: 
X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=0.364,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkZYNo3VdF4P for ; Tue, 12 Feb 2013 02:07:05 -0800 (PST)
Received: from nm8.bullet.mail.bf1.yahoo.com (nm8.bullet.mail.bf1.yahoo.com [98.139.212.167]) by ietfa.amsl.com (Postfix) with SMTP id 01F5F21F8B66 for ; Tue, 12 Feb 2013 02:06:57 -0800 (PST)
Received: from [98.139.212.149] by nm8.bullet.mail.bf1.yahoo.com with NNFMP; 12 Feb 2013 10:06:56 -0000
Received: from [98.139.212.228] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 12 Feb 2013 10:06:56 -0000
Received: from [127.0.0.1] by omp1037.mail.bf1.yahoo.com with NNFMP; 12 Feb 2013 10:06:56 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 690584.8029.bm@omp1037.mail.bf1.yahoo.com
Received: (qmail 88477 invoked by uid 60001); 12 Feb 2013 10:06:56 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360663616; bh=5L5+xRNl6khT0LjFrWtCAGZsYHmuS5frOiXM5/y56no=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=YOkF3FbWC91yZy7vBhiRHhIZxcILYb53VUHJnkgTwSew7nPm7Z+xdhjcIUl04Bul3mkbrQ6rRa6+ayFZHMy2Xcg1PaWd8sSfG3k8dZFdHrTQ600u3Ss6JiWLJz1AeqwDN2DW0Ylm53J6qRb1M92oljlZQMdvX6kKlpRUOOEj2X4=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ycl6VFw7zJOPGastpL2VdffdLZPKjrUju1jkqc/7KOwqGXp+lvdnoufiZUUcgF3sTLJDhJuIUgEjOhFljevN3im4uKsE7p1EFeTqKc3C0sAMOWoS3ge3mxpDcolgpZbJPN5x+ZdnNsKk4tLSEeeBqnMcNaN05vI6W08Lot/TVps=;
X-YMail-OSG: xGyOi70VM1mAfwZ8TE8PFB2tzmsvyhWPcRg6bwfcZGmCOZe 3cZLIKGe3q_3aPd9eTpdyETdfw3eNdINY2RAGdgOeMHOKRBwNoM1s0sC7AiW GwAyIFGzXGL6md6.3cjgSMbHwk5JUcySS1hxQ9.FP9oNapHIwPj5Hkj6c4Y1 V6bEiIZ6uE.3pH0Tix4SQukeobCQMxT3EO5A.4PnHrGCdumQfgcb9RTDZodT YFnnitwMJE9n3i12bPpZR_RC0ZPJlvmxHIfMXVSe1xvoQICNKG2Bxb62yIj7 hUbmLw4nySgrc62EYxB3pLVhGNiuNqdk1h1UphyDB.fvHCc_R3Az8Q6_Kiuo A6ibbHhlKCdjeI6Qf7kN3eyqU8_EtVF_dRSMY.Z_sog5yyK0eI8BODrTRsvo Sonayf4Jc26_TUNVEfmjxe4U4X335qJji6pUkvBAl3VlKIddOj0x.bzv_QPy 9hxHlN5lURqT0.Afpg2wzpDFkNAHPBViL0a2Tg8CFbwndMQERhmuuA3bKsKu K_7p8N3iHui88QBYxVZ1oOcuftrTblY_vkfyhBeriEA.X6AZb0YVV3XMymB8 Fhgeh5c8tY1TNYoi9JJ.MvLEXP499TNNZokS_0QlcwSbkBlgr9ky0QcDhxdR d8k7f_i0KlJalze6uKCwsB1iayNzE8_bKYt.Ff9FxKgqG
Received: from [209.131.62.115] by web31803.mail.mud.yahoo.com via HTTP; Tue, 12 Feb 2013 02:06:55 PST
X-Rocket-MIMEInfo: 001.001, Rm9yIGtleSBleGNoYW5nZSB0aGF0J3MgdHJ1ZSBmb3Igc3ltbWV0cmljIGtleSwgYnV0IG5vIGtleSBleGNoYW5nZSBpcyByZXF1aXJlZCBmb3IgcHVibGljIGtleSBzaWduaW5nIGJ5IHRoZSBjbGllbnQuCgpUaGVyZSdzIHNvIG1hbnkgcG9zc2liaWxpdGllcyBoZXJlLCBidXQgSSB0aGluayB0aGUgYmVzdCBpcyB0aGF0IHRoZSBrZXkgbWF0ZXJpZWwgaXMgY29udmV5ZWQgaW4gdGhlIHRva2VuLiDCoFRoZSBrZXkgY291bGQgYmUgaW5jbHVkZWQgZGlyZWN0bHksIG9yIGFub3RoZXIgd2F5IHRvIGltcGxlbWUBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.133.508
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net> <1360661249.62997.YahooMailNeo@web31803.mail.mud.yahoo.com> <103117A9-0922-4E1A-AC73-D2914743046C@gmx.net>
Message-ID: <1360663615.75403.YahooMailNeo@web31803.mail.mud.yahoo.com>
Date: Tue, 12 Feb 2013 02:06:55 -0800 (PST)
From: William Mills 
To: Hannes Tschofenig 
In-Reply-To: <103117A9-0922-4E1A-AC73-D2914743046C@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="1502656925-1766511797-1360663615=:75403"
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 10:07:06 -0000

--1502656925-1766511797-1360663615=:75403
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

For key exchange that's true for symmetric key, but no key exchange is requ=
ired for public key signing by the client.=0A=0AThere's so many possibiliti=
es here, but I think the best is that the key materiel is conveyed in the t=
oken. =A0The key could be included directly, or another way to implement wo=
uld be that a salt is included in the token and then the secret is some cry=
pto hash of the token contents and a shared secret between the AS and the P=
R. =A0=0A=0AIf we we must pick one I'd say include the signing key as part =
of the encrypted token itself. =A0Completely self contained then.=0A=0A=0A_=
_______________________________=0A From: Hannes Tschofenig =0ATo: William Mills  =0ACc: Hannes Tsch=
ofenig ; IETF oauth WG  =0ASent:=
 Tuesday, February 12, 2013 1:44 AM=0ASubject: Re: [OAUTH-WG] Minutes from =
the OAuth Design Team Conference Call - 11th February 2013=0A =0AHi Bill, =
=0A=0AOn Feb 12, 2013, at 11:27 AM, William Mills wrote:=0A=0A> Is key dist=
ribution how AS and PR share keys=A0 for token encryption/decryption or spe=
cifically about the keys for the HOK tokens?=0A> =0AIn order for the client=
 to compute the keyed message digest it needs to have the session key. This=
 session key is sent from the authorization server to the client and everyo=
ne on the call agreed that this has to be standardized. =0A=0AThe resource =
server who receives the message from the client also needs to have the sess=
ion key to verify the message. How the resource server obtains this session=
 key was subject for some discussion on the call. I presented three differe=
nt ways of how the resource server is able to obtain that key. We have to d=
ecide on one mandatory-to-implement mechanism. The open issue is which one?=
 =0A=0A> For the MAC token spec, I don't actually care whether we use JSON =
or now, but I'm in full agreement that we do NOT duplicate any HTTP info in=
to the JSON.=A0 Just signatures of that stuff.=0A> =0AI believe the folks o=
n the call also agreed with you on that aspect that the content of the HTTP=
 message should not be replicated in the JSON payload itself. =0A=0ACiao=0A=
Hannes=0A=0A> From: Hannes Tschofenig =0A> To: I=
ETF oauth WG  =0A> Sent: Tuesday, February 12, 2013 1:10 AM=
=0A> Subject: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call=
 - 11th February 2013=0A> =0A> Here are my notes. =0A> =0A> Participants:=
=0A> =0A> * John Bradley=0A> * Derek Atkins=0A> * Phil Hunt=0A> * Prateek M=
ishra=0A> * Hannes Tschofenig=0A> * Mike Jones=0A> * Antonio Sanso=0A> * Ju=
stin Richer=0A> =0A> Notes: =0A> =0A> My slides are available here: http://=
www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt=0A> =0A> Slide #2 summ=
arizes earlier discussions during the conference calls. =0A> =0A> -- HTTP v=
s. JSON=0A> =0A> Phil noted that he does not like to use the MAC Token draf=
t as a starting point because it does not re-use any of the work done in th=
e JOSE working group and in particular all the libraries that are available=
 today. He mentioned that earlier attempts to write the MAC Token code lead=
 to problems for implementers. =0A> =0A> Justin responded that he does not =
agree with using JSON as a transport mechanism since this would replicate a=
 SOAP style. =0A> =0A> Phil noted that he wants to send JSON but the signat=
ure shall be computed over the HTTP header field. =0A> =0A> -- Flexibility =
for the keyed message digest computation=0A> =0A> From earlier discussion i=
t was clear that the conference call participants wanted more flexibility r=
egarding the keyed message digest computation. For this purpose Hannes pres=
ented the DKIM based approach, which allows selective header fields to be i=
ncluded in the digest. This is shown in slide #4. =0A> =0A> After some disc=
ussion the conference call participants thought that this would meet their =
needs. Further investigations would still be useful to determine the degree=
 of failed HMAC calculations due to HTTP proxies modifying the content. =0A=
> =0A> -- Key Distribution=0A> =0A> Hannes presented the open issue regardi=
ng the choice of key distribution. Slides #6-#8 present three techniques an=
d Hannes asked for feedback regarding the preferred style. Justin and other=
s didn't see the need to decide on one mechanism - they wanted to keep the =
choice open. Derek indicated that this will not be an acceptable approach. =
Since the resource server and the authorization server may, in the OAuth 2.=
0 framework, be entities produced by different vendors there is an interope=
rability need. Justin responded that he disagrees and that the resource ser=
ver needs to understand the access token and referred to the recent draft s=
ubmission for the token introspection endpoint. Derek indicated that the re=
source server has to understand the content of the access token and the tok=
en introspection endpoint just pushes the problem around: the resource serv=
er has to send the access token to the authorization server and then the re=
source server gets the
 result back (which he then a=0A> gain needs to understand) in order to mak=
e a meaningful authorization decision. =0A> =0A> Everyone agreed that the c=
lient must receive the session key from the authorization server and that t=
his approach has to be standardized. It was also agreed that this is a comm=
on approach among all three key distribution mechanisms.=0A> =0A> Hannes as=
ked the participants to think about their preference. =0A> =0A> The questio=
ns regarding key naming and the indication for the intended resource server=
 the client wants to talk to have been postponed. =0A> =0A> Ciao=0A> Hannes=
=0A> =0A> =0A> _______________________________________________=0A> OAuth ma=
iling list=0A> OAuth@ietf.org=0A> https://www.ietf.org/mailman/listinfo/oau=
th=0A> =0A> 
--1502656925-1766511797-1360663615=:75403
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

For =
key exchange that's true for symmetric key, but no key exchange is required=
 for public key signing by the client.

There's so many possibilities here, but I think the best is that the =
key materiel is conveyed in the token.  The key could be included dire=
ctly, or another way to implement would be that a salt is included in the t=
oken and then the secret is some crypto hash of the token contents and a sh=
ared secret between the AS and the PR.  

If we we must pick one I'd say in=
clude the signing key as part of the encrypted token itself.  Complete=
ly self contained then.

  From: Hannes Tschofen=
ig <hannes.tschofenig@gmx.net>
 To: William Mills <wmills_92105@yahoo.com> 
Cc: Hannes Tschofenig <hannes.=
tschofenig@gmx.net>; IETF oauth WG <oauth@ietf.org> 
 Sent: Tuesday, February 12, 2013 1=
:44 AM
 Subject: Re: [O=
AUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February=
 2013

=0AHi Bill, 

On Feb 12, 2013, at 11:27 =
AM, William Mills wrote:

> Is key distribution how AS and PR shar=
e keys  for token encryption/decryption or specifically about the keys=
 for the HOK tokens?
> 
In order for the client to compute the key=
ed message digest it needs to have the session key. This session key is sen=
t from the authorization server to the client and everyone on the call agre=
ed that this has to be standardized. 

The resource server who receiv=
es the message from the client also needs to have the session key to verify=
 the message. How the resource server obtains this session key was subject =
for some discussion on the call. I presented three different ways of how th=
e resource server is able to obtain that key. We have to decide on one mand=
atory-to-implement mechanism. The open issue is which one? 

> Fo=
r the MAC token spec, I don't actually care whether we use JSON or now, but=
 I'm in full agreement
 that we do NOT duplicate any HTTP info into the JSON.  Just signature=
s of that stuff.
> 
I believe the folks on the call also agreed wi=
th you on that aspect that the content of the HTTP message should not be re=
plicated in the JSON payload itself. 

Ciao
Hannes

> Fro=
m: Hannes Tschofenig <hannes.tschofenig@gmx.net>> To: IETF oauth WG <oauth@ietf.org> 
> Sent: Tuesday, Februa=
ry 12, 2013 1:10 AM
> Subject: [OAUTH-WG] Minutes from the OAuth Desi=
gn Team Conference Call - 11th February 2013
> 
> Here are my n=
otes. 
> 
> Participants:
> 
> * John Bradley
&g=
t; * Derek Atkins
> * Phil Hunt
> * Prateek Mishra
> * Ha=
nnes Tschofenig
> * Mike Jones
> * Antonio Sanso
> *
 Justin Richer
> 
> Notes: 
> 
> My slides are avai=
lable here: http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
=
> 
> Slide #2 summarizes earlier discussions during the conference=
 calls. 
> 
> -- HTTP vs. JSON
> 
> Phil noted that=
 he does not like to use the MAC Token draft as a starting point because it=
 does not re-use any of the work done in the JOSE working group and in part=
icular all the libraries that are available today. He mentioned that earlie=
r attempts to write the MAC Token code lead to problems for implementers. <=
br>> 
> Justin responded that he does not agree with using JSON as=
 a transport mechanism since this would replicate a SOAP style. 
> > Phil noted that he wants to send JSON but the signature shall be com=
puted over the HTTP header field. 
> 
> -- Flexibility for the =
keyed message digest computation
> 
> From earlier
 discussion it was clear that the conference call participants wanted more =
flexibility regarding the keyed message digest computation. For this purpos=
e Hannes presented the DKIM based approach, which allows selective header f=
ields to be included in the digest. This is shown in slide #4. 
> > After some discussion the conference call participants thought that t=
his would meet their needs. Further investigations would still be useful to=
 determine the degree of failed HMAC calculations due to HTTP proxies modif=
ying the content. 
> 
> -- Key Distribution
> 
> Ha=
nnes presented the open issue regarding the choice of key distribution. Sli=
des #6-#8 present three techniques and Hannes asked for feedback regarding =
the preferred style. Justin and others didn't see the need to decide on one=
 mechanism - they wanted to keep the choice open. Derek indicated that this=
 will not be an acceptable approach. Since the resource server and
 the authorization server may, in the OAuth 2.0 framework, be entities prod=
uced by different vendors there is an interoperability need. Justin respond=
ed that he disagrees and that the resource server needs to understand the a=
ccess token and referred to the recent draft submission for the token intro=
spection endpoint. Derek indicated that the resource server has to understa=
nd the content of the access token and the token introspection endpoint jus=
t pushes the problem around: the resource server has to send the access tok=
en to the authorization server and then the resource server gets the result=
 back (which he then a
> gain needs to understand) in order to make a=
 meaningful authorization decision. 
> 
> Everyone agreed that =
the client must receive the session key from the authorization server and t=
hat this approach has to be standardized. It was also agreed that this is a=
 common approach among all three key distribution
 mechanisms.
> 
> Hannes asked the participants to think about =
their preference. 
> 
> The questions regarding key naming and =
the indication for the intended resource server the client wants to talk to=
 have been postponed. 
> 
> Ciao
> Hannes
> 
>=
; 
> _______________________________________________
> OAuth ma=
iling list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo=
/oauth
> 
> 

--1502656925-1766511797-1360663615=:75403--

From asanso@adobe.com  Tue Feb 12 02:29:27 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0306721F8C0C for ; Tue, 12 Feb 2013 02:29:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpiuFvfOn+Uq for ; Tue, 12 Feb 2013 02:29:25 -0800 (PST)
Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1A321F8BC9 for ; Tue, 12 Feb 2013 02:29:22 -0800 (PST)
Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKURoZgp/Ga2HDYIiod18IBS9RH7zShTvC@postini.com; Tue, 12 Feb 2013 02:29:25 PST
Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r1CATLC9027794; Tue, 12 Feb 2013 02:29:21 -0800 (PST)
Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id r1CAT2XO000223; Tue, 12 Feb 2013 02:29:21 -0800 (PST)
Received: from eurcas01.eur.adobe.com (10.128.4.27) by nahub02.corp.adobe.com (10.8.189.98) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 12 Feb 2013 02:29:02 -0800
Received: from eurmbx01.eur.adobe.com ([10.128.4.32]) by eurcas01.eur.adobe.com ([10.128.4.27]) with mapi; Tue, 12 Feb 2013 10:28:58 +0000
From: Antonio Sanso 
To: Hannes Tschofenig 
Date: Tue, 12 Feb 2013 10:28:56 +0000
Thread-Topic: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call -	11th February 2013
Thread-Index: Ac4JC8N9QrHStA4xRQScTTHKdGjVDw==
Message-ID: 
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net> <1360661249.62997.YahooMailNeo@web31803.mail.mud.yahoo.com> <103117A9-0922-4E1A-AC73-D2914743046C@gmx.net>
In-Reply-To: <103117A9-0922-4E1A-AC73-D2914743046C@gmx.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call -	11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 10:29:27 -0000

Hi Hannes,

how this session key "differs" from the key described in the current draft =
[0]?

Thanks and regards

Antonio

[0] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02

On Feb 12, 2013, at 10:44 AM, Hannes Tschofenig wrote:

> Hi Bill,=20
>=20
> On Feb 12, 2013, at 11:27 AM, William Mills wrote:
>=20
>> Is key distribution how AS and PR share keys  for token encryption/decry=
ption or specifically about the keys for the HOK tokens?
>>=20
> In order for the client to compute the keyed message digest it needs to h=
ave the session key. This session key is sent from the authorization server=
 to the client and everyone on the call agreed that this has to be standard=
ized.=20
>=20
> The resource server who receives the message from the client also needs t=
o have the session key to verify the message. How the resource server obtai=
ns this session key was subject for some discussion on the call. I presente=
d three different ways of how the resource server is able to obtain that ke=
y. We have to decide on one mandatory-to-implement mechanism. The open issu=
e is which one?=20
>=20
>> For the MAC token spec, I don't actually care whether we use JSON or now=
, but I'm in full agreement that we do NOT duplicate any HTTP info into the=
 JSON.  Just signatures of that stuff.
>>=20
> I believe the folks on the call also agreed with you on that aspect that =
the content of the HTTP message should not be replicated in the JSON payloa=
d itself.=20
>=20
> Ciao
> Hannes
>=20
>> From: Hannes Tschofenig 
>> To: IETF oauth WG =20
>> Sent: Tuesday, February 12, 2013 1:10 AM
>> Subject: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call -=
 11th February 2013
>>=20
>> Here are my notes.=20
>>=20
>> Participants:
>>=20
>> * John Bradley
>> * Derek Atkins
>> * Phil Hunt
>> * Prateek Mishra
>> * Hannes Tschofenig
>> * Mike Jones
>> * Antonio Sanso
>> * Justin Richer
>>=20
>> Notes:=20
>>=20
>> My slides are available here: http://www.tschofenig.priv.at/OAuth2-Secur=
ity-11Feb2013.ppt
>>=20
>> Slide #2 summarizes earlier discussions during the conference calls.=20
>>=20
>> -- HTTP vs. JSON
>>=20
>> Phil noted that he does not like to use the MAC Token draft as a startin=
g point because it does not re-use any of the work done in the JOSE working=
 group and in particular all the libraries that are available today. He men=
tioned that earlier attempts to write the MAC Token code lead to problems f=
or implementers.=20
>>=20
>> Justin responded that he does not agree with using JSON as a transport m=
echanism since this would replicate a SOAP style.=20
>>=20
>> Phil noted that he wants to send JSON but the signature shall be compute=
d over the HTTP header field.=20
>>=20
>> -- Flexibility for the keyed message digest computation
>>=20
>> From earlier discussion it was clear that the conference call participan=
ts wanted more flexibility regarding the keyed message digest computation. =
For this purpose Hannes presented the DKIM based approach, which allows sel=
ective header fields to be included in the digest. This is shown in slide #=
4.=20
>>=20
>> After some discussion the conference call participants thought that this=
 would meet their needs. Further investigations would still be useful to de=
termine the degree of failed HMAC calculations due to HTTP proxies modifyin=
g the content.=20
>>=20
>> -- Key Distribution
>>=20
>> Hannes presented the open issue regarding the choice of key distribution=
. Slides #6-#8 present three techniques and Hannes asked for feedback regar=
ding the preferred style. Justin and others didn't see the need to decide o=
n one mechanism - they wanted to keep the choice open. Derek indicated that=
 this will not be an acceptable approach. Since the resource server and the=
 authorization server may, in the OAuth 2.0 framework, be entities produced=
 by different vendors there is an interoperability need. Justin responded t=
hat he disagrees and that the resource server needs to understand the acces=
s token and referred to the recent draft submission for the token introspec=
tion endpoint. Derek indicated that the resource server has to understand t=
he content of the access token and the token introspection endpoint just pu=
shes the problem around: the resource server has to send the access token t=
o the authorization server and then the resource server gets the result bac=
k (which he then
>  a
>> gain needs to understand) in order to make a meaningful authorization de=
cision.=20
>>=20
>> Everyone agreed that the client must receive the session key from the au=
thorization server and that this approach has to be standardized. It was al=
so agreed that this is a common approach among all three key distribution m=
echanisms.
>>=20
>> Hannes asked the participants to think about their preference.=20
>>=20
>> The questions regarding key naming and the indication for the intended r=
esource server the client wants to talk to have been postponed.=20
>>=20
>> Ciao
>> Hannes
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From sberyozkin@gmail.com  Tue Feb 12 02:37:50 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6262E21F8778 for ; Tue, 12 Feb 2013 02:37:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33yPygpFfiJR for ; Tue, 12 Feb 2013 02:37:49 -0800 (PST)
Received: from mail-ea0-f174.google.com (mail-ea0-f174.google.com [209.85.215.174]) by ietfa.amsl.com (Postfix) with ESMTP id 5074D21F867D for ; Tue, 12 Feb 2013 02:37:49 -0800 (PST)
Received: by mail-ea0-f174.google.com with SMTP id 1so87636eaa.5 for ; Tue, 12 Feb 2013 02:37:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=dHUQE2KGB7b9JmFX9a8P2VXoGU6Mh9c/LNP/PAc+PrU=; b=xK69HB7wmSyUWi5j9hNo/2YUhzKzoKIJ6WBn79a3a09Jq/7XdePzktBemLK86rKMBj 5g9A9RELFeUzOKtY9zCIwaogD/PZG2rNmsYWWl634J/ADTRNRlpCjXUAom+GZ32y5rUe sRFtgVcta85NPZXZ6ZLxDR79XDILBqMFeL/wyvZlWFkAMmoXP21+xE6WEKlMyAwXgT0o Dxu4mH3+oUMRkbk0r5LKgcS2ThYF50FPooV3UfAaam7hzrkVWWMht2oJ2Hb1cFe1n5cR gSyuncpyeSXm9DjPsz0ZIrjM7CD/Lxu+yjIcPBCwToPlerghQDD1LqnPgsqTBoy6ZJfY bTLw==
X-Received: by 10.14.193.198 with SMTP id k46mr60842721een.40.1360665468261; Tue, 12 Feb 2013 02:37:48 -0800 (PST)
Received: from [10.36.226.5] ([217.173.99.61]) by mx.google.com with ESMTPS id 44sm67090960eek.5.2013.02.12.02.37.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 02:37:47 -0800 (PST)
Message-ID: <511A1B78.1050107@gmail.com>
Date: Tue, 12 Feb 2013 10:37:44 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: oauth@ietf.org
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net>
In-Reply-To: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 10:37:50 -0000

Hi Hannes, All,
On 12/02/13 09:10, Hannes Tschofenig wrote:
> Here are my notes.
>
> Participants:
>
> * John Bradley
> * Derek Atkins
> * Phil Hunt
> * Prateek Mishra
> * Hannes Tschofenig
> * Mike Jones
> * Antonio Sanso
> * Justin Richer
>
> Notes:
>
> My slides are available here: http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
>
> Slide #2 summarizes earlier discussions during the conference calls.
>
> -- HTTP vs. JSON
>
> Phil noted that he does not like to use the MAC Token draft as a starting point because it does not re-use any of the work done in the JOSE working group and in particular all the libraries that are available today. He mentioned that earlier attempts to write the MAC Token code lead to problems for implementers.
>

I'm concerned that the argument about the arguable absence of utilities 
for processing MAC tokens; it is obvious it is simpler to process MAC 
than more involved tokens and to be honest it is really not a point at 
all as the utility of a given token type should be judged on what it can 
bring to the whole system as opposed to whether it can be simpler or not 
to implement it - apologies if I've misread the above note and/or taken 
it out of context

Thanks, Sergey

> Justin responded that he does not agree with using JSON as a transport mechanism since this would replicate a SOAP style.
>
> Phil noted that he wants to send JSON but the signature shall be computed over the HTTP header field.
>
> -- Flexibility for the keyed message digest computation
>
>  From earlier discussion it was clear that the conference call participants wanted more flexibility regarding the keyed message digest computation. For this purpose Hannes presented the DKIM based approach, which allows selective header fields to be included in the digest. This is shown in slide #4.
>
> After some discussion the conference call participants thought that this would meet their needs. Further investigations would still be useful to determine the degree of failed HMAC calculations due to HTTP proxies modifying the content.
>
> -- Key Distribution
>
> Hannes presented the open issue regarding the choice of key distribution. Slides #6-#8 present three techniques and Hannes asked for feedback regarding the preferred style. Justin and others didn't see the need to decide on one mechanism - they wanted to keep the choice open. Derek indicated that this will not be an acceptable approach. Since the resource server and the authorization server may, in the OAuth 2.0 framework, be entities produced by different vendors there is an interoperability need. Justin responded that he disagrees and that the resource server needs to understand the access token and referred to the recent draft submission for the token introspection endpoint. Derek indicated that the resource server has to understand the content of the access token and the token introspection endpoint just pushes the problem around: the resource server has to send the access token to the authorization server and then the resource server gets the result back (which he then
  a
>   gain needs to understand) in order to make a meaningful authorization decision.
>
> Everyone agreed that the client must receive the session key from the authorization server and that this approach has to be standardized. It was also agreed that this is a common approach among all three key distribution mechanisms.
>
> Hannes asked the participants to think about their preference.
>
> The questions regarding key naming and the indication for the intended resource server the client wants to talk to have been postponed.
>
> Ciao
> Hannes
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From hannes.tschofenig@gmx.net  Tue Feb 12 03:06:56 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7CE21F8CEE for ; Tue, 12 Feb 2013 03:06:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.811
X-Spam-Level: 
X-Spam-Status: No, score=-100.811 tagged_above=-999 required=5 tests=[AWL=-0.791, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTdt+FgvOaQ3 for ; Tue, 12 Feb 2013 03:06:55 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 5349F21F8CEB for ; Tue, 12 Feb 2013 03:06:55 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.31]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MQsi0-1UU0t52N4g-00UJkh for ; Tue, 12 Feb 2013 12:06:49 +0100
Received: (qmail invoked by alias); 12 Feb 2013 11:06:49 -0000
Received: from unknown (EHLO [10.255.128.222]) [194.251.119.201] by mail.gmx.net (mp031) with SMTP; 12 Feb 2013 12:06:49 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19RmZFAfAFRbTwPAPS3hOwR36d8F40YwnE1EVeK1o QyFcuiKehgCR66
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Hannes Tschofenig 
In-Reply-To: 
Date: Tue, 12 Feb 2013 13:06:47 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <49D2CAF1-61AE-4DEB-A59D-D3F8F6D9C701@gmx.net>
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net> <1360661249.62997.YahooMailNeo@web31803.mail.mud.yahoo.com> <103117A9-0922-4E1A-AC73-D2914743046C@gmx.net> 
To: Antonio Sanso 
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 11:06:56 -0000

The transport of the session key from the authorization server is =
described in Section 5.1 and is called "mac_key".=20

The mechanism to transport the session key from the authorization server =
to the resource server is not yet described in the document. This has =
historical reasons: OAuth 1.0 did not separate the authorization server =
from the resource server in the way OAuth 2.0 does.

Ciao
Hannes

On Feb 12, 2013, at 12:28 PM, Antonio Sanso wrote:

> Hi Hannes,
>=20
> how this session key "differs" from the key described in the current =
draft [0]?
>=20
> Thanks and regards
>=20
> Antonio
>=20
> [0] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02
>=20
> On Feb 12, 2013, at 10:44 AM, Hannes Tschofenig wrote:
>=20
>> Hi Bill,=20
>>=20
>> On Feb 12, 2013, at 11:27 AM, William Mills wrote:
>>=20
>>> Is key distribution how AS and PR share keys  for token =
encryption/decryption or specifically about the keys for the HOK tokens?
>>>=20
>> In order for the client to compute the keyed message digest it needs =
to have the session key. This session key is sent from the authorization =
server to the client and everyone on the call agreed that this has to be =
standardized.=20
>>=20
>> The resource server who receives the message from the client also =
needs to have the session key to verify the message. How the resource =
server obtains this session key was subject for some discussion on the =
call. I presented three different ways of how the resource server is =
able to obtain that key. We have to decide on one mandatory-to-implement =
mechanism. The open issue is which one?=20
>>=20
>>> For the MAC token spec, I don't actually care whether we use JSON or =
now, but I'm in full agreement that we do NOT duplicate any HTTP info =
into the JSON.  Just signatures of that stuff.
>>>=20
>> I believe the folks on the call also agreed with you on that aspect =
that the content of the HTTP message should not be replicated in the =
JSON payload itself.=20
>>=20
>> Ciao
>> Hannes
>>=20
>>> From: Hannes Tschofenig 
>>> To: IETF oauth WG =20
>>> Sent: Tuesday, February 12, 2013 1:10 AM
>>> Subject: [OAUTH-WG] Minutes from the OAuth Design Team Conference =
Call - 11th February 2013
>>>=20
>>> Here are my notes.=20
>>>=20
>>> Participants:
>>>=20
>>> * John Bradley
>>> * Derek Atkins
>>> * Phil Hunt
>>> * Prateek Mishra
>>> * Hannes Tschofenig
>>> * Mike Jones
>>> * Antonio Sanso
>>> * Justin Richer
>>>=20
>>> Notes:=20
>>>=20
>>> My slides are available here: =
http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
>>>=20
>>> Slide #2 summarizes earlier discussions during the conference calls.=20=

>>>=20
>>> -- HTTP vs. JSON
>>>=20
>>> Phil noted that he does not like to use the MAC Token draft as a =
starting point because it does not re-use any of the work done in the =
JOSE working group and in particular all the libraries that are =
available today. He mentioned that earlier attempts to write the MAC =
Token code lead to problems for implementers.=20
>>>=20
>>> Justin responded that he does not agree with using JSON as a =
transport mechanism since this would replicate a SOAP style.=20
>>>=20
>>> Phil noted that he wants to send JSON but the signature shall be =
computed over the HTTP header field.=20
>>>=20
>>> -- Flexibility for the keyed message digest computation
>>>=20
>>> =46rom earlier discussion it was clear that the conference call =
participants wanted more flexibility regarding the keyed message digest =
computation. For this purpose Hannes presented the DKIM based approach, =
which allows selective header fields to be included in the digest. This =
is shown in slide #4.=20
>>>=20
>>> After some discussion the conference call participants thought that =
this would meet their needs. Further investigations would still be =
useful to determine the degree of failed HMAC calculations due to HTTP =
proxies modifying the content.=20
>>>=20
>>> -- Key Distribution
>>>=20
>>> Hannes presented the open issue regarding the choice of key =
distribution. Slides #6-#8 present three techniques and Hannes asked for =
feedback regarding the preferred style. Justin and others didn't see the =
need to decide on one mechanism - they wanted to keep the choice open. =
Derek indicated that this will not be an acceptable approach. Since the =
resource server and the authorization server may, in the OAuth 2.0 =
framework, be entities produced by different vendors there is an =
interoperability need. Justin responded that he disagrees and that the =
resource server needs to understand the access token and referred to the =
recent draft submission for the token introspection endpoint. Derek =
indicated that the resource server has to understand the content of the =
access token and the token introspection endpoint just pushes the =
problem around: the resource server has to send the access token to the =
authorization server and then the resource server gets the result back =
(which he then
>> a
>>> gain needs to understand) in order to make a meaningful =
authorization decision.=20
>>>=20
>>> Everyone agreed that the client must receive the session key from =
the authorization server and that this approach has to be standardized. =
It was also agreed that this is a common approach among all three key =
distribution mechanisms.
>>>=20
>>> Hannes asked the participants to think about their preference.=20
>>>=20
>>> The questions regarding key naming and the indication for the =
intended resource server the client wants to talk to have been =
postponed.=20
>>>=20
>>> Ciao
>>> Hannes
>>>=20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20

From sberyozkin@gmail.com  Tue Feb 12 03:25:12 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E58F21F8CE8 for ; Tue, 12 Feb 2013 03:25:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72M278bIR6qb for ; Tue, 12 Feb 2013 03:25:11 -0800 (PST)
Received: from mail-ee0-f53.google.com (mail-ee0-f53.google.com [74.125.83.53]) by ietfa.amsl.com (Postfix) with ESMTP id 077E021F8CDF for ; Tue, 12 Feb 2013 03:25:10 -0800 (PST)
Received: by mail-ee0-f53.google.com with SMTP id e53so3731000eek.12 for ; Tue, 12 Feb 2013 03:25:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=14EyA+DQm6s//Eb0iqo+cOPc/gRXvsgIB732ao8Leto=; b=O0yFavUg8lkRjmcuyH+rteP5wBFPq0Pbi0GO8fAYnYOJ8eeVwYpzhZIZg6ZBiuIJZr a261Rb/W36xGS5uZD1xJTmC+FxC6I5dN6fK6Au+p5TCL+f8slCMeMrDVD0oPPdLZUNuW jIserObN0HEEqVMnbHSi3WnIBczJHpwNyZbibyDSJDZG44y/i9RC1LiZFX4IPtptfRwp V7ZvlSQINZsWnEBvHmJcO/K/eeo2ou4Cvbi0BC3KRCR1WKzmSmjVUCaowo78nm205BTI EZyuiQp4N/Yra9I4Hg0QwPTEBc4hsiTMeEADLYqUdFLA7fBFE5aIcb84vd9Ee6rz4nEh rTHw==
X-Received: by 10.14.200.137 with SMTP id z9mr61200670een.20.1360668310027; Tue, 12 Feb 2013 03:25:10 -0800 (PST)
Received: from [10.36.226.5] ([217.173.99.61]) by mx.google.com with ESMTPS id l8sm33277732een.10.2013.02.12.03.25.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 03:25:08 -0800 (PST)
Message-ID: <511A2692.2070209@gmail.com>
Date: Tue, 12 Feb 2013 11:25:06 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: oauth@ietf.org
References: <51195F39.3040809@mitre.org> <4E1F6AAD24975D4BA5B16804296739436743E3DD@TK5EX14MBXC285.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436743E3DD@TK5EX14MBXC285.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [OAUTH-WG] Registration: Endpoint Definition (& operation parameter)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 11:25:12 -0000

Hi Mike,
On 12/02/13 01:26, Mike Jones wrote:
> At most, there should be two endpoints - creation and management - for a client, but the protocol should be structured such that they *can* be at the same URL, if the server so chooses.  A simple way to accomplish this is to require that the client_id value be provided as an input parameter on update operations.  Then for implementations that use a single endpoint, they can distinguish "create" and "update" operations on the management endpoint by the presence or absence of the client_id value.
>
Perhaps the text can be relaxed somehow to not refer to

/register
and
/register/{client_id}

as two different endpoints ? I think it is a single endpoint from the 
implementation point of view :-).

Or may be the spec can indeed be relaxed a bit and allow for a PUT form 
payload be sent directly to /register

Cheers, Sergey

> If you want to have separate endpoints and don't need the client_id because you have somehow encoded it into the management endpoint URL, that's fine.  It still can serve as a useful cross-check that the client (or an attacker) is requesting a change to a client that matches the bearer token used.  But including it is necessary for implementations that want to use a single registration endpoint, rather than having a proliferation of per-client endpoints.
>
> BTW, just for the record, OAuth 2.0 uses the same endpoint for initial access token requests and requests for refreshed access tokens - with the operations being distinguished by whether a refresh_token parameter is present.  So there's a useful OAuth precedent for doing things this way.
>
> 				-- Mike
>
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
> Sent: Monday, February 11, 2013 1:15 PM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Registration: Endpoint Definition (&  operation parameter)
>
> Draft -05 of OAuth Dynamic Client Registration [1] defines three fundamental operations that a client can undertake: Client Registration, Client Update, and Secret Rotation. Each of these actions needs to be differentiated *somehow* by the client and server as part of the protocol. Draft -00 defined only the "register" operation, drafts -01 through -04 made use of an "operation" parameter on a single endpoint, which brought up a long discussion on the list on whether or not that was an appropriate design. Draft -05 did away with the definition of the "operation" parameter on a single endpoint and instead opted for separating the base functionality into three different endpoints.
>
> Pro:
>    - Closer to RESTful semantics of having one URL for creation and another URL for management of an item (eg, most REST APIs use /object for creation and /object/object_id for manipulation)
>    - The rest of OAuth (and its extensions) defines separate endpoints for different actions (Authorization, Token, Revocation, Introspection) as opposed to a single endpoint with a mode-switch parameter
>    - Client doesn't have to generate a URL string for different endpoints by combining parameters with a base URL
>
> Con:
>    - Not quite exactly RESTful as the spec doesn't dictate the client_id
> be part of the update or rotate URL (though and implementor's note
> suggests this)
>    - Client has to track different URLs for different actions
>    - Server must be able to differentiate actions based on these
> different URLs.
>
> Alternatives include using different HTTP verbs (see other thread) or
> defining an operational switch parameter, like older drafts, on a single
> endpoint URL. Another suggested alternative is to look for the presence
> of certain parameters, such as client_id or the registration access
> token, to indicate that a different operation is requested.
>
> There's also question of whether the Secret Rotation action needs to
> have its own endpoint, or if it can be collapsed into one of the others.
> It has been suggested off-list that the secret rotation should never be
> initiated by the Client but instead the client should simply request its
> latest secret from the server through the update (or read) semantics.
>
>    -- Justin
>
> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
> _______________________________________________
> 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

From asanso@adobe.com  Tue Feb 12 03:53:13 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C3921F88DB for ; Tue, 12 Feb 2013 03:53:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfCD-YrO-J2k for ; Tue, 12 Feb 2013 03:53:12 -0800 (PST)
Received: from exprod6og125.obsmtp.com (exprod6og125.obsmtp.com [64.18.1.218]) by ietfa.amsl.com (Postfix) with ESMTP id 5789B21F88E1 for ; Tue, 12 Feb 2013 03:53:09 -0800 (PST)
Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob125.postini.com ([64.18.5.12]) with SMTP ID DSNKURotJaX9F9mZ0ZevsPYmkoFUmz8leuBf@postini.com; Tue, 12 Feb 2013 03:53:12 PST
Received: from inner-relay-4.eur.adobe.com (inner-relay-4.adobe.com [193.104.215.14]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r1CBo41v024724; Tue, 12 Feb 2013 03:50:04 -0800 (PST)
Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id r1CBr6XL018934; Tue, 12 Feb 2013 03:53:06 -0800 (PST)
Received: from eurhub01.eur.adobe.com (10.128.4.30) by nacas02.corp.adobe.com (10.8.189.100) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 12 Feb 2013 03:53:05 -0800
Received: from eurmbx01.eur.adobe.com ([10.128.4.32]) by eurhub01.eur.adobe.com ([10.128.4.30]) with mapi; Tue, 12 Feb 2013 11:51:52 +0000
From: Antonio Sanso 
To: Hannes Tschofenig 
Date: Tue, 12 Feb 2013 11:51:51 +0000
Thread-Topic: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
Thread-Index: Ac4JF1kCLPYZ7Ba5Tjev+rm0zUjUsg==
Message-ID: <3F39ADEE-C072-4EE0-9C2A-4B0C93810449@adobe.com>
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net> <1360661249.62997.YahooMailNeo@web31803.mail.mud.yahoo.com> <103117A9-0922-4E1A-AC73-D2914743046C@gmx.net>  <49D2CAF1-61AE-4DEB-A59D-D3F8F6D9C701@gmx.net>
In-Reply-To: <49D2CAF1-61AE-4DEB-A59D-D3F8F6D9C701@gmx.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 11:53:13 -0000

Thanks Hannes

On Feb 12, 2013, at 12:06 PM, Hannes Tschofenig wrote:

> The transport of the session key from the authorization server is describ=
ed in Section 5.1 and is called "mac_key".=20
>=20
> The mechanism to transport the session key from the authorization server =
to the resource server is not yet described in the document. This has histo=
rical reasons: OAuth 1.0 did not separate the authorization server from the=
 resource server in the way OAuth 2.0 does.

but why do not we hit this same issue in the JWS case? In this situation th=
ere is as well a key for sign... And AS and RS can be as well two different=
 entities...

Regards

Antonio

>=20
> Ciao
> Hannes
>=20
> On Feb 12, 2013, at 12:28 PM, Antonio Sanso wrote:
>=20
>> Hi Hannes,
>>=20
>> how this session key "differs" from the key described in the current dra=
ft [0]?
>>=20
>> Thanks and regards
>>=20
>> Antonio
>>=20
>> [0] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02
>>=20
>> On Feb 12, 2013, at 10:44 AM, Hannes Tschofenig wrote:
>>=20
>>> Hi Bill,=20
>>>=20
>>> On Feb 12, 2013, at 11:27 AM, William Mills wrote:
>>>=20
>>>> Is key distribution how AS and PR share keys  for token encryption/dec=
ryption or specifically about the keys for the HOK tokens?
>>>>=20
>>> In order for the client to compute the keyed message digest it needs to=
 have the session key. This session key is sent from the authorization serv=
er to the client and everyone on the call agreed that this has to be standa=
rdized.=20
>>>=20
>>> The resource server who receives the message from the client also needs=
 to have the session key to verify the message. How the resource server obt=
ains this session key was subject for some discussion on the call. I presen=
ted three different ways of how the resource server is able to obtain that =
key. We have to decide on one mandatory-to-implement mechanism. The open is=
sue is which one?=20
>>>=20
>>>> For the MAC token spec, I don't actually care whether we use JSON or n=
ow, but I'm in full agreement that we do NOT duplicate any HTTP info into t=
he JSON.  Just signatures of that stuff.
>>>>=20
>>> I believe the folks on the call also agreed with you on that aspect tha=
t the content of the HTTP message should not be replicated in the JSON payl=
oad itself.=20
>>>=20
>>> Ciao
>>> Hannes
>>>=20
>>>> From: Hannes Tschofenig 
>>>> To: IETF oauth WG =20
>>>> Sent: Tuesday, February 12, 2013 1:10 AM
>>>> Subject: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call=
 - 11th February 2013
>>>>=20
>>>> Here are my notes.=20
>>>>=20
>>>> Participants:
>>>>=20
>>>> * John Bradley
>>>> * Derek Atkins
>>>> * Phil Hunt
>>>> * Prateek Mishra
>>>> * Hannes Tschofenig
>>>> * Mike Jones
>>>> * Antonio Sanso
>>>> * Justin Richer
>>>>=20
>>>> Notes:=20
>>>>=20
>>>> My slides are available here: http://www.tschofenig.priv.at/OAuth2-Sec=
urity-11Feb2013.ppt
>>>>=20
>>>> Slide #2 summarizes earlier discussions during the conference calls.=20
>>>>=20
>>>> -- HTTP vs. JSON
>>>>=20
>>>> Phil noted that he does not like to use the MAC Token draft as a start=
ing point because it does not re-use any of the work done in the JOSE worki=
ng group and in particular all the libraries that are available today. He m=
entioned that earlier attempts to write the MAC Token code lead to problems=
 for implementers.=20
>>>>=20
>>>> Justin responded that he does not agree with using JSON as a transport=
 mechanism since this would replicate a SOAP style.=20
>>>>=20
>>>> Phil noted that he wants to send JSON but the signature shall be compu=
ted over the HTTP header field.=20
>>>>=20
>>>> -- Flexibility for the keyed message digest computation
>>>>=20
>>>> From earlier discussion it was clear that the conference call particip=
ants wanted more flexibility regarding the keyed message digest computation=
. For this purpose Hannes presented the DKIM based approach, which allows s=
elective header fields to be included in the digest. This is shown in slide=
 #4.=20
>>>>=20
>>>> After some discussion the conference call participants thought that th=
is would meet their needs. Further investigations would still be useful to =
determine the degree of failed HMAC calculations due to HTTP proxies modify=
ing the content.=20
>>>>=20
>>>> -- Key Distribution
>>>>=20
>>>> Hannes presented the open issue regarding the choice of key distributi=
on. Slides #6-#8 present three techniques and Hannes asked for feedback reg=
arding the preferred style. Justin and others didn't see the need to decide=
 on one mechanism - they wanted to keep the choice open. Derek indicated th=
at this will not be an acceptable approach. Since the resource server and t=
he authorization server may, in the OAuth 2.0 framework, be entities produc=
ed by different vendors there is an interoperability need. Justin responded=
 that he disagrees and that the resource server needs to understand the acc=
ess token and referred to the recent draft submission for the token introsp=
ection endpoint. Derek indicated that the resource server has to understand=
 the content of the access token and the token introspection endpoint just =
pushes the problem around: the resource server has to send the access token=
 to the authorization server and then the resource server gets the result b=
ack (which he then
>>> a
>>>> gain needs to understand) in order to make a meaningful authorization =
decision.=20
>>>>=20
>>>> Everyone agreed that the client must receive the session key from the =
authorization server and that this approach has to be standardized. It was =
also agreed that this is a common approach among all three key distribution=
 mechanisms.
>>>>=20
>>>> Hannes asked the participants to think about their preference.=20
>>>>=20
>>>> The questions regarding key naming and the indication for the intended=
 resource server the client wants to talk to have been postponed.=20
>>>>=20
>>>> Ciao
>>>> Hannes
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>=20
>>>>=20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>=20

From jricher@mitre.org  Tue Feb 12 06:24:19 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B974621F8B6D for ; Tue, 12 Feb 2013 06:24:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.574
X-Spam-Level: 
X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.024,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiQGFP9WFNsZ for ; Tue, 12 Feb 2013 06:24:18 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEC721F8B3B for ; Tue, 12 Feb 2013 06:24:17 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 201EB53117E2; Tue, 12 Feb 2013 09:24:14 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id DE8CA1F17B1; Tue, 12 Feb 2013 09:24:13 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 12 Feb 2013 09:24:13 -0500
Message-ID: <511A5062.5010108@mitre.org>
Date: Tue, 12 Feb 2013 09:23:30 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Richard Harrington 
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com> <5112AE0B.1080501@mitre.org>  <5113C3AA.1040701@mitre.org>  <5113DDB2.7060805@mitre.org>  <51196777.6000502@mitre.org>  
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080204030402040100020608"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 14:24:19 -0000

--------------080204030402040100020608
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit

OK, I can see the wisdom in changing this term.

I picked "valid" because I wanted a simple "boolean" value that would 
require no additional parsing or string-matching on the client's behalf, 
and I'd like to stick with that. OAuth is built with the assumption that 
clients need to be able to recover from invalid tokens at any stage, so 
I think a simple yes/no is the right step here.

That said, I think you're both right that "valid" seems to have caused a 
bit of confusion. I don't want to go with "revoked" because I'd rather 
have the "token is OK" be the positive boolean value.

Would "valid_token" be more clear? Or do we need a different adjective 
all together?

  -- Justin

On 02/11/2013 08:02 PM, Richard Harrington wrote:
> Have you considered "status" instead of "valid"?  It could have values 
> like "active", "expired", and "revoked".
>
> Is it worthwhile including the status of the client also?  For 
> example, a client application could be disabled, temporarily or 
> permanently, and thus disabling its access tokens as well.
>
>
> On Feb 11, 2013, at 1:56 PM, Prabath Siriwardena  > wrote:
>
>> I guess confusion is with 'valid' parameter is in the response..
>>
>> I thought this will be helpful to standardize the communication 
>> between Resource Server and the Authorization Server..
>>
>> I would suggest we completely remove "valid" from the response - or 
>> define it much clearly..
>>
>> May be can add "revoked" with a boolean attribute..
>>
>> Thanks & regards,
>> -Prabath
>>
>> On Tue, Feb 12, 2013 at 3:19 AM, Justin Richer > > wrote:
>>
>>
>>     On 02/08/2013 12:51 AM, Prabath Siriwardena wrote:
>>>     Hi Justin,
>>>
>>>     I have couple of questions related to "valid" parameter...
>>>
>>>     This endpoint can be invoked by the Resource Server in runtime...
>>
>>     That's correct.
>>
>>
>>>
>>>     In that case what is exactly meant by the "resource_id" in request ?
>>
>>     The resource_id field is a service-specific string that basically
>>     lets the resource server provide some context to the request to
>>     the auth server. There have been some other suggestions like
>>     client IP address, but I wanted to put this one in because it
>>     seemed to be a common theme. The client is trying to do
>>     *something* with the token, after all, and the rights,
>>     permissions, and metadata associated with the token could change
>>     based on that. Since the Introspection endpoint is all about
>>     getting that metadata back to the PR, this seemed like a good idea.
>>
>>
>>>
>>>     IMO a token to be valid depends on set of criteria based on it's
>>>     type..
>>>
>>>     For a Bearer token..
>>>
>>>     1. Token should not be expired
>>>     2. Token should not be revoked.
>>>     3. The scope the token issued should match with the scope
>>>     required for the resource.
>>>
>>>     For a MAC token...
>>>
>>>     1. Token not expired (mac id)
>>>     2. Token should not be revoked
>>>     3. The scope the token issued should match with the scope
>>>     required for the resource.
>>>     4. HMAC check should be valid
>>>
>>>     There are similar conditions for SAML bearer too..
>>
>>     This isn't really true. The SAML bearer token is fully
>>     self-contained and doesn't change based on other parameters in
>>     the message, unlike MAC. Same with JWT. When it hands a SAML or
>>     JWT token to the AS, the PR has given *everything* the server
>>     needs to check that token's validity and use.
>>
>>     MAC signatures change with every message, and they're done across
>>     several components of the HTTP message. Therefor, the HMAC check
>>     for MAC style tokens will still need to be done by the protected
>>     resource. Introspection would help in the case that the signature
>>     validated just fine, but the token might have expired. Or you
>>     need to know what scopes apply. Introspection isn't to fully
>>     validate the call to the protected resource -- if that were the
>>     case, the PR would have to send some kind of encapsulated version
>>     of the original request. Otherwise, the AS won't have all of the
>>     information it needs to check the MAC.
>>
>>
>>     I think what you're describing is ultimately *not* what the
>>     introspection endpoint is intended to do. If that's unclear from
>>     the document, can you please suggest text that would help clear
>>     the use case up? I wouldn't want it to be ambiguous.
>>
>>      -- Justin
>>
>>
>>>
>>>     Thanks & regards,
>>>     -Prabath
>>>
>>>
>>>     On Thu, Feb 7, 2013 at 10:30 PM, Justin Richer
>>>     > wrote:
>>>
>>>         It validates the token, which would be either the token
>>>         itself in the case of Bearer or the token "id" part of
>>>         something more complex like MAC. It doesn't directly
>>>         validate the usage of the token, that's still up to the PR
>>>         to do that.
>>>
>>>         I nearly added a "token type" field in this draft, but held
>>>         back because there are several kinds of "token type" that
>>>         people talk about in OAuth. First, there's "Bearer" vs.
>>>         "MAC" vs. "HOK", or what have you. Then within Bearer you
>>>         have "JWT" or "SAML" or "unstructured blob". Then you've
>>>         also got "access" vs. "refresh" and other flavors of token,
>>>         like the id_token in OpenID Connect.
>>>
>>>         Thing is, the server running the introspection endpoint will
>>>         probably know *all* of these. But should it tell the client?
>>>         If so, which of the three, and what names should the fields be?
>>>
>>>          -- Justin
>>>
>>>
>>>         On 02/07/2013 11:26 AM, Prabath Siriwardena wrote:
>>>>         Okay.. I was thinking this could be used as a way to
>>>>         validate the token as well. BTW even in this case shouldn't
>>>>         communicate the type of token to AS? For example in the
>>>>         case of SAML profile - it could be SAML token..
>>>>
>>>>         Thanks & regards,
>>>>         -Prabath
>>>>
>>>>         On Thu, Feb 7, 2013 at 8:39 PM, Justin Richer
>>>>         > wrote:
>>>>
>>>>             "valid" might not be the best term, but it's meant to
>>>>             be a field where the server says "yes this token is
>>>>             still good" or "no this token isn't good anymore". We
>>>>             could instead do this with HTTP codes or something but
>>>>             I went with a pure JSON response.
>>>>
>>>>              -- Justin
>>>>
>>>>
>>>>             On 02/06/2013 10:47 PM, Prabath Siriwardena wrote:
>>>>>             Hi Justin,
>>>>>
>>>>>             I believe this is addressing one of the key missing
>>>>>             part in OAuth 2.0...
>>>>>
>>>>>             One question - I guess this was discussed already...
>>>>>
>>>>>             In the spec - in the introspection response it has the
>>>>>             attribute "valid" - this is basically the validity of
>>>>>             the token provided in the request.
>>>>>
>>>>>             Validation criteria depends on the token and well as
>>>>>             token type ( Bearer, MAC..).
>>>>>
>>>>>             In the spec it seems like it's coupled with Bearer
>>>>>             token type... But I guess, by adding "token_type" to
>>>>>             the request we can remove this dependency.
>>>>>
>>>>>             WDYT..?
>>>>>
>>>>>             Thanks & regards,
>>>>>             -Prabath
>>>>>
>>>>>             On Thu, Feb 7, 2013 at 12:54 AM, Justin Richer
>>>>>             > wrote:
>>>>>
>>>>>                 Updated introspection draft based on recent
>>>>>                 comments. Changes include:
>>>>>
>>>>>                  - "scope" return parameter now follows RFC6749
>>>>>                 format instead of JSON array
>>>>>                  - "subject" -> "sub", and "audience" -> "aud", to
>>>>>                 be parallel with JWT claims
>>>>>                  - clarified what happens if the authentication is bad
>>>>>
>>>>>                  -- Justin
>>>>>
>>>>>
>>>>>                 -------- Original Message --------
>>>>>                 Subject: 	New Version Notification for
>>>>>                 draft-richer-oauth-introspection-02.txt
>>>>>                 Date: 	Wed, 6 Feb 2013 11:24:20 -0800
>>>>>                 From: 	
>>>>>                 
>>>>>                 To: 	 
>>>>>
>>>>>
>>>>>
>>>>>                 A new version of I-D, draft-richer-oauth-introspection-02.txt
>>>>>                 has been successfully submitted by Justin Richer and posted to the
>>>>>                 IETF repository.
>>>>>
>>>>>                 Filename:	 draft-richer-oauth-introspection
>>>>>                 Revision:	 02
>>>>>                 Title:		 OAuth Token Introspection
>>>>>                 Creation date:	 2013-02-06
>>>>>                 WG ID:		 Individual Submission
>>>>>                 Number of pages: 6
>>>>>                 URL:http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
>>>>>                 Status:http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
>>>>>                 Htmlized:http://tools.ietf.org/html/draft-richer-oauth-introspection-02
>>>>>                 Diff:http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02
>>>>>
>>>>>                 Abstract:
>>>>>                     This specification defines a method for a client or protected
>>>>>                     resource to query an OAuth authorization server to determine meta-
>>>>>                     information about an OAuth token.
>>>>>
>>>>>
>>>>>                                                                                                    
>>>>>
>>>>>
>>>>>                 The IETF Secretariat
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>                 _______________________________________________
>>>>>                 OAuth mailing list
>>>>>                 OAuth@ietf.org 
>>>>>                 https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>             -- 
>>>>>             Thanks & Regards,
>>>>>             Prabath
>>>>>
>>>>>             Mobile : +94 71 809 6732 
>>>>>
>>>>>             http://blog.facilelogin.com
>>>>>             http://RampartFAQ.com
>>>>
>>>>
>>>>
>>>>
>>>>         -- 
>>>>         Thanks & Regards,
>>>>         Prabath
>>>>
>>>>         Mobile : +94 71 809 6732 
>>>>
>>>>         http://blog.facilelogin.com
>>>>         http://RampartFAQ.com
>>>
>>>
>>>
>>>
>>>     -- 
>>>     Thanks & Regards,
>>>     Prabath
>>>
>>>     Mobile : +94 71 809 6732 
>>>
>>>     http://blog.facilelogin.com
>>>     http://RampartFAQ.com
>>
>>
>>
>>
>> -- 
>> Thanks & Regards,
>> Prabath
>>
>> Mobile : +94 71 809 6732
>>
>> http://blog.facilelogin.com
>> http://RampartFAQ.com
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth

--------------080204030402040100020608
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 8bit

    OK, I can see the wisdom in changing this term. 

    I picked "valid" because I wanted a simple "boolean" value that
    would require no additional parsing or string-matching on the
    client's behalf, and I'd like to stick with that. OAuth is built
    with the assumption that clients need to be able to recover from
    invalid tokens at any stage, so I think a simple yes/no is the right
    step here. 

    That said, I think you're both right that "valid" seems to have
    caused a bit of confusion. I don't want to go with "revoked" because
    I'd rather have the "token is OK" be the positive boolean value. 

    Would "valid_token" be more clear? Or do we need a different
    adjective all together?

     -- Justin

    On 02/11/2013 08:02 PM, Richard
      Harrington wrote:

      Have you considered "status" instead of "valid"?  It could
        have values like "active", "expired", and "revoked".

      Is it worthwhile including the status of the client also?
         For example, a client application could be disabled,
        temporarily or permanently, and thus disabling its access tokens
        as well.

        On Feb 11, 2013, at 1:56 PM, Prabath Siriwardena <prabath@wso2.com>
        wrote:

        I guess confusion is with 'valid' parameter is in the
          response..

          I thought this will be helpful to standardize the
            communication between Resource Server and the Authorization
            Server..

          I would suggest we completely remove "valid" from the
            response - or define it much clearly..

          May be can add "revoked" with a boolean attribute..

          Thanks & regards,
          -Prabath

            On Tue, Feb 12, 2013 at 3:19 AM,
              Justin Richer <jricher@mitre.org>
              wrote:

                    On 02/08/2013 12:51 AM, Prabath Siriwardena
                      wrote:

                   Hi Justin,

                      I have couple of questions related to "valid"
                        parameter...

                      This endpoint can be invoked by the Resource
                        Server in runtime...

                  That's correct.

                      In that case what is exactly meant by the
                        "resource_id" in request ?

                  The resource_id field is a service-specific string
                  that basically lets the resource server provide some
                  context to the request to the auth server. There have
                  been some other suggestions like client IP address,
                  but I wanted to put this one in because it seemed to
                  be a common theme. The client is trying to do
                  *something* with the token, after all, and the rights,
                  permissions, and metadata associated with the token
                  could change based on that. Since the Introspection
                  endpoint is all about getting that metadata back to
                  the PR, this seemed like a good idea.

                      IMO a token to be valid depends on set of
                        criteria based on it's type..

                      For a Bearer token..

                      1. Token should not be expired
                      2. Token should not be revoked.
                      3. The scope the token issued should match
                        with the scope required for the resource.

                      For a MAC token...

                      1. Token not expired (mac id)
                      2. Token should not be revoked
                      3. The scope the token issued should match
                        with the scope required for the resource.
                      4. HMAC check should be valid

                      There are similar conditions for SAML bearer too..

                  This isn't really true. The SAML bearer token is fully
                  self-contained and doesn't change based on other
                  parameters in the message, unlike MAC. Same with JWT.
                  When it hands a SAML or JWT token to the AS, the PR
                  has given *everything* the server needs to check that
                  token's validity and use. 

                  MAC signatures change with every message, and they're
                  done across several components of the HTTP message.
                  Therefor, the HMAC check for MAC style tokens will
                  still need to be done by the protected resource.
                  Introspection would help in the case that the
                  signature validated just fine, but the token might
                  have expired. Or you need to know what scopes apply.
                  Introspection isn't to fully validate the call to the
                  protected resource -- if that were the case, the PR
                  would have to send some kind of encapsulated version
                  of the original request. Otherwise, the AS won't have
                  all of the information it needs to check the MAC.

                  I think what you're describing is ultimately *not*
                  what the introspection endpoint is intended to do. If
                  that's unclear from the document, can you please
                  suggest text that would help clear the use case up? I
                  wouldn't want it to be ambiguous.

                       -- Justin

                        Thanks & regards,
                        -Prabath

                          On Thu, Feb 7, 2013
                            at 10:30 PM, Justin Richer <jricher@mitre.org>
                            wrote:

                               It
                                validates the token, which would be
                                either the token itself in the case of
                                Bearer or the token "id" part of
                                something more complex like MAC. It
                                doesn't directly validate the usage of
                                the token, that's still up to the PR to
                                do that.

                                I nearly added a "token type" field in
                                this draft, but held back because there
                                are several kinds of "token type" that
                                people talk about in OAuth. First,
                                there's "Bearer" vs. "MAC" vs. "HOK", or
                                what have you. Then within Bearer you
                                have "JWT" or "SAML" or "unstructured
                                blob". Then you've also got "access" vs.
                                "refresh" and other flavors of token,
                                like the id_token in OpenID Connect. 

                                Thing is, the server running the
                                introspection endpoint will probably
                                know *all* of these. But should it tell
                                the client? If so, which of the three,
                                and what names should the fields be?

                                     -- Justin

                                    On 02/07/2013 11:26 AM, Prabath
                                      Siriwardena wrote:

                                     Okay.. I
                                      was thinking this could be used as
                                      a way to validate the token as
                                      well. BTW even in this case
                                      shouldn't communicate the type of
                                      token to AS? For example in the
                                      case of SAML profile - it could be
                                      SAML token..

                                      Thanks & regards,
                                      -Prabath

                                        On Thu,
                                          Feb 7, 2013 at 8:39 PM, Justin
                                          Richer <jricher@mitre.org>
                                          wrote:

                                             "valid"
                                              might not be the best
                                              term, but it's meant to be
                                              a field where the server
                                              says "yes this token is
                                              still good" or "no this
                                              token isn't good anymore".
                                              We could instead do this
                                              with HTTP codes or
                                              something but I went with
                                              a pure JSON response.

                                                   -- Justin

                                                  On 02/06/2013
                                                    10:47 PM, Prabath
                                                    Siriwardena wrote:

                                                   Hi
                                                    Justin,

                                                    I believe this
                                                      is addressing one
                                                      of the key missing
                                                      part in OAuth
                                                      2.0...

                                                    One question -
                                                      I guess this was
                                                      discussed
                                                      already...

                                                    In the spec -
                                                      in the
                                                      introspection
                                                      response it has
                                                      the attribute
                                                      "valid" - this is
                                                      basically the
                                                      validity of the
                                                      token provided in
                                                      the request.

                                                    Validation criteria
                                                      depends on the
                                                      token and well as
                                                      token type (
                                                      Bearer, MAC..).

                                                    In the spec it
                                                      seems like it's
                                                      coupled with
                                                      Bearer token
                                                      type... But I
                                                      guess, by adding
                                                      "token_type" to
                                                      the request we can
                                                      remove this
                                                      dependency.

                                                    WDYT..?

                                                    Thanks &
                                                      regards,
                                                    -Prabath 

                                                      On
                                                        Thu, Feb 7, 2013
                                                        at 12:54 AM,
                                                        Justin Richer <jricher@mitre.org>
                                                        wrote:

                                                          Updated
                                                          introspection
                                                          draft based on
                                                          recent
                                                          comments.
                                                          Changes
                                                          include:

                                                           - "scope"
                                                          return
                                                          parameter now
                                                          follows
                                                          RFC6749 format
                                                          instead of
                                                          JSON array

                                                           - "subject"
                                                          -> "sub",
                                                          and "audience"
                                                          -> "aud",
                                                          to be parallel
                                                          with JWT
                                                          claims

                                                           - clarified
                                                          what happens
                                                          if the
                                                          authentication
                                                          is bad

                                                           -- Justin

                                                          --------
                                                          Original
                                                          Message
                                                          --------

                                                          Subject: 
                                                          New
                                                          Version
                                                          Notification
                                                          for
                                                          draft-richer-oauth-introspection-02.txt

                                                          Date: 
                                                          Wed, 6 Feb
                                                          2013 11:24:20
                                                          -0800

                                                          From: 
                                                          <internet-drafts@ietf.org>

                                                          To: 
                                                          <jricher@mitre.org>

                                                          A new version of I-D, draft-richer-oauth-introspection-02.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 02
Title:		 OAuth Token Introspection
Creation date:	 2013-02-06
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.

The IETF Secretariat

_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

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

                                                      -- 

                                                      Thanks &
                                                      Regards,

                                                      Prabath

                                                      Mobile : +94 71 809 6732 

                                                        http://blog.facilelogin.com

                                                        http://RampartFAQ.com

                                        -- 

                                        Thanks & Regards,

                                        Prabath

                                        Mobile : +94 71 809
                                            6732 

                                          http://blog.facilelogin.com

                                          http://RampartFAQ.com

                          -- 

                          Thanks & Regards,

                          Prabath

                          Mobile : +94
                              71 809 6732 

                            http://blog.facilelogin.com

                            http://RampartFAQ.com

            -- 

            Thanks & Regards,

            Prabath

            Mobile : +94 71 809 6732 

              http://blog.facilelogin.com

              http://RampartFAQ.com

        _______________________________________________

          OAuth mailing list

          OAuth@ietf.org

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

--------------080204030402040100020608--

From jricher@mitre.org  Tue Feb 12 06:25:55 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA29921F8B3B for ; Tue, 12 Feb 2013 06:25:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.574
X-Spam-Level: 
X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.024,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYAfIuYxZVbJ for ; Tue, 12 Feb 2013 06:25:54 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id B55A921F8E70 for ; Tue, 12 Feb 2013 06:25:54 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 59C2B1F16FE; Tue, 12 Feb 2013 09:25:54 -0500 (EST)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 331E21F1772; Tue, 12 Feb 2013 09:25:54 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 12 Feb 2013 09:25:53 -0500
Message-ID: <511A50C7.8080102@mitre.org>
Date: Tue, 12 Feb 2013 09:25:11 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Richard Harrington 
References: <51195F3D.1050006@mitre.org> <222C28CB-7F6F-4BC3-8692-40404C2DC2D3@maymount.com>
In-Reply-To: <222C28CB-7F6F-4BC3-8692-40404C2DC2D3@maymount.com>
Content-Type: multipart/alternative; boundary="------------090702080305050905090000"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 14:25:56 -0000

--------------090702080305050905090000
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit

I'd be fine with the return from a creation request being a 201 instead 
of a 200.

  -- Justin

On 02/11/2013 06:33 PM, Richard Harrington wrote:
> Since the request is an HTTP POST and a resource is created 
> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5) the 
> response should be an HTTP 201 Created 
> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.2) 
> which is supposed to include the location of the newly created resource.
>
> This is a good pattern to follow since, as you say, it does provide 
> flexibility.
>
>
>
> On Feb 11, 2013, at 1:14 PM, Justin Richer  > wrote:
>
>> Draft -05 of OAuth Dynamic Client Registration [1] returns a URL 
>> pointer for the client to perform update and secret rotation actions. 
>> This functionality arose from discussions on the list about moving 
>> towards a more RESTful pattern, and Nat Sakimura proposed this 
>> approach in the OpenID Connect Working Group. This URL may be 
>> distinct from the Client Registration Endpoint URL, but draft -05 
>> makes no promises as to its content, form, or structure, though it 
>> does contain implementor's notes on possible methods.
>>
>> Two questions arise from this change:
>> - The semantics of returning the client manipulation URL
>> - The syntax (derived from HAL for JSON [2], an individual I-D 
>> submission)
>>
>> On semantics:
>>
>> Pro:
>> - The server has flexibility on how to define the "update" endpoint, 
>> sending all clients to one URL, sending different clients to 
>> different URLs, or sending clients to a URL with a baked-in query 
>> parameter
>> - The client can take the URL as-is and use it for all management 
>> operations (ie, it doesn't have to generate or compose the URL based 
>> on component parts)
>>
>> Con:
>> - The client must remember one more piece of information from the 
>> server at runtime if it wants to do manipulation and management of 
>> itself at the server (in addition to client_id, client_secret, 
>> registration_access_token, and others)
>>
>> Alternatives include specifying a URL pattern for the server to use 
>> and all clients to follow, specifying a query parameter for the 
>> update action, and specifying a separate endpoint entirely and using 
>> the presence of items such as client_id and the registration access 
>> token to differentiate the requests. Note that *all* of these 
>> alternatives can be accommodated using the semantics described above, 
>> with the same actions on the client's part.
>>
>>
>> On syntax:
>>
>> Pro:
>> - Follows the designs of RFC5988 for link relations
>> - The HAL format is general, and allows for all kinds of other 
>> information to be placed inside the _links structure
>> - Allows for full use of the JSON object to specify advanced 
>> operations on the returned endpoint if desired
>>
>> Con:
>> - The rest of OAuth doesn't follow link relation guidelines (though 
>> it's been brought up)
>> - The HAL format is general, and allows for all kinds of other 
>> information to be placed inside the _links structure
>> - The HAL-JSON document is an expired individual I-D, and it's 
>> unclear what wider adoption looks like right now
>>
>> Alternatives include returning the URL as a separate data member 
>> (registration_update_url), using HTTP headers, or using JSON Schema.
>>
>> -- Justin
>>
>>
>>
>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>> [2] http://tools.ietf.org/html/draft-kelly-json-hal-03
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth

--------------090702080305050905090000
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 8bit

    I'd be fine with the return from a creation request being a 201
    instead of a 200. 

     -- Justin

    On 02/11/2013 06:33 PM, Richard
      Harrington wrote:

      Since the request is an HTTP POST and a resource is created (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5) the response should be an
          HTTP 201 Created (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.2) which is supposed to include
          the location of the newly created resource.

      This is a good pattern to
          follow since, as you say, it does provide flexibility.

        On Feb 11, 2013, at 1:14 PM, Justin Richer <jricher@mitre.org>
        wrote:

        Draft -05 of OAuth Dynamic Client Registration [1]
            returns a URL pointer for the client to perform update and
            secret rotation actions. This functionality arose from
            discussions on the list about moving towards a more RESTful
            pattern, and Nat Sakimura proposed this approach in the
            OpenID Connect Working Group. This URL may be distinct from
            the Client Registration Endpoint URL, but draft -05 makes no
            promises as to its content, form, or structure, though it
            does contain implementor's notes on possible methods.

          Two questions arise from this change:

           - The semantics of returning the client manipulation
            URL

           - The syntax (derived from HAL for JSON [2], an
            individual I-D submission)

          On semantics:

          Pro:

           - The server has flexibility on how to define the
            "update" endpoint, sending all clients to one URL, sending
            different clients to different URLs, or sending clients to a
            URL with a baked-in query parameter

           - The client can take the URL as-is and use it for all
            management operations (ie, it doesn't have to generate or
            compose the URL based on component parts)

          Con:

           - The client must remember one more piece of
            information from the server at runtime if it wants to do
            manipulation and management of itself at the server (in
            addition to client_id, client_secret,
            registration_access_token, and others)

          Alternatives include specifying a URL pattern for the
            server to use and all clients to follow, specifying a query
            parameter for the update action, and specifying a separate
            endpoint entirely and using the presence of items such as
            client_id and the registration access token to differentiate
            the requests. Note that *all* of these alternatives can be
            accommodated using the semantics described above, with the
            same actions on the client's part.

          On syntax:

          Pro:

           - Follows the designs of RFC5988 for link relations

           - The HAL format is general, and allows for all kinds
            of other information to be placed inside the _links
            structure

           - Allows for full use of the JSON object to specify
            advanced operations on the returned endpoint if desired

          Con:

           - The rest of OAuth doesn't follow link relation
            guidelines (though it's been brought up)

           - The HAL format is general, and allows for all kinds
            of other information to be placed inside the _links
            structure

           - The HAL-JSON document is an expired individual I-D,
            and it's unclear what wider adoption looks like right now

          Alternatives include returning the URL as a separate
            data member (registration_update_url), using HTTP headers,
            or using JSON Schema.

           -- Justin

          [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05

          [2] http://tools.ietf.org/html/draft-kelly-json-hal-03

          _______________________________________________

          OAuth mailing list

          OAuth@ietf.org

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

--------------090702080305050905090000--

From jricher@mitre.org  Tue Feb 12 06:30:27 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D47621F8E1B for ; Tue, 12 Feb 2013 06:30:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.275
X-Spam-Level: 
X-Spam-Status: No, score=-6.275 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mk5CnZXpX7-l for ; Tue, 12 Feb 2013 06:30:26 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2F821F8E19 for ; Tue, 12 Feb 2013 06:30:26 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AC1171F1772; Tue, 12 Feb 2013 09:30:25 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7D3801F1748; Tue, 12 Feb 2013 09:30:25 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 12 Feb 2013 09:30:25 -0500
Message-ID: <511A51D6.9040604@mitre.org>
Date: Tue, 12 Feb 2013 09:29:42 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: John Bradley 
References: <51195F3F.7000704@mitre.org> <4E1F6AAD24975D4BA5B16804296739436743E371@TK5EX14MBXC285.redmond.corp.microsoft.com> <7FB7A108-EA9E-429A-BD86-7E09EA206748@ve7jtb.com>
In-Reply-To: <7FB7A108-EA9E-429A-BD86-7E09EA206748@ve7jtb.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: Client secret rotation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 14:30:27 -0000

This is actually the approach that I favor now as well -- let the server 
do the secret rotation if it wants to, and have the client be prepared 
to receive a new client_secret or registration_access_token on any read 
or update request.

This would necessitate changing the returned values, essentially 
collapsing the returns from the read/update and rotate actions into one 
structure that's closer to the one returned from initial registration. 
This has the added benefit of parallelizing the responses for these 
three actions, which I like as well.

  -- Justin

On 02/11/2013 08:42 PM, John Bradley wrote:
> OAuth doesn't say anything about client secrets other than they are provisioned in a magic realm outside the OAuth spec (Getting in the mood for the next IETF).
>
> Rotating client secrets was something I made up for connect because it seemed like a good idea at the time given that someone breaking in to the registration endpoint could take over a connection.
>
> We later separated the authentication to the token endpoint from the registration endpoint,in what I think was a good move.
>
> It is sort of up to the authorization server to make decisions about rotating client secrets, I expect that in the real world a client would try access ing the token endpoint and get back a invalid_client error response and then heck it's registration to see if the client_secret has changed.
>
> I suppose that a client could request rotating its secret if it thinks it has been compromised,  however the compromiser is more likely to quickly change the secret to lock out the legitimate clients before the good one notices.    I think the client wanting to rotate is enough of a edge case that it could deal with it out of band.
>
> Letting the server rotate the client secret according to what ever policy it decides is best is probably safest.
>
> We didn't have anything for rotating the access token.  I suspect that rotating it under the clients control is going to create as many problems as it solves.
>
> If you want to rotate it,  make it a refresh token that is issues and use OAuth to provide access tokens from the token endpoint.   Creating a new endpoint to duplicate existing OAuth functionality is overkill.
>
> John B.
> On 2013-02-11, at 10:18 PM, Mike Jones  wrote:
>
>> The rotate_secret operation was added to OpenID Connect Registration as a workaround to the fact that registration updates used to be authenticated using the client secret, so it seemed overly dangerous to have an update operation potentially return an updated secret and have the secret be lost due to communication problems - leaving the client stranded.  Since then, registration was changed to use a bearer token to authenticate update operations, and so this failure mode can't occur anymore.  It was an omission not to have deleted the unneeded operation then.
>>
>> It's been deleted from OpenID Connect Registration and should likewise be deleted from OAuth registration, since it is unneeded.  If a new client secret is needed, there's nothing stopping the registration server from returning it in the result of an update operation.
>>
>> 				-- Mike
>>
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
>> Sent: Monday, February 11, 2013 1:15 PM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Registration: Client secret rotation
>>
>> Draft -05 of OAuth Dynamic Client Registration [1] defines a means of the client requesting a new client_secret (if applicable) and a new registration_access_token. Client secrets MAY expire after some period of time, and this method allows for a refresh of that secret. Draft -00 defined no such operation, drafts -01 through -04 defined this operation in terms of the operation=rotate_secret parameter, and draft -05 defines it through a secondary endpoint, the Client Secret Rotation Endpoint.
>> This raises several questions:
>>
>>   - Should the client be allowed to request rotation of its secret?
>>   - Would a client ever take this action of its own accord?
>>   - Can a server rotate the secret of the client without the client asking? (This seems to be an obvious "yes")
>>
>> Alternatives that keep this functionality include defining the rotate_secret operation in terms of an HTTP verb, a query parameter, or separate endpoint. Alternatively, we could drop the rotate_secret operation all together. If we do this, we have to decide if the client secret can still expire. If it can, then we need a way for the client to get this new secret through a means that doesn't require it to request a change in secret, such as sending it back as part of the client READ operation (see other thread on RESTful verbs).
>>
>>   -- Justin
>>
>>
>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>> _______________________________________________
>> 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

From twbray@google.com  Tue Feb 12 06:43:54 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45B221F8E8B for ; Tue, 12 Feb 2013 06:43:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.144
X-Spam-Level: 
X-Spam-Status: No, score=-101.144 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yW-PZiCCBZOn for ; Tue, 12 Feb 2013 06:43:53 -0800 (PST)
Received: from mail-ie0-x231.google.com (ie-in-x0231.1e100.net [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 46B5421F8E87 for ; Tue, 12 Feb 2013 06:43:53 -0800 (PST)
Received: by mail-ie0-f177.google.com with SMTP id 16so179083iea.36 for ; Tue, 12 Feb 2013 06:43:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=hzCjzpyjRGy37joiPH3sCB42s2ZUJ/lKa8pZ9DVepIE=; b=hP4uW6QxetS6UeUGQYlDeNxJ6qGJc8zTypbAf9TWV//dXpVXhgutRQ3rY4CgWW7hgo njze/U3ZOJ5UliP/xeK8ddlGIAm6R0DrS+K5aTflcyKmhuy8UCnw/Rr4p9e7rvQHE2yd KVIGkfC4HstcUldGMwV9oMuXSBqN9jSEvGZH5MZZZYqqcvBuVY7xKHWDmkaL8ciC3EYx LAGNma/9/4H4Ege/RmTttOmK7mA+tPii2uW3HlnDSDBqwvUAoJLGZxv8rOd4D8kSNAXY JueK88vdd74fZBk0TaSiOD7e76F4CRQVazCrpIUWh/ACGKYTW3ZqKgM0WaYUmFv8ksO4 iRKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=hzCjzpyjRGy37joiPH3sCB42s2ZUJ/lKa8pZ9DVepIE=; b=jnTOm04m2c0Rm26Kg3ptEEPtVokTlyAwrQWo01B3GlB7h9sZIinTH368nGFEnIaazb sbEEl0YQ+ZIk+GILB6EzMz/82X3huI/KsjpG2AabW03+dRWUCfzpJzyo3vPm+OlN5Gy0 zxcx3kxYSXv4dMSxYZoSpnjkSXiClwcbGeT3PVzu5F+VEJ4Nfl7MAhtm1ep5dCyysmhz UC5iGpwY8NtBjJgG69MN7pVLG1BFR80i74W7UGCHos1Tcs/fWWEsDM3efce+XWXfIUz7 iBiLBuJSYx0kyL5ljHjdvTMnXdvFHFia2owrHcxxC0w2l1UCn67ceGHuQVMYW4j+gEKi Fowg==
MIME-Version: 1.0
X-Received: by 10.50.208.68 with SMTP id mc4mr3766653igc.35.1360680232583; Tue, 12 Feb 2013 06:43:52 -0800 (PST)
Received: by 10.64.25.17 with HTTP; Tue, 12 Feb 2013 06:43:52 -0800 (PST)
Received: by 10.64.25.17 with HTTP; Tue, 12 Feb 2013 06:43:52 -0800 (PST)
In-Reply-To: <511A2692.2070209@gmail.com>
References: <51195F39.3040809@mitre.org> <4E1F6AAD24975D4BA5B16804296739436743E3DD@TK5EX14MBXC285.redmond.corp.microsoft.com> <511A2692.2070209@gmail.com>
Date: Tue, 12 Feb 2013 06:43:52 -0800
Message-ID: 
From: Tim Bray 
To: Sergey Beryozkin 
Content-Type: multipart/alternative; boundary=14dae93408e7ea831504d5880d86
X-Gm-Message-State: ALoCoQmjtSJfOigh59/zAACUrgOPHrWNYZQenULraUMZcUAavGlvtQMkkjtibFsyWB4z//CcwfI2/d+CXXkFNGFDOVqdGsdMO/Ybmq4BnhPWLLZ9gehPgj3jA7umB3+CwDHoT2kRxZ/FFTCTe1dTfHH3IPCc5D58BEcHPjwgpnNInnj7ePo3bm5Jl6uEgqio35LfGVsrspgk
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Endpoint Definition (& operation parameter)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 14:43:54 -0000

--14dae93408e7ea831504d5880d86
Content-Type: text/plain; charset=UTF-8

?! /foo and /foo/bar are obviously distinct endpoints.
On Feb 12, 2013 3:25 AM, "Sergey Beryozkin"  wrote:

> Hi Mike,
> On 12/02/13 01:26, Mike Jones wrote:
>
>> At most, there should be two endpoints - creation and management - for a
>> client, but the protocol should be structured such that they *can* be at
>> the same URL, if the server so chooses.  A simple way to accomplish this is
>> to require that the client_id value be provided as an input parameter on
>> update operations.  Then for implementations that use a single endpoint,
>> they can distinguish "create" and "update" operations on the management
>> endpoint by the presence or absence of the client_id value.
>>
>>  Perhaps the text can be relaxed somehow to not refer to
>
> /register
> and
> /register/{client_id}
>
> as two different endpoints ? I think it is a single endpoint from the
> implementation point of view :-).
>
> Or may be the spec can indeed be relaxed a bit and allow for a PUT form
> payload be sent directly to /register
>
> Cheers, Sergey
>
>  If you want to have separate endpoints and don't need the client_id
>> because you have somehow encoded it into the management endpoint URL,
>> that's fine.  It still can serve as a useful cross-check that the client
>> (or an attacker) is requesting a change to a client that matches the bearer
>> token used.  But including it is necessary for implementations that want to
>> use a single registration endpoint, rather than having a proliferation of
>> per-client endpoints.
>>
>> BTW, just for the record, OAuth 2.0 uses the same endpoint for initial
>> access token requests and requests for refreshed access tokens - with the
>> operations being distinguished by whether a refresh_token parameter is
>> present.  So there's a useful OAuth precedent for doing things this way.
>>
>>                                 -- Mike
>>
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org**] On Behalf
>> Of Justin Richer
>> Sent: Monday, February 11, 2013 1:15 PM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Registration: Endpoint Definition (&  operation
>> parameter)
>>
>> Draft -05 of OAuth Dynamic Client Registration [1] defines three
>> fundamental operations that a client can undertake: Client Registration,
>> Client Update, and Secret Rotation. Each of these actions needs to be
>> differentiated *somehow* by the client and server as part of the protocol.
>> Draft -00 defined only the "register" operation, drafts -01 through -04
>> made use of an "operation" parameter on a single endpoint, which brought up
>> a long discussion on the list on whether or not that was an appropriate
>> design. Draft -05 did away with the definition of the "operation" parameter
>> on a single endpoint and instead opted for separating the base
>> functionality into three different endpoints.
>>
>> Pro:
>>    - Closer to RESTful semantics of having one URL for creation and
>> another URL for management of an item (eg, most REST APIs use /object for
>> creation and /object/object_id for manipulation)
>>    - The rest of OAuth (and its extensions) defines separate endpoints
>> for different actions (Authorization, Token, Revocation, Introspection) as
>> opposed to a single endpoint with a mode-switch parameter
>>    - Client doesn't have to generate a URL string for different endpoints
>> by combining parameters with a base URL
>>
>> Con:
>>    - Not quite exactly RESTful as the spec doesn't dictate the client_id
>> be part of the update or rotate URL (though and implementor's note
>> suggests this)
>>    - Client has to track different URLs for different actions
>>    - Server must be able to differentiate actions based on these
>> different URLs.
>>
>> Alternatives include using different HTTP verbs (see other thread) or
>> defining an operational switch parameter, like older drafts, on a single
>> endpoint URL. Another suggested alternative is to look for the presence
>> of certain parameters, such as client_id or the registration access
>> token, to indicate that a different operation is requested.
>>
>> There's also question of whether the Secret Rotation action needs to
>> have its own endpoint, or if it can be collapsed into one of the others.
>> It has been suggested off-list that the secret rotation should never be
>> initiated by the Client but instead the client should simply request its
>> latest secret from the server through the update (or read) semantics.
>>
>>    -- Justin
>>
>> [1] http://tools.ietf.org/html/**draft-ietf-oauth-dyn-reg-05
>> ______________________________**_________________
>> 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
>

--14dae93408e7ea831504d5880d86
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

?! /foo and /foo/bar are obviously distinct endpoints.
On Feb 12, 2013 3:25 AM, "Sergey Beryozkin&=
quot; <sberyozkin@gmail.com&=
gt; wrote:

Hi Mike,

On 12/02/13 01:26, Mike Jones wrote:

At most, there should be two endpoints - creation and management - for a cl=
ient, but the protocol should be structured such that they *can* be at the =
same URL, if the server so chooses. =C2=A0A simple way to accomplish this i=
s to require that the client_id value be provided as an input parameter on =
update operations. =C2=A0Then for implementations that use a single endpoin=
t, they can distinguish "create" and "update" operation=
s on the management endpoint by the presence or absence of the client_id va=
lue.

Perhaps the text can be relaxed somehow to not refer to

/register

and

/register/{client_id}

as two different endpoints ? I think it is a single endpoint from the imple=
mentation point of view :-).

Or may be the spec can indeed be relaxed a bit and allow for a PUT form pay=
load be sent directly to /register

Cheers, Sergey

If you want to have separate endpoints and don't need the client_id bec=
ause you have somehow encoded it into the management endpoint URL, that'=
;s fine. =C2=A0It still can serve as a useful cross-check that the client (=
or an attacker) is requesting a change to a client that matches the bearer =
token used. =C2=A0But including it is necessary for implementations that wa=
nt to use a single registration endpoint, rather than having a proliferatio=
n of per-client endpoints.

BTW, just for the record, OAuth 2.0 uses the same endpoint for initial acce=
ss token requests and requests for refreshed access tokens - with the opera=
tions being distinguished by whether a refresh_token parameter is present. =
=C2=A0So there's a useful OAuth precedent for doing things this way.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike

-----Original Message-----

From: oauth-bou=
nces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Monday, February 11, 2013 1:15 PM

To: oauth@ietf.org<=
br>
Subject: [OAUTH-WG] Registration: Endpoint Definition (& =C2=A0operatio=
n parameter)

Draft -05 of OAuth Dynamic Client Registration [1] defines three fundamenta=
l operations that a client can undertake: Client Registration, Client Updat=
e, and Secret Rotation. Each of these actions needs to be differentiated *s=
omehow* by the client and server as part of the protocol. Draft -00 defined=
 only the "register" operation, drafts -01 through -04 made use o=
f an "operation" parameter on a single endpoint, which brought up=
 a long discussion on the list on whether or not that was an appropriate de=
sign. Draft -05 did away with the definition of the "operation" p=
arameter on a single endpoint and instead opted for separating the base fun=
ctionality into three different endpoints.

Pro:

=C2=A0 =C2=A0- Closer to RESTful semantics of having one URL for creation a=
nd another URL for management of an item (eg, most REST APIs use /object fo=
r creation and /object/object_id for manipulation)

=C2=A0 =C2=A0- The rest of OAuth (and its extensions) defines separate endp=
oints for different actions (Authorization, Token, Revocation, Introspectio=
n) as opposed to a single endpoint with a mode-switch parameter

=C2=A0 =C2=A0- Client doesn't have to generate a URL string for differe=
nt endpoints by combining parameters with a base URL

Con:

=C2=A0 =C2=A0- Not quite exactly RESTful as the spec doesn't dictate th=
e client_id

be part of the update or rotate URL (though and implementor's note

suggests this)

=C2=A0 =C2=A0- Client has to track different URLs for different actions

=C2=A0 =C2=A0- Server must be able to differentiate actions based on these<=
br>
different URLs.

Alternatives include using different HTTP verbs (see other thread) or

defining an operational switch parameter, like older drafts, on a single
endpoint URL. Another suggested alternative is to look for the presence

of certain parameters, such as client_id or the registration access

token, to indicate that a different operation is requested.

There's also question of whether the Secret Rotation action needs to
have its own endpoint, or if it can be collapsed into one of the others.
It has been suggested off-list that the secret rotation should never be

initiated by the Client but instead the client should simply request its
latest secret from the server through the update (or read) semantics.

=C2=A0 =C2=A0-- Justin

[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05=

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

--14dae93408e7ea831504d5880d86--

From jricher@mitre.org  Tue Feb 12 06:54:08 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C336E21F8E73 for ; Tue, 12 Feb 2013 06:53:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.569
X-Spam-Level: 
X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t381G5XIFVWu for ; Tue, 12 Feb 2013 06:53:38 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5212721F8E75 for ; Tue, 12 Feb 2013 06:53:34 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 873A51F172B; Tue, 12 Feb 2013 09:53:33 -0500 (EST)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7BEFD1F1723; Tue, 12 Feb 2013 09:53:33 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 12 Feb 2013 09:53:33 -0500
Message-ID: <511A5742.30707@mitre.org>
Date: Tue, 12 Feb 2013 09:52:50 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Torsten Lodderstedt 
References: <51195F36.6040705@mitre.org> <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com> <80727F20-A830-4778-B11C-D45389310646@lodderstedt.net>
In-Reply-To: <80727F20-A830-4778-B11C-D45389310646@lodderstedt.net>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 14:54:08 -0000

The problem that I have with "always including the client_id" is *where* 
to include it. Are we talking a query parameter, URI template, or 
somewhere in the request body? The latter will only work for POST and 
PUT, so it's out of the question to support GET and DELETE using that 
semantic. I think we should support all operations using parallel syntax 
-- that's just good API design.

I *really* don't like the idea of switching the action solely based on 
whether or not the client_id is present in the request body of a POST. 
This is a side-effectful mode switch, and it will only lead to pain and 
misery. Additionally, if the input is JSON (separate discussion), then a 
server would have to parse the JSON body before knowing where to route 
the request. In most web development frameworks that I've used, this is 
impossible. A query parameter or URL pattern, on the other hand, is doable.

As it stands right now, a server is free to include the client_id in the 
"update/management" URL that it returns as part of the _link structure 
(separate discussion). The current text goes as far as recommending that 
practice, but doesn't take the step of requiring it in any form, and 
leaving it up to the server to decide what form it takes. If a server 
can route better with a query parameter, it'll return a URL to the 
client that has a client_id= query parameter. If a server would rather 
use a path component with the client_id, it can do that, too. If it 
wants to put everything on one URL and differentiate through the request 
body or presence/absence of the registration_access_token, it can always 
return the same URL to every client. I think that's nuts, but you can do 
it. Interoperability is preserved because the client simply follows the 
returned URL to do its bits and pieces, and it doesn't ever have to 
create or compose this URL from component parts.

I want to continue to distinguish between the POST and PUT operations 
for create and update, respectively. This is a common pattern and the 
one described in the original REST thesis that described the 
architectural style. I'll also bring up that the semantics of PUT are 
intended to be "replace all", which is what you had originally argued 
for in the update case as well. I not convinced that developers of today 
can't handle HTTP verbs like PUT if they want to do fancier operations 
like updates. Note that the core operations, create and read, remain as 
POST and GET, which would be well within the grasp of every library and 
web developer today.

  -- Justin

On 02/12/2013 02:23 AM, Torsten Lodderstedt wrote:
> +1 for always including the client_id
>
> As John pointed out, there could be different entities updating client data. Then one has to distinguish the resource and the credential.
>
> Am 12.02.2013 um 02:51 schrieb John Bradley :
>
>> I would always include the client_id on update.
>>
>> I think it is also us full to have other tokens used at the update endpoint.  I can see the master token used to update all the clients it has registered as part of API management.
>> Relying on the registration_access_token is probably a design that will cause trouble down the road.
>>
>> I think GET and POST are relatively clear.   I don't know about expelling PUT to developers.  I think POST with a client_id to a (separate discussion) update_uri works without restricting it to PUT.
>>
>> I think DELETE needs to be better understood.   I think a status that can be set for client lifecycle is better than letting a client delete a entry.
>> In some cases there will be more than one instance of a client and letting them know they have been turned off for a reason is better than making there registration disappear.
>> So for the moment I would levee out DELETE.
>>
>> John B.
>>
>> On 2013-02-11, at 6:14 PM, Justin Richer  wrote:
>>
>>> Draft -05 of OAuth Dynamic Client Registration [1] defines several operations that the client can take on its behalf as part of the registration process. These boil down to the basic CRUD operations that you find in many APIs: Create, Read, Update, Delete. Draft -00 defined only the "Create" operation, draft -01 through -04 added the "Update" operation, switched using the "operation=" parameter.
>>>
>>> Following several suggestions to do so on the list, the -05 draft defines these operations in terms of a RESTful API for the client. Namely:
>>>
>>> - HTTP POST to registration endpoint => Create (register) a new client
>>> - HTTP PUT to update endpoint (with registration_access_token) => Update the registered information for this client
>>> - HTTP GET to update endpoint (with registration_access_token) => read the registered information for this client
>>> - HTTP DELETE to update endpoint (with registration_access_token) => Delete (unregister/de-provision) this client
>>>
>>> The two main issues at stake here are: the addition of the READ and DELETE methods, and the use of HTTP verbs following a RESTful design philosophy.
>>>
>>> Pro:
>>> - RESTful APIs (with HTTP verbs to differentiate functionality) are the norm today
>>> - Full lifecycle management is common and is going to be expected by many users of this protocol in the wild
>>>
>>> Cons:
>>> - Update semantics are still under debate (full replace? patch?)
>>> - Somewhat increased complexity on the server to support all operations
>>> - Client has to understand all HTTP verbs for full access (though plain registration is just POST)
>>>
>>>
>>> Alternatives include using an operational switch parameter (like the old drafts), defining separate endpoints for every action, or doing all operations on a single endpoint using verbs to switch.
>>>
>>> -- Justin
>>>
>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>>> _______________________________________________
>>> 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

From jricher@mitre.org  Tue Feb 12 06:58:32 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042E321F8EB0 for ; Tue, 12 Feb 2013 06:58:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.57
X-Spam-Level: 
X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.029,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pUJK6H8Kk8H for ; Tue, 12 Feb 2013 06:58:31 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1B26E21F8EAC for ; Tue, 12 Feb 2013 06:58:31 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 98FFE1F0284; Tue, 12 Feb 2013 09:58:30 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8C0121F16E1; Tue, 12 Feb 2013 09:58:30 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 12 Feb 2013 09:58:30 -0500
Message-ID: <511A586B.9060606@mitre.org>
Date: Tue, 12 Feb 2013 09:57:47 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Torsten Lodderstedt 
References: <51195F39.3040809@mitre.org> <4E1F6AAD24975D4BA5B16804296739436743E3DD@TK5EX14MBXC285.redmond.corp.microsoft.com> 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: Endpoint Definition (& operation parameter)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 14:58:32 -0000

Technically you could have your auth endpoint be:

/oauth?method=authorization

and your token endpoint be:

/oauth?method=token

and they're syntactically being served by the same URL. It's a 
deep-in-the-weeds argument of little value whether or not you consider 
these to be "separate endpoints" from the server perspective. You could 
also, if you so choose, define your endpoints to be the same URL and 
switch in a side-effectful fashion on parameters like response_type and 
grant_type. I think you'd be a bit nuts to do it that way, but you could 
pull it off.

The important thing is that because they're defined in the spec as 
"separate endpoints", all clients expect there to be one URL for authz 
and one for tokens, and so all clients have two slots for them. Clients 
are not expected to take one URL and add a parameter to *make* the other 
URL, they're expected to be given two URLs.

I think that's a very important difference.

  -- Justin

On 02/12/2013 02:17 AM, Torsten Lodderstedt wrote:
> Hi Mike,
>
> why do you think the protocol should allow to have two endpoints on the same URL? Even the core spec does not allow to map tokens and authorization endpoint to the same URL.
>
> Regards,
> Torsten.
>
> Am 12.02.2013 um 02:26 schrieb Mike Jones :
>
>> At most, there should be two endpoints - creation and management - for a client, but the protocol should be structured such that they *can* be at the same URL, if the server so chooses.  A simple way to accomplish this is to require that the client_id value be provided as an input parameter on update operations.  Then for implementations that use a single endpoint, they can distinguish "create" and "update" operations on the management endpoint by the presence or absence of the client_id value.
>>
>> If you want to have separate endpoints and don't need the client_id because you have somehow encoded it into the management endpoint URL, that's fine.  It still can serve as a useful cross-check that the client (or an attacker) is requesting a change to a client that matches the bearer token used.  But including it is necessary for implementations that want to use a single registration endpoint, rather than having a proliferation of per-client endpoints.
>>
>> BTW, just for the record, OAuth 2.0 uses the same endpoint for initial access token requests and requests for refreshed access tokens - with the operations being distinguished by whether a refresh_token parameter is present.  So there's a useful OAuth precedent for doing things this way.
>>
>>                 -- Mike
>>
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
>> Sent: Monday, February 11, 2013 1:15 PM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Registration: Endpoint Definition (& operation parameter)
>>
>> Draft -05 of OAuth Dynamic Client Registration [1] defines three fundamental operations that a client can undertake: Client Registration, Client Update, and Secret Rotation. Each of these actions needs to be differentiated *somehow* by the client and server as part of the protocol. Draft -00 defined only the "register" operation, drafts -01 through -04 made use of an "operation" parameter on a single endpoint, which brought up a long discussion on the list on whether or not that was an appropriate design. Draft -05 did away with the definition of the "operation" parameter on a single endpoint and instead opted for separating the base functionality into three different endpoints.
>>
>> Pro:
>>   - Closer to RESTful semantics of having one URL for creation and another URL for management of an item (eg, most REST APIs use /object for creation and /object/object_id for manipulation)
>>   - The rest of OAuth (and its extensions) defines separate endpoints for different actions (Authorization, Token, Revocation, Introspection) as opposed to a single endpoint with a mode-switch parameter
>>   - Client doesn't have to generate a URL string for different endpoints by combining parameters with a base URL
>>
>> Con:
>>   - Not quite exactly RESTful as the spec doesn't dictate the client_id
>> be part of the update or rotate URL (though and implementor's note
>> suggests this)
>>   - Client has to track different URLs for different actions
>>   - Server must be able to differentiate actions based on these
>> different URLs.
>>
>> Alternatives include using different HTTP verbs (see other thread) or
>> defining an operational switch parameter, like older drafts, on a single
>> endpoint URL. Another suggested alternative is to look for the presence
>> of certain parameters, such as client_id or the registration access
>> token, to indicate that a different operation is requested.
>>
>> There's also question of whether the Secret Rotation action needs to
>> have its own endpoint, or if it can be collapsed into one of the others.
>> It has been suggested off-list that the secret rotation should never be
>> initiated by the Client but instead the client should simply request its
>> latest secret from the server through the update (or read) semantics.
>>
>>   -- Justin
>>
>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>> _______________________________________________
>> 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

From ve7jtb@ve7jtb.com  Tue Feb 12 07:00:58 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD97621F8ED6 for ; Tue, 12 Feb 2013 07:00:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.327
X-Spam-Level: 
X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=-0.395, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7Sr70tDYIrJ for ; Tue, 12 Feb 2013 07:00:57 -0800 (PST)
Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id 58AD321F8ED5 for ; Tue, 12 Feb 2013 07:00:57 -0800 (PST)
Received: by mail-qc0-f173.google.com with SMTP id b12so60393qca.18 for ; Tue, 12 Feb 2013 07:00:56 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=bY4Oft6lvlzspW16J5EWZsLniSw5w0S3CTshNPNk6lk=; b=F+ZxR0gDZ6jGYE3Og10RM/KGCbbErmnHEFryLIOwFXU/KkvUvpEDT1cxcNUMuIRfac XUWWMMgliDS8UMPv0vvIIfTiGKetcgEFW7tvnkiyTzF/1Y+oZjKsrTbtOhwCgo1rpmr4 2ZmZYRaJr6HnUI/lMyXSM/YJHbREzMXADVOqZLMhxKTC6xhm+BaBw9lLamHafXjL2Gb8 st+87+/bLfnD88xhFdYhq2XNIJUOlJANeif4nVbYUn8sJA1NGsrXCd5+NPUa5rh0hxW2 2+k3cTvTeijROZLoCVyp2C0x5obnlR1MZ+p+7IiljoR6nlAS558GJ8GTKYGyWuegdQw9 uLzQ==
X-Received: by 10.49.128.37 with SMTP id nl5mr8168188qeb.59.1360681256582; Tue, 12 Feb 2013 07:00:56 -0800 (PST)
Received: from [192.168.1.213] (190-20-23-212.baf.movistar.cl. [190.20.23.212]) by mx.google.com with ESMTPS id f7sm16563837qap.13.2013.02.12.07.00.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 07:00:54 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_3138D1F7-D8A6-4083-86B3-2FAC92C2D1AC"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: 
Date: Tue, 12 Feb 2013 12:00:48 -0300
Message-Id: <5213467D-C61A-4323-BC26-D519A1886C55@ve7jtb.com>
References: <51195F39.3040809@mitre.org> <4E1F6AAD24975D4BA5B16804296739436743E3DD@TK5EX14MBXC285.redmond.corp.microsoft.com> <511A2692.2070209@gmail.com> 
To: Tim Bray 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQk0YveTx6edjxQbz/6knGkexj1fZNkQagMOiWa2WN+/Ficx886z/l6FPZXbvoYi7TP9nFa3
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Endpoint Definition (& operation parameter)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 15:00:58 -0000

--Apple-Mail=_3138D1F7-D8A6-4083-86B3-2FAC92C2D1AC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

It can be argued that /foo  and /foo?provider=3Dabc  are different URI =
resources.

Nat and I were recommending that the registration return a update URI =
that can be unique per client.

In the Apps for domains or Salesforce case the hosting client could be =
encoded into the path or a parameter if required, or it could even be a =
different host name if some client's data needed to be kept in a =
particular jurisdiction like Canada. (honestly there are laws to prevent =
you hosing data in the US)=20

The update URI returned may also be exactly the same as the original =
create URI that should be left up to the Registration server.

Allowing the Registration server to set the update URI is the most =
flexible for supporting multi tenant and other use-cases. =20

the only downside is that the client needs to remember what it is.  As =
the client needs to remember a secret and the locations of the =
endpoint's I don't think that is a large burden.

In reality the only clients possibly having a issue with that are going =
to be native clients, but they are generally registered and managed by a =
developer and not by individual client instances.

The problem is a native client is not going to keep it's secret for =
updating safe.   It would work if client instances create their own =
unique client_id, but at that point managing another parameter is the =
least of your worries.

John B.

On 2013-02-12, at 11:43 AM, Tim Bray  wrote:

> ?! /foo and /foo/bar are obviously distinct endpoints.
>=20
> On Feb 12, 2013 3:25 AM, "Sergey Beryozkin"  =
wrote:
> Hi Mike,
> On 12/02/13 01:26, Mike Jones wrote:
> At most, there should be two endpoints - creation and management - for =
a client, but the protocol should be structured such that they *can* be =
at the same URL, if the server so chooses.  A simple way to accomplish =
this is to require that the client_id value be provided as an input =
parameter on update operations.  Then for implementations that use a =
single endpoint, they can distinguish "create" and "update" operations =
on the management endpoint by the presence or absence of the client_id =
value.
>=20
> Perhaps the text can be relaxed somehow to not refer to
>=20
> /register
> and
> /register/{client_id}
>=20
> as two different endpoints ? I think it is a single endpoint from the =
implementation point of view :-).
>=20
> Or may be the spec can indeed be relaxed a bit and allow for a PUT =
form payload be sent directly to /register
>=20
> Cheers, Sergey
>=20
> If you want to have separate endpoints and don't need the client_id =
because you have somehow encoded it into the management endpoint URL, =
that's fine.  It still can serve as a useful cross-check that the client =
(or an attacker) is requesting a change to a client that matches the =
bearer token used.  But including it is necessary for implementations =
that want to use a single registration endpoint, rather than having a =
proliferation of per-client endpoints.
>=20
> BTW, just for the record, OAuth 2.0 uses the same endpoint for initial =
access token requests and requests for refreshed access tokens - with =
the operations being distinguished by whether a refresh_token parameter =
is present.  So there's a useful OAuth precedent for doing things this =
way.
>=20
>                                 -- Mike
>=20
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf =
Of Justin Richer
> Sent: Monday, February 11, 2013 1:15 PM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Registration: Endpoint Definition (&  operation =
parameter)
>=20
> Draft -05 of OAuth Dynamic Client Registration [1] defines three =
fundamental operations that a client can undertake: Client Registration, =
Client Update, and Secret Rotation. Each of these actions needs to be =
differentiated *somehow* by the client and server as part of the =
protocol. Draft -00 defined only the "register" operation, drafts -01 =
through -04 made use of an "operation" parameter on a single endpoint, =
which brought up a long discussion on the list on whether or not that =
was an appropriate design. Draft -05 did away with the definition of the =
"operation" parameter on a single endpoint and instead opted for =
separating the base functionality into three different endpoints.
>=20
> Pro:
>    - Closer to RESTful semantics of having one URL for creation and =
another URL for management of an item (eg, most REST APIs use /object =
for creation and /object/object_id for manipulation)
>    - The rest of OAuth (and its extensions) defines separate endpoints =
for different actions (Authorization, Token, Revocation, Introspection) =
as opposed to a single endpoint with a mode-switch parameter
>    - Client doesn't have to generate a URL string for different =
endpoints by combining parameters with a base URL
>=20
> Con:
>    - Not quite exactly RESTful as the spec doesn't dictate the =
client_id
> be part of the update or rotate URL (though and implementor's note
> suggests this)
>    - Client has to track different URLs for different actions
>    - Server must be able to differentiate actions based on these
> different URLs.
>=20
> Alternatives include using different HTTP verbs (see other thread) or
> defining an operational switch parameter, like older drafts, on a =
single
> endpoint URL. Another suggested alternative is to look for the =
presence
> of certain parameters, such as client_id or the registration access
> token, to indicate that a different operation is requested.
>=20
> There's also question of whether the Secret Rotation action needs to
> have its own endpoint, or if it can be collapsed into one of the =
others.
> It has been suggested off-list that the secret rotation should never =
be
> initiated by the Client but instead the client should simply request =
its
> latest secret from the server through the update (or read) semantics.
>=20
>    -- Justin
>=20
> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
> _______________________________________________
> 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
>=20
> _______________________________________________
> 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

--Apple-Mail=_3138D1F7-D8A6-4083-86B3-2FAC92C2D1AC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

It =
can be argued that /foo  and /foo?provider=3Dabc  are =
different URI resources.
Nat and I were recommending =
that the registration return a update URI that can be unique per =
client.

In the Apps for domains or Salesforce =
case the hosting client could be encoded into the path or a parameter if =
required, or it could even be a different host name if some client's =
data needed to be kept in a particular jurisdiction like Canada. =
(honestly there are laws to prevent you hosing data in the =
US) 

The update URI returned may also be =
exactly the same as the original create URI that should be left up to =
the Registration server.

Allowing the =
Registration server to set the update URI is the most flexible for =
supporting multi tenant and other use-cases. =

the only downside is that the client =
needs to remember what it is.  As the client needs to remember a =
secret and the locations of the endpoint's I don't think that is a large =
burden.

In reality the only clients possibly =
having a issue with that are going to be native clients, but they are =
generally registered and managed by a developer and not by individual =
client instances.

The problem is a native =
client is not going to keep it's secret for updating safe.   It =
would work if client instances create their own unique client_id, but at =
that point managing another parameter is the least of your =
worries.

John =
B.

On 2013-02-12, at 11:43 =
AM, Tim Bray <twbray@google.com> =
wrote:

?! /foo and /foo/bar are obviously distinct =
endpoints.
On Feb 12, 2013 3:25 AM, "Sergey Beryozkin" =
<sberyozkin@gmail.com> =
wrote:

Hi Mike,

On 12/02/13 01:26, Mike Jones wrote:

At most, there should be two endpoints - creation and management - for a =
client, but the protocol should be structured such that they *can* be at =
the same URL, if the server so chooses.  A simple way to accomplish =
this is to require that the client_id value be provided as an input =
parameter on update operations.  Then for implementations that use =
a single endpoint, they can distinguish "create" and "update" operations =
on the management endpoint by the presence or absence of the client_id =
value.

Perhaps the text can be relaxed somehow to not refer to

/register

and

/register/{client_id}

as two different endpoints ? I think it is a single endpoint from the =
implementation point of view :-).

Or may be the spec can indeed be relaxed a bit and allow for a PUT form =
payload be sent directly to /register

Cheers, Sergey

If you want to have separate endpoints and don't need the client_id =
because you have somehow encoded it into the management endpoint URL, =
that's fine.  It still can serve as a useful cross-check that the =
client (or an attacker) is requesting a change to a client that matches =
the bearer token used.  But including it is necessary for =
implementations that want to use a single registration endpoint, rather =
than having a proliferation of per-client endpoints.

BTW, just for the record, OAuth 2.0 uses the same endpoint for initial =
access token requests and requests for refreshed access tokens - with =
the operations being distinguished by whether a refresh_token parameter =
is present.  So there's a useful OAuth precedent for doing things =
this way.

                    =
            -- Mike

-----Original Message-----

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin =
Richer

Sent: Monday, February 11, 2013 1:15 PM

To: oauth@ietf.org

Subject: [OAUTH-WG] Registration: Endpoint Definition (& =
 operation parameter)

Draft -05 of OAuth Dynamic Client Registration [1] defines three =
fundamental operations that a client can undertake: Client Registration, =
Client Update, and Secret Rotation. Each of these actions needs to be =
differentiated *somehow* by the client and server as part of the =
protocol. Draft -00 defined only the "register" operation, drafts -01 =
through -04 made use of an "operation" parameter on a single endpoint, =
which brought up a long discussion on the list on whether or not that =
was an appropriate design. Draft -05 did away with the definition of the =
"operation" parameter on a single endpoint and instead opted for =
separating the base functionality into three different endpoints.

Pro:

   - Closer to RESTful semantics of having one URL for =
creation and another URL for management of an item (eg, most REST APIs =
use /object for creation and /object/object_id for manipulation)

   - The rest of OAuth (and its extensions) defines separate =
endpoints for different actions (Authorization, Token, Revocation, =
Introspection) as opposed to a single endpoint with a mode-switch =
parameter

   - Client doesn't have to generate a URL string for =
different endpoints by combining parameters with a base URL

Con:

   - Not quite exactly RESTful as the spec doesn't dictate the =
client_id

be part of the update or rotate URL (though and implementor's note

suggests this)

   - Client has to track different URLs for different =
actions

   - Server must be able to differentiate actions based on =
these

different URLs.

Alternatives include using different HTTP verbs (see other thread) =
or

defining an operational switch parameter, like older drafts, on a =
single

endpoint URL. Another suggested alternative is to look for the =
presence

of certain parameters, such as client_id or the registration access

token, to indicate that a different operation is requested.

There's also question of whether the Secret Rotation action needs to

have its own endpoint, or if it can be collapsed into one of the =
others.

It has been suggested off-list that the secret rotation should never =
be

initiated by the Client but instead the client should simply request =
its

latest secret from the server through the update (or read) =
semantics.

   -- Justin

[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-r=
eg-05

_______________________________________________

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

=

--Apple-Mail=_3138D1F7-D8A6-4083-86B3-2FAC92C2D1AC--

From sberyozkin@gmail.com  Tue Feb 12 07:01:50 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3983B21F8EC4 for ; Tue, 12 Feb 2013 07:01:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTrjaN6fSzAa for ; Tue, 12 Feb 2013 07:01:49 -0800 (PST)
Received: from mail-ea0-f182.google.com (mail-ea0-f182.google.com [209.85.215.182]) by ietfa.amsl.com (Postfix) with ESMTP id 16C4721F8EBA for ; Tue, 12 Feb 2013 07:01:48 -0800 (PST)
Received: by mail-ea0-f182.google.com with SMTP id a12so83161eaa.13 for ; Tue, 12 Feb 2013 07:01:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2x/zMVlhMVHTBYLUqucRy0dm7fSU+1HrYsSDHby4wN8=; b=hmaFZ2AIQwAeHDwRRVqlBIB7N1ldP7Jy1MhNloh8jHK53mZUH1R/iJLSP+AVrIa+9+ nLn4KqJWnB07y5SzvelaFKfCeWtjkGRuDNAzcCW8bPwSgCaREyxTXx2FZngnY1QQ8tpu 3pteE1j93iVo2olcR2UdnFSPmxYYVmQR9T39BTTihfdM/7ScTmA6AjjSP/hK/qQEcE9M bsnDnqHJOGcdD1kPDczolAp93X8qmycRkO7y7D+4ex463zKabCBdBuPUXIFDdcILPNcb Y8QbuH1JCHZajMccsJijDpIviJYZSIhxarWeQaH84joljYAKmOg9J3Be1oz2sPb9fx+B SK0w==
X-Received: by 10.14.4.69 with SMTP id 45mr64812061eei.0.1360681308211; Tue, 12 Feb 2013 07:01:48 -0800 (PST)
Received: from [10.36.226.5] ([217.173.99.61]) by mx.google.com with ESMTPS id j46sm64891671eeo.3.2013.02.12.07.01.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 07:01:47 -0800 (PST)
Message-ID: <511A5958.7020003@gmail.com>
Date: Tue, 12 Feb 2013 15:01:44 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Tim Bray 
References: <51195F39.3040809@mitre.org> <4E1F6AAD24975D4BA5B16804296739436743E3DD@TK5EX14MBXC285.redmond.corp.microsoft.com> <511A2692.2070209@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Endpoint Definition (& operation parameter)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 15:01:50 -0000

On 12/02/13 14:43, Tim Bray wrote:
> ?! /foo and /foo/bar are obviously distinct endpoints.

definitely yes from the client's  point of view, at the implementation 
level - it is the internal detail, right ?

Cheers, Sergey

>
> On Feb 12, 2013 3:25 AM, "Sergey Beryozkin"  > wrote:
>
>     Hi Mike,
>     On 12/02/13 01:26, Mike Jones wrote:
>
>         At most, there should be two endpoints - creation and management
>         - for a client, but the protocol should be structured such that
>         they *can* be at the same URL, if the server so chooses.  A
>         simple way to accomplish this is to require that the client_id
>         value be provided as an input parameter on update operations.
>           Then for implementations that use a single endpoint, they can
>         distinguish "create" and "update" operations on the management
>         endpoint by the presence or absence of the client_id value.
>
>     Perhaps the text can be relaxed somehow to not refer to
>
>     /register
>     and
>     /register/{client_id}
>
>     as two different endpoints ? I think it is a single endpoint from
>     the implementation point of view :-).
>
>     Or may be the spec can indeed be relaxed a bit and allow for a PUT
>     form payload be sent directly to /register
>
>     Cheers, Sergey
>
>         If you want to have separate endpoints and don't need the
>         client_id because you have somehow encoded it into the
>         management endpoint URL, that's fine.  It still can serve as a
>         useful cross-check that the client (or an attacker) is
>         requesting a change to a client that matches the bearer token
>         used.  But including it is necessary for implementations that
>         want to use a single registration endpoint, rather than having a
>         proliferation of per-client endpoints.
>
>         BTW, just for the record, OAuth 2.0 uses the same endpoint for
>         initial access token requests and requests for refreshed access
>         tokens - with the operations being distinguished by whether a
>         refresh_token parameter is present.  So there's a useful OAuth
>         precedent for doing things this way.
>
>                                          -- Mike
>
>         -----Original Message-----
>         From: oauth-bounces@ietf.org 
>         [mailto:oauth-bounces@ietf.org
>         __] On Behalf Of Justin Richer
>         Sent: Monday, February 11, 2013 1:15 PM
>         To: oauth@ietf.org 
>         Subject: [OAUTH-WG] Registration: Endpoint Definition (&
>           operation parameter)
>
>         Draft -05 of OAuth Dynamic Client Registration [1] defines three
>         fundamental operations that a client can undertake: Client
>         Registration, Client Update, and Secret Rotation. Each of these
>         actions needs to be differentiated *somehow* by the client and
>         server as part of the protocol. Draft -00 defined only the
>         "register" operation, drafts -01 through -04 made use of an
>         "operation" parameter on a single endpoint, which brought up a
>         long discussion on the list on whether or not that was an
>         appropriate design. Draft -05 did away with the definition of
>         the "operation" parameter on a single endpoint and instead opted
>         for separating the base functionality into three different
>         endpoints.
>
>         Pro:
>             - Closer to RESTful semantics of having one URL for creation
>         and another URL for management of an item (eg, most REST APIs
>         use /object for creation and /object/object_id for manipulation)
>             - The rest of OAuth (and its extensions) defines separate
>         endpoints for different actions (Authorization, Token,
>         Revocation, Introspection) as opposed to a single endpoint with
>         a mode-switch parameter
>             - Client doesn't have to generate a URL string for different
>         endpoints by combining parameters with a base URL
>
>         Con:
>             - Not quite exactly RESTful as the spec doesn't dictate the
>         client_id
>         be part of the update or rotate URL (though and implementor's note
>         suggests this)
>             - Client has to track different URLs for different actions
>             - Server must be able to differentiate actions based on these
>         different URLs.
>
>         Alternatives include using different HTTP verbs (see other
>         thread) or
>         defining an operational switch parameter, like older drafts, on
>         a single
>         endpoint URL. Another suggested alternative is to look for the
>         presence
>         of certain parameters, such as client_id or the registration access
>         token, to indicate that a different operation is requested.
>
>         There's also question of whether the Secret Rotation action needs to
>         have its own endpoint, or if it can be collapsed into one of the
>         others.
>         It has been suggested off-list that the secret rotation should
>         never be
>         initiated by the Client but instead the client should simply
>         request its
>         latest secret from the server through the update (or read)
>         semantics.
>
>             -- Justin
>
>         [1] http://tools.ietf.org/html/__draft-ietf-oauth-dyn-reg-05
>         
>         _________________________________________________
>         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
>     
>

From jricher@mitre.org  Tue Feb 12 07:10:58 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A4F21F8EB1 for ; Tue, 12 Feb 2013 07:10:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.571
X-Spam-Level: 
X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.028,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWeOEkHyT+mI for ; Tue, 12 Feb 2013 07:10:57 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE9B21F8EB7 for ; Tue, 12 Feb 2013 07:10:57 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E17991F177C; Tue, 12 Feb 2013 10:10:56 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7EDB25311800; Tue, 12 Feb 2013 10:10:56 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 12 Feb 2013 10:10:56 -0500
Message-ID: <511A5B55.8020701@mitre.org>
Date: Tue, 12 Feb 2013 10:10:13 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Mike Jones 
References: <51195F39.3040809@mitre.org> <4E1F6AAD24975D4BA5B16804296739436743E3DD@TK5EX14MBXC285.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436743E3DD@TK5EX14MBXC285.redmond.corp.microsoft.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: Endpoint Definition (& operation parameter)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 15:10:58 -0000

So, I think we agree in general, but to be explicit: I want a server to 
be free to include the client_id as an input parameter if it wants to, 
but I would rather not have the client be required to compose that 
parameter onto the base registration URL on its own. This is to preserve 
the flexibility on the server side to deploy things as you describe 
below, but also to have URL path components as the identifier (common in 
REST frameworks) if it so chooses. The client shouldn't ever care which 
pattern the server wants to use. This is the motivation behind providing 
the client management URL as part of the response (separate discussion).

Also, for the record, OAuth 2.0 does not use the same endpoint for 
different things in the way you describe. To refresh a token, you send a 
request to the token endpoint with grant_type=refresh_token (section 6). 
The "grant_type" parameter is explicitly designed as a mode-switch 
parameter (for instance, see the discussion in section 4.5) and the 
refresh token flow is no different. Some early drafts of the OAuth 2.0 
core document even called out refresh token as a parallel "flow" with 
the rest of them, like authorization_code and implicit, but that seemed 
to confuse people more than it helped, so Eran pulled it into a separate 
section entirely. Nevertheless, the structure and syntax remains parallel.

  -- Justin

On 02/11/2013 08:26 PM, Mike Jones wrote:
> At most, there should be two endpoints - creation and management - for a client, but the protocol should be structured such that they *can* be at the same URL, if the server so chooses.  A simple way to accomplish this is to require that the client_id value be provided as an input parameter on update operations.  Then for implementations that use a single endpoint, they can distinguish "create" and "update" operations on the management endpoint by the presence or absence of the client_id value.
>
> If you want to have separate endpoints and don't need the client_id because you have somehow encoded it into the management endpoint URL, that's fine.  It still can serve as a useful cross-check that the client (or an attacker) is requesting a change to a client that matches the bearer token used.  But including it is necessary for implementations that want to use a single registration endpoint, rather than having a proliferation of per-client endpoints.
>
> BTW, just for the record, OAuth 2.0 uses the same endpoint for initial access token requests and requests for refreshed access tokens - with the operations being distinguished by whether a refresh_token parameter is present.  So there's a useful OAuth precedent for doing things this way.
>
> 				-- Mike
>
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
> Sent: Monday, February 11, 2013 1:15 PM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Registration: Endpoint Definition (& operation parameter)
>
> Draft -05 of OAuth Dynamic Client Registration [1] defines three fundamental operations that a client can undertake: Client Registration, Client Update, and Secret Rotation. Each of these actions needs to be differentiated *somehow* by the client and server as part of the protocol. Draft -00 defined only the "register" operation, drafts -01 through -04 made use of an "operation" parameter on a single endpoint, which brought up a long discussion on the list on whether or not that was an appropriate design. Draft -05 did away with the definition of the "operation" parameter on a single endpoint and instead opted for separating the base functionality into three different endpoints.
>
> Pro:
>    - Closer to RESTful semantics of having one URL for creation and another URL for management of an item (eg, most REST APIs use /object for creation and /object/object_id for manipulation)
>    - The rest of OAuth (and its extensions) defines separate endpoints for different actions (Authorization, Token, Revocation, Introspection) as opposed to a single endpoint with a mode-switch parameter
>    - Client doesn't have to generate a URL string for different endpoints by combining parameters with a base URL
>
> Con:
>    - Not quite exactly RESTful as the spec doesn't dictate the client_id
> be part of the update or rotate URL (though and implementor's note
> suggests this)
>    - Client has to track different URLs for different actions
>    - Server must be able to differentiate actions based on these
> different URLs.
>
> Alternatives include using different HTTP verbs (see other thread) or
> defining an operational switch parameter, like older drafts, on a single
> endpoint URL. Another suggested alternative is to look for the presence
> of certain parameters, such as client_id or the registration access
> token, to indicate that a different operation is requested.
>
> There's also question of whether the Secret Rotation action needs to
> have its own endpoint, or if it can be collapsed into one of the others.
> It has been suggested off-list that the secret rotation should never be
> initiated by the Client but instead the client should simply request its
> latest secret from the server through the update (or read) semantics.
>
>    -- Justin
>
> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From jricher@mitre.org  Tue Feb 12 07:22:13 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 257C021F8EE2 for ; Tue, 12 Feb 2013 07:22:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.571
X-Spam-Level: 
X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.028,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEMCthr2+cK1 for ; Tue, 12 Feb 2013 07:22:11 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1030E21F8EE5 for ; Tue, 12 Feb 2013 07:22:10 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0F8C91F17D5; Tue, 12 Feb 2013 10:22:08 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id F22611F1772; Tue, 12 Feb 2013 10:22:07 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 12 Feb 2013 10:22:07 -0500
Message-ID: <511A5DF4.5090801@mitre.org>
Date: Tue, 12 Feb 2013 10:21:24 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Mike Jones 
References: <51195F3D.1050006@mitre.org> <4E1F6AAD24975D4BA5B16804296739436743E33D@TK5EX14MBXC285.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436743E33D@TK5EX14MBXC285.redmond.corp.microsoft.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 15:22:13 -0000

I would be OK with the change to registration_access_url or something 
similar to that. The main argument against it is that we'd be inventing 
a bespoke field for something that's already covered out there by the 
HTTP Linked Data world. Nat did a good job of trying to generalize 
concepts of linked OAuth metadata with

    http://tools.ietf.org/html/draft-sakimura-oauth-meta-01

I don't think it's inherently silly to try and generalize the problem, 
but I can appreciate the argument that such generalization could be 
overkill in this instance.

  -- Justin

On 02/11/2013 08:12 PM, Mike Jones wrote:
> It seems like significant overkill, bordering on silliness, to use the syntax
>    _links: {
>      "self": {
>        "href":
>            "https://server.example.com/register/s6BhdRkqt3"
>        }
>    }
> to represent a value that could be more straightforwardly represented as:
>    "registration_access_url": "https://server.example.com/register/s6BhdRkqt3"
>
> Even some of the advocates for it have called it "pedantic".  I believe that most developers would have less charitable things to say about it, and would wonder why we're trying to foist needless complexity on them.
>
> I'll also point out that this syntax is based upon an expired individual submission draft http://tools.ietf.org/html/draft-kelly-json-hal-03 that is not in any working group.  I don't believe we should take a dependence on this draft or this syntax.
>
> Occam's razor says that this isn't needed.
>
> 				-- Mike
>
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
> Sent: Monday, February 11, 2013 1:15 PM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Registration: HAL _links structure and client self-URL
>
> Draft -05 of OAuth Dynamic Client Registration [1] returns a URL pointer for the client to perform update and secret rotation actions. This functionality arose from discussions on the list about moving towards a more RESTful pattern, and Nat Sakimura proposed this approach in the OpenID Connect Working Group. This URL may be distinct from the Client Registration Endpoint URL, but draft -05 makes no promises as to its content, form, or structure, though it does contain implementor's notes on possible methods.
>
> Two questions arise from this change:
>    - The semantics of returning the client manipulation URL
>    - The syntax (derived from HAL for JSON [2], an individual I-D
> submission)
>
> On semantics:
>
> Pro:
>    - The server has flexibility on how to define the "update" endpoint, sending all clients to one URL, sending different clients to different URLs, or sending clients to a URL with a baked-in query parameter
>    - The client can take the URL as-is and use it for all management operations (ie, it doesn't have to generate or compose the URL based on component parts)
>
> Con:
>    - The client must remember one more piece of information from the server at runtime if it wants to do manipulation and management of itself at the server (in addition to client_id, client_secret, registration_access_token, and others)
>
> Alternatives include specifying a URL pattern for the server to use and all clients to follow, specifying a query parameter for the update action, and specifying a separate endpoint entirely and using the presence of items such as client_id and the registration access token to differentiate the requests. Note that *all* of these alternatives can be accommodated using the semantics described above, with the same actions on the client's part.
>
>
> On syntax:
>
> Pro:
>    - Follows the designs of RFC5988 for link relations
>    - The HAL format is general, and allows for all kinds of other information to be placed inside the _links structure
>    - Allows for full use of the JSON object to specify advanced operations on the returned endpoint if desired
>
> Con:
>    - The rest of OAuth doesn't follow link relation guidelines (though it's been brought up)
>    - The HAL format is general, and allows for all kinds of other information to be placed inside the _links structure
>    - The HAL-JSON document is an expired individual I-D, and it's unclear what wider adoption looks like right now
>
> Alternatives include returning the URL as a separate data member (registration_update_url), using HTTP headers, or using JSON Schema.
>
>    -- Justin
>
>
>
> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
> [2] http://tools.ietf.org/html/draft-kelly-json-hal-03
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From ve7jtb@ve7jtb.com  Tue Feb 12 07:28:26 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C561B21F8F0A for ; Tue, 12 Feb 2013 07:28:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.124
X-Spam-Level: 
X-Spam-Status: No, score=-3.124 tagged_above=-999 required=5 tests=[AWL=0.474,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQqfYV9B23Dx for ; Tue, 12 Feb 2013 07:28:25 -0800 (PST)
Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7B87421F8EFC for ; Tue, 12 Feb 2013 07:28:25 -0800 (PST)
Received: by mail-qc0-f170.google.com with SMTP id d42so73391qca.1 for ; Tue, 12 Feb 2013 07:28:24 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=TfBGYAm9RQ8JAThhAQocSzEwTenh7dT2EOfizOdkVRM=; b=XOtmU+ZAtvJCxmSHXIUILXrdMOHy5A+LqRZjMdFD+UpjHDbBVZjNRrCieyx4FpS1Dl Jpt/9dqthyue4M1Qk5jX/2D93K5o9l6DvvBTpzddGq+o2mFfHLNZNMGBS8ugwRCEw17l E85Xz7J3VY99wvmHqQFiCyWOprzy3zUD9nkpySXSviHWvuw/Ki8c4qmT55rN2FpdIQvT dwQefHyMTigsHL2D+w5epL7RLREn7VUvbW8MsRhVMIPku3bAjWj7yF/A1G1PiqwqyLAJ OKEaa3jvk5+O0HHliNMycNQCAoz0wHQJlu4cKjJSjH50kt7Tn11okjbzPapIgVXFd4wu BYqQ==
X-Received: by 10.49.121.40 with SMTP id lh8mr8227774qeb.30.1360682904589; Tue, 12 Feb 2013 07:28:24 -0800 (PST)
Received: from [192.168.1.213] (190-20-23-212.baf.movistar.cl. [190.20.23.212]) by mx.google.com with ESMTPS id dt10sm16592758qab.0.2013.02.12.07.28.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 07:28:23 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_7C4672B2-203B-4136-BA8D-A2E7A628786C"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <511A50C7.8080102@mitre.org>
Date: Tue, 12 Feb 2013 12:28:17 -0300
Message-Id: 
References: <51195F3D.1050006@mitre.org> <222C28CB-7F6F-4BC3-8692-40404C2DC2D3@maymount.com> <511A50C7.8080102@mitre.org>
To: Justin Richer 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQkxgGSt/vvm6n6L62upWdpDV38nWkrgpcUFUga7egUHvSEj0/f9r8ohrvw8qzpcL6UlyJBQ
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 15:28:27 -0000

--Apple-Mail=_7C4672B2-203B-4136-BA8D-A2E7A628786C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Returning a location header in the 201 ids fine as long as we also have =
the same info as a claim.

I think most clients will want to process the JSON and store all the =
parameters together.  Making them fish out a header makes the W3C happy =
and is the correct thing to do but taking it from a claim is what =
developers are more comfortable with.

John B.

On 2013-02-12, at 11:25 AM, Justin Richer  wrote:

> I'd be fine with the return from a creation request being a 201 =
instead of a 200.=20
>=20
>  -- Justin
>=20
> On 02/11/2013 06:33 PM, Richard Harrington wrote:
>> Since the request is an HTTP POST and a resource is created =
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5) the =
response should be an HTTP 201 Created =
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.2) which =
is supposed to include the location of the newly created resource.
>>=20
>> This is a good pattern to follow since, as you say, it does provide =
flexibility.
>>=20
>>=20
>>=20
>> On Feb 11, 2013, at 1:14 PM, Justin Richer  wrote:
>>=20
>>> Draft -05 of OAuth Dynamic Client Registration [1] returns a URL =
pointer for the client to perform update and secret rotation actions. =
This functionality arose from discussions on the list about moving =
towards a more RESTful pattern, and Nat Sakimura proposed this approach =
in the OpenID Connect Working Group. This URL may be distinct from the =
Client Registration Endpoint URL, but draft -05 makes no promises as to =
its content, form, or structure, though it does contain implementor's =
notes on possible methods.
>>>=20
>>> Two questions arise from this change:
>>> - The semantics of returning the client manipulation URL
>>> - The syntax (derived from HAL for JSON [2], an individual I-D =
submission)
>>>=20
>>> On semantics:
>>>=20
>>> Pro:
>>> - The server has flexibility on how to define the "update" endpoint, =
sending all clients to one URL, sending different clients to different =
URLs, or sending clients to a URL with a baked-in query parameter
>>> - The client can take the URL as-is and use it for all management =
operations (ie, it doesn't have to generate or compose the URL based on =
component parts)
>>>=20
>>> Con:
>>> - The client must remember one more piece of information from the =
server at runtime if it wants to do manipulation and management of =
itself at the server (in addition to client_id, client_secret, =
registration_access_token, and others)
>>>=20
>>> Alternatives include specifying a URL pattern for the server to use =
and all clients to follow, specifying a query parameter for the update =
action, and specifying a separate endpoint entirely and using the =
presence of items such as client_id and the registration access token to =
differentiate the requests. Note that *all* of these alternatives can be =
accommodated using the semantics described above, with the same actions =
on the client's part.
>>>=20
>>>=20
>>> On syntax:
>>>=20
>>> Pro:
>>> - Follows the designs of RFC5988 for link relations
>>> - The HAL format is general, and allows for all kinds of other =
information to be placed inside the _links structure
>>> - Allows for full use of the JSON object to specify advanced =
operations on the returned endpoint if desired
>>>=20
>>> Con:
>>> - The rest of OAuth doesn't follow link relation guidelines (though =
it's been brought up)
>>> - The HAL format is general, and allows for all kinds of other =
information to be placed inside the _links structure
>>> - The HAL-JSON document is an expired individual I-D, and it's =
unclear what wider adoption looks like right now
>>>=20
>>> Alternatives include returning the URL as a separate data member =
(registration_update_url), using HTTP headers, or using JSON Schema.
>>>=20
>>> -- Justin
>>>=20
>>>=20
>>>=20
>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>>> [2] http://tools.ietf.org/html/draft-kelly-json-hal-03
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail=_7C4672B2-203B-4136-BA8D-A2E7A628786C
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

Returning a location header in the 201 ids fine as long as we also have the same info as a claim.

I think most clients will want to process the JSON and store all the parameters together.  Making them fish out a header makes the W3C happy and is the correct thing to do but taking it from a claim is what developers are more comfortable with.

John B.

On 2013-02-12, at 11:25 AM, Justin Richer <jricher@mitre.org> wrote:

    I'd be fine with the return from a creation request being a 201
    instead of a 200. 

     -- Justin

    On 02/11/2013 06:33 PM, Richard
      Harrington wrote:

      Since the request is an HTTP POST and a resource is created (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5) the response should be an
          HTTP 201 Created (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.2) which is supposed to include
          the location of the newly created resource.

      This is a good pattern to
          follow since, as you say, it does provide flexibility.

        On Feb 11, 2013, at 1:14 PM, Justin Richer <jricher@mitre.org>
        wrote:

        Draft -05 of OAuth Dynamic Client Registration [1]
            returns a URL pointer for the client to perform update and
            secret rotation actions. This functionality arose from
            discussions on the list about moving towards a more RESTful
            pattern, and Nat Sakimura proposed this approach in the
            OpenID Connect Working Group. This URL may be distinct from
            the Client Registration Endpoint URL, but draft -05 makes no
            promises as to its content, form, or structure, though it
            does contain implementor's notes on possible methods.

          Two questions arise from this change:

           - The semantics of returning the client manipulation
            URL

           - The syntax (derived from HAL for JSON [2], an
            individual I-D submission)

          On semantics:

          Pro:

           - The server has flexibility on how to define the
            "update" endpoint, sending all clients to one URL, sending
            different clients to different URLs, or sending clients to a
            URL with a baked-in query parameter

           - The client can take the URL as-is and use it for all
            management operations (ie, it doesn't have to generate or
            compose the URL based on component parts)

          Con:

           - The client must remember one more piece of
            information from the server at runtime if it wants to do
            manipulation and management of itself at the server (in
            addition to client_id, client_secret,
            registration_access_token, and others)

          Alternatives include specifying a URL pattern for the
            server to use and all clients to follow, specifying a query
            parameter for the update action, and specifying a separate
            endpoint entirely and using the presence of items such as
            client_id and the registration access token to differentiate
            the requests. Note that *all* of these alternatives can be
            accommodated using the semantics described above, with the
            same actions on the client's part.

          On syntax:

          Pro:

           - Follows the designs of RFC5988 for link relations

           - The HAL format is general, and allows for all kinds
            of other information to be placed inside the _links
            structure

           - Allows for full use of the JSON object to specify
            advanced operations on the returned endpoint if desired

          Con:

           - The rest of OAuth doesn't follow link relation
            guidelines (though it's been brought up)

           - The HAL format is general, and allows for all kinds
            of other information to be placed inside the _links
            structure

           - The HAL-JSON document is an expired individual I-D,
            and it's unclear what wider adoption looks like right now

          Alternatives include returning the URL as a separate
            data member (registration_update_url), using HTTP headers,
            or using JSON Schema.

           -- Justin

          [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05

          [2] http://tools.ietf.org/html/draft-kelly-json-hal-03

          _______________________________________________

          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

--Apple-Mail=_7C4672B2-203B-4136-BA8D-A2E7A628786C--

From wmills_92105@yahoo.com  Tue Feb 12 07:53:10 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4266C21F8E12 for ; Tue, 12 Feb 2013 07:53:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.039
X-Spam-Level: 
X-Spam-Status: No, score=-1.039 tagged_above=-999 required=5 tests=[AWL=-0.896, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SVNnpFGIsly for ; Tue, 12 Feb 2013 07:53:09 -0800 (PST)
Received: from nm5-vm0.bullet.mail.bf1.yahoo.com (nm5-vm0.bullet.mail.bf1.yahoo.com [98.139.213.150]) by ietfa.amsl.com (Postfix) with SMTP id C8DA221F8E0B for ; Tue, 12 Feb 2013 07:53:08 -0800 (PST)
Received: from [98.139.215.143] by nm5.bullet.mail.bf1.yahoo.com with NNFMP; 12 Feb 2013 15:53:08 -0000
Received: from [98.139.212.196] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 12 Feb 2013 15:53:08 -0000
Received: from [127.0.0.1] by omp1005.mail.bf1.yahoo.com with NNFMP; 12 Feb 2013 15:53:08 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 237798.69347.bm@omp1005.mail.bf1.yahoo.com
Received: (qmail 93152 invoked by uid 60001); 12 Feb 2013 15:53:07 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360684387; bh=OKw5hMCjrdEBPUXysIIzemmFAQ/c/sR9rFKtrj/E594=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=5LAnNkOtCRmsDKh+PefhBCn/iKq0MrPP7mo1XJ5tbDGBdfxJ6N8/bxlhOUF6PB2Q5ZxDJqsECunng5iqVf8PrMVxUNni3hsohqIbDCius4oBd1nWqmaMmryff7AiqbsG0LExZitwjczkSska+JUC7KPo8MJhPwqKm4uR/J//7bo=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=UvTR5RGItW+X4Tuh2mWHVYIg/czKeoKl8DVctvCNHQUyzmNFiFfqf9vnE6QkJyhtXqnPy7+OPew8H2cHEoM3qy7QRhV14hK/LMNYF0EySKgGd6LlyAhsAS0LgghuOnsZe5uwXDD8c2eHEYsAAZ9FzUd9A+cYtZSNaIc4gHMH04s=;
X-YMail-OSG: mIlMR9IVM1mJPu4L46scrIFWxY.YvM46FdGtlDgLCL9ITtZ LDhDizn6E6i2IV1VCJ0Ff53yzsXm00wzFN5Ff22oyN6l5PTpG4c.JQRe6CLc a4uEBLdYr5JR9wsXbDP86xaDPjU0s_3X0g7K.o5IYJf7IheD.2OfBpQPA.Yv vCvjARCjaY6w8B5XWK6ZVJHD4ee38hJZepVn_W_1jA7D8VkPO7GOY8Ut4smL oMxe_g.LtFd4szkvZ8S1ssAolTJtn6p8B._unpWVy.wvMcma2qyTPNhryWyc ggRWF7WJrLYSsiLADK9NdyoGNd.Gr2tizUas1_yQte3M6kY.jkyUOQ57apSa tNtiK5gHcMLqD4bKCKTFqN6CuNp0u7dJZBXN3xuAV6VHE7ZxblDlJAlevZqd NLVV1pefTjOT_JkB3sFeTOx2XxfFjZu19nDEeT6pmxbhxvnNrF7U8Re_aCZZ gI5JCntsF1lZlyHU71VR4CKxyHW4fBFRJKkC44rdwLd1kBY8OLzlAHwf5fMA 8dgsFCI7IdGnvFY1cVUSyiLOcjHhKZhcIi8pRK5At5mjEeHcWiRuh.AKGhxu dQum0nbWkqY2jREcM58S26A5cIT8f2nbMc4odZ2.rRh2qdePhI11MPjsbWot mbUS1NM_5_z0wwDUimgeyMy4bhA--
Received: from [209.131.62.115] by web31812.mail.mud.yahoo.com via HTTP; Tue, 12 Feb 2013 07:53:07 PST
X-Rocket-MIMEInfo: 001.001, T25lIG9mIHRoZSB0aGluZ3MgSSBkbyBub3QgbGlrZSBhYm91dCBhIE1USSBrZXkgdHJhbnNwb3J0IG1lY2hhbmlzbSBpZiB3ZSBwdXQgaXQgaW4gdGhlIHRva2VuIGlzIHRoYXQgdGhlcmUgd2lsbCBiZSBzb21lIHN5c3RlbXMgdGhhdCBhbHJlYWR5IGhhdmUgYSBwZXIgdXNlciBzZWNyZXQgcHJvdmlzaW9uZWQgYW5kIHdlJ2xsIGJlIGZvcmNpbmcgZGF0YSBkdXBsaWNhdGlvbi4gwqBJZiBpZiB0aGUgZW5jcnlwdGVkIHRva2VuIGFscmVhZHkgaW5jbHVkZXMgYW55IHJhbmRvbSBjb21wb25lbnQgdGhhdCBjb3UBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.133.508
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net> <1360661249.62997.YahooMailNeo@web31803.mail.mud.yahoo.com> <103117A9-0922-4E1A-AC73-D2914743046C@gmx.net>  <49D2CAF1-61AE-4DEB-A59D-D3F8F6D9C701@gmx.net>
Message-ID: <1360684387.88166.YahooMailNeo@web31812.mail.mud.yahoo.com>
Date: Tue, 12 Feb 2013 07:53:07 -0800 (PST)
From: William Mills 
To: Hannes Tschofenig , Antonio Sanso 
In-Reply-To: <49D2CAF1-61AE-4DEB-A59D-D3F8F6D9C701@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="1458549034-473964860-1360684387=:88166"
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 15:53:10 -0000

--1458549034-473964860-1360684387=:88166
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

One of the things I do not like about a MTI key transport mechanism if we p=
ut it in the token is that there will be some systems that already have a p=
er user secret provisioned and we'll be forcing data duplication. =A0If if =
the encrypted token already includes any random component that could easily=
 be used as part of the signing key. =A0So I feel like this will fatten up =
the token, potentially a lot.=0A=0AIf we don't put it in the token this pro=
blem is WAY harder.=0A=0A=0A________________________________=0A From: Hanne=
s Tschofenig =0ATo: Antonio Sanso  =0ACc: Hannes Tschofenig ; William Mills ; IETF oauth WG  =0ASent: Tuesday, Fe=
bruary 12, 2013 3:06 AM=0ASubject: Re: [OAUTH-WG] Minutes from the OAuth De=
sign Team Conference Call - 11th February 2013=0A =0AThe transport of the s=
ession key from the authorization server is described in Section 5.1 and is=
 called "mac_key". =0A=0AThe mechanism to transport the session key from th=
e authorization server to the resource server is not yet described in the d=
ocument. This has historical reasons: OAuth 1.0 did not separate the author=
ization server from the resource server in the way OAuth 2.0 does.=0A=0ACia=
o=0AHannes=0A=0AOn Feb 12, 2013, at 12:28 PM, Antonio Sanso wrote:=0A=0A> H=
i Hannes,=0A> =0A> how this session key "differs" from the key described in=
 the current draft [0]?=0A> =0A> Thanks and regards=0A> =0A> Antonio=0A> =
=0A> [0] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02=0A> =0A=
> On Feb 12, 2013, at 10:44 AM, Hannes Tschofenig wrote:=0A> =0A>> Hi Bill,=
 =0A>> =0A>> On Feb 12, 2013, at 11:27 AM, William Mills wrote:=0A>> =0A>>>=
 Is key distribution how AS and PR share keys=A0 for token encryption/decry=
ption or specifically about the keys for the HOK tokens?=0A>>> =0A>> In ord=
er for the client to compute the keyed message digest it needs to have the =
session key. This session key is sent from the authorization server to the =
client and everyone on the call agreed that this has to be standardized. =
=0A>> =0A>> The resource server who receives the message from the client al=
so needs to have the session key to verify the message. How the resource se=
rver obtains this session key was subject for some discussion on the call. =
I presented three different ways of how the resource server is able to obta=
in that key. We have to decide on one mandatory-to-implement mechanism. The=
 open issue is which one? =0A>> =0A>>> For the MAC token spec, I don't actu=
ally care whether we use JSON or now, but I'm in full agreement that we do =
NOT duplicate any HTTP info into the JSON.=A0 Just signatures of that stuff=
.=0A>>> =0A>> I believe the folks on the call also agreed with you on that =
aspect that the content of the HTTP message should not be replicated in the=
 JSON payload itself. =0A>> =0A>> Ciao=0A>> Hannes=0A>> =0A>>> From: Hannes=
 Tschofenig =0A>>> To: IETF oauth WG  =0A>>> Sent: Tuesday, February 12, 2013 1:10 AM=0A>>> Subject: [OAUTH=
-WG] Minutes from the OAuth Design Team Conference Call - 11th February 201=
3=0A>>> =0A>>> Here are my notes. =0A>>> =0A>>> Participants:=0A>>> =0A>>> =
* John Bradley=0A>>> * Derek Atkins=0A>>> * Phil Hunt=0A>>> * Prateek Mishr=
a=0A>>> * Hannes Tschofenig=0A>>> * Mike Jones=0A>>> * Antonio Sanso=0A>>> =
* Justin Richer=0A>>> =0A>>> Notes: =0A>>> =0A>>> My slides are available h=
ere: http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt=0A>>> =0A>=
>> Slide #2 summarizes earlier discussions during the conference calls. =0A=
>>> =0A>>> -- HTTP vs. JSON=0A>>> =0A>>> Phil noted that he does not like t=
o use the MAC Token draft as a starting point because it does not re-use an=
y of the work done in the JOSE working group and in particular all the libr=
aries that are available today. He mentioned that earlier attempts to write=
 the MAC Token code lead to problems for implementers. =0A>>> =0A>>> Justin=
 responded that he does not agree with using JSON as a transport mechanism =
since this would replicate a SOAP style. =0A>>> =0A>>> Phil noted that he w=
ants to send JSON but the signature shall be computed over the HTTP header =
field. =0A>>> =0A>>> -- Flexibility for the keyed message digest computatio=
n=0A>>> =0A>>> From earlier discussion it was clear that the conference cal=
l participants wanted more flexibility regarding the keyed message digest c=
omputation. For this purpose Hannes presented the DKIM based approach, whic=
h allows selective header fields to be included in the digest. This is show=
n in slide #4. =0A>>> =0A>>> After some discussion the conference call part=
icipants thought that this would meet their needs. Further investigations w=
ould still be useful to determine the degree of failed HMAC calculations du=
e to HTTP proxies modifying the content. =0A>>> =0A>>> -- Key Distribution=
=0A>>> =0A>>> Hannes presented the open issue regarding the choice of key d=
istribution. Slides #6-#8 present three techniques and Hannes asked for fee=
dback regarding the preferred style. Justin and others didn't see the need =
to decide on one mechanism - they wanted to keep the choice open. Derek ind=
icated that this will not be an acceptable approach. Since the resource ser=
ver and the authorization server may, in the OAuth 2.0 framework, be entiti=
es produced by different vendors there is an interoperability need. Justin =
responded that he disagrees and that the resource server needs to understan=
d the access token and referred to the recent draft submission for the toke=
n introspection endpoint. Derek indicated that the resource server has to u=
nderstand the content of the access token and the token introspection endpo=
int just pushes the problem around: the resource server has to send the acc=
ess token to the authorization server and then the resource server gets the
 result back (which he then=0A>> a=0A>>> gain needs to understand) in order=
 to make a meaningful authorization decision. =0A>>> =0A>>> Everyone agreed=
 that the client must receive the session key from the authorization server=
 and that this approach has to be standardized. It was also agreed that thi=
s is a common approach among all three key distribution mechanisms.=0A>>> =
=0A>>> Hannes asked the participants to think about their preference. =0A>>=
> =0A>>> The questions regarding key naming and the indication for the inte=
nded resource server the client wants to talk to have been postponed. =0A>>=
> =0A>>> Ciao=0A>>> Hannes=0A>>> =0A>>> =0A>>> ____________________________=
___________________=0A>>> OAuth mailing list=0A>>> OAuth@ietf.org=0A>>> htt=
ps://www.ietf.org/mailman/listinfo/oauth=0A>>> =0A>>> =0A>> =0A>> _________=
______________________________________=0A>> OAuth mailing list=0A>> OAuth@i=
etf.org=0A>> https://www.ietf.org/mailman/listinfo/oauth=0A> 
--1458549034-473964860-1360684387=:88166
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

One of the things I do not like about a MTI key transport mechanism if we=
 put it in the token is that there will be some systems that already have a=
 per user secret provisioned and we'll be forcing data duplication.  I=
f if the encrypted token already includes any random component that could e=
asily be used as part of the signing key.  So I feel like this will fa=
tten up the token, potentially a lot.

If we don't put it in the
 token this problem is WAY harder.

  From:<=
/b> Hannes Tschofenig <hannes.tschofenig@gmx.net>
 To: Antonio Sanso <asanso@adobe.com&g=
t; 
Cc: Hannes Tschofen=
ig <hannes.tschofenig@gmx.net>; William Mills <wmills_92105@yahoo.=
com>; IETF oauth WG <oauth@ietf.org> 
 Sent: Tuesday, February 12, 2013 3:06 AM
 Subject: Re: [OAUTH-WG] Minutes=
 from the OAuth Design Team Conference Call - 11th February 2013

=0AThe transport of the session key from the authorization ser=
ver is described in Section 5.1 and is called "mac_key". 

The mechan=
ism to transport the session key from the authorization server to the resou=
rce server is not yet described in the document. This has historical reason=
s: OAuth 1.0 did not separate the authorization server from the resource se=
rver in the way OAuth 2.0 does.

Ciao
Hannes

On Feb 12, 201=
3, at 12:28 PM, Antonio Sanso wrote:

> Hi Hannes,
> 
>=
; how this session key "differs" from the key described in the current draf=
t [0]?
> 
> Thanks and regards
> 
> Antonio
>=

> [0] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02> 
> On Feb 12, 2013, at 10:44 AM, Hannes Tschofenig wrote:
&g=
t; 
>> Hi Bill, 
>> 
>> On Feb 12, 2013, at 11:2=
7 AM, William Mills wrote:
>> 
>>> Is key distribution=
 how AS
 and PR share keys  for token encryption/decryption or specifically ab=
out the keys for the HOK tokens?
>>> 
>> In order for =
the client to compute the keyed message digest it needs to have the session=
 key. This session key is sent from the authorization server to the client =
and everyone on the call agreed that this has to be standardized. 
>&=
gt; 
>> The resource server who receives the message from the clie=
nt also needs to have the session key to verify the message. How the resour=
ce server obtains this session key was subject for some discussion on the c=
all. I presented three different ways of how the resource server is able to=
 obtain that key. We have to decide on one mandatory-to-implement mechanism=
. The open issue is which one? 
>> 
>>> For the MAC to=
ken spec, I don't actually care whether we use JSON or now, but I'm in full=
 agreement that we do NOT duplicate any HTTP info into the
 JSON.  Just signatures of that stuff.
>>> 
>> I =
believe the folks on the call also agreed with you on that aspect that the =
content of the HTTP message should not be replicated in the JSON payload it=
self. 
>> 
>> Ciao
>> Hannes
>> 
>=
;>> From: Hannes Tschofenig <hannes.tschofenig@gmx.=
net>
>>> To: IETF oauth WG <oauth@ietf.org> 
>&=
gt;> Sent: Tuesday, February 12, 2013 1:10 AM
>>> Subject: [=
OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th Februar=
y 2013
>>> 
>>> Here are my notes. 
>>>=

>>> Participants:
>>> 
>>> * John Bra=
dley
>>> * Derek Atkins
>>> * Phil
 Hunt
>>> * Prateek Mishra
>>> * Hannes Tschofenig<=
br>>>> * Mike Jones
>>> * Antonio Sanso
>>>=
; * Justin Richer
>>> 
>>> Notes: 
>>> =

>>> My slides are available here: http://www.tschofenig.priv.a=
t/OAuth2-Security-11Feb2013.ppt
>>> 
>>> Slide #2 s=
ummarizes earlier discussions during the conference calls. 
>>>=

>>> -- HTTP vs. JSON
>>> 
>>> Phil no=
ted that he does not like to use the MAC Token draft as a starting point be=
cause it does not re-use any of the work done in the JOSE working group and=
 in particular all the libraries that are available today. He mentioned tha=
t earlier attempts to write the MAC Token code lead to problems for impleme=
nters. 
>>> 
>>> Justin responded that he does not =
agree with using JSON as a transport mechanism since this would
 replicate a SOAP style. 
>>> 
>>> Phil noted that =
he wants to send JSON but the signature shall be computed over the HTTP hea=
der field. 
>>> 
>>> -- Flexibility for the keyed m=
essage digest computation
>>> 
>>> From earlier dis=
cussion it was clear that the conference call participants wanted more flex=
ibility regarding the keyed message digest computation. For this purpose Ha=
nnes presented the DKIM based approach, which allows selective header field=
s to be included in the digest. This is shown in slide #4. 
>>>=

>>> After some discussion the conference call participants th=
ought that this would meet their needs. Further investigations would still =
be useful to determine the degree of failed HMAC calculations due to HTTP p=
roxies modifying the content. 
>>> 
>>> -- Key Dist=
ribution
>>> 
>>> Hannes presented the open
 issue regarding the choice of key distribution. Slides #6-#8 present three=
 techniques and Hannes asked for feedback regarding the preferred style. Ju=
stin and others didn't see the need to decide on one mechanism - they wante=
d to keep the choice open. Derek indicated that this will not be an accepta=
ble approach. Since the resource server and the authorization server may, i=
n the OAuth 2.0 framework, be entities produced by different vendors there =
is an interoperability need. Justin responded that he disagrees and that th=
e resource server needs to understand the access token and referred to the =
recent draft submission for the token introspection endpoint. Derek indicat=
ed that the resource server has to understand the content of the access tok=
en and the token introspection endpoint just pushes the problem around: the=
 resource server has to send the access token to the authorization server a=
nd then the resource server gets the result back (which he
 then
>> a
>>> gain needs to understand) in order to m=
ake a meaningful authorization decision. 
>>> 
>>> =
Everyone agreed that the client must receive the session key from the autho=
rization server and that this approach has to be standardized. It was also =
agreed that this is a common approach among all three key distribution mech=
anisms.
>>> 
>>> Hannes asked the participants to t=
hink about their preference. 
>>> 
>>> The question=
s regarding key naming and the indication for the intended resource server =
the client wants to talk to have been postponed. 
>>> 
>&=
gt;> Ciao
>>> Hannes
>>> 
>>> 
&g=
t;>> _______________________________________________
>>> =
OAuth mailing list
>>> OAuth@ietf.org
>>> htt=
ps://www.ietf.org/mailman/listinfo/oauth
>>> 
>>&g=
t; 
>> 
>> ______________________________________________=
_
>> OAuth mailing list
>> OAuth@ietf.org
>> https:/=
/www.ietf.org/mailman/listinfo/oauth
> 

--1458549034-473964860-1360684387=:88166--

From prabath@wso2.com  Tue Feb 12 08:05:22 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD1F21F8F1E for ; Tue, 12 Feb 2013 08:05:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.865
X-Spam-Level: 
X-Spam-Status: No, score=-2.865 tagged_above=-999 required=5 tests=[AWL=0.111,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5jDcozYxgnR for ; Tue, 12 Feb 2013 08:05:20 -0800 (PST)
Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by ietfa.amsl.com (Postfix) with ESMTP id A0F1A21F8F1B for ; Tue, 12 Feb 2013 08:05:19 -0800 (PST)
Received: by mail-ee0-f48.google.com with SMTP id t10so137029eei.7 for ; Tue, 12 Feb 2013 08:05:18 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=it/14u1JfGU6DtGA5b4yXyzZyEf2444lhjmxeMOSRuQ=; b=iPKeiNTj2yCzDyD7eTs8sAsgXmFLQ/T4mJi4XySdMSoQd69bRJP55XU+3tiNcN5Q1B r2jUldbtMNMYNF2j2AWskGziATUWtFCpVG0qeV811LUcuEigCk20QE5PnsPVzEDOAfRg TPaiVHZGVw6W6nQQjDGADGmUB922ic7HMzmSgwg6/HxTNZLzifvkDa4i5qCfHDrClxU4 i+iHJQ+iK/YoYWufx9W7eoiYoiaocwB7NVn9jRDdnl1waRwRGkq+Q2q2bXgq9ovBNeht rr/lkGt3SL8RTnQMh+bRRaTylddkCAXZCyZjjUqK2ZWvLCH+sdDdr5e66Sz3+M+g1AHS Y3Zg==
MIME-Version: 1.0
X-Received: by 10.14.218.71 with SMTP id j47mr63953602eep.28.1360685107999; Tue, 12 Feb 2013 08:05:07 -0800 (PST)
Received: by 10.223.146.76 with HTTP; Tue, 12 Feb 2013 08:05:07 -0800 (PST)
In-Reply-To: <511A5062.5010108@mitre.org>
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com> <5112AE0B.1080501@mitre.org>  <5113C3AA.1040701@mitre.org>  <5113DDB2.7060805@mitre.org>  <51196777.6000502@mitre.org>   <511A5062.5010108@mitre.org>
Date: Tue, 12 Feb 2013 21:35:07 +0530
Message-ID: 
From: Prabath Siriwardena 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=047d7b621afc8372fb04d5893011
X-Gm-Message-State: ALoCoQn0JigXseWdnQLW4LcVzw8mGnYCHagkUkspk5y1pEq38PoM4KL7+ALfhFbaFULqQnphzbrZ
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 16:05:22 -0000

--047d7b621afc8372fb04d5893011
Content-Type: text/plain; charset=ISO-8859-1

Hi Justin,

I doubt whether valid_token would make a difference..?

My initial argument is what is the validation criteria..? Validation
criteria depends on the token_type..

If we are talking only about metadata - then I believe "revoked", "expired"
would be more meaningful..

Thanks & regards,
-Prabath

On Tue, Feb 12, 2013 at 7:53 PM, Justin Richer  wrote:

>  OK, I can see the wisdom in changing this term.
>
> I picked "valid" because I wanted a simple "boolean" value that would
> require no additional parsing or string-matching on the client's behalf,
> and I'd like to stick with that. OAuth is built with the assumption that
> clients need to be able to recover from invalid tokens at any stage, so I
> think a simple yes/no is the right step here.
>
> That said, I think you're both right that "valid" seems to have caused a
> bit of confusion. I don't want to go with "revoked" because I'd rather have
> the "token is OK" be the positive boolean value.
>
> Would "valid_token" be more clear? Or do we need a different adjective all
> together?
>
>  -- Justin
>
>
> On 02/11/2013 08:02 PM, Richard Harrington wrote:
>
> Have you considered "status" instead of "valid"?  It could have values
> like "active", "expired", and "revoked".
>
>  Is it worthwhile including the status of the client also?  For example,
> a client application could be disabled, temporarily or permanently, and
> thus disabling its access tokens as well.
>
>
> On Feb 11, 2013, at 1:56 PM, Prabath Siriwardena  wrote:
>
>  I guess confusion is with 'valid' parameter is in the response..
>
>  I thought this will be helpful to standardize the communication between
> Resource Server and the Authorization Server..
>
>  I would suggest we completely remove "valid" from the response - or
> define it much clearly..
>
>  May be can add "revoked" with a boolean attribute..
>
>  Thanks & regards,
> -Prabath
>
> On Tue, Feb 12, 2013 at 3:19 AM, Justin Richer  wrote:
>
>>
>> On 02/08/2013 12:51 AM, Prabath Siriwardena wrote:
>>
>> Hi Justin,
>>
>>  I have couple of questions related to "valid" parameter...
>>
>>  This endpoint can be invoked by the Resource Server in runtime...
>>
>>
>> That's correct.
>>
>>
>>
>>  In that case what is exactly meant by the "resource_id" in request ?
>>
>>
>>  The resource_id field is a service-specific string that basically lets
>> the resource server provide some context to the request to the auth server.
>> There have been some other suggestions like client IP address, but I wanted
>> to put this one in because it seemed to be a common theme. The client is
>> trying to do *something* with the token, after all, and the rights,
>> permissions, and metadata associated with the token could change based on
>> that. Since the Introspection endpoint is all about getting that metadata
>> back to the PR, this seemed like a good idea.
>>
>>
>>
>>  IMO a token to be valid depends on set of criteria based on it's type..
>>
>>  For a Bearer token..
>>
>>  1. Token should not be expired
>> 2. Token should not be revoked.
>> 3. The scope the token issued should match with the scope required for
>> the resource.
>>
>>  For a MAC token...
>>
>>  1. Token not expired (mac id)
>> 2. Token should not be revoked
>> 3. The scope the token issued should match with the scope required for
>> the resource.
>> 4. HMAC check should be valid
>>
>>  There are similar conditions for SAML bearer too..
>>
>>
>>  This isn't really true. The SAML bearer token is fully self-contained
>> and doesn't change based on other parameters in the message, unlike MAC.
>> Same with JWT. When it hands a SAML or JWT token to the AS, the PR has
>> given *everything* the server needs to check that token's validity and use.
>>
>> MAC signatures change with every message, and they're done across several
>> components of the HTTP message. Therefor, the HMAC check for MAC style
>> tokens will still need to be done by the protected resource. Introspection
>> would help in the case that the signature validated just fine, but the
>> token might have expired. Or you need to know what scopes apply.
>> Introspection isn't to fully validate the call to the protected resource --
>> if that were the case, the PR would have to send some kind of encapsulated
>> version of the original request. Otherwise, the AS won't have all of the
>> information it needs to check the MAC.
>>
>>
>> I think what you're describing is ultimately *not* what the introspection
>> endpoint is intended to do. If that's unclear from the document, can you
>> please suggest text that would help clear the use case up? I wouldn't want
>> it to be ambiguous.
>>
>>  -- Justin
>>
>>
>>
>>  Thanks & regards,
>> -Prabath
>>
>>
>> On Thu, Feb 7, 2013 at 10:30 PM, Justin Richer  wrote:
>>
>>>  It validates the token, which would be either the token itself in the
>>> case of Bearer or the token "id" part of something more complex like MAC.
>>> It doesn't directly validate the usage of the token, that's still up to the
>>> PR to do that.
>>>
>>> I nearly added a "token type" field in this draft, but held back because
>>> there are several kinds of "token type" that people talk about in OAuth.
>>> First, there's "Bearer" vs. "MAC" vs. "HOK", or what have you. Then within
>>> Bearer you have "JWT" or "SAML" or "unstructured blob". Then you've also
>>> got "access" vs. "refresh" and other flavors of token, like the id_token in
>>> OpenID Connect.
>>>
>>> Thing is, the server running the introspection endpoint will probably
>>> know *all* of these. But should it tell the client? If so, which of the
>>> three, and what names should the fields be?
>>>
>>>  -- Justin
>>>
>>>
>>> On 02/07/2013 11:26 AM, Prabath Siriwardena wrote:
>>>
>>> Okay.. I was thinking this could be used as a way to validate the token
>>> as well. BTW even in this case shouldn't communicate the type of token to
>>> AS? For example in the case of SAML profile - it could be SAML token..
>>>
>>>  Thanks & regards,
>>> -Prabath
>>>
>>> On Thu, Feb 7, 2013 at 8:39 PM, Justin Richer  wrote:
>>>
>>>>  "valid" might not be the best term, but it's meant to be a field where
>>>> the server says "yes this token is still good" or "no this token isn't good
>>>> anymore". We could instead do this with HTTP codes or something but I went
>>>> with a pure JSON response.
>>>>
>>>>  -- Justin
>>>>
>>>>
>>>> On 02/06/2013 10:47 PM, Prabath Siriwardena wrote:
>>>>
>>>> Hi Justin,
>>>>
>>>>  I believe this is addressing one of the key missing part in OAuth
>>>> 2.0...
>>>>
>>>>  One question - I guess this was discussed already...
>>>>
>>>>  In the spec - in the introspection response it has the attribute
>>>> "valid" - this is basically the validity of the token provided in the
>>>> request.
>>>>
>>>>  Validation criteria depends on the token and well as token type (
>>>> Bearer, MAC..).
>>>>
>>>>  In the spec it seems like it's coupled with Bearer token type... But
>>>> I guess, by adding "token_type" to the request we can remove this
>>>> dependency.
>>>>
>>>>  WDYT..?
>>>>
>>>>  Thanks & regards,
>>>> -Prabath
>>>>
>>>> On Thu, Feb 7, 2013 at 12:54 AM, Justin Richer wrote:
>>>>
>>>>>  Updated introspection draft based on recent comments. Changes include:
>>>>>
>>>>>  - "scope" return parameter now follows RFC6749 format instead of JSON
>>>>> array
>>>>>  - "subject" -> "sub", and "audience" -> "aud", to be parallel with
>>>>> JWT claims
>>>>>  - clarified what happens if the authentication is bad
>>>>>
>>>>>  -- Justin
>>>>>
>>>>>
>>>>> -------- Original Message --------  Subject: New Version Notification
>>>>> for draft-richer-oauth-introspection-02.txt  Date: Wed, 6 Feb 2013
>>>>> 11:24:20 -0800  From:   To:
>>>>>  
>>>>>
>>>>> A new version of I-D, draft-richer-oauth-introspection-02.txt
>>>>> has been successfully submitted by Justin Richer and posted to the
>>>>> IETF repository.
>>>>>
>>>>> Filename:	 draft-richer-oauth-introspection
>>>>> Revision:	 02
>>>>> Title:		 OAuth Token Introspection
>>>>> Creation date:	 2013-02-06
>>>>> WG ID:		 Individual Submission
>>>>> Number of pages: 6
>>>>> URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
>>>>> Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
>>>>> Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-02
>>>>> Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02
>>>>>
>>>>> Abstract:
>>>>>    This specification defines a method for a client or protected
>>>>>    resource to query an OAuth authorization server to determine meta-
>>>>>    information about an OAuth token.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> The IETF Secretariat
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>>
>>>>
>>>>
>>>>  --
>>>> Thanks & Regards,
>>>> Prabath
>>>>
>>>>  Mobile : +94 71 809 6732
>>>>
>>>> http://blog.facilelogin.com
>>>> http://RampartFAQ.com
>>>>
>>>>
>>>>
>>>
>>>
>>>  --
>>> Thanks & Regards,
>>> Prabath
>>>
>>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>>
>>> http://blog.facilelogin.com
>>> http://RampartFAQ.com
>>>
>>>
>>>
>>
>>
>>  --
>> Thanks & Regards,
>> Prabath
>>
>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>
>> http://blog.facilelogin.com
>> http://RampartFAQ.com
>>
>>
>>
>
>
>  --
> Thanks & Regards,
> Prabath
>
>  Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com
>
>  _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.com

--047d7b621afc8372fb04d5893011
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Justin,
I doubt whether valid_token would make a diff=
erence..?

My initial argument is what is the valid=
ation criteria..? Validation criteria depends on the token_type..

If we are talking only about metadata - then I believe "=
;revoked", "expired" would be more meaningful..
Thanks & regards,
-Prabath

On Tue, Feb 12, 2013 at 7:53 PM, Justin Richer <jricher@mitre.org><=
/span> wrote:

 =20
   =20
 =20

    OK, I can see the wisdom in changing this term. 

    I picked "valid" because I wanted a simple "boolean"=
; value that
    would require no additional parsing or string-matching on the
    client's behalf, and I'd like to stick with that. OAuth is buil=
t
    with the assumption that clients need to be able to recover from
    invalid tokens at any stage, so I think a simple yes/no is the right
    step here. 

    That said, I think you're both right that "valid" seems t=
o have
    caused a bit of confusion. I don't want to go with "revoked&qu=
ot; because
    I'd rather have the "token is OK" be the positive boolean=
 value. 

    Would "valid_token" be more clear? Or do we need a different
    adjective all together?<=
br>

    =A0-- Justin

    On 02/11/2013 08:02 PM, Richard
      Harrington wrote:

     =20
      Have you considered "status" instead of "valid&qu=
ot;? =A0It could
        have values like "active", "expired", and "=
;revoked".

      Is it worthwhile including the status of the client also?
        =A0For example, a client application could be disabled,
        temporarily or permanently, and thus disabling its access tokens
        as well.

        On Feb 11, 2013, at 1:56 PM, Prabath Siriwardena <prabath@wso2.com>
        wrote:

        I guess confusion is with 'valid' parameter is in the
          response..

          I thought this will be helpful to=A0standardize=A0the
            communication between Resource Server and the Authorization
            Server..

          I would suggest we completely remove "valid" from =
the
            response - or define it much clearly..

          May be can add "revoked" with a boolean attribute.=
.

          Thanks & regards,
          -Prabath

            On Tue, Feb 12, 2013 at 3:19 AM,
              Justin Richer <jricher@mitre.org>
              wrote:

                    On 02/08/2013 12:51 AM, Prabath Siriwardena
                      wrote:

                   Hi=A0Justin,

                      I have couple of questions related to "vali=
d"
                        parameter...

                      This endpoint can be invoked by the Resource
                        Server in runtime...

                  That's correct.

                      In that case what is exactly meant by the
                        "resource_id" in request ?

                  The resource_id field is a service-specific string
                  that basically lets the resource server provide some
                  context to the request to the auth server. There have
                  been some other suggestions like client IP address,
                  but I wanted to put this one in because it seemed to
                  be a common theme. The client is trying to do
                  *something* with the token, after all, and the rights,
                  permissions, and metadata associated with the token
                  could change based on that. Since the Introspection
                  endpoint is all about getting that metadata back to
                  the PR, this seemed like a good idea.

                      IMO a token to be valid depends on set of
                        criteria based on it's type..

                      For a Bearer token..

                      1. Token should not be expired
                      2. Token should not be revoked.
                      3. The scope the token issued should match
                        with the scope required for the resource.

                      For a MAC token...

                      1. Token not expired (mac id)
                      2. Token should not be revoked
                      3. The scope the token issued should match
                        with the scope required for the resource.
                      4. HMAC check should be valid

                      There are similar conditions for SAML bearer too..

                  This isn't really true. The SAML bearer token is full=
y
                  self-contained and doesn't change based on other
                  parameters in the message, unlike MAC. Same with JWT.
                  When it hands a SAML or JWT token to the AS, the PR
                  has given *everything* the server needs to check that
                  token's validity and use. 

                  MAC signatures change with every message, and they're
                  done across several components of the HTTP message.
                  Therefor, the HMAC check for MAC style tokens will
                  still need to be done by the protected resource.
                  Introspection would help in the case that the
                  signature validated just fine, but the token might
                  have expired. Or you need to know what scopes apply.
                  Introspection isn't to fully validate the call to the
                  protected resource -- if that were the case, the PR
                  would have to send some kind of encapsulated version
                  of the original request. Otherwise, the AS won't have
                  all of the information it needs to check the MAC.

                  I think what you're describing is ultimately *not*
                  what the introspection endpoint is intended to do. If
                  that's unclear from the document, can you please
                  suggest text that would help clear the use case up? I
                  wouldn't want it to be ambiguous.

                      =A0-- Justin

                        Thanks & regards,
                        -Prabath

                          On Thu, Feb 7, 2013
                            at 10:30 PM, Justin Richer &l=
t;jricher@mitre.org<=
/a>>
                            wrote:

                               It
                                validates the token, which would be
                                either the token itself in the case of
                                Bearer or the token "id" part of
                                something more complex like MAC. It
                                doesn't directly validate the usage of
                                the token, that's still up to the PR to
                                do that.

                                I nearly added a "token type" fie=
ld in
                                this draft, but held back because there
                                are several kinds of "token type"=
 that
                                people talk about in OAuth. First,
                                there's "Bearer" vs. "MA=
C" vs. "HOK", or
                                what have you. Then within Bearer you
                                have "JWT" or "SAML" or=
 "unstructured
                                blob". Then you've also got "=
access" vs.
                                "refresh" and other flavors of to=
ken,
                                like the id_token in OpenID Connect. 

                                Thing is, the server running the
                                introspection endpoint will probably
                                know *all* of these. But should it tell
                                the client? If so, which of the three,
                                and what names should the fields be?<=
font color=3D"#888888">

                                    =A0-- Justin

                                    On 02/07/2013 11:26 AM, Prabath
                                      Siriwardena wrote:

                                     Okay.. I
                                      was thinking this could be used as
                                      a way to validate the token as
                                      well. BTW even in this case
                                      shouldn't communicate the type of
                                      token to AS? For example in the
                                      case of SAML profile - it could be
                                      SAML token..

                                      Thanks & regards,
                                      -Prabath

                                        On Thu,
                                          Feb 7, 2013 at 8:39 PM, Justin
                                          Richer <jricher@mitre.org>=
;
                                          wrote:

                                             "valid"
                                              might not be the best
                                              term, but it's meant to b=
e
                                              a field where the server
                                              says "yes this token is
                                              still good" or "no =
this
                                              token isn't good anymore&=
quot;.
                                              We could instead do this
                                              with HTTP codes or
                                              something but I went with
                                              a pure JSON response.

                                                  =A0-- Justin

                                                  On 02/06/2013
                                                    10:47 PM, Prabath
                                                    Siriwardena wrote:

                                                   Hi
                                                    Justin,

                                                    I believe this
                                                      is addressing one
                                                      of the key missing
                                                      part in OAuth
                                                      2.0...

                                                    One question -
                                                      I guess this was
                                                      discussed
                                                      already...

                                                    In the spec -
                                                      in the
                                                      introspection
                                                      response it has
                                                      the attribute
                                                      "valid" - t=
his is
                                                      basically the
                                                      validity of the
                                                      token provided in
                                                      the request.

                                                    Validation=A0crite=
ria
                                                      depends on the
                                                      token and well as
                                                      token type (
                                                      Bearer, MAC..).

                                                    In the spec it
                                                      seems like it's
                                                      coupled with
                                                      Bearer token
                                                      type... But I
                                                      guess, by adding
                                                      "token_type"=
; to
                                                      the request we can
                                                      remove this
                                                      dependency.

                                                    WDYT..?

                                                    Thanks &
                                                      regards,
                                                    -Prabath=A0

                                                      On
                                                        Thu, Feb 7, 2013
                                                        at 12:54 AM,
                                                        Justin Richer <jri=
cher@mitre.org>
                                                        wrote:

                                                          Updated
                                                          introspection
                                                          draft based on
                                                          recent
                                                          comments.
                                                          Changes
                                                          include:

                                                          =A0- "scope&=
quot;
                                                          return
                                                          parameter now
                                                          follows
                                                          RFC6749 format
                                                          instead of
                                                          JSON array

                                                          =A0- "subjec=
t"
                                                          -> "sub&q=
uot;,
                                                          and "audienc=
e"
                                                          -> "aud&q=
uot;,
                                                          to be parallel
                                                          with JWT
                                                          claims

                                                          =A0- clarified
                                                          what happens
                                                          if the
                                                          authentication
                                                          is bad

                                                          =A0-- Justin

                                                          --------
                                                          Original
                                                          Message
                                                          --------

                                                          Subject: 
                                                          New
                                                          Version
                                                          Notification
                                                          for
                                                          draft-richer-oaut=
h-introspection-02.txt

                                                          Date: 
                                                          Wed, 6 Feb
                                                          2013 11:24:20
                                                          -0800

                                                          From: 
                                                          <internet-drafts@ietf.o=
rg>

                                                          To: 
                                                          <jricher@mitre.org>

                                                          A new versio=
n of I-D, draft-richer-oauth-introspection-02.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 02
Title:		 OAuth Token Introspection
Creation date:	 2013-02-06
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/interne=
t-drafts/draft-richer-oauth-introspection-02.txt
Status:          http://datatracker.ietf.org/doc/draft-=
richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-=
oauth-introspection-02
Diff:            http://www.ietf.org/rfcdiff?url2=
=3Ddraft-richer-oauth-introspection-02

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.

                                                                           =
      =20

The IETF Secretariat

_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

                                                          https://www.ietf.o=
rg/mailman/listinfo/oauth

                                                      -- 

                                                      Thanks &
                                                      Regards,

                                                      Prabath

                                                      Mobile : +=
94 71 809 6732=A0

                                                        http://blog.facilelogin.com

                                                        http://RampartFAQ.com

                                        -- 

                                        Thanks & Regards,

                                        Prabath

                                        Mobile : +94 71 809
                                            6732=A0

                                          http://blog.facilelogin.com

                                          http://RampartFAQ.com

                          -- 

                          Thanks & Regards,

                          Prabath

                          Mobile : +94
                              71 809 6732=A0

                            http://blog.facilelogin.com

                            http://RampartFAQ.com

            -- 

            Thanks & Regards,

            Prabath

            Mobile : +94 71 809 6732=A0

              htt=
p://blog.facilelogin.com

              http://Ra=
mpartFAQ.com

        _______________________________________________
          OAuth mailing list

          OAuth@i=
etf.org

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

-- 
Thanks &=
 Regards,
Prabath
Mobile : +94 71 809 6732=A0

=
http://blog.facil=
elogin.com

http://RampartFAQ.com

--047d7b621afc8372fb04d5893011--

From ve7jtb@ve7jtb.com  Tue Feb 12 08:20:43 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66FF821F8F7A for ; Tue, 12 Feb 2013 08:20:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.864
X-Spam-Level: 
X-Spam-Status: No, score=-2.864 tagged_above=-999 required=5 tests=[AWL=0.135,  BAYES_00=-2.599, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTVfvrek1qvT for ; Tue, 12 Feb 2013 08:20:42 -0800 (PST)
Received: from mail-qe0-f52.google.com (mail-qe0-f52.google.com [209.85.128.52]) by ietfa.amsl.com (Postfix) with ESMTP id 4965721F8F6C for ; Tue, 12 Feb 2013 08:20:42 -0800 (PST)
Received: by mail-qe0-f52.google.com with SMTP id 6so116221qeb.11 for ; Tue, 12 Feb 2013 08:20:37 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=+D6SVwsgVjjxYIhuD7vEwrSAn5IJ9H6hTz6JNcDjD8U=; b=bL+DbsBB9xWzTYbJIIV0s0+ifysusQhTyb0K3fXN0KrpsG0z+RXsEt4f9QdeGOPl+H C1DsLKNjOJV4J1tNjz8gY5vrhr2Rit4AWAr3EPeAv+gBUlveVn+y90WxKsRojnugIuni ZTygom4n/c4ACu1vdFIunsnX+45SqQozO81GD+N0tkr2UI6GLirO+exo/8xc2hYe/Yyd D2L13Jix20OPxUzmR9wSDASop9wL600vA4p9zzzzH15K7eEaT1AkIOJhExBKxVJarPbk GxCLzc+VafHSBagAb6LA+5rr8lkWSQgjkjPkOu4uDNlZON4DrOzr/oNEM7cKbo1CAE4h yt+g==
X-Received: by 10.49.127.145 with SMTP id ng17mr8045840qeb.25.1360686036701; Tue, 12 Feb 2013 08:20:36 -0800 (PST)
Received: from [192.168.1.213] (190-20-23-212.baf.movistar.cl. [190.20.23.212]) by mx.google.com with ESMTPS id o5sm16620858qao.12.2013.02.12.08.20.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 08:20:35 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <511A51D6.9040604@mitre.org>
Date: Tue, 12 Feb 2013 13:20:28 -0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <9FC3A5CD-B4EC-4CA2-8082-FAC65C499B3B@ve7jtb.com>
References: <51195F3F.7000704@mitre.org> <4E1F6AAD24975D4BA5B16804296739436743E371@TK5EX14MBXC285.redmond.corp.microsoft.com> <7FB7A108-EA9E-429A-BD86-7E09EA206748@ve7jtb.com> <511A51D6.9040604@mitre.org>
To: Justin Richer 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQm4sukEqQce4mSZAStenrk9ADdWoX/Tjje6WuMXZFbN5p/JCGl/dLO/XLaNjNJ9Kx3NkOr4
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: Client secret rotation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 16:20:43 -0000

Yes, that agrees with my thoughts on it.

John B.
On 2013-02-12, at 11:29 AM, Justin Richer  wrote:

> This is actually the approach that I favor now as well -- let the =
server do the secret rotation if it wants to, and have the client be =
prepared to receive a new client_secret or registration_access_token on =
any read or update request.
>=20
> This would necessitate changing the returned values, essentially =
collapsing the returns from the read/update and rotate actions into one =
structure that's closer to the one returned from initial registration. =
This has the added benefit of parallelizing the responses for these =
three actions, which I like as well.
>=20
> -- Justin
>=20
> On 02/11/2013 08:42 PM, John Bradley wrote:
>> OAuth doesn't say anything about client secrets other than they are =
provisioned in a magic realm outside the OAuth spec (Getting in the mood =
for the next IETF).
>>=20
>> Rotating client secrets was something I made up for connect because =
it seemed like a good idea at the time given that someone breaking in to =
the registration endpoint could take over a connection.
>>=20
>> We later separated the authentication to the token endpoint from the =
registration endpoint,in what I think was a good move.
>>=20
>> It is sort of up to the authorization server to make decisions about =
rotating client secrets, I expect that in the real world a client would =
try access ing the token endpoint and get back a invalid_client error =
response and then heck it's registration to see if the client_secret has =
changed.
>>=20
>> I suppose that a client could request rotating its secret if it =
thinks it has been compromised,  however the compromiser is more likely =
to quickly change the secret to lock out the legitimate clients before =
the good one notices.    I think the client wanting to rotate is enough =
of a edge case that it could deal with it out of band.
>>=20
>> Letting the server rotate the client secret according to what ever =
policy it decides is best is probably safest.
>>=20
>> We didn't have anything for rotating the access token.  I suspect =
that rotating it under the clients control is going to create as many =
problems as it solves.
>>=20
>> If you want to rotate it,  make it a refresh token that is issues and =
use OAuth to provide access tokens from the token endpoint.   Creating a =
new endpoint to duplicate existing OAuth functionality is overkill.
>>=20
>> John B.
>> On 2013-02-11, at 10:18 PM, Mike Jones  =
wrote:
>>=20
>>> The rotate_secret operation was added to OpenID Connect Registration =
as a workaround to the fact that registration updates used to be =
authenticated using the client secret, so it seemed overly dangerous to =
have an update operation potentially return an updated secret and have =
the secret be lost due to communication problems - leaving the client =
stranded.  Since then, registration was changed to use a bearer token to =
authenticate update operations, and so this failure mode can't occur =
anymore.  It was an omission not to have deleted the unneeded operation =
then.
>>>=20
>>> It's been deleted from OpenID Connect Registration and should =
likewise be deleted from OAuth registration, since it is unneeded.  If a =
new client secret is needed, there's nothing stopping the registration =
server from returning it in the result of an update operation.
>>>=20
>>> 				-- Mike
>>>=20
>>> -----Original Message-----
>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf Of Justin Richer
>>> Sent: Monday, February 11, 2013 1:15 PM
>>> To: oauth@ietf.org
>>> Subject: [OAUTH-WG] Registration: Client secret rotation
>>>=20
>>> Draft -05 of OAuth Dynamic Client Registration [1] defines a means =
of the client requesting a new client_secret (if applicable) and a new =
registration_access_token. Client secrets MAY expire after some period =
of time, and this method allows for a refresh of that secret. Draft -00 =
defined no such operation, drafts -01 through -04 defined this operation =
in terms of the operation=3Drotate_secret parameter, and draft -05 =
defines it through a secondary endpoint, the Client Secret Rotation =
Endpoint.
>>> This raises several questions:
>>>=20
>>>  - Should the client be allowed to request rotation of its secret?
>>>  - Would a client ever take this action of its own accord?
>>>  - Can a server rotate the secret of the client without the client =
asking? (This seems to be an obvious "yes")
>>>=20
>>> Alternatives that keep this functionality include defining the =
rotate_secret operation in terms of an HTTP verb, a query parameter, or =
separate endpoint. Alternatively, we could drop the rotate_secret =
operation all together. If we do this, we have to decide if the client =
secret can still expire. If it can, then we need a way for the client to =
get this new secret through a means that doesn't require it to request a =
change in secret, such as sending it back as part of the client READ =
operation (see other thread on RESTful verbs).
>>>=20
>>>  -- Justin
>>>=20
>>>=20
>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>>> _______________________________________________
>>> 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
>=20

From jricher@mitre.org  Tue Feb 12 08:23:21 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC64321F8F58 for ; Tue, 12 Feb 2013 08:23:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.571
X-Spam-Level: 
X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.027,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5T1T8ZggaN2L for ; Tue, 12 Feb 2013 08:23:18 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id A78E221F8F3E for ; Tue, 12 Feb 2013 08:23:17 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 224DA5310839; Tue, 12 Feb 2013 11:23:17 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id E4067435028F; Tue, 12 Feb 2013 11:23:16 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 12 Feb 2013 11:23:16 -0500
Message-ID: <511A6C49.50801@mitre.org>
Date: Tue, 12 Feb 2013 11:22:33 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: John Bradley 
References: <51195F3D.1050006@mitre.org> <222C28CB-7F6F-4BC3-8692-40404C2DC2D3@maymount.com> <511A50C7.8080102@mitre.org> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060302090908010409030908"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 16:23:21 -0000

--------------060302090908010409030908
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Agreed - I didn't think that header-only was the proposal, but let's be 
explicit about the returned body always containing the URL. The way I 
read the 201 definition, it suggests (SHOULD) that you use the location 
header, but also says that the entity should refer to the new resource. 
It was my assumption that the returned JSON would still have some form 
of client-entity management URL (whether it's the HAL _links structure 
or registration_management_url or something else is still up for debate).

  -- Justin

On 02/12/2013 10:28 AM, John Bradley wrote:
> Returning a location header in the 201 ids fine as long as we also 
> have the same info as a claim.
>
> I think most clients will want to process the JSON and store all the 
> parameters together.  Making them fish out a header makes the W3C 
> happy and is the correct thing to do but taking it from a claim is 
> what developers are more comfortable with.
>
> John B.
>
> On 2013-02-12, at 11:25 AM, Justin Richer  > wrote:
>
>> I'd be fine with the return from a creation request being a 201 
>> instead of a 200.
>>
>>  -- Justin
>>
>> On 02/11/2013 06:33 PM, Richard Harrington wrote:
>>> Since the request is an HTTP POST and a resource is created 
>>> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5) the 
>>> response should be an HTTP 201 Created 
>>> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.2) 
>>> which is supposed to include the location of the newly created resource.
>>>
>>> This is a good pattern to follow since, as you say, it does provide 
>>> flexibility.
>>>
>>>
>>>
>>> On Feb 11, 2013, at 1:14 PM, Justin Richer >> > wrote:
>>>
>>>> Draft -05 of OAuth Dynamic Client Registration [1] returns a URL 
>>>> pointer for the client to perform update and secret rotation 
>>>> actions. This functionality arose from discussions on the list 
>>>> about moving towards a more RESTful pattern, and Nat Sakimura 
>>>> proposed this approach in the OpenID Connect Working Group. This 
>>>> URL may be distinct from the Client Registration Endpoint URL, but 
>>>> draft -05 makes no promises as to its content, form, or structure, 
>>>> though it does contain implementor's notes on possible methods.
>>>>
>>>> Two questions arise from this change:
>>>> - The semantics of returning the client manipulation URL
>>>> - The syntax (derived from HAL for JSON [2], an individual I-D 
>>>> submission)
>>>>
>>>> On semantics:
>>>>
>>>> Pro:
>>>> - The server has flexibility on how to define the "update" 
>>>> endpoint, sending all clients to one URL, sending different clients 
>>>> to different URLs, or sending clients to a URL with a baked-in 
>>>> query parameter
>>>> - The client can take the URL as-is and use it for all management 
>>>> operations (ie, it doesn't have to generate or compose the URL 
>>>> based on component parts)
>>>>
>>>> Con:
>>>> - The client must remember one more piece of information from the 
>>>> server at runtime if it wants to do manipulation and management of 
>>>> itself at the server (in addition to client_id, client_secret, 
>>>> registration_access_token, and others)
>>>>
>>>> Alternatives include specifying a URL pattern for the server to use 
>>>> and all clients to follow, specifying a query parameter for the 
>>>> update action, and specifying a separate endpoint entirely and 
>>>> using the presence of items such as client_id and the registration 
>>>> access token to differentiate the requests. Note that *all* of 
>>>> these alternatives can be accommodated using the semantics 
>>>> described above, with the same actions on the client's part.
>>>>
>>>>
>>>> On syntax:
>>>>
>>>> Pro:
>>>> - Follows the designs of RFC5988 for link relations
>>>> - The HAL format is general, and allows for all kinds of other 
>>>> information to be placed inside the _links structure
>>>> - Allows for full use of the JSON object to specify advanced 
>>>> operations on the returned endpoint if desired
>>>>
>>>> Con:
>>>> - The rest of OAuth doesn't follow link relation guidelines (though 
>>>> it's been brought up)
>>>> - The HAL format is general, and allows for all kinds of other 
>>>> information to be placed inside the _links structure
>>>> - The HAL-JSON document is an expired individual I-D, and it's 
>>>> unclear what wider adoption looks like right now
>>>>
>>>> Alternatives include returning the URL as a separate data member 
>>>> (registration_update_url), using HTTP headers, or using JSON Schema.
>>>>
>>>> -- Justin
>>>>
>>>>
>>>>
>>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>>>> [2] http://tools.ietf.org/html/draft-kelly-json-hal-03
>>>> _______________________________________________
>>>> 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
>

--------------060302090908010409030908
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

    Agreed - I didn't think that header-only was the proposal, but let's
    be explicit about the returned body always containing the URL. The
    way I read the 201 definition, it suggests (SHOULD) that you use the
    location header, but also says that the entity should refer to the
    new resource. It was my assumption that the returned JSON would
    still have some form of client-entity management URL (whether it's
    the HAL _links structure or registration_management_url or something
    else is still up for debate). 

     -- Justin

    On 02/12/2013 10:28 AM, John Bradley
      wrote:

      Returning a location header in the 201 ids fine as long as we
        also have the same info as a claim.

      I think most clients will want to process the JSON and store
        all the parameters together.  Making them fish out a header
        makes the W3C happy and is the correct thing to do but taking it
        from a claim is what developers are more comfortable with.

      John B.

          On 2013-02-12, at 11:25 AM, Justin Richer <jricher@mitre.org>
            wrote:

             I'd be fine with the
              return from a creation request being a 201 instead of a
              200. 

               -- Justin

              On 02/11/2013 06:33 PM,
                Richard Harrington wrote:

                Since the request is an HTTP POST and a resource is
                  created (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5) the
                    response should be an HTTP 201 Created (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.2) which
                    is supposed to include the location of the newly
                    created resource.

                This is
                    a good pattern to follow since, as you say, it does
                    provide flexibility.

                  On Feb 11, 2013, at 1:14 PM, Justin Richer <jricher@mitre.org>

                  wrote:

                  Draft -05 of OAuth Dynamic Client
                      Registration [1] returns a URL pointer for the
                      client to perform update and secret rotation
                      actions. This functionality arose from discussions
                      on the list about moving towards a more RESTful
                      pattern, and Nat Sakimura proposed this approach
                      in the OpenID Connect Working Group. This URL may
                      be distinct from the Client Registration Endpoint
                      URL, but draft -05 makes no promises as to its
                      content, form, or structure, though it does
                      contain implementor's notes on possible methods.

                    Two questions arise from this change:

                     - The semantics of returning the client
                      manipulation URL

                     - The syntax (derived from HAL for JSON [2],
                      an individual I-D submission)

                    On semantics:

                    Pro:

                     - The server has flexibility on how to define
                      the "update" endpoint, sending all clients to one
                      URL, sending different clients to different URLs,
                      or sending clients to a URL with a baked-in query
                      parameter

                     - The client can take the URL as-is and use
                      it for all management operations (ie, it doesn't
                      have to generate or compose the URL based on
                      component parts)

                    Con:

                     - The client must remember one more piece of
                      information from the server at runtime if it wants
                      to do manipulation and management of itself at the
                      server (in addition to client_id, client_secret,
                      registration_access_token, and others)

                    Alternatives include specifying a URL pattern
                      for the server to use and all clients to follow,
                      specifying a query parameter for the update
                      action, and specifying a separate endpoint
                      entirely and using the presence of items such as
                      client_id and the registration access token to
                      differentiate the requests. Note that *all* of
                      these alternatives can be accommodated using the
                      semantics described above, with the same actions
                      on the client's part.

                    On syntax:

                    Pro:

                     - Follows the designs of RFC5988 for link
                      relations

                     - The HAL format is general, and allows for
                      all kinds of other information to be placed inside
                      the _links structure

                     - Allows for full use of the JSON object to
                      specify advanced operations on the returned
                      endpoint if desired

                    Con:

                     - The rest of OAuth doesn't follow link
                      relation guidelines (though it's been brought up)

                     - The HAL format is general, and allows for
                      all kinds of other information to be placed inside
                      the _links structure

                     - The HAL-JSON document is an expired
                      individual I-D, and it's unclear what wider
                      adoption looks like right now

                    Alternatives include returning the URL as a
                      separate data member (registration_update_url),
                      using HTTP headers, or using JSON Schema.

                     -- Justin

                    [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05

                    [2] http://tools.ietf.org/html/draft-kelly-json-hal-03

                    _______________________________________________

                    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

--------------060302090908010409030908--

From ve7jtb@ve7jtb.com  Tue Feb 12 08:30:49 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D2121F8F7E for ; Tue, 12 Feb 2013 08:30:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.174
X-Spam-Level: 
X-Spam-Status: No, score=-3.174 tagged_above=-999 required=5 tests=[AWL=0.425,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMqlSdMTAHkz for ; Tue, 12 Feb 2013 08:30:48 -0800 (PST)
Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5A921F8F4E for ; Tue, 12 Feb 2013 08:30:48 -0800 (PST)
Received: by mail-qc0-f180.google.com with SMTP id v28so94529qcm.39 for ; Tue, 12 Feb 2013 08:30:43 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=I/O8RaePt6fEwbg35ZDCoaLzr2DLsc5YM2zVnygm96U=; b=gMwih/m68Kt29brWdbJ3YNU5ufpnU1OYbVNZjhdLQyk9//IVc7vV/wPEfhQAm/De9v KeyDw86YshM+B1ISwU4GcffmXib+mgGarltWRF7ACfSPJhnA86Cd0tZw7smkEaF8d7UU 35I5LyyZilQp7GNZLXWIgbYyi7EzFqEyCATuIwu7u6ZzfwYC/x1ArFblWsD1A2cdmtq5 w0HpU0Cqqve6/dxGIXd4gDaRH4xRDF+4bKwQ095yiGTuQ1sSduHhk8unJpAcL3U3XgJr X6PpK707DsHw+VpFpywpXEUaGWTn8PNCbMT4JAkktcbLYcqWgbBW2PmdYlMCojAMnSyx 9Ftw==
X-Received: by 10.229.111.130 with SMTP id s2mr1717887qcp.91.1360686643606; Tue, 12 Feb 2013 08:30:43 -0800 (PST)
Received: from [192.168.1.213] (190-20-23-212.baf.movistar.cl. [190.20.23.212]) by mx.google.com with ESMTPS id dg4sm16630151qab.7.2013.02.12.08.30.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 08:30:42 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <511A5742.30707@mitre.org>
Date: Tue, 12 Feb 2013 13:30:36 -0300
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <51195F36.6040705@mitre.org> <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com> <80727F20-A830-4778-B11C-D45389310646@lodderstedt.net> <511A5742.30707@mitre.org>
To: Justin Richer 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQmlImv6b9tPG+fkGUJJ9S/fuq1m3zgjThe6Z2/4VXCwShJhjmTbiROA3x7rfrP6JZZjqGY9
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 16:30:49 -0000

To some extent we want the server to have the flexibility it needs.

If the server knows it is going to need client_id for GET it needs to =
encode it in the resource URI ether as part of the path or as a query =
parameter (that is up to the server)

When doing updates the client MUST include the client_id as an =
additional integrity check.  Some servers may switch on that but that is =
up to them.

If we want incremental replace (not resetting claims not sent to there =
defaults) then we need POST for update. =20
I think if you want to do the REST thing and be pure about PUT it needs =
to reset all values not sent to there defaults.

I suppose we could have both but two ways of doing it leads to =
confusion.

John B.

On 2013-02-12, at 11:52 AM, Justin Richer  wrote:

> The problem that I have with "always including the client_id" is =
*where* to include it. Are we talking a query parameter, URI template, =
or somewhere in the request body? The latter will only work for POST and =
PUT, so it's out of the question to support GET and DELETE using that =
semantic. I think we should support all operations using parallel syntax =
-- that's just good API design.
>=20
> I *really* don't like the idea of switching the action solely based on =
whether or not the client_id is present in the request body of a POST. =
This is a side-effectful mode switch, and it will only lead to pain and =
misery. Additionally, if the input is JSON (separate discussion), then a =
server would have to parse the JSON body before knowing where to route =
the request. In most web development frameworks that I've used, this is =
impossible. A query parameter or URL pattern, on the other hand, is =
doable.
>=20
> As it stands right now, a server is free to include the client_id in =
the "update/management" URL that it returns as part of the _link =
structure (separate discussion). The current text goes as far as =
recommending that practice, but doesn't take the step of requiring it in =
any form, and leaving it up to the server to decide what form it takes. =
If a server can route better with a query parameter, it'll return a URL =
to the client that has a client_id=3D query parameter. If a server would =
rather use a path component with the client_id, it can do that, too. If =
it wants to put everything on one URL and differentiate through the =
request body or presence/absence of the registration_access_token, it =
can always return the same URL to every client. I think that's nuts, but =
you can do it. Interoperability is preserved because the client simply =
follows the returned URL to do its bits and pieces, and it doesn't ever =
have to create or compose this URL from component parts.
>=20
> I want to continue to distinguish between the POST and PUT operations =
for create and update, respectively. This is a common pattern and the =
one described in the original REST thesis that described the =
architectural style. I'll also bring up that the semantics of PUT are =
intended to be "replace all", which is what you had originally argued =
for in the update case as well. I not convinced that developers of today =
can't handle HTTP verbs like PUT if they want to do fancier operations =
like updates. Note that the core operations, create and read, remain as =
POST and GET, which would be well within the grasp of every library and =
web developer today.
>=20
> -- Justin
>=20
> On 02/12/2013 02:23 AM, Torsten Lodderstedt wrote:
>> +1 for always including the client_id
>>=20
>> As John pointed out, there could be different entities updating =
client data. Then one has to distinguish the resource and the =
credential.
>>=20
>> Am 12.02.2013 um 02:51 schrieb John Bradley :
>>=20
>>> I would always include the client_id on update.
>>>=20
>>> I think it is also us full to have other tokens used at the update =
endpoint.  I can see the master token used to update all the clients it =
has registered as part of API management.
>>> Relying on the registration_access_token is probably a design that =
will cause trouble down the road.
>>>=20
>>> I think GET and POST are relatively clear.   I don't know about =
expelling PUT to developers.  I think POST with a client_id to a =
(separate discussion) update_uri works without restricting it to PUT.
>>>=20
>>> I think DELETE needs to be better understood.   I think a status =
that can be set for client lifecycle is better than letting a client =
delete a entry.
>>> In some cases there will be more than one instance of a client and =
letting them know they have been turned off for a reason is better than =
making there registration disappear.
>>> So for the moment I would levee out DELETE.
>>>=20
>>> John B.
>>>=20
>>> On 2013-02-11, at 6:14 PM, Justin Richer  wrote:
>>>=20
>>>> Draft -05 of OAuth Dynamic Client Registration [1] defines several =
operations that the client can take on its behalf as part of the =
registration process. These boil down to the basic CRUD operations that =
you find in many APIs: Create, Read, Update, Delete. Draft -00 defined =
only the "Create" operation, draft -01 through -04 added the "Update" =
operation, switched using the "operation=3D" parameter.
>>>>=20
>>>> Following several suggestions to do so on the list, the -05 draft =
defines these operations in terms of a RESTful API for the client. =
Namely:
>>>>=20
>>>> - HTTP POST to registration endpoint =3D> Create (register) a new =
client
>>>> - HTTP PUT to update endpoint (with registration_access_token) =3D> =
Update the registered information for this client
>>>> - HTTP GET to update endpoint (with registration_access_token) =3D> =
read the registered information for this client
>>>> - HTTP DELETE to update endpoint (with registration_access_token) =
=3D> Delete (unregister/de-provision) this client
>>>>=20
>>>> The two main issues at stake here are: the addition of the READ and =
DELETE methods, and the use of HTTP verbs following a RESTful design =
philosophy.
>>>>=20
>>>> Pro:
>>>> - RESTful APIs (with HTTP verbs to differentiate functionality) are =
the norm today
>>>> - Full lifecycle management is common and is going to be expected =
by many users of this protocol in the wild
>>>>=20
>>>> Cons:
>>>> - Update semantics are still under debate (full replace? patch?)
>>>> - Somewhat increased complexity on the server to support all =
operations
>>>> - Client has to understand all HTTP verbs for full access (though =
plain registration is just POST)
>>>>=20
>>>>=20
>>>> Alternatives include using an operational switch parameter (like =
the old drafts), defining separate endpoints for every action, or doing =
all operations on a single endpoint using verbs to switch.
>>>>=20
>>>> -- Justin
>>>>=20
>>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>>>> _______________________________________________
>>>> 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
>=20

From jricher@mitre.org  Tue Feb 12 08:40:44 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6C221F8F73 for ; Tue, 12 Feb 2013 08:40:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.572
X-Spam-Level: 
X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bygq1ayk+1fz for ; Tue, 12 Feb 2013 08:40:43 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 54D8221F8F71 for ; Tue, 12 Feb 2013 08:40:43 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D7C5A1F15AF; Tue, 12 Feb 2013 11:40:42 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 6A3C31F186F; Tue, 12 Feb 2013 11:40:42 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 12 Feb 2013 11:40:42 -0500
Message-ID: <511A705F.4070204@mitre.org>
Date: Tue, 12 Feb 2013 11:39:59 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: John Bradley 
References: <51195F36.6040705@mitre.org> <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com> <80727F20-A830-4778-B11C-D45389310646@lodderstedt.net> <511A5742.30707@mitre.org> 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 16:40:44 -0000

On 02/12/2013 11:30 AM, John Bradley wrote:
> To some extent we want the server to have the flexibility it needs.
>
> If the server knows it is going to need client_id for GET it needs to e=
ncode it in the resource URI ether as part of the path or as a query para=
meter (that is up to the server)
>
> When doing updates the client MUST include the client_id as an addition=
al integrity check.  Some servers may switch on that but that is up to th=
em.
So if by this you mean that the client still simply follows whatever=20
update url the server hands it (which may or may not include the=20
client_id in some form, but the client doesn't care), and that the=20
client MUST include its client_id in the request body (top-level member=20
of a JSON object, at the moment) when doing a PUT (or POST/PATCH? see=20
below) for the update action, then I'm totally fine with that. Is this=20
what you're suggesting?

> If we want incremental replace (not resetting claims not sent to there =
defaults) then we need POST for update.
> I think if you want to do the REST thing and be pure about PUT it needs=
 to reset all values not sent to there defaults.

I agree with this argument in terms of the purity, and as I would rather =

see the different verb used for different actions, I am willing to give=20
up the semantics of the not-resetting-claims that's in there right now=20
for this action. There's actually another HTTP verb, PATCH, that isn't=20
used much but is meant for partial updates, and we could transfer the=20
not-resetting-claims action to this instead.

> I suppose we could have both but two ways of doing it leads to confusio=
n.

I agree that we can't do both PUT and POST, and we can't have both=20
partial and complete replacement on the same verb/endpoint combination.=20
We need to pick one combination and have it be clear.

  -- Justin

> On 2013-02-12, at 11:52 AM, Justin Richer  wrote:
>
>> The problem that I have with "always including the client_id" is *wher=
e* to include it. Are we talking a query parameter, URI template, or some=
where in the request body? The latter will only work for POST and PUT, so=
 it's out of the question to support GET and DELETE using that semantic. =
I think we should support all operations using parallel syntax -- that's =
just good API design.
>>
>> I *really* don't like the idea of switching the action solely based on=
 whether or not the client_id is present in the request body of a POST. T=
his is a side-effectful mode switch, and it will only lead to pain and mi=
sery. Additionally, if the input is JSON (separate discussion), then a se=
rver would have to parse the JSON body before knowing where to route the =
request. In most web development frameworks that I've used, this is impos=
sible. A query parameter or URL pattern, on the other hand, is doable.
>>
>> As it stands right now, a server is free to include the client_id in t=
he "update/management" URL that it returns as part of the _link structure=
 (separate discussion). The current text goes as far as recommending that=
 practice, but doesn't take the step of requiring it in any form, and lea=
ving it up to the server to decide what form it takes. If a server can ro=
ute better with a query parameter, it'll return a URL to the client that =
has a client_id=3D query parameter. If a server would rather use a path c=
omponent with the client_id, it can do that, too. If it wants to put ever=
ything on one URL and differentiate through the request body or presence/=
absence of the registration_access_token, it can always return the same U=
RL to every client. I think that's nuts, but you can do it. Interoperabil=
ity is preserved because the client simply follows the returned URL to do=
 its bits and pieces, and it doesn't ever have to create or compose this =
URL from component parts.
>>
>> I want to continue to distinguish between the POST and PUT operations =
for create and update, respectively. This is a common pattern and the one=
 described in the original REST thesis that described the architectural s=
tyle. I'll also bring up that the semantics of PUT are intended to be "re=
place all", which is what you had originally argued for in the update cas=
e as well. I not convinced that developers of today can't handle HTTP ver=
bs like PUT if they want to do fancier operations like updates. Note that=
 the core operations, create and read, remain as POST and GET, which woul=
d be well within the grasp of every library and web developer today.
>>
>> -- Justin
>>
>> On 02/12/2013 02:23 AM, Torsten Lodderstedt wrote:
>>> +1 for always including the client_id
>>>
>>> As John pointed out, there could be different entities updating clien=
t data. Then one has to distinguish the resource and the credential.
>>>
>>> Am 12.02.2013 um 02:51 schrieb John Bradley :
>>>
>>>> I would always include the client_id on update.
>>>>
>>>> I think it is also us full to have other tokens used at the update e=
ndpoint.  I can see the master token used to update all the clients it ha=
s registered as part of API management.
>>>> Relying on the registration_access_token is probably a design that w=
ill cause trouble down the road.
>>>>
>>>> I think GET and POST are relatively clear.   I don't know about expe=
lling PUT to developers.  I think POST with a client_id to a (separate di=
scussion) update_uri works without restricting it to PUT.
>>>>
>>>> I think DELETE needs to be better understood.   I think a status tha=
t can be set for client lifecycle is better than letting a client delete =
a entry.
>>>> In some cases there will be more than one instance of a client and l=
etting them know they have been turned off for a reason is better than ma=
king there registration disappear.
>>>> So for the moment I would levee out DELETE.
>>>>
>>>> John B.
>>>>
>>>> On 2013-02-11, at 6:14 PM, Justin Richer  wrote:
>>>>
>>>>> Draft -05 of OAuth Dynamic Client Registration [1] defines several =
operations that the client can take on its behalf as part of the registra=
tion process. These boil down to the basic CRUD operations that you find =
in many APIs: Create, Read, Update, Delete. Draft -00 defined only the "C=
reate" operation, draft -01 through -04 added the "Update" operation, swi=
tched using the "operation=3D" parameter.
>>>>>
>>>>> Following several suggestions to do so on the list, the -05 draft d=
efines these operations in terms of a RESTful API for the client. Namely:=

>>>>>
>>>>> - HTTP POST to registration endpoint =3D> Create (register) a new c=
lient
>>>>> - HTTP PUT to update endpoint (with registration_access_token) =3D>=
 Update the registered information for this client
>>>>> - HTTP GET to update endpoint (with registration_access_token) =3D>=
 read the registered information for this client
>>>>> - HTTP DELETE to update endpoint (with registration_access_token) =3D=
> Delete (unregister/de-provision) this client
>>>>>
>>>>> The two main issues at stake here are: the addition of the READ and=
 DELETE methods, and the use of HTTP verbs following a RESTful design phi=
losophy.
>>>>>
>>>>> Pro:
>>>>> - RESTful APIs (with HTTP verbs to differentiate functionality) are=
 the norm today
>>>>> - Full lifecycle management is common and is going to be expected b=
y many users of this protocol in the wild
>>>>>
>>>>> Cons:
>>>>> - Update semantics are still under debate (full replace? patch?)
>>>>> - Somewhat increased complexity on the server to support all operat=
ions
>>>>> - Client has to understand all HTTP verbs for full access (though p=
lain registration is just POST)
>>>>>
>>>>>
>>>>> Alternatives include using an operational switch parameter (like th=
e old drafts), defining separate endpoints for every action, or doing all=
 operations on a single endpoint using verbs to switch.
>>>>>
>>>>> -- Justin
>>>>>
>>>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>>>>> _______________________________________________
>>>>> 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

From ve7jtb@ve7jtb.com  Tue Feb 12 08:47:26 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E0121F8F7F for ; Tue, 12 Feb 2013 08:47:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.204
X-Spam-Level: 
X-Spam-Status: No, score=-3.204 tagged_above=-999 required=5 tests=[AWL=0.394,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTWaTDT1UYJq for ; Tue, 12 Feb 2013 08:47:25 -0800 (PST)
Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by ietfa.amsl.com (Postfix) with ESMTP id 304F421F8F7E for ; Tue, 12 Feb 2013 08:47:25 -0800 (PST)
Received: by mail-qa0-f50.google.com with SMTP id dx4so161062qab.2 for ; Tue, 12 Feb 2013 08:47:24 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=rlF6dxbwufZaX2Nnm4eY+fe2kwvNTy7014NHxkipUHs=; b=h/cNhaYrOEBKJEP3P/OZFwQlUfZ+qUhqUdx44nPiVFDQW+tWIJ1FnP6eqxmHdwuOMl V6jdKw49VkKxsU6U0dQGnD7HOW4GQ93Okf5ulMCiY30NRtIiW1cbbZMdnj3FSG5CCRfz kiHp7jGjPsEzbj0l3bV8X+crdMM4FulUVVfN3+jIDvkxz63anwbrTj8nWrHASPoD1Brp Q3AdCEck/Ye/l8QLyNUMO5o+atMRdOzRYOIVX5ZcJDoyh4RnE8G5DtcBchK+A2LhDlmm Z48ULjFA/qLui/srm9GnOJRdWZxl8RyIwXjZ/pvIVvhDg4CxKuMvKDGeiuLHErlumv6N DpCw==
X-Received: by 10.229.209.232 with SMTP id gh40mr1710160qcb.69.1360687644246;  Tue, 12 Feb 2013 08:47:24 -0800 (PST)
Received: from [192.168.1.213] (190-20-23-212.baf.movistar.cl. [190.20.23.212]) by mx.google.com with ESMTPS id o5sm16641315qao.12.2013.02.12.08.47.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 08:47:21 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_1A45EBDE-2624-4EB1-B960-26BCB62CF27C"
Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$)
From: John Bradley 
In-Reply-To: <1360663615.75403.YahooMailNeo@web31803.mail.mud.yahoo.com>
Date: Tue, 12 Feb 2013 13:47:16 -0300
Message-Id: 
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net> <1360661249.62997.YahooMailNeo@web31803.mail.mud.yahoo.com> <103117A9-0922-4E1A-AC73-D2914743046C@gmx.net> <1360663615.75403.YahooMailNeo@web31803.mail.mud.yahoo.com>
To: William Mills 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQkJtaI1aBgMzxCIaRR++wqJYkq7noyeVe4R9abfermLE9ci7dOsLU4wQwRSzno/cYA4GED+
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 16:47:27 -0000

--Apple-Mail=_1A45EBDE-2624-4EB1-B960-26BCB62CF27C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

The token may or may not need to be encrypted on top of being signed.  =
All tokens red to be signed.

If the Key is asymmetric or using DH key agreement it would not need to =
be encrypted.=20
If it is a symmetric key then yes you need to use encrypted key =
transport.   The JOSE working group is working on a clean method of =
using JOSE fro Key transport.
We should align with that.

In some ways ECDH-ES would be perfect for this, but I am realistic about =
adoption.

If we fall back to regular DH then if RS's have a way of communicating =
there DH info to the AS then when the client requests a token providing =
it's DH info the server can place that in the token and return the RS's =
info in a separate parameter to the client and the key is never sent =
over the wire, so no encryption needed. =20

One problem is that who the intended RS is may be a touch vague in =
OAuth. (This affects both key transport and agreement.)  so the AS may =
not know what the RS is if it is not explicit in the scope.

That may lead us to make asymmetric keys (including the public key of =
the client)  as the default as that is the only one that works with both =
known and unknown RS.

You could design a DH floe to work where the RS on request failures =
provides its DH info and then the client passes that and it's info to =
the AS in the token request.
That works but sort of messes up the flow.

John B.

On 2013-02-12, at 7:06 AM, William Mills  wrote:

> For key exchange that's true for symmetric key, but no key exchange is =
required for public key signing by the client.
>=20
> There's so many possibilities here, but I think the best is that the =
key materiel is conveyed in the token.  The key could be included =
directly, or another way to implement would be that a salt is included =
in the token and then the secret is some crypto hash of the token =
contents and a shared secret between the AS and the PR. =20
>=20
> If we we must pick one I'd say include the signing key as part of the =
encrypted token itself.  Completely self contained then.
>=20
> From: Hannes Tschofenig 
> To: William Mills =20
> Cc: Hannes Tschofenig ; IETF oauth WG =
=20
> Sent: Tuesday, February 12, 2013 1:44 AM
> Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference =
Call - 11th February 2013
>=20
> Hi Bill,=20
>=20
> On Feb 12, 2013, at 11:27 AM, William Mills wrote:
>=20
> > Is key distribution how AS and PR share keys  for token =
encryption/decryption or specifically about the keys for the HOK tokens?
> >=20
> In order for the client to compute the keyed message digest it needs =
to have the session key. This session key is sent from the authorization =
server to the client and everyone on the call agreed that this has to be =
standardized.=20
>=20
> The resource server who receives the message from the client also =
needs to have the session key to verify the message. How the resource =
server obtains this session key was subject for some discussion on the =
call. I presented three different ways of how the resource server is =
able to obtain that key. We have to decide on one mandatory-to-implement =
mechanism. The open issue is which one?=20
>=20
> > For the MAC token spec, I don't actually care whether we use JSON or =
now, but I'm in full agreement that we do NOT duplicate any HTTP info =
into the JSON.  Just signatures of that stuff.
> >=20
> I believe the folks on the call also agreed with you on that aspect =
that the content of the HTTP message should not be replicated in the =
JSON payload itself.=20
>=20
> Ciao
> Hannes
>=20
> > From: Hannes Tschofenig 
> > To: IETF oauth WG =20
> > Sent: Tuesday, February 12, 2013 1:10 AM
> > Subject: [OAUTH-WG] Minutes from the OAuth Design Team Conference =
Call - 11th February 2013
> >=20
> > Here are my notes.=20
> >=20
> > Participants:
> >=20
> > * John Bradley
> > * Derek Atkins
> > * Phil Hunt
> > * Prateek Mishra
> > * Hannes Tschofenig
> > * Mike Jones
> > * Antonio Sanso
> > * Justin Richer
> >=20
> > Notes:=20
> >=20
> > My slides are available here: =
http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
> >=20
> > Slide #2 summarizes earlier discussions during the conference calls.=20=

> >=20
> > -- HTTP vs. JSON
> >=20
> > Phil noted that he does not like to use the MAC Token draft as a =
starting point because it does not re-use any of the work done in the =
JOSE working group and in particular all the libraries that are =
available today. He mentioned that earlier attempts to write the MAC =
Token code lead to problems for implementers.=20
> >=20
> > Justin responded that he does not agree with using JSON as a =
transport mechanism since this would replicate a SOAP style.=20
> >=20
> > Phil noted that he wants to send JSON but the signature shall be =
computed over the HTTP header field.=20
> >=20
> > -- Flexibility for the keyed message digest computation
> >=20
> > =46rom earlier discussion it was clear that the conference call =
participants wanted more flexibility regarding the keyed message digest =
computation. For this purpose Hannes presented the DKIM based approach, =
which allows selective header fields to be included in the digest. This =
is shown in slide #4.=20
> >=20
> > After some discussion the conference call participants thought that =
this would meet their needs. Further investigations would still be =
useful to determine the degree of failed HMAC calculations due to HTTP =
proxies modifying the content.=20
> >=20
> > -- Key Distribution
> >=20
> > Hannes presented the open issue regarding the choice of key =
distribution. Slides #6-#8 present three techniques and Hannes asked for =
feedback regarding the preferred style. Justin and others didn't see the =
need to decide on one mechanism - they wanted to keep the choice open. =
Derek indicated that this will not be an acceptable approach. Since the =
resource server and the authorization server may, in the OAuth 2.0 =
framework, be entities produced by different vendors there is an =
interoperability need. Justin responded that he disagrees and that the =
resource server needs to understand the access token and referred to the =
recent draft submission for the token introspection endpoint. Derek =
indicated that the resource server has to understand the content of the =
access token and the token introspection endpoint just pushes the =
problem around: the resource server has to send the access token to the =
authorization server and then the resource server gets the result back =
(which he then a
> > gain needs to understand) in order to make a meaningful =
authorization decision.=20
> >=20
> > Everyone agreed that the client must receive the session key from =
the authorization server and that this approach has to be standardized. =
It was also agreed that this is a common approach among all three key =
distribution mechanisms.
> >=20
> > Hannes asked the participants to think about their preference.=20
> >=20
> > The questions regarding key naming and the indication for the =
intended resource server the client wants to talk to have been =
postponed.=20
> >=20
> > Ciao
> > Hannes
> >=20
> >=20
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >=20
> >=20
>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail=_1A45EBDE-2624-4EB1-B960-26BCB62CF27C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

The =
token may or may not need to be encrypted on top of being signed. =
 All tokens red to be signed.
If the Key is =
asymmetric or using DH key agreement it would not need to be =
encrypted. 
If it is a symmetric key then yes you need to =
use encrypted key transport.   The JOSE working group is working on =
a clean method of using JOSE fro Key transport.
We should =
align with that.

In some ways ECDH-ES would be =
perfect for this, but I am realistic about =
adoption.

If we fall back to regular DH then if =
RS's have a way of communicating there DH info to the AS then when the =
client requests a token providing it's DH info the server can place that =
in the token and return the RS's info in a separate parameter to the =
client and the key is never sent over the wire, so no encryption needed. =

One problem is that who the intended RS =
is may be a touch vague in OAuth. (This affects both key transport and =
agreement.)  so the AS may not know what the RS is if it is not =
explicit in the scope.

That may lead us to make =
asymmetric keys (including the public key of the client)  as the =
default as that is the only one that works with both known and unknown =
RS.

You could design a DH floe to work where =
the RS on request failures provides its DH info and then the client =
passes that and it's info to the AS in the token request.
That =
works but sort of messes up the flow.

John =
B.

On 2013-02-12, =
at 7:06 AM, William Mills <wmills_92105@yahoo.com> =
wrote:

For key exchange that's true for symmetric key, =
but no key exchange is required for public key signing by the =
client.

There's so many possibilities here, =
but I think the best is that the key materiel is conveyed in the token. =
 The key could be included directly, or another way to implement =
would be that a salt is included in the token and then the secret is =
some crypto hash of the token contents and a shared secret between the =
AS and the PR.  

If we =
we must pick one I'd say include the signing key as part of the =
encrypted token itself.  Completely self contained =
then.

      =
  From: =
Hannes Tschofenig <hannes.tschofenig@gmx.net>=
;
 To: William Mills =
<wmills_92105@yahoo.com> =

Cc: Hannes =
Tschofenig <hannes.tschofenig@gmx.net>=
;; IETF oauth WG <oauth@ietf.org> 
 Sent: Tuesday, February 12, 2013 =
1:44 AM
 Subject: =
Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th =
February 2013

Hi Bill, 

On Feb 12, 2013, at 11:27 AM, William Mills =
wrote:

> Is key distribution how AS and PR share keys  =
for token encryption/decryption or specifically about the keys for the =
HOK tokens?
> 
In order for the client to compute the keyed =
message digest it needs to have the session key. This session key is =
sent from the authorization server to the client and everyone on the =
call agreed that this has to be standardized. 

The resource =
server who receives the message from the client also needs to have the =
session key to verify the message. How the resource server obtains this =
session key was subject for some discussion on the call. I presented =
three different ways of how the resource server is able to obtain that =
key. We have to decide on one mandatory-to-implement mechanism. The open =
issue is which one? 

> For the MAC token spec, I don't =
actually care whether we use JSON or now, but I'm in full agreement
 that we do NOT duplicate any HTTP info into the JSON.  Just =
signatures of that stuff.
> 
I believe the folks on the call =
also agreed with you on that aspect that the content of the HTTP message =
should not be replicated in the JSON payload itself. =

Ciao
Hannes

> From: Hannes Tschofenig <hannes.tschofenig@gmx.net>=
;
> To: IETF oauth WG <oauth@ietf.org> 
> Sent: =
Tuesday, February 12, 2013 1:10 AM
> Subject: [OAUTH-WG] Minutes =
from the OAuth Design Team Conference Call - 11th February 2013
> =

> Here are my notes. 
> 
> Participants:
> =

> * John Bradley
> * Derek Atkins
> * Phil =
Hunt
> * Prateek Mishra
> * Hannes Tschofenig
> * Mike =
Jones
> * Antonio Sanso
> *
 Justin Richer
> 
> Notes: 
> 
> My slides are =
available here: http:=
//www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
> =

> Slide #2 summarizes earlier discussions during the conference =
calls. 
> 
> -- HTTP vs. JSON
> 
> Phil noted =
that he does not like to use the MAC Token draft as a starting point =
because it does not re-use any of the work done in the JOSE working =
group and in particular all the libraries that are available today. He =
mentioned that earlier attempts to write the MAC Token code lead to =
problems for implementers. 
> 
> Justin responded that he =
does not agree with using JSON as a transport mechanism since this would =
replicate a SOAP style. 
> 
> Phil noted that he wants to =
send JSON but the signature shall be computed over the HTTP header =
field. 
> 
> -- Flexibility for the keyed message digest =
computation
> 
> =46rom earlier
 discussion it was clear that the conference call participants wanted =
more flexibility regarding the keyed message digest computation. For =
this purpose Hannes presented the DKIM based approach, which allows =
selective header fields to be included in the digest. This is shown in =
slide #4. 
> 
> After some discussion the conference call =
participants thought that this would meet their needs. Further =
investigations would still be useful to determine the degree of failed =
HMAC calculations due to HTTP proxies modifying the content. 
> =

> -- Key Distribution
> 
> Hannes presented the open =
issue regarding the choice of key distribution. Slides #6-#8 present =
three techniques and Hannes asked for feedback regarding the preferred =
style. Justin and others didn't see the need to decide on one mechanism =
- they wanted to keep the choice open. Derek indicated that this will =
not be an acceptable approach. Since the resource server and
 the authorization server may, in the OAuth 2.0 framework, be entities =
produced by different vendors there is an interoperability need. Justin =
responded that he disagrees and that the resource server needs to =
understand the access token and referred to the recent draft submission =
for the token introspection endpoint. Derek indicated that the resource =
server has to understand the content of the access token and the token =
introspection endpoint just pushes the problem around: the resource =
server has to send the access token to the authorization server and then =
the resource server gets the result back (which he then a
> gain =
needs to understand) in order to make a meaningful authorization =
decision. 
> 
> Everyone agreed that the client must receive =
the session key from the authorization server and that this approach has =
to be standardized. It was also agreed that this is a common approach =
among all three key distribution
 mechanisms.
> 
> Hannes asked the participants to think =
about their preference. 
> 
> The questions regarding key =
naming and the indication for the intended resource server the client =
wants to talk to have been postponed. 
> 
> 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

=

--Apple-Mail=_1A45EBDE-2624-4EB1-B960-26BCB62CF27C--

From sakimura@gmail.com  Tue Feb 12 09:10:51 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D097421F89D8 for ; Tue, 12 Feb 2013 09:10:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.422
X-Spam-Level: 
X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.577,  BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DArIk2ecg6IN for ; Tue, 12 Feb 2013 09:10:49 -0800 (PST)
Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by ietfa.amsl.com (Postfix) with ESMTP id 042CD21F8FAB for ; Tue, 12 Feb 2013 09:10:48 -0800 (PST)
Received: by mail-lb0-f178.google.com with SMTP id n1so280846lba.23 for ; Tue, 12 Feb 2013 09:10:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=9hd4aA6ohUOlqEV2cTp8oFcjGvi66RzuthH5cgVRG2E=; b=n1fS4MZ4Z/vqTiS4ubqCFwtQHVJYsag0xvmStGTt1z4SrVVNmAfHb4I+3WhL3IJTZJ wGm1t77KFiv5QAeaSQWFCo471tLgxs0QjUG4wGpomLgDQubJdvZeNbtUFB0+PYDjmMbu SJGMiqYmanjByv1NROwrVP5OIj/Oqi644B0iYu0vIkaBlChkK6+RAAqIRERoI1HPVI44 VweTyxoLnOnrU3vzWm3G2KDStCm5BGGgYko3bEWcKEJ4AhlGgjeZKesQSz6dLtg7YUpE tHyjCIqKLkwtbYc1GL9d4As5opfC0aKNserSWxJza5FVAJSVrR3ckbl+Fm3BsYbJ/vwk Zk/A==
MIME-Version: 1.0
X-Received: by 10.112.41.101 with SMTP id e5mr7298247lbl.120.1360689046139; Tue, 12 Feb 2013 09:10:46 -0800 (PST)
Received: by 10.112.14.44 with HTTP; Tue, 12 Feb 2013 09:10:45 -0800 (PST)
In-Reply-To: <511A6C49.50801@mitre.org>
References: <51195F3D.1050006@mitre.org> <222C28CB-7F6F-4BC3-8692-40404C2DC2D3@maymount.com> <511A50C7.8080102@mitre.org>  <511A6C49.50801@mitre.org>
Date: Wed, 13 Feb 2013 02:10:45 +0900
Message-ID: 
From: Nat Sakimura 
To: Justin Richer , "oauth@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 17:10:51 -0000

Actually, if it is to return it in the HTTP header, then it should
also use the RFC5988 Web Linking format.
Now, that is nice to have, but for many JSON programmers, I agree that
it would be a hassle to obtain the header and store them in addition
to the JSON. So, it is nicer to have it in JSON body.

Re: Is "_links.self.href" grossly complex over "registration_access_url"?

I do not think so. Accessing a flat top level parameter such
as registration_access_url and _links.self.href does not make any
difference from a
client programmers point of view. That's a beauty of JSON. Both can be
treated as a parameter name. Doing a group operation on the links makes
difference though: the structured one is easier since you can just operate
on _links while in case of the top level parameters, you have to have an
explicit list of them and do the matches. (See below for the necessity
for the grouping).

I and John discussed this for at least half an hour F2F last week, both
technically and from operation/legal point of view, for OpenID Connect
Registration.
Similar points could be made to OAuth dyn reg.

Here is what we have discussed:

When dynamically registering the client to the server,
the server probably needs to return the following:

  * terms-of-service (terms of service of the server to the client)
  * privacy-policy (privacy policy of the server to the client)

Both are defined in RFC5988/IANA Link Relations registry.

They should be returned together with

  * self.href

which is also defined in RFC5988/IANA Link Relations registry.

There are several ways to do it.

  * Return these using RFC5988 (HTTP Header)
  * Return these in entity body
      * Use HAL (or OAuth-meta)/JSON Schema
      * Use something else (e.g., a top level items)

Returning it in the entity body has several advantage over HTTP header:

  * They can be captured in one call;
  * They are protocol agnostic;

We determined that these advantages outweighs the disadvantage of creating
a new standard.

The question becomes then whether to:

  * Use HAL (or OAuth-meta)/JSON Schema
  * Use something else (e.g., a top level items)

First, we have to consider what needs to be returned in the
link/relationship category. If it were just _links.self.href, then grouping
probably does not make sense. However, since we have terms-of-service and
privacy-policy as well already, it may well make sense.

Moreover, when we think of a multi-tenant authorization server that may
want to use different OAuth authz and token endpoints for different
tennants, it would be better to be able to return those in the registration
response. Then, it would make sense to register OAuth authz and token
endpoints as rel type in the IANA registry (like Bill Mills is trying to
do) and use them in a uniform manner. Note: these per tenant endpoints may
support different scopes etc. as well. Then, these has to be coupled with
the URIs. That is why all of RFC5988/HAL/JSON Schema uses href instead of
just having the URL as the value of the parameter. The semantic
relationship would often have an associated URI, and other parameters that
goes with it.

e.g.:

{
    "_links": {
        "terms-of-service": {
            "href": "https: //server.example.com/tos"
        },
        "privacy-policy": {
            "href": "https: //server.example.com/pp"
        },
        "self": {
            "href": "https: //server.example.com/clients/1234",
            "authorize": "Bearer"
        },
        "oauth_authz": {
            "href": "https: //server.example.com/authz",
            "scopes": "openid profile email",
            "response_types": [
                "token id_token",
                "code id_token",
                "token",
                "code"
            ]
        },
        "oauth_token": {
            "href": "https: //server.example.com/token",
            "authorize": "Basic"
        }
    }
}

In short, there are bunch of link relations that needs to be returned
with additional parameters.
Grouping them seems to make sense.

Considering all these, John and I came to the conclusion that the HAL type
syntax would probably make more sense.
(Note: JSON Schema syntax does not make the parameter access as easy as HAL=
.)

In fact, Mike Kelly (the author of HAL) and I have just submit
a new version of draft-sakimura-oauth-meta

   http://tools.ietf.org/html/draft-sakimura-oauth-meta-02

The proposal was discussed at IETF 85 OAuth WG and the chairs asked to
submit the draft.
The -00 appeared in December, and this -02 has some simplification and
the addition
of the "operations" inspired by
https://tools.ietf.org/html/draft-ietf-scim-api-00#section-3.5 .
It is arguably a subset of HAL plus some OAuth specifics.
I have not added Discovery response example,
but adding them would makes even more sense, I think.

Cheers,

Nat

2013/2/13 Justin Richer 
>
> Agreed - I didn't think that header-only was the proposal, but let's be e=
xplicit about the returned body always containing the URL. The way I read t=
he 201 definition, it suggests (SHOULD) that you use the location header, b=
ut also says that the entity should refer to the new resource. It was my as=
sumption that the returned JSON would still have some form of client-entity=
 management URL (whether it's the HAL _links structure or registration_mana=
gement_url or something else is still up for debate).
>
>  -- Justin
>
>
>
> On 02/12/2013 10:28 AM, John Bradley wrote:
>
> Returning a location header in the 201 ids fine as long as we also have t=
he same info as a claim.
>
> I think most clients will want to process the JSON and store all the para=
meters together.  Making them fish out a header makes the W3C happy and is =
the correct thing to do but taking it from a claim is what developers are m=
ore comfortable with.
>
> John B.
>
> On 2013-02-12, at 11:25 AM, Justin Richer  wrote:
>
> I'd be fine with the return from a creation request being a 201 instead o=
f a 200.
>
>  -- Justin
>
> On 02/11/2013 06:33 PM, Richard Harrington wrote:
>
> Since the request is an HTTP POST and a resource is created (http://www.w=
3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5) the response should be an=
 HTTP 201 Created (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#s=
ec10.2.2) which is supposed to include the location of the newly created re=
source.
>
> This is a good pattern to follow since, as you say, it does provide flexi=
bility.
>
>
>
> On Feb 11, 2013, at 1:14 PM, Justin Richer  wrote:
>
> Draft -05 of OAuth Dynamic Client Registration [1] returns a URL pointer =
for the client to perform update and secret rotation actions. This function=
ality arose from discussions on the list about moving towards a more RESTfu=
l pattern, and Nat Sakimura proposed this approach in the OpenID Connect Wo=
rking Group. This URL may be distinct from the Client Registration Endpoint=
 URL, but draft -05 makes no promises as to its content, form, or structure=
, though it does contain implementor's notes on possible methods.
>
> Two questions arise from this change:
> - The semantics of returning the client manipulation URL
> - The syntax (derived from HAL for JSON [2], an individual I-D submission=
)
>
> On semantics:
>
> Pro:
> - The server has flexibility on how to define the "update" endpoint, send=
ing all clients to one URL, sending different clients to different URLs, or=
 sending clients to a URL with a baked-in query parameter
> - The client can take the URL as-is and use it for all management operati=
ons (ie, it doesn't have to generate or compose the URL based on component =
parts)
>
> Con:
> - The client must remember one more piece of information from the server =
at runtime if it wants to do manipulation and management of itself at the s=
erver (in addition to client_id, client_secret, registration_access_token, =
and others)
>
> Alternatives include specifying a URL pattern for the server to use and a=
ll clients to follow, specifying a query parameter for the update action, a=
nd specifying a separate endpoint entirely and using the presence of items =
such as client_id and the registration access token to differentiate the re=
quests. Note that *all* of these alternatives can be accommodated using the=
 semantics described above, with the same actions on the client's part.
>
>
> On syntax:
>
> Pro:
> - Follows the designs of RFC5988 for link relations
> - The HAL format is general, and allows for all kinds of other informatio=
n to be placed inside the _links structure
> - Allows for full use of the JSON object to specify advanced operations o=
n the returned endpoint if desired
>
> Con:
> - The rest of OAuth doesn't follow link relation guidelines (though it's =
been brought up)
> - The HAL format is general, and allows for all kinds of other informatio=
n to be placed inside the _links structure
> - The HAL-JSON document is an expired individual I-D, and it's unclear wh=
at wider adoption looks like right now
>
> Alternatives include returning the URL as a separate data member (registr=
ation_update_url), using HTTP headers, or using JSON Schema.
>
> -- Justin
>
>
>
> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
> [2] http://tools.ietf.org/html/draft-kelly-json-hal-03
> _______________________________________________
> 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
>

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

From sakimura@gmail.com  Tue Feb 12 09:15:05 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F372B21F8CF5 for ; Tue, 12 Feb 2013 09:15:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.033
X-Spam-Level: 
X-Spam-Status: No, score=-2.033 tagged_above=-999 required=5 tests=[AWL=0.567,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sY9zUoDQDGP8 for ; Tue, 12 Feb 2013 09:15:04 -0800 (PST)
Received: from mail-la0-x233.google.com (la-in-x0233.1e100.net [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id E762021F8945 for ; Tue, 12 Feb 2013 09:15:03 -0800 (PST)
Received: by mail-la0-f51.google.com with SMTP id fo13so306729lab.24 for ; Tue, 12 Feb 2013 09:15:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=WCOU1v/sONpm430eCqD0GbIRdtlfFrWqwK34pGhzCxc=; b=Xk2Je3lq3c49tEZX9w/zhh3S6SGFGo7H7OP1YIqiLQwPbZF7M9nsG9IlewefBQRrpO b0/7ThXlBwDHnmCTWo4jA+r7CuKztpCciU/u10fZXPjEgfvmrA3fw/xvnFi6iCPaUNiA xZ0i6tUjPCJO6Hk3OecxSCrBgWgz6uRzQqxEQHdAgvWbFVD8s1U2HBClp2VkR8YpWZ80 pmh7t1RkCdmgoIMD5O31MjfHA99lZTpXwJ6Vm/aZn2EHeRFBp0zX9KNI2pMox+dCPsUn h7braraWvxtAeL8UKADEG4gQz8PjtJnpi0STXwDHxHKL3fEib87Um45GlKEReT1dpZ9M FkkQ==
MIME-Version: 1.0
X-Received: by 10.152.109.112 with SMTP id hr16mr14200127lab.38.1360689302678;  Tue, 12 Feb 2013 09:15:02 -0800 (PST)
Received: by 10.112.14.44 with HTTP; Tue, 12 Feb 2013 09:15:02 -0800 (PST)
In-Reply-To: <511A705F.4070204@mitre.org>
References: <51195F36.6040705@mitre.org> <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com> <80727F20-A830-4778-B11C-D45389310646@lodderstedt.net> <511A5742.30707@mitre.org>  <511A705F.4070204@mitre.org>
Date: Wed, 13 Feb 2013 02:15:02 +0900
Message-ID: 
From: Nat Sakimura 
To: Justin Richer 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 17:15:05 -0000

2013/2/13 Justin Richer :
>
> On 02/12/2013 11:30 AM, John Bradley wrote:
>>
>> To some extent we want the server to have the flexibility it needs.
>>
>> If the server knows it is going to need client_id for GET it needs to
>> encode it in the resource URI ether as part of the path or as a query
>> parameter (that is up to the server)
>>
>> When doing updates the client MUST include the client_id as an additional
>> integrity check.  Some servers may switch on that but that is up to them.
>
> So if by this you mean that the client still simply follows whatever update
> url the server hands it (which may or may not include the client_id in some
> form, but the client doesn't care), and that the client MUST include its
> client_id in the request body (top-level member of a JSON object, at the
> moment) when doing a PUT (or POST/PATCH? see below) for the update action,
> then I'm totally fine with that. Is this what you're suggesting?

As far as I understand, yes. That is what we discussed last Thursday
face to face.

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

From sakimura@gmail.com  Tue Feb 12 09:17:32 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3417C21F9001 for ; Tue, 12 Feb 2013 09:17:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.011
X-Spam-Level: 
X-Spam-Status: No, score=-3.011 tagged_above=-999 required=5 tests=[AWL=0.589,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adNqkpI1l+LW for ; Tue, 12 Feb 2013 09:17:31 -0800 (PST)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 46EDC21F8FF6 for ; Tue, 12 Feb 2013 09:17:31 -0800 (PST)
Received: by mail-lb0-f172.google.com with SMTP id n8so292877lbj.31 for ; Tue, 12 Feb 2013 09:17:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=86I2xlyrXxu3HCS4gBDzkfXTUfp1P8bZ+dziBK2VezU=; b=u3EfS39vOqn93javUTrcAhOcTF7Aq0DgertNdGhYimKbTfUOpIMlDgiJXKWDM1y8YO uXf+krWui1FyontB/z4ZTaH78jkUJJWuNdiOsNx171rmkDQdt0rzWuluRFoQsda3zdR9 empKaYMA3ASCX19n87/U0Ovt7ubFi/xg4CMGh8XfkyJStFnLUyRnUZcA7lOiowpQcUai OqmPZGK9jkAxy2nHARHmpKfKxp309RU4v/17pH0Mwa5ERFMdt+CX6yRcrxSR1FM8+hjc kVpZEnGyhG/2oeLpzRSat+RHsHbF4MfYQG10SdVi7WuuzpJnrUHr8rR+/yRoE/067JZR 1lbQ==
MIME-Version: 1.0
X-Received: by 10.112.41.101 with SMTP id e5mr7306688lbl.120.1360689445893; Tue, 12 Feb 2013 09:17:25 -0800 (PST)
Received: by 10.112.14.44 with HTTP; Tue, 12 Feb 2013 09:17:25 -0800 (PST)
In-Reply-To: <20130212163841.4897.30278.idtracker@ietfa.amsl.com>
References: <20130212163841.4897.30278.idtracker@ietfa.amsl.com>
Date: Wed, 13 Feb 2013 02:17:25 +0900
Message-ID: 
From: Nat Sakimura 
To: oauth 
Content-Type: text/plain; charset=ISO-8859-1
Subject: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-meta-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 17:17:32 -0000

This is the second rev of the metadata spec that we discussed at IETF
85 OAuth WG and subsequently the chairs asked for the draft.

Nat

---------- Forwarded message ----------
From:  
Date: 2013/2/13
Subject: New Version Notification for draft-sakimura-oauth-meta-02.txt
To: sakimura@gmail.com
Cc: mike@stateless.co

A new version of I-D, draft-sakimura-oauth-meta-02.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Filename:        draft-sakimura-oauth-meta
Revision:        02
Title:           JSON Metadata for OAuth Responses 1.0
Creation date:   2013-02-12
WG ID:           Individual Submission
Number of pages: 10
URL:
http://www.ietf.org/internet-drafts/draft-sakimura-oauth-meta-02.txt
Status:          http://datatracker.ietf.org/doc/draft-sakimura-oauth-meta
Htmlized:        http://tools.ietf.org/html/draft-sakimura-oauth-meta-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-meta-02

Abstract:
   This specification defines an extensible metadata member that may be
   inserted into the OAuth 2.0 responses to assist the clients to
   process those responses.  It is expressed as a member called "_links"
   that is inserted as the top level member in the responses.  It will
   allow the client to learn where the members in the response could be
   used and how, etc.  Since it is just a member, any client that does
   not understand this extension should not break and work normally
   while supporting clients can utilize the metadata to its advantage.

The IETF Secretariat

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

From phil.hunt@oracle.com  Tue Feb 12 09:30:58 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC20921F9019 for ; Tue, 12 Feb 2013 09:30:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.355
X-Spam-Level: 
X-Spam-Status: No, score=-6.355 tagged_above=-999 required=5 tests=[AWL=0.244,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HbPaC+gODAF for ; Tue, 12 Feb 2013 09:30:57 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id C9FC521F9016 for ; Tue, 12 Feb 2013 09:30:57 -0800 (PST)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1CHUsAJ008432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Feb 2013 17:30:55 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1CHUsFv009830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Feb 2013 17:30:54 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1CHUqqs026761; Tue, 12 Feb 2013 11:30:54 -0600
Received: from [192.168.1.14] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 12 Feb 2013 09:30:52 -0800
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Phil Hunt 
In-Reply-To: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net>
Date: Tue, 12 Feb 2013 09:30:50 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net>
To: Hannes Tschofenig 
X-Mailer: Apple Mail (2.1283)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 17:30:58 -0000

Clarification.  I think Justin and I were in agreement that we don't =
want to see a format that requires JSON payloads.  We are both =
interested in a JSON token used in the authorization header that could =
be based on a computed signature of some combination of http headers and =
body if possible.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On 2013-02-12, at 1:10 AM, Hannes Tschofenig wrote:

> Here are my notes.=20
>=20
> Participants:
>=20
> * John Bradley
> * Derek Atkins
> * Phil Hunt
> * Prateek Mishra
> * Hannes Tschofenig
> * Mike Jones
> * Antonio Sanso
> * Justin Richer
>=20
> Notes:=20
>=20
> My slides are available here: =
http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
>=20
> Slide #2 summarizes earlier discussions during the conference calls.=20=

>=20
> -- HTTP vs. JSON
>=20
> Phil noted that he does not like to use the MAC Token draft as a =
starting point because it does not re-use any of the work done in the =
JOSE working group and in particular all the libraries that are =
available today. He mentioned that earlier attempts to write the MAC =
Token code lead to problems for implementers.=20
>=20
> Justin responded that he does not agree with using JSON as a transport =
mechanism since this would replicate a SOAP style.=20
>=20
> Phil noted that he wants to send JSON but the signature shall be =
computed over the HTTP header field.=20
>=20
> -- Flexibility for the keyed message digest computation
>=20
> =46rom earlier discussion it was clear that the conference call =
participants wanted more flexibility regarding the keyed message digest =
computation. For this purpose Hannes presented the DKIM based approach, =
which allows selective header fields to be included in the digest. This =
is shown in slide #4.=20
>=20
> After some discussion the conference call participants thought that =
this would meet their needs. Further investigations would still be =
useful to determine the degree of failed HMAC calculations due to HTTP =
proxies modifying the content.=20
>=20
> -- Key Distribution
>=20
> Hannes presented the open issue regarding the choice of key =
distribution. Slides #6-#8 present three techniques and Hannes asked for =
feedback regarding the preferred style. Justin and others didn't see the =
need to decide on one mechanism - they wanted to keep the choice open. =
Derek indicated that this will not be an acceptable approach. Since the =
resource server and the authorization server may, in the OAuth 2.0 =
framework, be entities produced by different vendors there is an =
interoperability need. Justin responded that he disagrees and that the =
resource server needs to understand the access token and referred to the =
recent draft submission for the token introspection endpoint. Derek =
indicated that the resource server has to understand the content of the =
access token and the token introspection endpoint just pushes the =
problem around: the resource server has to send the access token to the =
authorization server and then the resource server gets the result back =
(which he then a
> gain needs to understand) in order to make a meaningful authorization =
decision.=20
>=20
> Everyone agreed that the client must receive the session key from the =
authorization server and that this approach has to be standardized. It =
was also agreed that this is a common approach among all three key =
distribution mechanisms.
>=20
> Hannes asked the participants to think about their preference.=20
>=20
> The questions regarding key naming and the indication for the intended =
resource server the client wants to talk to have been postponed.=20
>=20
> Ciao
> Hannes
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From jricher@mitre.org  Tue Feb 12 09:35:16 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880EA21F9013 for ; Tue, 12 Feb 2013 09:35:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.573
X-Spam-Level: 
X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyXHHvDs5TmW for ; Tue, 12 Feb 2013 09:35:15 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9549721F9011 for ; Tue, 12 Feb 2013 09:35:15 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 169BA1F08B4; Tue, 12 Feb 2013 12:35:15 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id F2A1A1F0431; Tue, 12 Feb 2013 12:35:14 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 12 Feb 2013 12:35:14 -0500
Message-ID: <511A7D27.8010209@mitre.org>
Date: Tue, 12 Feb 2013 12:34:31 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Phil Hunt 
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net> 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [129.83.31.58]
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 17:35:16 -0000

That's my reading of it as well, Phil, thanks for providing the=20
clarification. One motivator behind using a JSON-based token is to be=20
able to re-use some of the great work that the JOSE group is doing but=20
apply it to an HTTP payload.

What neither of us want is a token type that requires stuffing all=20
query, header, and other parameters *into* the JSON object itself, which =

would be a more SOAPy approach.

  -- Justin

On 02/12/2013 12:30 PM, Phil Hunt wrote:
> Clarification.  I think Justin and I were in agreement that we don't wa=
nt to see a format that requires JSON payloads.  We are both interested i=
n a JSON token used in the authorization header that could be based on a =
computed signature of some combination of http headers and body if possib=
le.
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>
>
>
>
> On 2013-02-12, at 1:10 AM, Hannes Tschofenig wrote:
>
>> Here are my notes.
>>
>> Participants:
>>
>> * John Bradley
>> * Derek Atkins
>> * Phil Hunt
>> * Prateek Mishra
>> * Hannes Tschofenig
>> * Mike Jones
>> * Antonio Sanso
>> * Justin Richer
>>
>> Notes:
>>
>> My slides are available here: http://www.tschofenig.priv.at/OAuth2-Sec=
urity-11Feb2013.ppt
>>
>> Slide #2 summarizes earlier discussions during the conference calls.
>>
>> -- HTTP vs. JSON
>>
>> Phil noted that he does not like to use the MAC Token draft as a start=
ing point because it does not re-use any of the work done in the JOSE wor=
king group and in particular all the libraries that are available today. =
He mentioned that earlier attempts to write the MAC Token code lead to pr=
oblems for implementers.
>>
>> Justin responded that he does not agree with using JSON as a transport=
 mechanism since this would replicate a SOAP style.
>>
>> Phil noted that he wants to send JSON but the signature shall be compu=
ted over the HTTP header field.
>>
>> -- Flexibility for the keyed message digest computation
>>
>>  From earlier discussion it was clear that the conference call partici=
pants wanted more flexibility regarding the keyed message digest computat=
ion. For this purpose Hannes presented the DKIM based approach, which all=
ows selective header fields to be included in the digest. This is shown i=
n slide #4.
>>
>> After some discussion the conference call participants thought that th=
is would meet their needs. Further investigations would still be useful t=
o determine the degree of failed HMAC calculations due to HTTP proxies mo=
difying the content.
>>
>> -- Key Distribution
>>
>> Hannes presented the open issue regarding the choice of key distributi=
on. Slides #6-#8 present three techniques and Hannes asked for feedback r=
egarding the preferred style. Justin and others didn't see the need to de=
cide on one mechanism - they wanted to keep the choice open. Derek indica=
ted that this will not be an acceptable approach. Since the resource serv=
er and the authorization server may, in the OAuth 2.0 framework, be entit=
ies produced by different vendors there is an interoperability need. Just=
in responded that he disagrees and that the resource server needs to unde=
rstand the access token and referred to the recent draft submission for t=
he token introspection endpoint. Derek indicated that the resource server=
 has to understand the content of the access token and the token introspe=
ction endpoint just pushes the problem around: the resource server has to=
 send the access token to the authorization server and then the resource =
server gets the result back (which he then
>    a
>> gain needs to understand) in order to make a meaningful authorization =
decision.
>>
>> Everyone agreed that the client must receive the session key from the =
authorization server and that this approach has to be standardized. It wa=
s also agreed that this is a common approach among all three key distribu=
tion mechanisms.
>>
>> Hannes asked the participants to think about their preference.
>>
>> The questions regarding key naming and the indication for the intended=
 resource server the client wants to talk to have been postponed.
>>
>> 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

From Michael.Jones@microsoft.com  Tue Feb 12 09:57:01 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4DF821F9039 for ; Tue, 12 Feb 2013 09:57:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.164
X-Spam-Level: 
X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_82=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pr6fzW7jFD9l for ; Tue, 12 Feb 2013 09:57:00 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.32]) by ietfa.amsl.com (Postfix) with ESMTP id 07C5521F9030 for ; Tue, 12 Feb 2013 09:56:54 -0800 (PST)
Received: from BL2FFO11FD020.protection.gbl (10.173.161.204) by BL2FFO11HUB005.protection.gbl (10.173.160.225) with Microsoft SMTP Server (TLS) id 15.0.620.12; Tue, 12 Feb 2013 17:56:52 +0000
Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD020.mail.protection.outlook.com (10.173.161.38) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Tue, 12 Feb 2013 17:56:52 +0000
Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.232]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Tue, 12 Feb 2013 17:56:15 +0000
From: Mike Jones 
To: John Bradley , Justin Richer 
Thread-Topic: [OAUTH-WG] Registration: Client secret rotation
Thread-Index: AQHOCJ0LDzoQT/UaG0SbLONUo4RclZh1a0HAgAAH9QCAANZaAIAAHvMAgAAawhw=
Date: Tue, 12 Feb 2013 17:56:14 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394367443619@TK5EX14MBXC285.redmond.corp.microsoft.com>
References: <51195F3F.7000704@mitre.org> <4E1F6AAD24975D4BA5B16804296739436743E371@TK5EX14MBXC285.redmond.corp.microsoft.com> <7FB7A108-EA9E-429A-BD86-7E09EA206748@ve7jtb.com> <511A51D6.9040604@mitre.org>, <9FC3A5CD-B4EC-4CA2-8082-FAC65C499B3B@ve7jtb.com>
In-Reply-To: <9FC3A5CD-B4EC-4CA2-8082-FAC65C499B3B@ve7jtb.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367443619TK5EX14MBXC285r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(24454001)(51704002)(55885001)(479174001)(377424002)(377454001)(13464002)(199002)(189002)(49866001)(74662001)(16236675001)(79102001)(51856001)(44976002)(47976001)(47736001)(20776003)(512934001)(80022001)(56816002)(56776001)(65816001)(77982001)(15202345001)(47446002)(76482001)(46102001)(55846006)(16406001)(31966008)(5343655001)(63696002)(74502001)(53806001)(4396001)(54316002)(59766001)(54356001)(5343635001)(33656001)(50986001)(219293001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB005; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0755F54DD9
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: Client secret rotation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 17:57:02 -0000

--_000_4E1F6AAD24975D4BA5B168042967394367443619TK5EX14MBXC285r_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

+1

________________________________
From: John Bradley
Sent: 2/12/2013 8:20 AM
To: Justin Richer
Cc: Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Client secret rotation

Yes, that agrees with my thoughts on it.

John B.
On 2013-02-12, at 11:29 AM, Justin Richer  wrote:

> This is actually the approach that I favor now as well -- let the server =
do the secret rotation if it wants to, and have the client be prepared to r=
eceive a new client_secret or registration_access_token on any read or upda=
te request.
>
> This would necessitate changing the returned values, essentially collapsi=
ng the returns from the read/update and rotate actions into one structure t=
hat's closer to the one returned from initial registration. This has the ad=
ded benefit of parallelizing the responses for these three actions, which I=
 like as well.
>
> -- Justin
>
> On 02/11/2013 08:42 PM, John Bradley wrote:
>> OAuth doesn't say anything about client secrets other than they are prov=
isioned in a magic realm outside the OAuth spec (Getting in the mood for th=
e next IETF).
>>
>> Rotating client secrets was something I made up for connect because it s=
eemed like a good idea at the time given that someone breaking in to the re=
gistration endpoint could take over a connection.
>>
>> We later separated the authentication to the token endpoint from the reg=
istration endpoint,in what I think was a good move.
>>
>> It is sort of up to the authorization server to make decisions about rot=
ating client secrets, I expect that in the real world a client would try ac=
cess ing the token endpoint and get back a invalid_client error response an=
d then heck it's registration to see if the client_secret has changed.
>>
>> I suppose that a client could request rotating its secret if it thinks i=
t has been compromised,  however the compromiser is more likely to quickly =
change the secret to lock out the legitimate clients before the good one no=
tices.    I think the client wanting to rotate is enough of a edge case tha=
t it could deal with it out of band.
>>
>> Letting the server rotate the client secret according to what ever polic=
y it decides is best is probably safest.
>>
>> We didn't have anything for rotating the access token.  I suspect that r=
otating it under the clients control is going to create as many problems as=
 it solves.
>>
>> If you want to rotate it,  make it a refresh token that is issues and us=
e OAuth to provide access tokens from the token endpoint.   Creating a new =
endpoint to duplicate existing OAuth functionality is overkill.
>>
>> John B.
>> On 2013-02-11, at 10:18 PM, Mike Jones  wro=
te:
>>
>>> The rotate_secret operation was added to OpenID Connect Registration as=
 a workaround to the fact that registration updates used to be authenticate=
d using the client secret, so it seemed overly dangerous to have an update =
operation potentially return an updated secret and have the secret be lost =
due to communication problems - leaving the client stranded.  Since then, r=
egistration was changed to use a bearer token to authenticate update operat=
ions, and so this failure mode can't occur anymore.  It was an omission not=
 to have deleted the unneeded operation then.
>>>
>>> It's been deleted from OpenID Connect Registration and should likewise =
be deleted from OAuth registration, since it is unneeded.  If a new client =
secret is needed, there's nothing stopping the registration server from ret=
urning it in the result of an update operation.
>>>
>>>                              -- Mike
>>>
>>> -----Original Message-----
>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf =
Of Justin Richer
>>> Sent: Monday, February 11, 2013 1:15 PM
>>> To: oauth@ietf.org
>>> Subject: [OAUTH-WG] Registration: Client secret rotation
>>>
>>> Draft -05 of OAuth Dynamic Client Registration [1] defines a means of t=
he client requesting a new client_secret (if applicable) and a new registra=
tion_access_token. Client secrets MAY expire after some period of time, and=
 this method allows for a refresh of that secret. Draft -00 defined no such=
 operation, drafts -01 through -04 defined this operation in terms of the o=
peration=3Drotate_secret parameter, and draft -05 defines it through a seco=
ndary endpoint, the Client Secret Rotation Endpoint.
>>> This raises several questions:
>>>
>>>  - Should the client be allowed to request rotation of its secret?
>>>  - Would a client ever take this action of its own accord?
>>>  - Can a server rotate the secret of the client without the client aski=
ng? (This seems to be an obvious "yes")
>>>
>>> Alternatives that keep this functionality include defining the rotate_s=
ecret operation in terms of an HTTP verb, a query parameter, or separate en=
dpoint. Alternatively, we could drop the rotate_secret operation all togeth=
er. If we do this, we have to decide if the client secret can still expire.=
 If it can, then we need a way for the client to get this new secret throug=
h a means that doesn't require it to request a change in secret, such as se=
nding it back as part of the client READ operation (see other thread on RES=
Tful verbs).
>>>
>>>  -- Justin
>>>
>>>
>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>>> _______________________________________________
>>> 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
>

--_000_4E1F6AAD24975D4BA5B168042967394367443619TK5EX14MBXC285r_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

+1

From:
John B=
radley

Sent:
2/12/2=
013 8:20 AM

To:
Justin=
 Richer

Cc:
Mike J=
ones; oauth@ietf.org

Subject:
Re: [O=
AUTH-WG] Registration: Client secret rotation

Yes, that agrees with my thoughts on it.

John B.

On 2013-02-12, at 11:29 AM, Justin Richer <jricher@mitre.org> wrote:<=
br>

> This is actually the approach that I favor now as well -- let the serv=
er do the secret rotation if it wants to, and have the client be prepared t=
o receive a new client_secret or registration_access_token on any read or u=
pdate request.

> 

> This would necessitate changing the returned values, essentially colla=
psing the returns from the read/update and rotate actions into one structur=
e that's closer to the one returned from initial registration. This has the=
 added benefit of parallelizing the
 responses for these three actions, which I like as well.

> 

> -- Justin

> 

> On 02/11/2013 08:42 PM, John Bradley wrote:

>> OAuth doesn't say anything about client secrets other than they ar=
e provisioned in a magic realm outside the OAuth spec (Getting in the mood =
for the next IETF).

>> 

>> Rotating client secrets was something I made up for connect becaus=
e it seemed like a good idea at the time given that someone breaking in to =
the registration endpoint could take over a connection.

>> 

>> We later separated the authentication to the token endpoint from t=
he registration endpoint,in what I think was a good move.

>> 

>> It is sort of up to the authorization server to make decisions abo=
ut rotating client secrets, I expect that in the real world a client would =
try access ing the token endpoint and get back a invalid_client error respo=
nse and then heck it's registration to
 see if the client_secret has changed.

>> 

>> I suppose that a client could request rotating its secret if it th=
inks it has been compromised,  however the compromiser is more likely =
to quickly change the secret to lock out the legitimate clients before the =
good one notices.    I think the client wanting
 to rotate is enough of a edge case that it could deal with it out of band.=

>> 

>> Letting the server rotate the client secret according to what ever=
 policy it decides is best is probably safest.

>> 

>> We didn't have anything for rotating the access token.  I sus=
pect that rotating it under the clients control is going to create as many =
problems as it solves.

>> 

>> If you want to rotate it,  make it a refresh token that is is=
sues and use OAuth to provide access tokens from the token endpoint. &=
nbsp; Creating a new endpoint to duplicate existing OAuth functionality is =
overkill.

>> 

>> John B.

>> On 2013-02-11, at 10:18 PM, Mike Jones <Michael.Jones@microsoft=
.com> wrote:

>> 

>>> The rotate_secret operation was added to OpenID Connect Regist=
ration as a workaround to the fact that registration updates used to be aut=
henticated using the client secret, so it seemed overly dangerous to have a=
n update operation potentially return an
 updated secret and have the secret be lost due to communication problems -=
 leaving the client stranded.  Since then, registration was changed to=
 use a bearer token to authenticate update operations, and so this failure =
mode can't occur anymore.  It was an
 omission not to have deleted the unneeded operation then.

>>> 

>>> It's been deleted from OpenID Connect Registration and should =
likewise be deleted from OAuth registration, since it is unneeded.  If=
 a new client secret is needed, there's nothing stopping the registration s=
erver from returning it in the result of an update
 operation.

>>> 

>>>          &nb=
sp;            =
       -- Mike

>>> 

>>> -----Original Message-----

>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer

>>> Sent: Monday, February 11, 2013 1:15 PM

>>> To: oauth@ietf.org

>>> Subject: [OAUTH-WG] Registration: Client secret rotation

>>> 

>>> Draft -05 of OAuth Dynamic Client Registration [1] defines a m=
eans of the client requesting a new client_secret (if applicable) and a new=
 registration_access_token. Client secrets MAY expire after some period of =
time, and this method allows for a refresh
 of that secret. Draft -00 defined no such operation, drafts -01 through -0=
4 defined this operation in terms of the operation=3Drotate_secret paramete=
r, and draft -05 defines it through a secondary endpoint, the Client Secret=
 Rotation Endpoint.

>>> This raises several questions:

>>> 

>>>  - Should the client be allowed to request rotation of it=
s secret?

>>>  - Would a client ever take this action of its own accord=
?

>>>  - Can a server rotate the secret of the client without t=
he client asking? (This seems to be an obvious "yes")

>>> 

>>> Alternatives that keep this functionality include defining the=
 rotate_secret operation in terms of an HTTP verb, a query parameter, or se=
parate endpoint. Alternatively, we could drop the rotate_secret operation a=
ll together. If we do this, we have to decide
 if the client secret can still expire. If it can, then we need a way for t=
he client to get this new secret through a means that doesn't require it to=
 request a change in secret, such as sending it back as part of the client =
READ operation (see other thread
 on RESTful verbs).

>>> 

>>>  -- Justin

>>> 

>>> 

>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05

>>> _______________________________________________

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

> 

--_000_4E1F6AAD24975D4BA5B168042967394367443619TK5EX14MBXC285r_--

From torsten@lodderstedt.net  Tue Feb 12 10:02:43 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB2D21F8FFA for ; Tue, 12 Feb 2013 10:02:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.969
X-Spam-Level: 
X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[AWL=0.280,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrSsdo8pMbub for ; Tue, 12 Feb 2013 10:02:43 -0800 (PST)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.26]) by ietfa.amsl.com (Postfix) with ESMTP id F1E7621F8FDF for ; Tue, 12 Feb 2013 10:02:42 -0800 (PST)
Received: from [91.2.75.145] (helo=[192.168.71.56]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1U5KBk-0007Ij-1h; Tue, 12 Feb 2013 19:02:40 +0100
References: <51195F39.3040809@mitre.org> <4E1F6AAD24975D4BA5B16804296739436743E3DD@TK5EX14MBXC285.redmond.corp.microsoft.com>  <511A586B.9060606@mitre.org>
Mime-Version: 1.0 (1.0)
In-Reply-To: <511A586B.9060606@mitre.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: 
X-Mailer: iPad Mail (10B141)
From: Torsten Lodderstedt 
Date: Tue, 12 Feb 2013 19:02:40 +0100
To: Justin Richer 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: Endpoint Definition (& operation parameter)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 18:02:43 -0000

Am 12.02.2013 um 15:57 schrieb Justin Richer :

> 
> I think that's a very important difference.

I fully agree.

From Michael.Jones@microsoft.com  Tue Feb 12 10:37:21 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C4F21F905E for ; Tue, 12 Feb 2013 10:37:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.591
X-Spam-Level: 
X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9cbDJvMkIbz for ; Tue, 12 Feb 2013 10:37:20 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.32]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9B621F9042 for ; Tue, 12 Feb 2013 10:37:19 -0800 (PST)
Received: from BY2FFO11FD009.protection.gbl (10.1.15.201) by BY2FFO11HUB008.protection.gbl (10.1.14.166) with Microsoft SMTP Server (TLS) id 15.0.620.12; Tue, 12 Feb 2013 18:37:18 +0000
Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD009.mail.protection.outlook.com (10.1.14.73) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Tue, 12 Feb 2013 18:37:18 +0000
Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.232]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Tue, 12 Feb 2013 18:37:01 +0000
From: Mike Jones 
To: Nat Sakimura , Justin Richer 
Thread-Topic: [OAUTH-WG] Registration: RESTful client lifecycle management
Thread-Index: AQHOCJzxVGwYODuh3UmktcEEXHrfK5h1dc0AgABcxoCAAH10AIAAG1EAgAACn4CAAAnLAIAAFhgg
Date: Tue, 12 Feb 2013 18:37:00 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394367443862@TK5EX14MBXC285.redmond.corp.microsoft.com>
References: <51195F36.6040705@mitre.org> <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com> <80727F20-A830-4778-B11C-D45389310646@lodderstedt.net> <511A5742.30707@mitre.org>	 <511A705F.4070204@mitre.org> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.33]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704002)(24454001)(189002)(199002)(13464002)(479174001)(55885001)(377454001)(51856001)(56776001)(16406001)(33656001)(46102001)(66066001)(4396001)(80022001)(54356001)(5343655001)(59766001)(23726001)(76482001)(46406002)(77982001)(55846006)(54316002)(44976002)(50986001)(47976001)(74502001)(47446002)(79102001)(53806001)(15202345001)(49866001)(47736001)(56816002)(47776003)(20776003)(63696002)(31966008)(65816001)(50466001)(74662001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB008; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0755F54DD9
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 18:37:21 -0000

Then I think we've reached an acceptable resolution on this one.  By having=
 the server return the registration_access_url upon create and having the c=
lient be required to include the client_id upon update, servers are free to=
 manage their registration endpoint(s) as they see fit and clients always d=
o the same thing.

				Thanks all,
				-- Mike

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of N=
at Sakimura
Sent: Tuesday, February 12, 2013 9:15 AM
To: Justin Richer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management

2013/2/13 Justin Richer :
>
> On 02/12/2013 11:30 AM, John Bradley wrote:
>>
>> To some extent we want the server to have the flexibility it needs.
>>
>> If the server knows it is going to need client_id for GET it needs to=20
>> encode it in the resource URI ether as part of the path or as a query=20
>> parameter (that is up to the server)
>>
>> When doing updates the client MUST include the client_id as an=20
>> additional integrity check.  Some servers may switch on that but that is=
 up to them.
>
> So if by this you mean that the client still simply follows whatever=20
> update url the server hands it (which may or may not include the=20
> client_id in some form, but the client doesn't care), and that the=20
> client MUST include its client_id in the request body (top-level=20
> member of a JSON object, at the
> moment) when doing a PUT (or POST/PATCH? see below) for the update=20
> action, then I'm totally fine with that. Is this what you're suggesting?

As far as I understand, yes. That is what we discussed last Thursday face t=
o face.

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

From jricher@mitre.org  Tue Feb 12 10:38:40 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F40D21F9086 for ; Tue, 12 Feb 2013 10:38:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.573
X-Spam-Level: 
X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCjmlY3pD6+A for ; Tue, 12 Feb 2013 10:38:39 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 75D2421F905E for ; Tue, 12 Feb 2013 10:38:39 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DF611531195A; Tue, 12 Feb 2013 13:38:38 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id CF7C65311958; Tue, 12 Feb 2013 13:38:38 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 12 Feb 2013 13:38:38 -0500
Message-ID: <511A8C02.8000504@mitre.org>
Date: Tue, 12 Feb 2013 13:37:54 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Mike Jones 
References: <51195F36.6040705@mitre.org> <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com> <80727F20-A830-4778-B11C-D45389310646@lodderstedt.net> <511A5742.30707@mitre.org>	 <511A705F.4070204@mitre.org>  <4E1F6AAD24975D4BA5B168042967394367443862@TK5EX14MBXC285.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367443862@TK5EX14MBXC285.redmond.corp.microsoft.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 18:38:40 -0000

I agree, and the "must include client_id" gels with the other discussion 
of doing a full-replace for the PUT operation for updates from another 
thread.

  -- Justin

On 02/12/2013 01:37 PM, Mike Jones wrote:
> Then I think we've reached an acceptable resolution on this one.  By having the server return the registration_access_url upon create and having the client be required to include the client_id upon update, servers are free to manage their registration endpoint(s) as they see fit and clients always do the same thing.
>
> 				Thanks all,
> 				-- Mike
>
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura
> Sent: Tuesday, February 12, 2013 9:15 AM
> To: Justin Richer
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
>
> 2013/2/13 Justin Richer :
>> On 02/12/2013 11:30 AM, John Bradley wrote:
>>> To some extent we want the server to have the flexibility it needs.
>>>
>>> If the server knows it is going to need client_id for GET it needs to
>>> encode it in the resource URI ether as part of the path or as a query
>>> parameter (that is up to the server)
>>>
>>> When doing updates the client MUST include the client_id as an
>>> additional integrity check.  Some servers may switch on that but that is up to them.
>> So if by this you mean that the client still simply follows whatever
>> update url the server hands it (which may or may not include the
>> client_id in some form, but the client doesn't care), and that the
>> client MUST include its client_id in the request body (top-level
>> member of a JSON object, at the
>> moment) when doing a PUT (or POST/PATCH? see below) for the update
>> action, then I'm totally fine with that. Is this what you're suggesting?
> As far as I understand, yes. That is what we discussed last Thursday face to face.
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From ve7jtb@ve7jtb.com  Tue Feb 12 10:39:19 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F1321F9094 for ; Tue, 12 Feb 2013 10:39:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.231
X-Spam-Level: 
X-Spam-Status: No, score=-3.231 tagged_above=-999 required=5 tests=[AWL=0.368,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-S2R7vvH9KD for ; Tue, 12 Feb 2013 10:39:19 -0800 (PST)
Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) by ietfa.amsl.com (Postfix) with ESMTP id CE5C721F905E for ; Tue, 12 Feb 2013 10:39:18 -0800 (PST)
Received: by mail-qa0-f53.google.com with SMTP id z4so209884qan.12 for ; Tue, 12 Feb 2013 10:39:18 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=tvgmsZQZO4a6y8DbH5TVGGUbmOthp3d+In7yySG71ok=; b=nWyjBUP7Ul23566yCT7WiR6AGb7bO322IVed9Ndtrl0DlNbfuzpsDh23EWUkM+VT8Y LNTjZ93Dt4andScG0OlFFl8mg/FK1+CEOtCovCOuuRY4cBhbCiU2IHkAdK2VU7Fd0oX3 yb6OGD6uMHoYBLA1bVj3jDfTzv8NmLIYotnHiPqq+hzTZijGR7Pf8js8fiZ3f+tdUzZ6 X5nhur7hyOMyVuh9iR8aq1rbnDvX3mq3Agv7tFGZOo+S4ccrjp6RM2afcSddR6OLzZce xQlcmmYhJbSZNFrQVrxQ1pqtDeX8hpmLO9asQpOI+VEbaxGtadrJ7P/F9fhPOkk77t9/ esmw==
X-Received: by 10.229.171.139 with SMTP id h11mr1719826qcz.67.1360694358137; Tue, 12 Feb 2013 10:39:18 -0800 (PST)
Received: from [192.168.1.213] (190-20-23-212.baf.movistar.cl. [190.20.23.212]) by mx.google.com with ESMTPS id hn9sm16725622qab.8.2013.02.12.10.39.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 10:39:16 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <511A705F.4070204@mitre.org>
Date: Tue, 12 Feb 2013 15:39:10 -0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <265D6A19-E8CA-4CCA-B6FC-0D843BD204D5@ve7jtb.com>
References: <51195F36.6040705@mitre.org> <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com> <80727F20-A830-4778-B11C-D45389310646@lodderstedt.net> <511A5742.30707@mitre.org>  <511A705F.4070204@mitre.org>
To: Justin Richer 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQl7nkFEoxwxcDx7PByG1YffngfB87d63DP1SNhbSnOUISPonkiJyLQ/XaFGlFwoARNfZN8i
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 18:39:20 -0000

On 2013-02-12, at 1:39 PM, Justin Richer  wrote:

>=20
> On 02/12/2013 11:30 AM, John Bradley wrote:
>> To some extent we want the server to have the flexibility it needs.
>>=20
>> If the server knows it is going to need client_id for GET it needs to =
encode it in the resource URI ether as part of the path or as a query =
parameter (that is up to the server)
>>=20
>> When doing updates the client MUST include the client_id as an =
additional integrity check.  Some servers may switch on that but that is =
up to them.
> So if by this you mean that the client still simply follows whatever =
update url the server hands it (which may or may not include the =
client_id in some form, but the client doesn't care), and that the =
client MUST include its client_id in the request body (top-level member =
of a JSON object, at the moment) when doing a PUT (or POST/PATCH? see =
below) for the update action, then I'm totally fine with that. Is this =
what you're suggesting?

Yes but It is a suggestion others may still hate it.
>=20
>> If we want incremental replace (not resetting claims not sent to =
there defaults) then we need POST for update.
>> I think if you want to do the REST thing and be pure about PUT it =
needs to reset all values not sent to there defaults.
>=20
> I agree with this argument in terms of the purity, and as I would =
rather see the different verb used for different actions, I am willing =
to give up the semantics of the not-resetting-claims that's in there =
right now for this action. There's actually another HTTP verb, PATCH, =
that isn't used much but is meant for partial updates, and we could =
transfer the not-resetting-claims action to this instead.

Yes PATCH would represent the incremental update but we are getting =
further from the beaten path here.=20

>=20
>> I suppose we could have both but two ways of doing it leads to =
confusion.
>=20
> I agree that we can't do both PUT and POST, and we can't have both =
partial and complete replacement on the same verb/endpoint combination. =
We need to pick one combination and have it be clear.
>=20
> -- Justin
>=20
>> On 2013-02-12, at 11:52 AM, Justin Richer  wrote:
>>=20
>>> The problem that I have with "always including the client_id" is =
*where* to include it. Are we talking a query parameter, URI template, =
or somewhere in the request body? The latter will only work for POST and =
PUT, so it's out of the question to support GET and DELETE using that =
semantic. I think we should support all operations using parallel syntax =
-- that's just good API design.
>>>=20
>>> I *really* don't like the idea of switching the action solely based =
on whether or not the client_id is present in the request body of a =
POST. This is a side-effectful mode switch, and it will only lead to =
pain and misery. Additionally, if the input is JSON (separate =
discussion), then a server would have to parse the JSON body before =
knowing where to route the request. In most web development frameworks =
that I've used, this is impossible. A query parameter or URL pattern, on =
the other hand, is doable.
>>>=20
>>> As it stands right now, a server is free to include the client_id in =
the "update/management" URL that it returns as part of the _link =
structure (separate discussion). The current text goes as far as =
recommending that practice, but doesn't take the step of requiring it in =
any form, and leaving it up to the server to decide what form it takes. =
If a server can route better with a query parameter, it'll return a URL =
to the client that has a client_id=3D query parameter. If a server would =
rather use a path component with the client_id, it can do that, too. If =
it wants to put everything on one URL and differentiate through the =
request body or presence/absence of the registration_access_token, it =
can always return the same URL to every client. I think that's nuts, but =
you can do it. Interoperability is preserved because the client simply =
follows the returned URL to do its bits and pieces, and it doesn't ever =
have to create or compose this URL from component parts.
>>>=20
>>> I want to continue to distinguish between the POST and PUT =
operations for create and update, respectively. This is a common pattern =
and the one described in the original REST thesis that described the =
architectural style. I'll also bring up that the semantics of PUT are =
intended to be "replace all", which is what you had originally argued =
for in the update case as well. I not convinced that developers of today =
can't handle HTTP verbs like PUT if they want to do fancier operations =
like updates. Note that the core operations, create and read, remain as =
POST and GET, which would be well within the grasp of every library and =
web developer today.
>>>=20
>>> -- Justin
>>>=20
>>> On 02/12/2013 02:23 AM, Torsten Lodderstedt wrote:
>>>> +1 for always including the client_id
>>>>=20
>>>> As John pointed out, there could be different entities updating =
client data. Then one has to distinguish the resource and the =
credential.
>>>>=20
>>>> Am 12.02.2013 um 02:51 schrieb John Bradley :
>>>>=20
>>>>> I would always include the client_id on update.
>>>>>=20
>>>>> I think it is also us full to have other tokens used at the update =
endpoint.  I can see the master token used to update all the clients it =
has registered as part of API management.
>>>>> Relying on the registration_access_token is probably a design that =
will cause trouble down the road.
>>>>>=20
>>>>> I think GET and POST are relatively clear.   I don't know about =
expelling PUT to developers.  I think POST with a client_id to a =
(separate discussion) update_uri works without restricting it to PUT.
>>>>>=20
>>>>> I think DELETE needs to be better understood.   I think a status =
that can be set for client lifecycle is better than letting a client =
delete a entry.
>>>>> In some cases there will be more than one instance of a client and =
letting them know they have been turned off for a reason is better than =
making there registration disappear.
>>>>> So for the moment I would levee out DELETE.
>>>>>=20
>>>>> John B.
>>>>>=20
>>>>> On 2013-02-11, at 6:14 PM, Justin Richer  =
wrote:
>>>>>=20
>>>>>> Draft -05 of OAuth Dynamic Client Registration [1] defines =
several operations that the client can take on its behalf as part of the =
registration process. These boil down to the basic CRUD operations that =
you find in many APIs: Create, Read, Update, Delete. Draft -00 defined =
only the "Create" operation, draft -01 through -04 added the "Update" =
operation, switched using the "operation=3D" parameter.
>>>>>>=20
>>>>>> Following several suggestions to do so on the list, the -05 draft =
defines these operations in terms of a RESTful API for the client. =
Namely:
>>>>>>=20
>>>>>> - HTTP POST to registration endpoint =3D> Create (register) a new =
client
>>>>>> - HTTP PUT to update endpoint (with registration_access_token) =3D>=
 Update the registered information for this client
>>>>>> - HTTP GET to update endpoint (with registration_access_token) =3D>=
 read the registered information for this client
>>>>>> - HTTP DELETE to update endpoint (with registration_access_token) =
=3D> Delete (unregister/de-provision) this client
>>>>>>=20
>>>>>> The two main issues at stake here are: the addition of the READ =
and DELETE methods, and the use of HTTP verbs following a RESTful design =
philosophy.
>>>>>>=20
>>>>>> Pro:
>>>>>> - RESTful APIs (with HTTP verbs to differentiate functionality) =
are the norm today
>>>>>> - Full lifecycle management is common and is going to be expected =
by many users of this protocol in the wild
>>>>>>=20
>>>>>> Cons:
>>>>>> - Update semantics are still under debate (full replace? patch?)
>>>>>> - Somewhat increased complexity on the server to support all =
operations
>>>>>> - Client has to understand all HTTP verbs for full access (though =
plain registration is just POST)
>>>>>>=20
>>>>>>=20
>>>>>> Alternatives include using an operational switch parameter (like =
the old drafts), defining separate endpoints for every action, or doing =
all operations on a single endpoint using verbs to switch.
>>>>>>=20
>>>>>> -- Justin
>>>>>>=20
>>>>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>>>>>> _______________________________________________
>>>>>> 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
>=20
>=20

From Michael.Jones@microsoft.com  Tue Feb 12 11:12:34 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29AFA21F90ED for ; Tue, 12 Feb 2013 11:12:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.591
X-Spam-Level: 
X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.007,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1FdxXa1qadP for ; Tue, 12 Feb 2013 11:12:32 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC1621F90EC for ; Tue, 12 Feb 2013 11:12:32 -0800 (PST)
Received: from BY2FFO11FD020.protection.gbl (10.1.15.202) by BY2FFO11HUB031.protection.gbl (10.1.14.116) with Microsoft SMTP Server (TLS) id 15.0.620.12; Tue, 12 Feb 2013 19:12:30 +0000
Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD020.mail.protection.outlook.com (10.1.14.137) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Tue, 12 Feb 2013 19:12:29 +0000
Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.232]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0318.003; Tue, 12 Feb 2013 19:11:54 +0000
From: Mike Jones 
To: Justin Richer , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Registration: JSON Encoded Input
Thread-Index: AQHOCJz80LLXzcDH1EumjHxgql90R5h2l5eg
Date: Tue, 12 Feb 2013 19:11:53 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394367443A16@TK5EX14MBXC285.redmond.corp.microsoft.com>
References: <51195F3B.1010701@mitre.org>
In-Reply-To: <51195F3B.1010701@mitre.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.33]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367443A16TK5EX14MBXC285r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(51444002)(377454001)(13464002)(55885001)(69234002)(15202345001)(20776003)(53806001)(33656001)(66066001)(512954001)(16236675001)(5343635001)(79102001)(16406001)(5343655001)(54356001)(63696002)(65816001)(49866001)(74502001)(80022001)(74662001)(4396001)(56776001)(44976002)(31966008)(54316002)(59766001)(47446002)(77982001)(47736001)(47976001)(55846006)(50986001)(76482001)(56816002)(51856001)(46102001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB031; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0755F54DD9
Subject: Re: [OAUTH-WG] Registration: JSON Encoded Input
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 19:12:34 -0000

--_000_4E1F6AAD24975D4BA5B168042967394367443A16TK5EX14MBXC285r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

FYI, this issue is also being discussed as an OpenID Connect issue at https=
://bitbucket.org/openid/connect/issue/747.  I think that Nat's recent comme=
nt there bears repeating on this list:

Nat Sakimura:

Not so sure. For example, PHP cannot get the JSON object form application/j=
son POST in $_POST.

It is OK to have a parameter like "request" that holds JSON. Then, you can =
get to it from $_POST['request']. However, if you POST the JSON as the POST=
 body, then you would have to call a low level function in the form of:

```

#!php

$file =3D file_get_contents('php://input'); $x =3D json_decode($file); ```

Not that it is harder, but it is much less known. Many PHP programmers will=
 certainly goes "???".

We need to check what would be the cases for other scripting languages befo=
re making the final decision.

                                                            -- Mike

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J=
ustin Richer
Sent: Monday, February 11, 2013 1:15 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Registration: JSON Encoded Input

Draft -05 of OAuth Dynamic Client Registration [1] switched from a form-enc=
oded input that had been used by drafts -01 through -04 to a JSON encoded i=
nput that was used originally in -00. Note that all versions keep JSON-enco=
ded output from all operations.

Pro:

  - JSON gives us a rich data structure so that things such as lists, numbe=
rs, nulls, and objects can be represented natively

  - Allows for parallelism between the input to the endpoint and output fro=
m the endpoint, reducing possible translation errors between the two

  - JSON specifies UTF8 encoding for all strings, forms may have many diffe=
rent encodings

  - JSON has minimal character escaping required for most strings, forms re=
quire escaping for common characters such as space, slash, comma, etc.

Con:

  - the rest of OAuth is form-in/JSON-out

  - nothing else in OAuth requires the Client to create a JSON object, mere=
ly to parse one

  - form-in/JSON-out is a very widely established pattern on the web today

  - Client information (client_name, client_id, etc.) is conflated with acc=
ess information (registration_access_token, _links, expires_at, etc.) in ro=
ot level of the same JSON object, leaving the client to decide what needs t=
o (can?) be sent back to the server for update operations.

Alternatives include any number of data encoding schemes, including form (l=
ike the old drafts), XML, ASN.1, etc.

  -- Justin

[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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

--_000_4E1F6AAD24975D4BA5B168042967394367443A16TK5EX14MBXC285r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

FYI, this issue is also being discussed as an Ope=
nID Connect issue at
https://bitbucke=
t.org/openid/connect/issue/747.  I think that Nat's recent comment=
 there bears repeating on this list:

Nat Sakimura:

Not so sure. For examp=
le, PHP cannot get the JSON object form application/json POST in $_POST.

It is OK to have a par=
ameter like "request" that holds JSON. Then, you can get to it fr=
om $_POST['request']. However, if you POST the JSON as the POST body, then =
you would have to call a low level function in
 the form of: 

```
#!php

$file =3D file_get_con=
tents('php://input'); $x =3D json_decode($file); ```

Not that it is harder,=
 but it is much less known. Many PHP programmers will certainly goes "=
???".

We need to check what =
would be the cases for other scripting languages before making the final de=
cision.

        &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp; -- Mike

-----Original Message-----

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J=
ustin Richer

Sent: Monday, February 11, 2013 1:15 PM

To: oauth@ietf.org

Subject: [OAUTH-WG] Registration: JSON Encoded Input

Draft -05 of OAuth Dynamic Client Registration [1=
] switched from a form-encoded input that had been used by drafts -01 throu=
gh -04 to a JSON encoded input that was used originally in -00. Note that a=
ll versions keep JSON-encoded output
 from all operations.

Pro:
  - JSON gives us a rich data structure so t=
hat things such as lists, numbers, nulls, and objects can be represented na=
tively
  - Allows for parallelism between the input=
 to the endpoint and output from the endpoint, reducing possible translatio=
n errors between the two
  - JSON specifies UTF8 encoding for all str=
ings, forms may have many different encodings
  - JSON has minimal character escaping requ=
ired for most strings, forms require escaping for common characters such as=
 space, slash, comma, etc.

Con:
  - the rest of OAuth is form-in/JSON-out
  - nothing else in OAuth requires the Clien=
t to create a JSON object, merely to parse one
  - form-in/JSON-out is a very widely establ=
ished pattern on the web today
  - Client information (client_name, client_=
id, etc.) is conflated with access information (registration_access_token, =
_links, expires_at, etc.) in root level of the same JSON object, leaving th=
e client to decide what needs to (can?)
 be sent back to the server for update operations.

Alternatives include any number of data encoding =
schemes, including form (like the old drafts), XML, ASN.1, etc.<=
/p>

  -- Justin

[1] 
http://tools.ietf.org=
/html/draft-ietf-oauth-dyn-reg-05
_______________________________________________
OAuth mailing list
OAuth@ietf.org=

https://www.ie=
tf.org/mailman/listinfo/oauth

--_000_4E1F6AAD24975D4BA5B168042967394367443A16TK5EX14MBXC285r_--

From Michael.Jones@microsoft.com  Tue Feb 12 11:26:04 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C14321F90FD for ; Tue, 12 Feb 2013 11:26:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.291
X-Spam-Level: 
X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, J_CHICKENPOX_44=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wMkpFhBMrDW for ; Tue, 12 Feb 2013 11:26:03 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6F42F21F90FC for ; Tue, 12 Feb 2013 11:26:03 -0800 (PST)
Received: from BY2FFO11FD013.protection.gbl (10.1.15.201) by BY2FFO11HUB025.protection.gbl (10.1.14.111) with Microsoft SMTP Server (TLS) id 15.0.620.12; Tue, 12 Feb 2013 19:26:01 +0000
Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD013.mail.protection.outlook.com (10.1.14.75) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Tue, 12 Feb 2013 19:26:01 +0000
Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.232]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Tue, 12 Feb 2013 19:25:33 +0000
From: Mike Jones 
To: Nat Sakimura , Justin Richer , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Registration: HAL _links structure and client self-URL
Thread-Index: AQHOCLBZ9TwcL9HNGkSDhglPftMUBph2SCeAgAARoYCAAA8pgIAADXiAgAAjZZA=
Date: Tue, 12 Feb 2013 19:25:33 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394367443A52@TK5EX14MBXC285.redmond.corp.microsoft.com>
References: <51195F3D.1050006@mitre.org> <222C28CB-7F6F-4BC3-8692-40404C2DC2D3@maymount.com> <511A50C7.8080102@mitre.org> 	<511A6C49.50801@mitre.org> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.33]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(377424002)(24454001)(189002)(199002)(15454002)(55885001)(479174001)(13464002)(51704002)(5343655001)(47446002)(77982001)(46102001)(80022001)(66066001)(47736001)(56776001)(74662001)(59766001)(54356001)(54316002)(49866001)(16406001)(56816002)(47776003)(44976002)(74502001)(20776003)(65816001)(63696002)(53806001)(46406002)(4396001)(15202345001)(79102001)(76482001)(23726001)(307094002)(50986001)(33656001)(47976001)(51856001)(50466001)(31966008)(5343635001)(55846006); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB025; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0755F54DD9
Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client	self-URL
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 19:26:04 -0000

Part of the REST/JSON philosophy is that interfaces should be as simple and=
 developer-friendly as possible.  XML was rejected by developers, in part, =
because of the self-describing nature of the structure, which required extr=
a syntax that was often not useful in practice.  Trying to re-impose that s=
tructure using extra JSON syntax conventions is just asking developers to h=
ave an allergic reaction to our specs upon encountering them.  The syntacti=
c complexity and *surprise factor* isn't worth the limited semantic benefit=
s of using "_links".

Since you bring up privacy policy and terms of service, I'll note that the =
OAuth Dynamic Registration spec already has these fields to address those:
	policy_url
	tos_url

Those have been working fine for OpenID Connect too.  There's no need to li=
kewise convolve them to add the extra syntax that you describe below.

(BTW, in a private thread, John Bradley pointed out that what the two of yo=
u talked about in person was actually the possibility of adding privacy pol=
icy and terms of service declarations at *discovery time*, rather than regi=
stration time.  That's a different topic, which we should discuss separatel=
y, if you want to pursue that.)

				Best wishes,
				-- Mike

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of N=
at Sakimura
Sent: Tuesday, February 12, 2013 9:11 AM
To: Justin Richer; oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client self-=
URL

Actually, if it is to return it in the HTTP header, then it should also use=
 the RFC5988 Web Linking format.
Now, that is nice to have, but for many JSON programmers, I agree that it w=
ould be a hassle to obtain the header and store them in addition to the JSO=
N. So, it is nicer to have it in JSON body.

Re: Is "_links.self.href" grossly complex over "registration_access_url"?

I do not think so. Accessing a flat top level parameter such as registratio=
n_access_url and _links.self.href does not make any difference from a clien=
t programmers point of view. That's a beauty of JSON. Both can be treated a=
s a parameter name. Doing a group operation on the links makes difference t=
hough: the structured one is easier since you can just operate on _links wh=
ile in case of the top level parameters, you have to have an explicit list =
of them and do the matches. (See below for the necessity for the grouping).

I and John discussed this for at least half an hour F2F last week, both tec=
hnically and from operation/legal point of view, for OpenID Connect Registr=
ation.
Similar points could be made to OAuth dyn reg.

Here is what we have discussed:

When dynamically registering the client to the server, the server probably =
needs to return the following:

  * terms-of-service (terms of service of the server to the client)
  * privacy-policy (privacy policy of the server to the client)

Both are defined in RFC5988/IANA Link Relations registry.

They should be returned together with

  * self.href

which is also defined in RFC5988/IANA Link Relations registry.

There are several ways to do it.

  * Return these using RFC5988 (HTTP Header)
  * Return these in entity body
      * Use HAL (or OAuth-meta)/JSON Schema
      * Use something else (e.g., a top level items)

Returning it in the entity body has several advantage over HTTP header:

  * They can be captured in one call;
  * They are protocol agnostic;

We determined that these advantages outweighs the disadvantage of creating =
a new standard.

The question becomes then whether to:

  * Use HAL (or OAuth-meta)/JSON Schema
  * Use something else (e.g., a top level items)

First, we have to consider what needs to be returned in the link/relationsh=
ip category. If it were just _links.self.href, then grouping probably does =
not make sense. However, since we have terms-of-service and privacy-policy =
as well already, it may well make sense.

Moreover, when we think of a multi-tenant authorization server that may wan=
t to use different OAuth authz and token endpoints for different tennants, =
it would be better to be able to return those in the registration response.=
 Then, it would make sense to register OAuth authz and token endpoints as r=
el type in the IANA registry (like Bill Mills is trying to
do) and use them in a uniform manner. Note: these per tenant endpoints may =
support different scopes etc. as well. Then, these has to be coupled with t=
he URIs. That is why all of RFC5988/HAL/JSON Schema uses href instead of ju=
st having the URL as the value of the parameter. The semantic relationship =
would often have an associated URI, and other parameters that goes with it.

e.g.:

{
    "_links": {
        "terms-of-service": {
            "href": "https: //server.example.com/tos"
        },
        "privacy-policy": {
            "href": "https: //server.example.com/pp"
        },
        "self": {
            "href": "https: //server.example.com/clients/1234",
            "authorize": "Bearer"
        },
        "oauth_authz": {
            "href": "https: //server.example.com/authz",
            "scopes": "openid profile email",
            "response_types": [
                "token id_token",
                "code id_token",
                "token",
                "code"
            ]
        },
        "oauth_token": {
            "href": "https: //server.example.com/token",
            "authorize": "Basic"
        }
    }
}

In short, there are bunch of link relations that needs to be returned with =
additional parameters.
Grouping them seems to make sense.

Considering all these, John and I came to the conclusion that the HAL type =
syntax would probably make more sense.
(Note: JSON Schema syntax does not make the parameter access as easy as HAL=
.)

In fact, Mike Kelly (the author of HAL) and I have just submit a new versio=
n of draft-sakimura-oauth-meta

   http://tools.ietf.org/html/draft-sakimura-oauth-meta-02

The proposal was discussed at IETF 85 OAuth WG and the chairs asked to subm=
it the draft.
The -00 appeared in December, and this -02 has some simplification and the =
addition of the "operations" inspired by
https://tools.ietf.org/html/draft-ietf-scim-api-00#section-3.5 .
It is arguably a subset of HAL plus some OAuth specifics.
I have not added Discovery response example, but adding them would makes ev=
en more sense, I think.

Cheers,

Nat

2013/2/13 Justin Richer 
>
> Agreed - I didn't think that header-only was the proposal, but let's be e=
xplicit about the returned body always containing the URL. The way I read t=
he 201 definition, it suggests (SHOULD) that you use the location header, b=
ut also says that the entity should refer to the new resource. It was my as=
sumption that the returned JSON would still have some form of client-entity=
 management URL (whether it's the HAL _links structure or registration_mana=
gement_url or something else is still up for debate).
>
>  -- Justin
>
>
>
> On 02/12/2013 10:28 AM, John Bradley wrote:
>
> Returning a location header in the 201 ids fine as long as we also have t=
he same info as a claim.
>
> I think most clients will want to process the JSON and store all the para=
meters together.  Making them fish out a header makes the W3C happy and is =
the correct thing to do but taking it from a claim is what developers are m=
ore comfortable with.
>
> John B.
>
> On 2013-02-12, at 11:25 AM, Justin Richer  wrote:
>
> I'd be fine with the return from a creation request being a 201 instead o=
f a 200.
>
>  -- Justin
>
> On 02/11/2013 06:33 PM, Richard Harrington wrote:
>
> Since the request is an HTTP POST and a resource is created (http://www.w=
3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5) the response should be an=
 HTTP 201 Created (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#s=
ec10.2.2) which is supposed to include the location of the newly created re=
source.
>
> This is a good pattern to follow since, as you say, it does provide flexi=
bility.
>
>
>
> On Feb 11, 2013, at 1:14 PM, Justin Richer  wrote:
>
> Draft -05 of OAuth Dynamic Client Registration [1] returns a URL pointer =
for the client to perform update and secret rotation actions. This function=
ality arose from discussions on the list about moving towards a more RESTfu=
l pattern, and Nat Sakimura proposed this approach in the OpenID Connect Wo=
rking Group. This URL may be distinct from the Client Registration Endpoint=
 URL, but draft -05 makes no promises as to its content, form, or structure=
, though it does contain implementor's notes on possible methods.
>
> Two questions arise from this change:
> - The semantics of returning the client manipulation URL
> - The syntax (derived from HAL for JSON [2], an individual I-D=20
> submission)
>
> On semantics:
>
> Pro:
> - The server has flexibility on how to define the "update" endpoint,=20
> sending all clients to one URL, sending different clients to different=20
> URLs, or sending clients to a URL with a baked-in query parameter
> - The client can take the URL as-is and use it for all management=20
> operations (ie, it doesn't have to generate or compose the URL based=20
> on component parts)
>
> Con:
> - The client must remember one more piece of information from the=20
> server at runtime if it wants to do manipulation and management of=20
> itself at the server (in addition to client_id, client_secret,=20
> registration_access_token, and others)
>
> Alternatives include specifying a URL pattern for the server to use and a=
ll clients to follow, specifying a query parameter for the update action, a=
nd specifying a separate endpoint entirely and using the presence of items =
such as client_id and the registration access token to differentiate the re=
quests. Note that *all* of these alternatives can be accommodated using the=
 semantics described above, with the same actions on the client's part.
>
>
> On syntax:
>
> Pro:
> - Follows the designs of RFC5988 for link relations
> - The HAL format is general, and allows for all kinds of other=20
> information to be placed inside the _links structure
> - Allows for full use of the JSON object to specify advanced=20
> operations on the returned endpoint if desired
>
> Con:
> - The rest of OAuth doesn't follow link relation guidelines (though=20
> it's been brought up)
> - The HAL format is general, and allows for all kinds of other=20
> information to be placed inside the _links structure
> - The HAL-JSON document is an expired individual I-D, and it's unclear=20
> what wider adoption looks like right now
>
> Alternatives include returning the URL as a separate data member (registr=
ation_update_url), using HTTP headers, or using JSON Schema.
>
> -- Justin
>
>
>
> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
> [2] http://tools.ietf.org/html/draft-kelly-json-hal-03
> _______________________________________________
> 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
>

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

From jricher@mitre.org  Tue Feb 12 11:33:35 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A85021F90B5 for ; Tue, 12 Feb 2013 11:33:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.573
X-Spam-Level: 
X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.025,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rt0jcpnXVSJ for ; Tue, 12 Feb 2013 11:33:34 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id E7AC821F903A for ; Tue, 12 Feb 2013 11:33:33 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 35D9D5312EFC; Tue, 12 Feb 2013 14:33:30 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id DB1F21F04BB; Tue, 12 Feb 2013 14:33:29 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 12 Feb 2013 14:33:29 -0500
Message-ID: <511A98DE.4030507@mitre.org>
Date: Tue, 12 Feb 2013 14:32:46 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Mike Jones 
References: <51195F3B.1010701@mitre.org> <4E1F6AAD24975D4BA5B168042967394367443A16@TK5EX14MBXC285.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367443A16@TK5EX14MBXC285.redmond.corp.microsoft.com>
Content-Type: multipart/alternative; boundary="------------060906090100010907020602"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: JSON Encoded Input
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 19:33:35 -0000

--------------060906090100010907020602
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Thanks for forwarding that, Mike. I'll paste in my response to Nat's 
concern here as well:

    It's an increasingly well known pattern that has reasonable support
    on the server side. For PHP, I was able to find the above example
    via the top hit on Stack Overflow. In Ruby, it's a matter of
    something like:

    JSON.parse(request.body.read)

    depending on the web app framework. On Java/Spring, it's a matter of
    injecting the entity body as a string and handing it to a parser
    (Gson in this case):

    public String doApi(@RequestBody String jsonString) { JsonObject
    json = new JsonParser().parse(jsonString).getAsJsonObject();

    It's a similar read/parse setup in Node.js as well.

    It's true that in all of these cases you don't get to make use of
    the routing or data binding facilities (though in Spring you can do
    that for simpler domain objects using a ModelBinding), so you don't
    get niceities like the $_POST array in PHP handed to you. This is
    why I don't think it's a good idea at all to switch functionality
    based on the contents of the JSON object. It should be a domain
    object only, which is what it would be in this case.

    I think that the positives of using JSON from the client's
    perspective and the overall protocol design far outweigh the
    slightly increased implementation cost at the server.

  -- Justin

On 02/12/2013 02:11 PM, Mike Jones wrote:
>
> FYI, this issue is also being discussed as an OpenID Connect issue at 
> https://bitbucket.org/openid/connect/issue/747. I think that Nat's 
> recent comment there bears repeating on this list:
>
> Nat Sakimura:
>
> Not so sure. For example, PHP cannot get the JSON object form 
> application/json POST in $_POST.
>
> It is OK to have a parameter like "request" that holds JSON. Then, you 
> can get to it from $_POST['request']. However, if you POST the JSON as 
> the POST body, then you would have to call a low level function in the 
> form of:
>
> ```
>
> #!php
>
> $file = file_get_contents('php://input'); $x = json_decode($file); ```
>
> Not that it is harder, but it is much less known. Many PHP programmers 
> will certainly goes "???".
>
> We need to check what would be the cases for other scripting languages 
> before making the final decision.
>
> -- Mike
>
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf 
> Of Justin Richer
> Sent: Monday, February 11, 2013 1:15 PM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Registration: JSON Encoded Input
>
> Draft -05 of OAuth Dynamic Client Registration [1] switched from a 
> form-encoded input that had been used by drafts -01 through -04 to a 
> JSON encoded input that was used originally in -00. Note that all 
> versions keep JSON-encoded output from all operations.
>
> Pro:
>
>   - JSON gives us a rich data structure so that things such as lists, 
> numbers, nulls, and objects can be represented natively
>
>   - Allows for parallelism between the input to the endpoint and 
> output from the endpoint, reducing possible translation errors between 
> the two
>
>   - JSON specifies UTF8 encoding for all strings, forms may have many 
> different encodings
>
>   - JSON has minimal character escaping required for most strings, 
> forms require escaping for common characters such as space, slash, 
> comma, etc.
>
> Con:
>
>   - the rest of OAuth is form-in/JSON-out
>
>   - nothing else in OAuth requires the Client to create a JSON object, 
> merely to parse one
>
>   - form-in/JSON-out is a very widely established pattern on the web today
>
>   - Client information (client_name, client_id, etc.) is conflated 
> with access information (registration_access_token, _links, 
> expires_at, etc.) in root level of the same JSON object, leaving the 
> client to decide what needs to (can?) be sent back to the server for 
> update operations.
>
> Alternatives include any number of data encoding schemes, including 
> form (like the old drafts), XML, ASN.1, etc.
>
>   -- Justin
>
> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org 
>
> https://www.ietf.org/mailman/listinfo/oauth
>

--------------060906090100010907020602
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

    Thanks for forwarding that, Mike. I'll paste in my response to Nat's
    concern here as well:

    It's an increasingly well known pattern that has
      reasonable support on the server side. For PHP, I was able to find
      the above example via the top hit on Stack Overflow. In Ruby, it's
      a matter of something like:

      JSON.parse(request.body.read)

      depending on the web app framework. On Java/Spring, it's a matter
      of injecting the entity body as a string and handing it to a
      parser (Gson in this case):

      public String doApi(@RequestBody String jsonString) { JsonObject
      json = new JsonParser().parse(jsonString).getAsJsonObject();

      It's a similar read/parse setup in Node.js as well.

      It's true that in all of these cases you don't get to make use of
      the routing or data binding facilities (though in Spring you can
      do that for simpler domain objects using a ModelBinding), so you
      don't get niceities like the $_POST array in PHP handed to you.
      This is why I don't think it's a good idea at all to switch
      functionality based on the contents of the JSON object. It should
      be a domain object only, which is what it would be in this case.

      I think that the positives of using JSON from the client's
      perspective and the overall protocol design far outweigh the
      slightly increased implementation cost at the server.

     -- Justin

    On 02/12/2013 02:11 PM, Mike Jones
      wrote:

        FYI, this issue is also being discussed
          as an OpenID Connect issue at
          https://bitbucket.org/openid/connect/issue/747. 
          I think that Nat's recent comment there bears repeating on
          this list:

        Nat Sakimura:

        Not so sure.
          For example, PHP cannot get the JSON object form
          application/json POST in $_POST.

        It is OK to
          have a parameter like "request" that holds JSON. Then, you can
          get to it from $_POST['request']. However, if you POST the
          JSON as the POST body, then you would have to call a low level
          function in the form of: 

        ```
        #!php

        $file =
          file_get_contents('php://input'); $x = json_decode($file); ```

        Not that it is
          harder, but it is much less known. Many PHP programmers will
          certainly goes "???".

        We need to
          check what would be the cases for other scripting languages
          before making the final decision.

          -- Mike

        -----Original Message-----

          From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]
          On Behalf Of Justin Richer

          Sent: Monday, February 11, 2013 1:15 PM

          To: oauth@ietf.org

          Subject: [OAUTH-WG] Registration: JSON Encoded Input

        Draft -05 of OAuth Dynamic Client
          Registration [1] switched from a form-encoded input that had
          been used by drafts -01 through -04 to a JSON encoded input
          that was used originally in -00. Note that all versions keep
          JSON-encoded output from all operations.

        Pro:
          - JSON gives us a rich data structure
          so that things such as lists, numbers, nulls, and objects can
          be represented natively
          - Allows for parallelism between the
          input to the endpoint and output from the endpoint, reducing
          possible translation errors between the two
          - JSON specifies UTF8 encoding for all
          strings, forms may have many different encodings
          - JSON has minimal character escaping
          required for most strings, forms require escaping for common
          characters such as space, slash, comma, etc.

        Con:
          - the rest of OAuth is
          form-in/JSON-out
          - nothing else in OAuth requires the
          Client to create a JSON object, merely to parse one
          - form-in/JSON-out is a very widely
          established pattern on the web today
          - Client information (client_name,
          client_id, etc.) is conflated with access information
          (registration_access_token, _links, expires_at, etc.) in root
          level of the same JSON object, leaving the client to decide
          what needs to (can?) be sent back to the server for update
          operations.

        Alternatives include any number of data
          encoding schemes, including form (like the old drafts), XML,
          ASN.1, etc.

          -- Justin

        [1] 
            http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
        _______________________________________________
        OAuth mailing list
        OAuth@ietf.org
        https://www.ietf.org/mailman/listinfo/oauth

--------------060906090100010907020602--

From ve7jtb@ve7jtb.com  Tue Feb 12 11:45:09 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6903921F8D74 for ; Tue, 12 Feb 2013 11:45:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.253
X-Spam-Level: 
X-Spam-Status: No, score=-3.253 tagged_above=-999 required=5 tests=[AWL=0.345,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IESbOrnYjZVM for ; Tue, 12 Feb 2013 11:45:07 -0800 (PST)
Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by ietfa.amsl.com (Postfix) with ESMTP id B26D321F8D68 for ; Tue, 12 Feb 2013 11:45:04 -0800 (PST)
Received: by mail-qe0-f47.google.com with SMTP id 2so205991qea.20 for ; Tue, 12 Feb 2013 11:45:04 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=6fN+axhngRRsKaEoqodHQXtdIF3t9rMvyRQVRWsgino=; b=UbkiYLwJXCEfENdlbxCM5UMm6JkpdBiq1CR6sTsaOvFderJWbxCpmh8CW1AZBqO4Ty yt1RmMenjtBExFs7rZdM3KfIGYVPh6EMtsK6nHxkQi2KuVnNw0+e6eyctUNG6qKr+fos oJCSQ4GyfxAoF9ZDpQSJfTIJfrrdfQfDPMdht+1CZfaR+IEfB6B9TgxAOBQN2mKlhDTi OHG4eaiPzRney9Fddc3o5wwhYrZeWm4c2fvzUt6IGdQXRq9y3oHbDVSpfzOJ/VUmNUeq RQDjdsE9Kr8MmPKXyPmy13RrKL8hG1DiK1PHNaIj7yAQzbP49x84GE2BIYpXB9Uk94yr 8tHQ==
X-Received: by 10.49.25.102 with SMTP id b6mr8307203qeg.27.1360698303882; Tue, 12 Feb 2013 11:45:03 -0800 (PST)
Received: from [192.168.1.213] (190-20-23-212.baf.movistar.cl. [190.20.23.212]) by mx.google.com with ESMTPS id gr8sm626136qab.9.2013.02.12.11.44.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 11:45:02 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_CE1FBB9C-CBB0-4DE8-8DBB-46EB5E727B79"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <511A98DE.4030507@mitre.org>
Date: Tue, 12 Feb 2013 16:44:56 -0300
Message-Id: <9309CDB3-8AEE-428D-A7F0-5DAC45EFD44C@ve7jtb.com>
References: <51195F3B.1010701@mitre.org> <4E1F6AAD24975D4BA5B168042967394367443A16@TK5EX14MBXC285.redmond.corp.microsoft.com> <511A98DE.4030507@mitre.org>
To: Justin Richer 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQlftpyFgvYE7Kw7iz5SpuyNGfQ7KP3CKUnz+c/ABr1XFXH+Oafq7xhO2i0N00zgVatGr4rM
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: JSON Encoded Input
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 19:45:09 -0000

--Apple-Mail=_CE1FBB9C-CBB0-4DE8-8DBB-46EB5E727B79
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Nat and I hashed out the pro's and cons of JSON requests. =20

If we POST or PUT a JSON object we need to be specific as there rare =
several ways to do it that may work better or worse depending on the =
receiver.
This needs to be looked over and one picked.

In the other thread about the server returning the update URI and being =
able to encode the client in that if it needs to takes care of Servers =
that need that info in query parameters or the path to do the routing.

The use of structure can be used to enhance readability and parsing of =
the input, and output.

However we need to temper our urge to apply structure to everything. =20

IT needs to be applied carefully otherwise we start looking like =
crazies.

If we do it cautiously I am in favour of JSON as input.

John B.

On 2013-02-12, at 4:32 PM, Justin Richer  wrote:

> Thanks for forwarding that, Mike. I'll paste in my response to Nat's =
concern here as well:
> It's an increasingly well known pattern that has reasonable support on =
the server side. For PHP, I was able to find the above example via the =
top hit on Stack Overflow. In Ruby, it's a matter of something like:
>=20
> JSON.parse(request.body.read)
>=20
> depending on the web app framework. On Java/Spring, it's a matter of =
injecting the entity body as a string and handing it to a parser (Gson =
in this case):
>=20
> public String doApi(@RequestBody String jsonString) { JsonObject json =
=3D new JsonParser().parse(jsonString).getAsJsonObject();
>=20
> It's a similar read/parse setup in Node.js as well.
>=20
> It's true that in all of these cases you don't get to make use of the =
routing or data binding facilities (though in Spring you can do that for =
simpler domain objects using a ModelBinding), so you don't get niceities =
like the $_POST array in PHP handed to you. This is why I don't think =
it's a good idea at all to switch functionality based on the contents of =
the JSON object. It should be a domain object only, which is what it =
would be in this case.
>=20
> I think that the positives of using JSON from the client's perspective =
and the overall protocol design far outweigh the slightly increased =
implementation cost at the server.
>=20
>=20
>  -- Justin
>=20
> On 02/12/2013 02:11 PM, Mike Jones wrote:
>> FYI, this issue is also being discussed as an OpenID Connect issue at =
https://bitbucket.org/openid/connect/issue/747.  I think that Nat's =
recent comment there bears repeating on this list:
>> =20
>> Nat Sakimura:
>> =20
>> Not so sure. For example, PHP cannot get the JSON object form =
application/json POST in $_POST.
>> =20
>> It is OK to have a parameter like "request" that holds JSON. Then, =
you can get to it from $_POST['request']. However, if you POST the JSON =
as the POST body, then you would have to call a low level function in =
the form of:
>> =20
>> =20
>> ```
>> #!php
>> =20
>> $file =3D file_get_contents('php://input'); $x =3D =
json_decode($file); ```
>> =20
>> Not that it is harder, but it is much less known. Many PHP =
programmers will certainly goes "???".
>> =20
>> We need to check what would be the cases for other scripting =
languages before making the final decision.
>> =20
>>                                                             -- Mike
>> =20
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf Of Justin Richer
>> Sent: Monday, February 11, 2013 1:15 PM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Registration: JSON Encoded Input
>> =20
>> Draft -05 of OAuth Dynamic Client Registration [1] switched from a =
form-encoded input that had been used by drafts -01 through -04 to a =
JSON encoded input that was used originally in -00. Note that all =
versions keep JSON-encoded output from all operations.
>> =20
>> Pro:
>>   - JSON gives us a rich data structure so that things such as lists, =
numbers, nulls, and objects can be represented natively
>>   - Allows for parallelism between the input to the endpoint and =
output from the endpoint, reducing possible translation errors between =
the two
>>   - JSON specifies UTF8 encoding for all strings, forms may have many =
different encodings
>>   - JSON has minimal character escaping required for most strings, =
forms require escaping for common characters such as space, slash, =
comma, etc.
>> =20
>> Con:
>>   - the rest of OAuth is form-in/JSON-out
>>   - nothing else in OAuth requires the Client to create a JSON =
object, merely to parse one
>>   - form-in/JSON-out is a very widely established pattern on the web =
today
>>   - Client information (client_name, client_id, etc.) is conflated =
with access information (registration_access_token, _links, expires_at, =
etc.) in root level of the same JSON object, leaving the client to =
decide what needs to (can?) be sent back to the server for update =
operations.
>> =20
>> =20
>> Alternatives include any number of data encoding schemes, including =
form (like the old drafts), XML, ASN.1, etc.
>> =20
>> =20
>>   -- Justin
>> =20
>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail=_CE1FBB9C-CBB0-4DE8-8DBB-46EB5E727B79
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

Nat =
and I hashed out the pro's and cons of JSON requests. =

If we POST or PUT a JSON object we need to be =
specific as there rare several ways to do it that may work better or =
worse depending on the receiver.
This needs to be looked over =
and one picked.

In the other thread about the =
server returning the update URI and being able to encode the client in =
that if it needs to takes care of Servers that need that info in query =
parameters or the path to do the routing.

The =
use of structure can be used to enhance readability and parsing of the =
input, and output.

However we need to temper =
our urge to apply structure to everything. =

IT needs to be applied carefully =
otherwise we start looking like crazies.

If we =
do it cautiously I am in favour of JSON as =
input.

John B.

On =
2013-02-12, at 4:32 PM, Justin Richer <jricher@mitre.org> =
wrote:

 =20

 =20

    Thanks for forwarding that, Mike. I'll paste in my response to Nat's
    concern here as well:

    It's an increasingly well known pattern that has
      reasonable support on the server side. For PHP, I was able to find
      the above example via the top hit on Stack Overflow. In Ruby, it's
      a matter of something like:

      JSON.parse(request.body.read)

      depending on the web app framework. On Java/Spring, it's a matter
      of injecting the entity body as a string and handing it to a
      parser (Gson in this case):

      public String doApi(@RequestBody String jsonString) { JsonObject
      json =3D new JsonParser().parse(jsonString).getAsJsonObject();

      It's a similar read/parse setup in Node.js as well.

      It's true that in all of these cases you don't get to make use of
      the routing or data binding facilities (though in Spring you can
      do that for simpler domain objects using a ModelBinding), so you
      don't get niceities like the $_POST array in PHP handed to you.
      This is why I don't think it's a good idea at all to switch
      functionality based on the contents of the JSON object. It should
      be a domain object only, which is what it would be in this =
case.

      I think that the positives of using JSON from the client's
      perspective and the overall protocol design far outweigh the
      slightly increased implementation cost at the server.

     -- Justin

    On 02/12/2013 02:11 PM, Mike Jones
      wrote:

      FYI, this =
issue is also being discussed
          as an OpenID Connect issue at
          https://bitbucket.=
org/openid/connect/issue/747. 
          I think that Nat's recent comment there bears repeating on
          this list:

Nat Sakimura:

Not so sure.
          For example, PHP cannot get the JSON object form
          application/json POST in $_POST.

It is OK to
          have a parameter like "request" that holds JSON. Then, you can
          get to it from $_POST['request']. However, if you POST the
          JSON as the POST body, then you would have to call a low level
          function in the form of: 

```
#!php

$file =3D
          file_get_contents('php://input'); =
$x =3D json_decode($file); ```

Not that it is
          harder, but it is much less known. Many PHP programmers will
          certainly goes "???".

We need to
          check what would be the cases for other scripting languages
          before making the final decision.

        &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;            =
; 
          -- Mike

-----Original Message-----

          From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]
          On Behalf Of Justin Richer

          Sent: Monday, February 11, 2013 1:15 PM

          To: oauth@ietf.org

          Subject: [OAUTH-WG] Registration: JSON Encoded Input

Draft -05 of OAuth Dynamic Client
          Registration [1] switched from a form-encoded input that had
          been used by drafts -01 through -04 to a JSON encoded input
          that was used originally in -00. Note that all versions keep
          JSON-encoded output from all operations.

Pro:
 =
 - JSON gives us a rich data structure
          so that things such as lists, numbers, nulls, and objects can
          be represented natively
  - Allows for parallelism between the
          input to the endpoint and output from the endpoint, reducing
          possible translation errors between the two
  - JSON specifies UTF8 encoding for all
          strings, forms may have many different =
encodings
  - JSON has =
minimal character escaping
          required for most strings, forms require escaping for common
          characters such as space, slash, comma, etc.

Con:
 =
 - the rest of OAuth is
          form-in/JSON-out
  =
- nothing else in OAuth requires the
          Client to create a JSON object, merely to parse =
one
  - form-in/JSON-out is =
a very widely
          established pattern on the web today
  - Client information (client_name,
          client_id, etc.) is conflated with access information
          (registration_access_token, _links, expires_at, etc.) in root
          level of the same JSON object, leaving the client to decide
          what needs to (can?) be sent back to the server for update
          operations.

Alternatives include any number of data
          encoding schemes, including form (like the old drafts), XML,
          ASN.1, etc.

  -- Justin

[1] =

            http://tools.ietf.org/html=
/draft-ietf-oauth-dyn-reg-05
_______________________________________________
OAuth mailing list
OAuth@ietf.org<=
o:p>
https://www.ietf.org/mailm=
an/listinfo/oauth

_______________________________________________
OAuth mailing =
list
OAuth@ietf.org
https://www.ietf.org/=
mailman/listinfo/oauth

=

--Apple-Mail=_CE1FBB9C-CBB0-4DE8-8DBB-46EB5E727B79--

From twbray@google.com  Tue Feb 12 11:49:07 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1521A21F8AD1 for ; Tue, 12 Feb 2013 11:49:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.699
X-Spam-Level: 
X-Spam-Status: No, score=-101.699 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeCxDO2bRnYx for ; Tue, 12 Feb 2013 11:49:05 -0800 (PST)
Received: from mail-ie0-x22d.google.com (ie-in-x022d.1e100.net [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 79CEC21F871C for ; Tue, 12 Feb 2013 11:49:05 -0800 (PST)
Received: by mail-ie0-f173.google.com with SMTP id 9so637801iec.32 for ; Tue, 12 Feb 2013 11:49:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=TcQMQd36ouUkpvKxW8dAi3BlQKE2sGJbXg4+8oEONDA=; b=kc6DV4y0VcnqJ1D7L0QwJcIvxvHaKncN8PFx8quFwaSz3Dv2I5Giy3gjozykUSTLum P6ISQiYKS68gcFQZlp+gwhF8PGlCbrdV9SetkQ/47B5DYEgGDUKzBnGl7pprk5Y2VVl6 GPzEBkt8X5nwWpfDYT5GK3NlWoADB/DmzHKRUwppQ0jq7wXFR3Lb0A8Suex8slQcdOh9 1+WC0R8BMErQdNYFG151pBbltH+XsByd2jDayT2F6S/YWO2vyDgdlM9SBJL7govRFzBG f8QzIX4qROuuPwoQp9l4PH5SPGAxaecu6XIp7uOU0ccTDIS1uf2NCA7zusWxYDGBgIt4 FNmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=TcQMQd36ouUkpvKxW8dAi3BlQKE2sGJbXg4+8oEONDA=; b=fhIK73zH4KnC0epZ6G2B5KQe0snUThJ9FYiBU4g0paJuX2h+kfWFtkLlvSTEMJbLbu R4ylwaLx5ihi3BuFxCSPJtIN/MLACNDlHnhau36afTWOEMjm4VxFjfjRoqpxfBTOg+hV j08p1S8Fle1eI2rZ1fPJqyP5j+rSGuAy9qx9zsOP/MXwCY+pzYSPmDd8rNYAHoZjnO0A VKDMnumTirQ87/6Pze62EmdvV36ylEN8MtF0/ql8bzHxXpXRUcm8ntxKKL/snw4C9pBs Jr1zFx8I0haWgd8LrzuNMthj0gPZZqs1Iz3TwACSug6/F9/We293rTmBUC0+r4KaJyIy llPw==
X-Received: by 10.42.180.65 with SMTP id bt1mr25339617icb.41.1360698544933; Tue, 12 Feb 2013 11:49:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.25.17 with HTTP; Tue, 12 Feb 2013 11:48:34 -0800 (PST)
In-Reply-To: <9309CDB3-8AEE-428D-A7F0-5DAC45EFD44C@ve7jtb.com>
References: <51195F3B.1010701@mitre.org> <4E1F6AAD24975D4BA5B168042967394367443A16@TK5EX14MBXC285.redmond.corp.microsoft.com> <511A98DE.4030507@mitre.org> <9309CDB3-8AEE-428D-A7F0-5DAC45EFD44C@ve7jtb.com>
From: Tim Bray 
Date: Tue, 12 Feb 2013 11:48:34 -0800
Message-ID: 
To: John Bradley 
Content-Type: multipart/alternative; boundary=90e6ba6e81d86acb7104d58c51e0
X-Gm-Message-State: ALoCoQmffeWpC0Fl5hCL23ga9HBNf29kmaCrFcmjzpfLYFPHrGohcOOxC243EOthSOYIO4rZYIdgpGrnz6rm9jVmogWR5FSLVCbh2HAfadgjAIIDGC4YR9nGMHhmlRHE5+OK66Ju9owtFxtaaJ7zd02Njc1cEFQ8dsAQ1bjfKlSlVy2GprtC3y7iFfAAiZlEHKxPR3wXuhhz
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: JSON Encoded Input
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 19:49:07 -0000

--90e6ba6e81d86acb7104d58c51e0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 12, 2013 at 11:44 AM, John Bradley  wrote:

> Nat and I hashed out the pro's and cons of JSON requests.
>
> If we POST or PUT a JSON object we need to be specific as there rare
> several ways to do it that may work better or worse depending on the
> receiver.
> This needs to be looked over and one picked.
>

Hm?  Not following on =E2=80=9Cseveral ways=E2=80=9D, I=E2=80=99d have thou=
ght that POSTing JSON is
just POSTing JSON, must be missing something. -T

>
> In the other thread about the server returning the update URI and being
> able to encode the client in that if it needs to takes care of Servers th=
at
> need that info in query parameters or the path to do the routing.
>
> The use of structure can be used to enhance readability and parsing of th=
e
> input, and output.
>
> However we need to temper our urge to apply structure to everything.
>
> IT needs to be applied carefully otherwise we start looking like crazies.
>
> If we do it cautiously I am in favour of JSON as input.
>
> John B.
>
> On 2013-02-12, at 4:32 PM, Justin Richer  wrote:
>
>  Thanks for forwarding that, Mike. I'll paste in my response to Nat's
> concern here as well:
>
> It's an increasingly well known pattern that has reasonable support on th=
e
> server side. For PHP, I was able to find the above example via the top hi=
t
> on Stack Overflow. In Ruby, it's a matter of something like:
>
> JSON.parse(request.body.read)
>
> depending on the web app framework. On Java/Spring, it's a matter of
> injecting the entity body as a string and handing it to a parser (Gson in
> this case):
>
> public String doApi(@RequestBody String jsonString) { JsonObject json =3D
> new JsonParser().parse(jsonString).getAsJsonObject();
>
> It's a similar read/parse setup in Node.js as well.
>
> It's true that in all of these cases you don't get to make use of the
> routing or data binding facilities (though in Spring you can do that for
> simpler domain objects using a ModelBinding), so you don't get niceities
> like the $_POST array in PHP handed to you. This is why I don't think it'=
s
> a good idea at all to switch functionality based on the contents of the
> JSON object. It should be a domain object only, which is what it would be
> in this case.
>
> I think that the positives of using JSON from the client's perspective an=
d
> the overall protocol design far outweigh the slightly increased
> implementation cost at the server.
>
>
>
>  -- Justin
>
> On 02/12/2013 02:11 PM, Mike Jones wrote:
>
> FYI, this issue is also being discussed as an OpenID Connect issue at
> https://bitbucket.org/openid/connect/issue/747.  I think that Nat's
> recent comment there bears repeating on this list:****
>
> ** **
>
> Nat Sakimura:****
>
> ** **
>
> Not so sure. For example, PHP cannot get the JSON object form
> application/json POST in $_POST. ****
>
> ** **
>
> It is OK to have a parameter like "request" that holds JSON. Then, you ca=
n
> get to it from $_POST['request']. However, if you POST the JSON as the PO=
ST
> body, then you would have to call a low level function in the form of: **=
*
> *
>
> ** **
>
> ** **
>
> ```****
>
> #!php****
>
> ** **
>
> $file =3D file_get_contents('php://input'); $x =3D json_decode($file); ``=
`****
>
> ** **
>
> Not that it is harder, but it is much less known. Many PHP programmers
> will certainly goes "???". ****
>
> ** **
>
> We need to check what would be the cases for other scripting languages
> before making the final decision.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]
> On Behalf Of Justin Richer
> Sent: Monday, February 11, 2013 1:15 PM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Registration: JSON Encoded Input
>
> ** **
>
> Draft -05 of OAuth Dynamic Client Registration [1] switched from a
> form-encoded input that had been used by drafts -01 through -04 to a JSON
> encoded input that was used originally in -00. Note that all versions kee=
p
> JSON-encoded output from all operations.****
>
> ** **
>
> Pro:****
>
>   - JSON gives us a rich data structure so that things such as lists,
> numbers, nulls, and objects can be represented natively****
>
>   - Allows for parallelism between the input to the endpoint and output
> from the endpoint, reducing possible translation errors between the two**=
*
> *
>
>   - JSON specifies UTF8 encoding for all strings, forms may have many
> different encodings****
>
>   - JSON has minimal character escaping required for most strings, forms
> require escaping for common characters such as space, slash, comma, etc.*=
*
> **
>
> ** **
>
> Con:****
>
>   - the rest of OAuth is form-in/JSON-out****
>
>   - nothing else in OAuth requires the Client to create a JSON object,
> merely to parse one****
>
>   - form-in/JSON-out is a very widely established pattern on the web toda=
y
> ****
>
>   - Client information (client_name, client_id, etc.) is conflated with
> access information (registration_access_token, _links, expires_at, etc.) =
in
> root level of the same JSON object, leaving the client to decide what nee=
ds
> to (can?) be sent back to the server for update operations.****
>
> ** **
>
> ** **
>
> Alternatives include any number of data encoding schemes, including form
> (like the old drafts), XML, ASN.1, etc.****
>
> ** **
>
> ** **
>
>   -- Justin****
>
> ** **
>
> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05****
>
> _______________________________________________****
>
> 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
>
>

--90e6ba6e81d86acb7104d58c51e0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 12, 2013 at 11:44 AM, John B=
radley <ve7jtb@ve7jtb.com> wrote:

Nat and I hashed out the pro's and =
cons of JSON requests. =C2=A0
If we POST or PUT a JSON o=
bject we need to be specific as there rare several ways to do it that may w=
ork better or worse depending on the receiver.

This needs to be looked over and one picked.<=
div>
Hm? =C2=A0Not following on =E2=80=9Cseveral ways=E2=80=
=9D, I=E2=80=99d have thought that POSTing JSON is just POSTing JSON, must =
be missing something. -T

=C2=A0

In the other thread about the server returning=
 the update URI and being able to encode the client in that if it needs to =
takes care of Servers that need that info in query parameters or the path t=
o do the routing.

The use of structure can be used to enhance readability=
 and parsing of the input, and output.

However we =
need to temper our urge to apply structure to everything. =C2=A0

IT needs to be applied carefully otherwise we start looking like=
 crazies.

If we do it cautiously I am in favour of=
 JSON as input.

John B.

On 2013-02-12, at 4:32 PM, Justin Richer <jricher@mitre.org> wrote=
:

 =20
   =20
 =20

    Thanks for forwarding that, Mike. I'll paste in my response to Nat&=
#39;s
    concern here as well:

    It's an increasingly well known pattern that has
      reasonable support on the server side. For PHP, I was able to find
      the above example via the top hit on Stack Overflow. In Ruby, it'=
s
      a matter of something like:

      JSON.parse(request.body.read)

      depending on the web app framework. On Java/Spring, it's a matter
      of injecting the entity body as a string and handing it to a
      parser (Gson in this case):

      public String doApi(@RequestBody String jsonString) { JsonObject
      json =3D new JsonParser().parse(jsonString).getAsJsonObject();

      It's a similar read/parse setup in Node.js as well.

      It's true that in all of these cases you don't get to make us=
e of
      the routing or data binding facilities (though in Spring you can
      do that for simpler domain objects using a ModelBinding), so you
      don't get niceities like the $_POST array in PHP handed to you.
      This is why I don't think it's a good idea at all to switch
      functionality based on the contents of the JSON object. It should
      be a domain object only, which is what it would be in this case.

      I think that the positives of using JSON from the client's
      perspective and the overall protocol design far outweigh the
      slightly increased implementation cost at the server.

    =C2=A0-- Justin

    On 02/12/2013 02:11 PM, Mike Jones
      wrote:

     =20
     =20
     =20
      FYI, this issue is also being discussed
          as an OpenID Connect issue at
          https://bitbucket.org/openid/connect/issue/747.=C2=A0
          I think that Nat's recent comment there bears repeating on
          this list:
=C2=A0
Nat Sakimura:
=C2=A0
Not so sure.
          For example, PHP cannot get the JSON object form
          application/json POST in $_POST.

=C2=A0<=
/u>
It is OK to
          have a parameter like "request" that holds JSON. Then, =
you can
          get to it from $_POST['request']. However, if you POST th=
e
          JSON as the POST body, then you would have to call a low level
          function in the form of: 
=C2=A0
=C2=A0=
```

#!php
=C2=A0
$file =3D
          file_get_contents('php://input'); $x =3D json_deco=
de($file); ```
=C2=A0=
Not that it is
          harder, but it is much less known. Many PHP programmers will
          certainly goes "???".

=C2=A0<=
/u>
We need to
          check what would be the cases for other scripting languages
          before making the final decision.
=C2=
=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
          -- Mike
=C2=A0
-----Origi=
nal Message-----

          From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]
          On Behalf Of Justin Richer

          Sent: Monday, February 11, 2013 1:15 PM

          To: oauth@iet=
f.org

          Subject: [OAUTH-WG] Registration: JSON Encoded Input
=C2=A0
Draft -05 of OAuth Dynamic Client
          Registration [1] switched from a form-encoded input that had
          been used by drafts -01 through -04 to a JSON encoded input
          that was used originally in -00. Note that all versions keep
          JSON-encoded output from all operations.
<=
/u>=C2=A0
Pro:
=C2=A0 - JSON gives us a ri=
ch data structure
          so that things such as lists, numbers, nulls, and objects can
          be represented natively
=C2=A0 - Allows for p=
arallelism between the
          input to the endpoint and output from the endpoint, reducing
          possible translation errors between the two
=
=C2=A0 - JSON specifies UTF8 encoding for all
          strings, forms may have many different encodings
=C2=A0 - JSON has minimal character escaping
          required for most strings, forms require escaping for common
          characters such as space, slash, comma, etc.
=
=C2=A0
Con:
=C2=A0 - the rest of OA=
uth is
          form-in/JSON-out
=C2=A0 - nothing else in OAu=
th requires the
          Client to create a JSON object, merely to parse one=
=C2=A0 - form-in/JSON-out is a very widely
          established pattern on the web today
=C2=A0 -=
 Client information (client_name,
          client_id, etc.) is conflated with access information
          (registration_access_token, _links, expires_at, etc.) in root
          level of the same JSON object, leaving the client to decide
          what needs to (can?) be sent back to the server for update
          operations.
=C2=A0
=C2=A0
Alternatives include any number of data
          encoding schemes, including form (like the old drafts), XML,
          ASN.1, etc.
=C2=A0
=C2=A0
=C2=A0 -- Justin
=C2=A0<=
/u>
[1] 
            http://to=
ols.ietf.org/html/draft-ietf-oauth-dyn-reg-05
<=
p>_______________________________________________
OAuth=
 mailing list

OAuth@ietf.org
https://www.ietf.=
org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
http=
s://www.ietf.org/mailman/listinfo/oauth

________________________=
_______________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

--90e6ba6e81d86acb7104d58c51e0--

From ve7jtb@ve7jtb.com  Tue Feb 12 11:53:07 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E89021F8DC2 for ; Tue, 12 Feb 2013 11:53:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.974
X-Spam-Level: 
X-Spam-Status: No, score=-2.974 tagged_above=-999 required=5 tests=[AWL=0.025,  BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngpcRYH+p+fF for ; Tue, 12 Feb 2013 11:53:05 -0800 (PST)
Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) by ietfa.amsl.com (Postfix) with ESMTP id A17BB21F8DBF for ; Tue, 12 Feb 2013 11:52:58 -0800 (PST)
Received: by mail-qe0-f46.google.com with SMTP id 1so213904qec.33 for ; Tue, 12 Feb 2013 11:52:58 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=JObg2yzsGPpwUYyT2NZGSCOk376NmadiXyGvFyoSX38=; b=iHedmIq2nHfyQyvzb2CqdaqR/LL4ne0gYtNKNdoCIbX+WYU8IC122AK1krLRifjU1+ o/zgSIB0BoRnUDDrecnO5TXI4k0eFvkhvV+gbAB+uf2bjTJrhGsaIbkTYOY+Tlbo5DvM c1RH/2+LVHlCTLedYA8y3q6mgqXqlGq8Oqd6aMfAV3UT3jArLR0EMv3Fj5w+92ULNVxd hLlzIjIcrIdlJpXV7UhHO3KW366xTgh2mUlFRr+hRRIVFKmgx0LAMnTd7uhhvv9+tx6/ j+Kc45gZBZr3bCJ9ilSDfjXI+/QQKwDTB1PXTVjKCGNP/BDj5raINADDvEZPt6ByPKzd 8iqA==
X-Received: by 10.224.177.6 with SMTP id bg6mr7410381qab.78.1360698777873; Tue, 12 Feb 2013 11:52:57 -0800 (PST)
Received: from [192.168.1.213] (190-20-23-212.baf.movistar.cl. [190.20.23.212]) by mx.google.com with ESMTPS id df6sm16781661qab.6.2013.02.12.11.52.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 11:52:56 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367443A52@TK5EX14MBXC285.redmond.corp.microsoft.com>
Date: Tue, 12 Feb 2013 16:52:48 -0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <9EDD79AA-5104-49CC-A528-C5A1A1777106@ve7jtb.com>
References: <51195F3D.1050006@mitre.org> <222C28CB-7F6F-4BC3-8692-40404C2DC2D3@maymount.com> <511A50C7.8080102@mitre.org> 	<511A6C49.50801@mitre.org>  <4E1F6AAD24975D4BA5B168042967394367443A52@TK5EX14MBXC285.redmond.corp.microsoft.com>
To: Mike Jones 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQn1kFH2jDpS37eG+SET7+K5/DV7+BuqYaZ7qQiWhUIAE1Pb6IbvhQTkWZyp5FbIgXmewi3Y
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client	self-URL
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 19:53:07 -0000

The current privacy policy and TOS URL in registration are the ones for =
the Client.

Nat and I discussed adding ones for the Authorization server that the =
client agrees to as separate from ones that the user is agreeing to.

The Authorization servers TOS would be in discovery and perhaps in the =
registration response to indicate what the client is agreeing to.

As there rare standard relationships that cover this links Nat was =
speculating that they could be part of the _links object.=20

That aside confirming the terms of service that the client has agreed to =
in some way is probably a good thing in the registration response.

John B.

On 2013-02-12, at 4:25 PM, Mike Jones  =
wrote:

> Part of the REST/JSON philosophy is that interfaces should be as =
simple and developer-friendly as possible.  XML was rejected by =
developers, in part, because of the self-describing nature of the =
structure, which required extra syntax that was often not useful in =
practice.  Trying to re-impose that structure using extra JSON syntax =
conventions is just asking developers to have an allergic reaction to =
our specs upon encountering them.  The syntactic complexity and =
*surprise factor* isn't worth the limited semantic benefits of using =
"_links".
>=20
> Since you bring up privacy policy and terms of service, I'll note that =
the OAuth Dynamic Registration spec already has these fields to address =
those:
> 	policy_url
> 	tos_url
>=20
> Those have been working fine for OpenID Connect too.  There's no need =
to likewise convolve them to add the extra syntax that you describe =
below.
>=20
> (BTW, in a private thread, John Bradley pointed out that what the two =
of you talked about in person was actually the possibility of adding =
privacy policy and terms of service declarations at *discovery time*, =
rather than registration time.  That's a different topic, which we =
should discuss separately, if you want to pursue that.)
>=20
> 				Best wishes,
> 				-- Mike
>=20
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf =
Of Nat Sakimura
> Sent: Tuesday, February 12, 2013 9:11 AM
> To: Justin Richer; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client =
self-URL
>=20
> Actually, if it is to return it in the HTTP header, then it should =
also use the RFC5988 Web Linking format.
> Now, that is nice to have, but for many JSON programmers, I agree that =
it would be a hassle to obtain the header and store them in addition to =
the JSON. So, it is nicer to have it in JSON body.
>=20
> Re: Is "_links.self.href" grossly complex over =
"registration_access_url"?
>=20
> I do not think so. Accessing a flat top level parameter such as =
registration_access_url and _links.self.href does not make any =
difference from a client programmers point of view. That's a beauty of =
JSON. Both can be treated as a parameter name. Doing a group operation =
on the links makes difference though: the structured one is easier since =
you can just operate on _links while in case of the top level =
parameters, you have to have an explicit list of them and do the =
matches. (See below for the necessity for the grouping).
>=20
> I and John discussed this for at least half an hour F2F last week, =
both technically and from operation/legal point of view, for OpenID =
Connect Registration.
> Similar points could be made to OAuth dyn reg.
>=20
> Here is what we have discussed:
>=20
> When dynamically registering the client to the server, the server =
probably needs to return the following:
>=20
>  * terms-of-service (terms of service of the server to the client)
>  * privacy-policy (privacy policy of the server to the client)
>=20
> Both are defined in RFC5988/IANA Link Relations registry.
>=20
>=20
> They should be returned together with
>=20
>  * self.href
>=20
> which is also defined in RFC5988/IANA Link Relations registry.
>=20
> There are several ways to do it.
>=20
>  * Return these using RFC5988 (HTTP Header)
>  * Return these in entity body
>      * Use HAL (or OAuth-meta)/JSON Schema
>      * Use something else (e.g., a top level items)
>=20
> Returning it in the entity body has several advantage over HTTP =
header:
>=20
>  * They can be captured in one call;
>  * They are protocol agnostic;
>=20
> We determined that these advantages outweighs the disadvantage of =
creating a new standard.
>=20
> The question becomes then whether to:
>=20
>  * Use HAL (or OAuth-meta)/JSON Schema
>  * Use something else (e.g., a top level items)
>=20
> First, we have to consider what needs to be returned in the =
link/relationship category. If it were just _links.self.href, then =
grouping probably does not make sense. However, since we have =
terms-of-service and privacy-policy as well already, it may well make =
sense.
>=20
> Moreover, when we think of a multi-tenant authorization server that =
may want to use different OAuth authz and token endpoints for different =
tennants, it would be better to be able to return those in the =
registration response. Then, it would make sense to register OAuth authz =
and token endpoints as rel type in the IANA registry (like Bill Mills is =
trying to
> do) and use them in a uniform manner. Note: these per tenant endpoints =
may support different scopes etc. as well. Then, these has to be coupled =
with the URIs. That is why all of RFC5988/HAL/JSON Schema uses href =
instead of just having the URL as the value of the parameter. The =
semantic relationship would often have an associated URI, and other =
parameters that goes with it.
>=20
> e.g.:
>=20
> {
>    "_links": {
>        "terms-of-service": {
>            "href": "https: //server.example.com/tos"
>        },
>        "privacy-policy": {
>            "href": "https: //server.example.com/pp"
>        },
>        "self": {
>            "href": "https: //server.example.com/clients/1234",
>            "authorize": "Bearer"
>        },
>        "oauth_authz": {
>            "href": "https: //server.example.com/authz",
>            "scopes": "openid profile email",
>            "response_types": [
>                "token id_token",
>                "code id_token",
>                "token",
>                "code"
>            ]
>        },
>        "oauth_token": {
>            "href": "https: //server.example.com/token",
>            "authorize": "Basic"
>        }
>    }
> }
>=20
> In short, there are bunch of link relations that needs to be returned =
with additional parameters.
> Grouping them seems to make sense.
>=20
> Considering all these, John and I came to the conclusion that the HAL =
type syntax would probably make more sense.
> (Note: JSON Schema syntax does not make the parameter access as easy =
as HAL.)
>=20
> In fact, Mike Kelly (the author of HAL) and I have just submit a new =
version of draft-sakimura-oauth-meta
>=20
>   http://tools.ietf.org/html/draft-sakimura-oauth-meta-02
>=20
> The proposal was discussed at IETF 85 OAuth WG and the chairs asked to =
submit the draft.
> The -00 appeared in December, and this -02 has some simplification and =
the addition of the "operations" inspired by
> https://tools.ietf.org/html/draft-ietf-scim-api-00#section-3.5 .
> It is arguably a subset of HAL plus some OAuth specifics.
> I have not added Discovery response example, but adding them would =
makes even more sense, I think.
>=20
> Cheers,
>=20
> Nat
>=20
>=20
> 2013/2/13 Justin Richer 
>>=20
>> Agreed - I didn't think that header-only was the proposal, but let's =
be explicit about the returned body always containing the URL. The way I =
read the 201 definition, it suggests (SHOULD) that you use the location =
header, but also says that the entity should refer to the new resource. =
It was my assumption that the returned JSON would still have some form =
of client-entity management URL (whether it's the HAL _links structure =
or registration_management_url or something else is still up for =
debate).
>>=20
>> -- Justin
>>=20
>>=20
>>=20
>> On 02/12/2013 10:28 AM, John Bradley wrote:
>>=20
>> Returning a location header in the 201 ids fine as long as we also =
have the same info as a claim.
>>=20
>> I think most clients will want to process the JSON and store all the =
parameters together.  Making them fish out a header makes the W3C happy =
and is the correct thing to do but taking it from a claim is what =
developers are more comfortable with.
>>=20
>> John B.
>>=20
>> On 2013-02-12, at 11:25 AM, Justin Richer  wrote:
>>=20
>> I'd be fine with the return from a creation request being a 201 =
instead of a 200.
>>=20
>> -- Justin
>>=20
>> On 02/11/2013 06:33 PM, Richard Harrington wrote:
>>=20
>> Since the request is an HTTP POST and a resource is created =
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5) the =
response should be an HTTP 201 Created =
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.2) which =
is supposed to include the location of the newly created resource.
>>=20
>> This is a good pattern to follow since, as you say, it does provide =
flexibility.
>>=20
>>=20
>>=20
>> On Feb 11, 2013, at 1:14 PM, Justin Richer  wrote:
>>=20
>> Draft -05 of OAuth Dynamic Client Registration [1] returns a URL =
pointer for the client to perform update and secret rotation actions. =
This functionality arose from discussions on the list about moving =
towards a more RESTful pattern, and Nat Sakimura proposed this approach =
in the OpenID Connect Working Group. This URL may be distinct from the =
Client Registration Endpoint URL, but draft -05 makes no promises as to =
its content, form, or structure, though it does contain implementor's =
notes on possible methods.
>>=20
>> Two questions arise from this change:
>> - The semantics of returning the client manipulation URL
>> - The syntax (derived from HAL for JSON [2], an individual I-D=20
>> submission)
>>=20
>> On semantics:
>>=20
>> Pro:
>> - The server has flexibility on how to define the "update" endpoint,=20=

>> sending all clients to one URL, sending different clients to =
different=20
>> URLs, or sending clients to a URL with a baked-in query parameter
>> - The client can take the URL as-is and use it for all management=20
>> operations (ie, it doesn't have to generate or compose the URL based=20=

>> on component parts)
>>=20
>> Con:
>> - The client must remember one more piece of information from the=20
>> server at runtime if it wants to do manipulation and management of=20
>> itself at the server (in addition to client_id, client_secret,=20
>> registration_access_token, and others)
>>=20
>> Alternatives include specifying a URL pattern for the server to use =
and all clients to follow, specifying a query parameter for the update =
action, and specifying a separate endpoint entirely and using the =
presence of items such as client_id and the registration access token to =
differentiate the requests. Note that *all* of these alternatives can be =
accommodated using the semantics described above, with the same actions =
on the client's part.
>>=20
>>=20
>> On syntax:
>>=20
>> Pro:
>> - Follows the designs of RFC5988 for link relations
>> - The HAL format is general, and allows for all kinds of other=20
>> information to be placed inside the _links structure
>> - Allows for full use of the JSON object to specify advanced=20
>> operations on the returned endpoint if desired
>>=20
>> Con:
>> - The rest of OAuth doesn't follow link relation guidelines (though=20=

>> it's been brought up)
>> - The HAL format is general, and allows for all kinds of other=20
>> information to be placed inside the _links structure
>> - The HAL-JSON document is an expired individual I-D, and it's =
unclear=20
>> what wider adoption looks like right now
>>=20
>> Alternatives include returning the URL as a separate data member =
(registration_update_url), using HTTP headers, or using JSON Schema.
>>=20
>> -- Justin
>>=20
>>=20
>>=20
>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>> [2] http://tools.ietf.org/html/draft-kelly-json-hal-03
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>=20
>=20
>=20
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
> _______________________________________________
> 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

From jricher@mitre.org  Tue Feb 12 11:53:36 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D62D21F8DED for ; Tue, 12 Feb 2013 11:53:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.574
X-Spam-Level: 
X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.024,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9uUn5PGTJ1X for ; Tue, 12 Feb 2013 11:53:35 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 98C0221F8DC9 for ; Tue, 12 Feb 2013 11:53:34 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 39283531169E; Tue, 12 Feb 2013 14:53:34 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 2490A1F1626; Tue, 12 Feb 2013 14:53:34 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 12 Feb 2013 14:53:33 -0500
Message-ID: <511A9D92.2030600@mitre.org>
Date: Tue, 12 Feb 2013 14:52:50 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: John Bradley 
References: <51195F3B.1010701@mitre.org> <4E1F6AAD24975D4BA5B168042967394367443A16@TK5EX14MBXC285.redmond.corp.microsoft.com> <511A98DE.4030507@mitre.org> <9309CDB3-8AEE-428D-A7F0-5DAC45EFD44C@ve7jtb.com>
In-Reply-To: <9309CDB3-8AEE-428D-A7F0-5DAC45EFD44C@ve7jtb.com>
Content-Type: multipart/alternative; boundary="------------040308030608090303090707"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: JSON Encoded Input
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 19:53:36 -0000

--------------040308030608090303090707
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

In this case, I believe that it really is a fairly straightforward case 
of replacing the form-based key-value hash with a JSON-based key-value 
hash. So all the existing parameters are converted into top-level JSON 
objects, and the parameter values become the values of those members. 
This is the exact same form that the JSON output from the endpoint 
already was. The data model remains essentially identical between the 
two. Is there another reasonable way to do this? I haven't seen another 
proposal put forward, yet, though I'm sure we could dream up all kinds 
of unreasonable ones. :)

The only extra structured in the discussion draft (-05) are most of the 
lists, like redirect_uri and grant_type. An extension would want to use 
JSON numbers or booleans where it makes sense. Note that the "scope" 
parameter is still defined as a space-separated list of strings, a 
definition taken directly from OAuth Core. This is largely from feedback 
I got in regard to the Introspection draft, which tried to add JSON list 
structure to "scope" and confused folks.

  -- Justin

On 02/12/2013 02:44 PM, John Bradley wrote:
> Nat and I hashed out the pro's and cons of JSON requests.
>
> If we POST or PUT a JSON object we need to be specific as there rare 
> several ways to do it that may work better or worse depending on the 
> receiver.
> This needs to be looked over and one picked.
>
> In the other thread about the server returning the update URI and 
> being able to encode the client in that if it needs to takes care of 
> Servers that need that info in query parameters or the path to do the 
> routing.
>
> The use of structure can be used to enhance readability and parsing of 
> the input, and output.
>
> However we need to temper our urge to apply structure to everything.
>
> IT needs to be applied carefully otherwise we start looking like crazies.
>
> If we do it cautiously I am in favour of JSON as input.
>
> John B.
>
> On 2013-02-12, at 4:32 PM, Justin Richer  > wrote:
>
>> Thanks for forwarding that, Mike. I'll paste in my response to Nat's 
>> concern here as well:
>>
>>     It's an increasingly well known pattern that has reasonable
>>     support on the server side. For PHP, I was able to find the above
>>     example via the top hit on Stack Overflow. In Ruby, it's a matter
>>     of something like:
>>
>>     JSON.parse(request.body.read)
>>
>>     depending on the web app framework. On Java/Spring, it's a matter
>>     of injecting the entity body as a string and handing it to a
>>     parser (Gson in this case):
>>
>>     public String doApi(@RequestBody String jsonString) { JsonObject
>>     json = new JsonParser().parse(jsonString).getAsJsonObject();
>>
>>     It's a similar read/parse setup in Node.js as well.
>>
>>     It's true that in all of these cases you don't get to make use of
>>     the routing or data binding facilities (though in Spring you can
>>     do that for simpler domain objects using a ModelBinding), so you
>>     don't get niceities like the $_POST array in PHP handed to you.
>>     This is why I don't think it's a good idea at all to switch
>>     functionality based on the contents of the JSON object. It should
>>     be a domain object only, which is what it would be in this case.
>>
>>     I think that the positives of using JSON from the client's
>>     perspective and the overall protocol design far outweigh the
>>     slightly increased implementation cost at the server.
>>
>>
>>
>>  -- Justin
>>
>> On 02/12/2013 02:11 PM, Mike Jones wrote:
>>>
>>> FYI, this issue is also being discussed as an OpenID Connect issue 
>>> at https://bitbucket.org/openid/connect/issue/747. I think that 
>>> Nat's recent comment there bears repeating on this list:
>>>
>>> Nat Sakimura:
>>>
>>> Not so sure. For example, PHP cannot get the JSON object form 
>>> application/json POST in $_POST.
>>>
>>> It is OK to have a parameter like "request" that holds JSON. Then, 
>>> you can get to it from $_POST['request']. However, if you POST the 
>>> JSON as the POST body, then you would have to call a low level 
>>> function in the form of:
>>>
>>> ```
>>>
>>> #!php
>>>
>>> $file = file_get_contents('php://input' ); $x = 
>>> json_decode($file); ```
>>>
>>> Not that it is harder, but it is much less known. Many PHP 
>>> programmers will certainly goes "???".
>>>
>>> We need to check what would be the cases for other scripting 
>>> languages before making the final decision.
>>>
>>> -- Mike
>>>
>>> -----Original Message-----
>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On 
>>> Behalf Of Justin Richer
>>> Sent: Monday, February 11, 2013 1:15 PM
>>> To: oauth@ietf.org
>>> Subject: [OAUTH-WG] Registration: JSON Encoded Input
>>>
>>> Draft -05 of OAuth Dynamic Client Registration [1] switched from a 
>>> form-encoded input that had been used by drafts -01 through -04 to a 
>>> JSON encoded input that was used originally in -00. Note that all 
>>> versions keep JSON-encoded output from all operations.
>>>
>>> Pro:
>>>
>>>   - JSON gives us a rich data structure so that things such as 
>>> lists, numbers, nulls, and objects can be represented natively
>>>
>>>   - Allows for parallelism between the input to the endpoint and 
>>> output from the endpoint, reducing possible translation errors 
>>> between the two
>>>
>>>   - JSON specifies UTF8 encoding for all strings, forms may have 
>>> many different encodings
>>>
>>>   - JSON has minimal character escaping required for most strings, 
>>> forms require escaping for common characters such as space, slash, 
>>> comma, etc.
>>>
>>> Con:
>>>
>>>   - the rest of OAuth is form-in/JSON-out
>>>
>>>   - nothing else in OAuth requires the Client to create a JSON 
>>> object, merely to parse one
>>>
>>>   - form-in/JSON-out is a very widely established pattern on the web 
>>> today
>>>
>>>   - Client information (client_name, client_id, etc.) is conflated 
>>> with access information (registration_access_token, _links, 
>>> expires_at, etc.) in root level of the same JSON object, leaving the 
>>> client to decide what needs to (can?) be sent back to the server for 
>>> update operations.
>>>
>>> Alternatives include any number of data encoding schemes, including 
>>> form (like the old drafts), XML, ASN.1, etc.
>>>
>>>   -- Justin
>>>
>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>>>
>>> _______________________________________________
>>>
>>> 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
>

--------------040308030608090303090707
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

    In this case, I believe that it really is a fairly straightforward
    case of replacing the form-based key-value hash with a JSON-based
    key-value hash. So all the existing parameters are converted into
    top-level JSON objects, and the parameter values become the values
    of those members. This is the exact same form that the JSON output
    from the endpoint already was. The data model remains essentially
    identical between the two. Is there another reasonable way to do
    this? I haven't seen another proposal put forward, yet, though I'm
    sure we could dream up all kinds of unreasonable ones. :)

    The only extra structured in the discussion draft (-05) are most of
    the lists, like redirect_uri and grant_type. An extension would want
    to use JSON numbers or booleans where it makes sense. Note that the
    "scope" parameter is still defined as a space-separated list of
    strings, a definition taken directly from OAuth Core. This is
    largely from feedback I got in regard to the Introspection draft,
    which tried to add JSON list structure to "scope" and confused
    folks.

     -- Justin

    On 02/12/2013 02:44 PM, John Bradley
      wrote:

      Nat and I hashed out the pro's and cons of JSON requests.  

      If we POST or PUT a JSON object we need to be specific as
        there rare several ways to do it that may work better or worse
        depending on the receiver.
      This needs to be looked over and one picked.

      In the other thread about the server returning the update URI
        and being able to encode the client in that if it needs to takes
        care of Servers that need that info in query parameters or the
        path to do the routing.

      The use of structure can be used to enhance readability and
        parsing of the input, and output.

      However we need to temper our urge to apply structure to
        everything.  

      IT needs to be applied carefully otherwise we start looking
        like crazies.

      If we do it cautiously I am in favour of JSON as input.

      John B.

          On 2013-02-12, at 4:32 PM, Justin Richer <jricher@mitre.org>
            wrote:

             Thanks for forwarding
              that, Mike. I'll paste in my response to Nat's concern
              here as well:

              It's an increasingly well known pattern that
                has reasonable support on the server side. For PHP, I
                was able to find the above example via the top hit on
                Stack Overflow. In Ruby, it's a matter of something
                like:

                JSON.parse(request.body.read)

                depending on the web app framework. On Java/Spring, it's
                a matter of injecting the entity body as a string and
                handing it to a parser (Gson in this case):

                public String doApi(@RequestBody String jsonString) {
                JsonObject json = new
                JsonParser().parse(jsonString).getAsJsonObject();

                It's a similar read/parse setup in Node.js as well.

                It's true that in all of these cases you don't get to
                make use of the routing or data binding facilities
                (though in Spring you can do that for simpler domain
                objects using a ModelBinding), so you don't get
                niceities like the $_POST array in PHP handed to you.
                This is why I don't think it's a good idea at all to
                switch functionality based on the contents of the JSON
                object. It should be a domain object only, which is what
                it would be in this case.

                I think that the positives of using JSON from the
                client's perspective and the overall protocol design far
                outweigh the slightly increased implementation cost at
                the server.

               -- Justin

              On 02/12/2013 02:11 PM, Mike
                Jones wrote:

                  FYI, this issue is also being
                    discussed as an OpenID Connect issue at https://bitbucket.org/openid/connect/issue/747. 

                    I think that Nat's recent comment there bears
                    repeating on this list:

                  Nat
                    Sakimura:

                  Not
                    so sure. For example, PHP cannot get the JSON object
                    form application/json POST in $_POST. 

                  It is
                    OK to have a parameter like "request" that holds
                    JSON. Then, you can get to it from
                    $_POST['request']. However, if you POST the JSON as
                    the POST body, then you would have to call a low
                    level function in the form of: 

                  ```
                  #!php

                  $file
                    = file_get_contents('php://input'); $x =
                    json_decode($file); ```

                  Not
                    that it is harder, but it is much less known. Many
                    PHP programmers will certainly goes "???". 

                  We
                    need to check what would be the cases for other
                    scripting languages before making the final
                    decision.

                    -- Mike

                  -----Original Message-----

                    From: oauth-bounces@ietf.org
                    [mailto:oauth-bounces@ietf.org]
                    On Behalf Of Justin Richer

                    Sent: Monday, February 11, 2013 1:15 PM

                    To: oauth@ietf.org

                    Subject: [OAUTH-WG] Registration: JSON Encoded Input

                  Draft -05 of OAuth Dynamic
                    Client Registration [1] switched from a form-encoded
                    input that had been used by drafts -01 through -04
                    to a JSON encoded input that was used originally in
                    -00. Note that all versions keep JSON-encoded output
                    from all operations.

                  Pro:
                    - JSON gives us a rich data
                    structure so that things such as lists, numbers,
                    nulls, and objects can be represented natively
                    - Allows for parallelism
                    between the input to the endpoint and output from
                    the endpoint, reducing possible translation errors
                    between the two
                    - JSON specifies UTF8
                    encoding for all strings, forms may have many
                    different encodings
                    - JSON has minimal character
                    escaping required for most strings, forms require
                    escaping for common characters such as space, slash,
                    comma, etc.

                  Con:
                    - the rest of OAuth is
                    form-in/JSON-out
                    - nothing else in OAuth
                    requires the Client to create a JSON object, merely
                    to parse one
                    - form-in/JSON-out is a very
                    widely established pattern on the web today
                    - Client information
                    (client_name, client_id, etc.) is conflated with
                    access information (registration_access_token,
                    _links, expires_at, etc.) in root level of the same
                    JSON object, leaving the client to decide what needs
                    to (can?) be sent back to the server for update
                    operations.

                  Alternatives include any
                    number of data encoding schemes, including form
                    (like the old drafts), XML, ASN.1, etc.

                    -- Justin

                  [1]  http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
                  _______________________________________________
                  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

--------------040308030608090303090707--

From jricher@mitre.org  Tue Feb 12 11:57:04 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB3521F8DF9 for ; Tue, 12 Feb 2013 11:57:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.275
X-Spam-Level: 
X-Spam-Status: No, score=-6.275 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdf3GaExfIMw for ; Tue, 12 Feb 2013 11:57:03 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id DEA8521F8DF7 for ; Tue, 12 Feb 2013 11:57:02 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B16FB5312FAD; Tue, 12 Feb 2013 14:56:51 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 9B98A5312F99; Tue, 12 Feb 2013 14:56:51 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 12 Feb 2013 14:56:50 -0500
Message-ID: <511A9E58.1040606@mitre.org>
Date: Tue, 12 Feb 2013 14:56:08 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: John Bradley 
References: <51195F3D.1050006@mitre.org> <222C28CB-7F6F-4BC3-8692-40404C2DC2D3@maymount.com> <511A50C7.8080102@mitre.org> 	<511A6C49.50801@mitre.org>  <4E1F6AAD24975D4BA5B168042967394367443A52@TK5EX14MBXC285.redmond.corp.microsoft.com> <9EDD79AA-5104-49CC-A528-C5A1A1777106@ve7jtb.com>
In-Reply-To: <9EDD79AA-5104-49CC-A528-C5A1A1777106@ve7jtb.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client	self-URL
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 19:57:04 -0000

One question though: How exactly would the client, a software 
application, agree to the TOS? Is it supposed to fetch the content of 
the tos_url and do some processing on it? I wasn't under the impression 
that the tos_url contents were machine readable. Is it supposed to 
present that to the user somehow? It seems that's a better thing for the 
server to do at Authorization time, since it's got the user's attention.

Remember, this is meant to be for *automated* registration. The 
developer of the Client has no say at this stage of the game.

So, I think this is a bit of a red herring, to be honest.

  -- Justin

On 02/12/2013 02:52 PM, John Bradley wrote:
> The current privacy policy and TOS URL in registration are the ones for the Client.
>
> Nat and I discussed adding ones for the Authorization server that the client agrees to as separate from ones that the user is agreeing to.
>
> The Authorization servers TOS would be in discovery and perhaps in the registration response to indicate what the client is agreeing to.
>
> As there rare standard relationships that cover this links Nat was speculating that they could be part of the _links object.
>
> That aside confirming the terms of service that the client has agreed to in some way is probably a good thing in the registration response.
>
> John B.
>
> On 2013-02-12, at 4:25 PM, Mike Jones  wrote:
>
>> Part of the REST/JSON philosophy is that interfaces should be as simple and developer-friendly as possible.  XML was rejected by developers, in part, because of the self-describing nature of the structure, which required extra syntax that was often not useful in practice.  Trying to re-impose that structure using extra JSON syntax conventions is just asking developers to have an allergic reaction to our specs upon encountering them.  The syntactic complexity and *surprise factor* isn't worth the limited semantic benefits of using "_links".
>>
>> Since you bring up privacy policy and terms of service, I'll note that the OAuth Dynamic Registration spec already has these fields to address those:
>> 	policy_url
>> 	tos_url
>>
>> Those have been working fine for OpenID Connect too.  There's no need to likewise convolve them to add the extra syntax that you describe below.
>>
>> (BTW, in a private thread, John Bradley pointed out that what the two of you talked about in person was actually the possibility of adding privacy policy and terms of service declarations at *discovery time*, rather than registration time.  That's a different topic, which we should discuss separately, if you want to pursue that.)
>>
>> 				Best wishes,
>> 				-- Mike
>>
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura
>> Sent: Tuesday, February 12, 2013 9:11 AM
>> To: Justin Richer; oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL
>>
>> Actually, if it is to return it in the HTTP header, then it should also use the RFC5988 Web Linking format.
>> Now, that is nice to have, but for many JSON programmers, I agree that it would be a hassle to obtain the header and store them in addition to the JSON. So, it is nicer to have it in JSON body.
>>
>> Re: Is "_links.self.href" grossly complex over "registration_access_url"?
>>
>> I do not think so. Accessing a flat top level parameter such as registration_access_url and _links.self.href does not make any difference from a client programmers point of view. That's a beauty of JSON. Both can be treated as a parameter name. Doing a group operation on the links makes difference though: the structured one is easier since you can just operate on _links while in case of the top level parameters, you have to have an explicit list of them and do the matches. (See below for the necessity for the grouping).
>>
>> I and John discussed this for at least half an hour F2F last week, both technically and from operation/legal point of view, for OpenID Connect Registration.
>> Similar points could be made to OAuth dyn reg.
>>
>> Here is what we have discussed:
>>
>> When dynamically registering the client to the server, the server probably needs to return the following:
>>
>>   * terms-of-service (terms of service of the server to the client)
>>   * privacy-policy (privacy policy of the server to the client)
>>
>> Both are defined in RFC5988/IANA Link Relations registry.
>>
>>
>> They should be returned together with
>>
>>   * self.href
>>
>> which is also defined in RFC5988/IANA Link Relations registry.
>>
>> There are several ways to do it.
>>
>>   * Return these using RFC5988 (HTTP Header)
>>   * Return these in entity body
>>       * Use HAL (or OAuth-meta)/JSON Schema
>>       * Use something else (e.g., a top level items)
>>
>> Returning it in the entity body has several advantage over HTTP header:
>>
>>   * They can be captured in one call;
>>   * They are protocol agnostic;
>>
>> We determined that these advantages outweighs the disadvantage of creating a new standard.
>>
>> The question becomes then whether to:
>>
>>   * Use HAL (or OAuth-meta)/JSON Schema
>>   * Use something else (e.g., a top level items)
>>
>> First, we have to consider what needs to be returned in the link/relationship category. If it were just _links.self.href, then grouping probably does not make sense. However, since we have terms-of-service and privacy-policy as well already, it may well make sense.
>>
>> Moreover, when we think of a multi-tenant authorization server that may want to use different OAuth authz and token endpoints for different tennants, it would be better to be able to return those in the registration response. Then, it would make sense to register OAuth authz and token endpoints as rel type in the IANA registry (like Bill Mills is trying to
>> do) and use them in a uniform manner. Note: these per tenant endpoints may support different scopes etc. as well. Then, these has to be coupled with the URIs. That is why all of RFC5988/HAL/JSON Schema uses href instead of just having the URL as the value of the parameter. The semantic relationship would often have an associated URI, and other parameters that goes with it.
>>
>> e.g.:
>>
>> {
>>     "_links": {
>>         "terms-of-service": {
>>             "href": "https: //server.example.com/tos"
>>         },
>>         "privacy-policy": {
>>             "href": "https: //server.example.com/pp"
>>         },
>>         "self": {
>>             "href": "https: //server.example.com/clients/1234",
>>             "authorize": "Bearer"
>>         },
>>         "oauth_authz": {
>>             "href": "https: //server.example.com/authz",
>>             "scopes": "openid profile email",
>>             "response_types": [
>>                 "token id_token",
>>                 "code id_token",
>>                 "token",
>>                 "code"
>>             ]
>>         },
>>         "oauth_token": {
>>             "href": "https: //server.example.com/token",
>>             "authorize": "Basic"
>>         }
>>     }
>> }
>>
>> In short, there are bunch of link relations that needs to be returned with additional parameters.
>> Grouping them seems to make sense.
>>
>> Considering all these, John and I came to the conclusion that the HAL type syntax would probably make more sense.
>> (Note: JSON Schema syntax does not make the parameter access as easy as HAL.)
>>
>> In fact, Mike Kelly (the author of HAL) and I have just submit a new version of draft-sakimura-oauth-meta
>>
>>    http://tools.ietf.org/html/draft-sakimura-oauth-meta-02
>>
>> The proposal was discussed at IETF 85 OAuth WG and the chairs asked to submit the draft.
>> The -00 appeared in December, and this -02 has some simplification and the addition of the "operations" inspired by
>> https://tools.ietf.org/html/draft-ietf-scim-api-00#section-3.5 .
>> It is arguably a subset of HAL plus some OAuth specifics.
>> I have not added Discovery response example, but adding them would makes even more sense, I think.
>>
>> Cheers,
>>
>> Nat
>>
>>
>> 2013/2/13 Justin Richer 
>>> Agreed - I didn't think that header-only was the proposal, but let's be explicit about the returned body always containing the URL. The way I read the 201 definition, it suggests (SHOULD) that you use the location header, but also says that the entity should refer to the new resource. It was my assumption that the returned JSON would still have some form of client-entity management URL (whether it's the HAL _links structure or registration_management_url or something else is still up for debate).
>>>
>>> -- Justin
>>>
>>>
>>>
>>> On 02/12/2013 10:28 AM, John Bradley wrote:
>>>
>>> Returning a location header in the 201 ids fine as long as we also have the same info as a claim.
>>>
>>> I think most clients will want to process the JSON and store all the parameters together.  Making them fish out a header makes the W3C happy and is the correct thing to do but taking it from a claim is what developers are more comfortable with.
>>>
>>> John B.
>>>
>>> On 2013-02-12, at 11:25 AM, Justin Richer  wrote:
>>>
>>> I'd be fine with the return from a creation request being a 201 instead of a 200.
>>>
>>> -- Justin
>>>
>>> On 02/11/2013 06:33 PM, Richard Harrington wrote:
>>>
>>> Since the request is an HTTP POST and a resource is created (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5) the response should be an HTTP 201 Created (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.2) which is supposed to include the location of the newly created resource.
>>>
>>> This is a good pattern to follow since, as you say, it does provide flexibility.
>>>
>>>
>>>
>>> On Feb 11, 2013, at 1:14 PM, Justin Richer  wrote:
>>>
>>> Draft -05 of OAuth Dynamic Client Registration [1] returns a URL pointer for the client to perform update and secret rotation actions. This functionality arose from discussions on the list about moving towards a more RESTful pattern, and Nat Sakimura proposed this approach in the OpenID Connect Working Group. This URL may be distinct from the Client Registration Endpoint URL, but draft -05 makes no promises as to its content, form, or structure, though it does contain implementor's notes on possible methods.
>>>
>>> Two questions arise from this change:
>>> - The semantics of returning the client manipulation URL
>>> - The syntax (derived from HAL for JSON [2], an individual I-D
>>> submission)
>>>
>>> On semantics:
>>>
>>> Pro:
>>> - The server has flexibility on how to define the "update" endpoint,
>>> sending all clients to one URL, sending different clients to different
>>> URLs, or sending clients to a URL with a baked-in query parameter
>>> - The client can take the URL as-is and use it for all management
>>> operations (ie, it doesn't have to generate or compose the URL based
>>> on component parts)
>>>
>>> Con:
>>> - The client must remember one more piece of information from the
>>> server at runtime if it wants to do manipulation and management of
>>> itself at the server (in addition to client_id, client_secret,
>>> registration_access_token, and others)
>>>
>>> Alternatives include specifying a URL pattern for the server to use and all clients to follow, specifying a query parameter for the update action, and specifying a separate endpoint entirely and using the presence of items such as client_id and the registration access token to differentiate the requests. Note that *all* of these alternatives can be accommodated using the semantics described above, with the same actions on the client's part.
>>>
>>>
>>> On syntax:
>>>
>>> Pro:
>>> - Follows the designs of RFC5988 for link relations
>>> - The HAL format is general, and allows for all kinds of other
>>> information to be placed inside the _links structure
>>> - Allows for full use of the JSON object to specify advanced
>>> operations on the returned endpoint if desired
>>>
>>> Con:
>>> - The rest of OAuth doesn't follow link relation guidelines (though
>>> it's been brought up)
>>> - The HAL format is general, and allows for all kinds of other
>>> information to be placed inside the _links structure
>>> - The HAL-JSON document is an expired individual I-D, and it's unclear
>>> what wider adoption looks like right now
>>>
>>> Alternatives include returning the URL as a separate data member (registration_update_url), using HTTP headers, or using JSON Schema.
>>>
>>> -- Justin
>>>
>>>
>>>
>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>>> [2] http://tools.ietf.org/html/draft-kelly-json-hal-03
>>> _______________________________________________
>>> 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
>>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>> _______________________________________________
>> 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

From ve7jtb@ve7jtb.com  Tue Feb 12 11:58:56 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E0121F8E09 for ; Tue, 12 Feb 2013 11:58:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.275
X-Spam-Level: 
X-Spam-Status: No, score=-3.275 tagged_above=-999 required=5 tests=[AWL=0.323,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5WoiqsVU9VF for ; Tue, 12 Feb 2013 11:58:54 -0800 (PST)
Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by ietfa.amsl.com (Postfix) with ESMTP id 99F9921F8DFC for ; Tue, 12 Feb 2013 11:58:54 -0800 (PST)
Received: by mail-qe0-f50.google.com with SMTP id 7so212224qea.37 for ; Tue, 12 Feb 2013 11:58:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=PeAFBSTFedPFgapZJXoCw94HgkQu1iJXUsvpvM4d4Wc=; b=XHllUh+LaryLKir/oNZwbb5HPHZdrLYilhw9Jd9/RAJDd4/mqKwfBoXmRTBXVmrQuc 4sidqVVXrNqlYlC7EMSIPc+DNeXfu4/Tbq01beycyCR1B8VXl0CVLoWbkPLijd5DX2Vn vfWuen4XBMik/kJ1uKWmOiHNbXwtk6e5rOdIxBP4UPanCD3JRG2a8LxKanR14LoH/rlR EqnkqCr1Qr0+vfRHQYBf8R0tQpymTSoc8E8o9FQ9p5HDL7kPxXwjiJZIapRI/gSEl2kW ClEdc3x0JIZ5KPKUlE7E+kdW2yiXGX9ATVNeHqhODk6ZuNjUL5+/3AXq6SiYyhxsa8Em Bosw==
X-Received: by 10.49.73.232 with SMTP id o8mr8716660qev.0.1360699133688; Tue, 12 Feb 2013 11:58:53 -0800 (PST)
Received: from [192.168.1.213] (190-20-23-212.baf.movistar.cl. [190.20.23.212]) by mx.google.com with ESMTPS id o5sm16784159qao.12.2013.02.12.11.58.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 11:58:52 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_01F9A728-ECD3-4372-8BDC-6D601FCC86D5"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: 
Date: Tue, 12 Feb 2013 16:58:44 -0300
Message-Id: <040A3633-A51F-4B17-8019-5DEEC349F39C@ve7jtb.com>
References: <51195F3B.1010701@mitre.org> <4E1F6AAD24975D4BA5B168042967394367443A16@TK5EX14MBXC285.redmond.corp.microsoft.com> <511A98DE.4030507@mitre.org> <9309CDB3-8AEE-428D-A7F0-5DAC45EFD44C@ve7jtb.com> 
To: Tim Bray 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQlnBjQzqaGsv3eJNZMfHE7htYWMRAXBMu4iBjdM6pEVndO911pH2iC0S2AFIuKMHwsPThwC
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: JSON Encoded Input
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 19:58:56 -0000

--Apple-Mail=_01F9A728-ECD3-4372-8BDC-6D601FCC86D5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Some people apparently encode the JSON as the key in a form POST,  some =
people do a form POST with a special key and the JSON as the value.=20

There appear to be a number of theories in the wild.   I am not an =
expert I just looked up code examples from several sources stack =
overflow and the like.

We probably need to get input from developers who have experience =
working with different frameworks.   I think the differences have to do =
with decoding it at the receiver.

We originally had registration posting JSON but we changed form encoding =
as that worked in all environments.   We just need to be sure we are not =
creating problems for people with the change back.

John B.

On 2013-02-12, at 4:48 PM, Tim Bray  wrote:

>=20
>=20
> On Tue, Feb 12, 2013 at 11:44 AM, John Bradley  =
wrote:
> Nat and I hashed out the pro's and cons of JSON requests. =20
>=20
> If we POST or PUT a JSON object we need to be specific as there rare =
several ways to do it that may work better or worse depending on the =
receiver.
> This needs to be looked over and one picked.
>=20
> Hm?  Not following on =93several ways=94, I=92d have thought that =
POSTing JSON is just POSTing JSON, must be missing something. -T
> =20
>=20
> In the other thread about the server returning the update URI and =
being able to encode the client in that if it needs to takes care of =
Servers that need that info in query parameters or the path to do the =
routing.
>=20
> The use of structure can be used to enhance readability and parsing of =
the input, and output.
>=20
> However we need to temper our urge to apply structure to everything. =20=

>=20
> IT needs to be applied carefully otherwise we start looking like =
crazies.
>=20
> If we do it cautiously I am in favour of JSON as input.
>=20
> John B.
>=20
> On 2013-02-12, at 4:32 PM, Justin Richer  wrote:
>=20
>> Thanks for forwarding that, Mike. I'll paste in my response to Nat's =
concern here as well:
>> It's an increasingly well known pattern that has reasonable support =
on the server side. For PHP, I was able to find the above example via =
the top hit on Stack Overflow. In Ruby, it's a matter of something like:
>>=20
>> JSON.parse(request.body.read)
>>=20
>> depending on the web app framework. On Java/Spring, it's a matter of =
injecting the entity body as a string and handing it to a parser (Gson =
in this case):
>>=20
>> public String doApi(@RequestBody String jsonString) { JsonObject json =
=3D new JsonParser().parse(jsonString).getAsJsonObject();
>>=20
>> It's a similar read/parse setup in Node.js as well.
>>=20
>> It's true that in all of these cases you don't get to make use of the =
routing or data binding facilities (though in Spring you can do that for =
simpler domain objects using a ModelBinding), so you don't get niceities =
like the $_POST array in PHP handed to you. This is why I don't think =
it's a good idea at all to switch functionality based on the contents of =
the JSON object. It should be a domain object only, which is what it =
would be in this case.
>>=20
>> I think that the positives of using JSON from the client's =
perspective and the overall protocol design far outweigh the slightly =
increased implementation cost at the server.
>>=20
>>=20
>>  -- Justin
>>=20
>> On 02/12/2013 02:11 PM, Mike Jones wrote:
>>> FYI, this issue is also being discussed as an OpenID Connect issue =
at https://bitbucket.org/openid/connect/issue/747.  I think that Nat's =
recent comment there bears repeating on this list:
>>>=20
>>> =20
>>>=20
>>> Nat Sakimura:
>>>=20
>>> =20
>>>=20
>>> Not so sure. For example, PHP cannot get the JSON object form =
application/json POST in $_POST.
>>>=20
>>> =20
>>>=20
>>> It is OK to have a parameter like "request" that holds JSON. Then, =
you can get to it from $_POST['request']. However, if you POST the JSON =
as the POST body, then you would have to call a low level function in =
the form of:
>>>=20
>>> =20
>>>=20
>>> =20
>>>=20
>>> ```
>>>=20
>>> #!php
>>>=20
>>> =20
>>>=20
>>> $file =3D file_get_contents('php://input'); $x =3D =
json_decode($file); ```
>>>=20
>>> =20
>>>=20
>>> Not that it is harder, but it is much less known. Many PHP =
programmers will certainly goes "???".
>>>=20
>>> =20
>>>=20
>>> We need to check what would be the cases for other scripting =
languages before making the final decision.
>>>=20
>>> =20
>>>=20
>>>                                                             -- Mike
>>>=20
>>> =20
>>>=20
>>> -----Original Message-----
>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf Of Justin Richer
>>> Sent: Monday, February 11, 2013 1:15 PM
>>> To: oauth@ietf.org
>>> Subject: [OAUTH-WG] Registration: JSON Encoded Input
>>>=20
>>> =20
>>>=20
>>> Draft -05 of OAuth Dynamic Client Registration [1] switched from a =
form-encoded input that had been used by drafts -01 through -04 to a =
JSON encoded input that was used originally in -00. Note that all =
versions keep JSON-encoded output from all operations.
>>>=20
>>> =20
>>>=20
>>> Pro:
>>>=20
>>>   - JSON gives us a rich data structure so that things such as =
lists, numbers, nulls, and objects can be represented natively
>>>=20
>>>   - Allows for parallelism between the input to the endpoint and =
output from the endpoint, reducing possible translation errors between =
the two
>>>=20
>>>   - JSON specifies UTF8 encoding for all strings, forms may have =
many different encodings
>>>=20
>>>   - JSON has minimal character escaping required for most strings, =
forms require escaping for common characters such as space, slash, =
comma, etc.
>>>=20
>>> =20
>>>=20
>>> Con:
>>>=20
>>>   - the rest of OAuth is form-in/JSON-out
>>>=20
>>>   - nothing else in OAuth requires the Client to create a JSON =
object, merely to parse one
>>>=20
>>>   - form-in/JSON-out is a very widely established pattern on the web =
today
>>>=20
>>>   - Client information (client_name, client_id, etc.) is conflated =
with access information (registration_access_token, _links, expires_at, =
etc.) in root level of the same JSON object, leaving the client to =
decide what needs to (can?) be sent back to the server for update =
operations.
>>>=20
>>> =20
>>>=20
>>> =20
>>>=20
>>> Alternatives include any number of data encoding schemes, including =
form (like the old drafts), XML, ASN.1, etc.
>>>=20
>>> =20
>>>=20
>>> =20
>>>=20
>>>   -- Justin
>>>=20
>>> =20
>>>=20
>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>>>=20
>>> _______________________________________________
>>>=20
>>> OAuth mailing list
>>>=20
>>> OAuth@ietf.org
>>>=20
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20

--Apple-Mail=_01F9A728-ECD3-4372-8BDC-6D601FCC86D5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Some =
people apparently encode the JSON as the key in a form POST,  some =
people do a form POST with a special key and the JSON as the =
value. 
There appear to be a number of theories =
in the wild.   I am not an expert I just looked up code examples =
from several sources stack overflow and the =
like.

We probably need to get input from =
developers who have experience working with different frameworks.   =
I think the differences have to do with decoding it at the =
receiver.

We originally had registration =
posting JSON but we changed form encoding as that worked in all =
environments.   We just need to be sure we are not creating =
problems for people with the change =
back.

John =
B.
On 2013-02-12, at 4:48 PM, Tim Bray <twbray@google.com> =
wrote:

On Tue, Feb 12, 2013 at =
11:44 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Nat and I hashed out the pro's and =
cons of JSON requests.  
If we POST or PUT a =
JSON object we need to be specific as there rare several ways to do it =
that may work better or worse depending on the receiver.

This needs to be looked over and one =
picked.

Hm?  Not =
following on =93several ways=94, I=92d have thought that POSTing JSON is =
just POSTing JSON, must be missing something. -T

In the other thread =
about the server returning the update URI and being able to encode the =
client in that if it needs to takes care of Servers that need that info =
in query parameters or the path to do the routing.

The use of structure can be used to enhance =
readability and parsing of the input, and =
output.

However we need to temper our urge to =
apply structure to everything.  

IT needs to be applied carefully otherwise we start looking =
like crazies.

If we do it cautiously I am in =
favour of JSON as input.

John B.

On 2013-02-12, at 4:32 PM, Justin Richer <jricher@mitre.org> wrote:

 =20
   =20
 =20

    Thanks for forwarding that, Mike. I'll paste in my response to Nat's
    concern here as well:

    It's an increasingly well known pattern that has
      reasonable support on the server side. For PHP, I was able to find
      the above example via the top hit on Stack Overflow. In Ruby, it's
      a matter of something like:

      JSON.parse(request.body.read)

      depending on the web app framework. On Java/Spring, it's a matter
      of injecting the entity body as a string and handing it to a
      parser (Gson in this case):

      public String doApi(@RequestBody String jsonString) { JsonObject
      json =3D new JsonParser().parse(jsonString).getAsJsonObject();

      It's a similar read/parse setup in Node.js as well.

      It's true that in all of these cases you don't get to make use of
      the routing or data binding facilities (though in Spring you can
      do that for simpler domain objects using a ModelBinding), so you
      don't get niceities like the $_POST array in PHP handed to you.
      This is why I don't think it's a good idea at all to switch
      functionality based on the contents of the JSON object. It should
      be a domain object only, which is what it would be in this =
case.

      I think that the positives of using JSON from the client's
      perspective and the overall protocol design far outweigh the
      slightly increased implementation cost at the server.

     -- Justin

    On 02/12/2013 02:11 PM, Mike Jones
      wrote:

     =20
     =20
     =20
      FYI, this issue is also being discussed
          as an OpenID Connect issue at
          https://bitbucket.org/openid/connect/issue/747. =
;
          I think that Nat's recent comment there bears repeating on
          this list:

Nat Sakimura:

Not so sure.
          For example, PHP cannot get the JSON object form
          application/json POST in $_POST.

It is OK to
          have a parameter like "request" that holds JSON. Then, you can
          get to it from $_POST['request']. However, if you POST the
          JSON as the POST body, then you would have to call a low level
          function in the form of: 

```

#!php

$file =3D
          file_get_contents('php://input'); $x =3D =
json_decode($file); ```

Not that it is
          harder, but it is much less known. Many PHP programmers will
          certainly goes "???".

We need to
          check what would be the cases for other scripting languages
          before making the final =
decision.

   =
;            &=
nbsp;           &nb=
sp;            =
;            &=
nbsp;      
          -- =
Mike

-----Original =
Message-----

          From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]
          On Behalf Of Justin Richer

          Sent: Monday, February 11, 2013 1:15 PM

          To: oauth@ietf.org

          Subject: [OAUTH-WG] Registration: JSON Encoded =
Input

Draft -05 of OAuth Dynamic Client
          Registration [1] switched from a form-encoded input that had
          been used by drafts -01 through -04 to a JSON encoded input
          that was used originally in -00. Note that all versions keep
          JSON-encoded output from all =
operations.

Pro:<=
/u>
  - JSON gives us a rich data structure
          so that things such as lists, numbers, nulls, and objects can
          be represented natively
  - Allows =
for parallelism between the
          input to the endpoint and output from the endpoint, reducing
          possible translation errors between the =
two
  - JSON specifies UTF8 encoding for all
          strings, forms may have many different =
encodings
  - JSON has minimal character =
escaping
          required for most strings, forms require escaping for common
          characters such as space, slash, comma, =
etc.

Con:
=
  - the rest of OAuth is
          form-in/JSON-out
  - nothing else in =
OAuth requires the
          Client to create a JSON object, merely to parse =
one
  - form-in/JSON-out is a very widely
          established pattern on the web =
today
  - Client information (client_name,
          client_id, etc.) is conflated with access information
          (registration_access_token, _links, expires_at, etc.) in root
          level of the same JSON object, leaving the client to decide
          what needs to (can?) be sent back to the server for update
          =
operations.

Alternatives include any number of data
          encoding schemes, including form (like the old drafts), XML,
          ASN.1, =
etc.

  -- Justin

[1] =

            http://tools.ietf.org/html=
/draft-ietf-oauth-dyn-reg-05
______________=
_________________________________
OAuth mailing =
list
OAuth@ietf.org<=
u>
https://www.ietf.org/mailm=
an/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

=

--Apple-Mail=_01F9A728-ECD3-4372-8BDC-6D601FCC86D5--

From jricher@mitre.org  Tue Feb 12 12:00:18 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B946521F8E47 for ; Tue, 12 Feb 2013 12:00:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.569
X-Spam-Level: 
X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.029,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueF-W6InAdbP for ; Tue, 12 Feb 2013 12:00:16 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id A9E0A21F8D94 for ; Tue, 12 Feb 2013 12:00:14 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 974DE531304F; Tue, 12 Feb 2013 15:00:13 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C06321F2ACE; Tue, 12 Feb 2013 15:00:07 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 12 Feb 2013 15:00:07 -0500
Message-ID: <511A9F1C.1010504@mitre.org>
Date: Tue, 12 Feb 2013 14:59:24 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: John Bradley 
References: <51195F3B.1010701@mitre.org> <4E1F6AAD24975D4BA5B168042967394367443A16@TK5EX14MBXC285.redmond.corp.microsoft.com> <511A98DE.4030507@mitre.org> <9309CDB3-8AEE-428D-A7F0-5DAC45EFD44C@ve7jtb.com>  <040A3633-A51F-4B17-8019-5DEEC349F39C@ve7jtb.com>
In-Reply-To: <040A3633-A51F-4B17-8019-5DEEC349F39C@ve7jtb.com>
Content-Type: multipart/alternative; boundary="------------070103050401010102030600"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: JSON Encoded Input
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 20:00:18 -0000

--------------070103050401010102030600
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit

If that's the question, then my proposal is the Content-type is 
"application/json" and the HTTP Entity Body is the JSON document. No 
form posts or parameter names to be had here.

  -- Justin

On 02/12/2013 02:58 PM, John Bradley wrote:
> Some people apparently encode the JSON as the key in a form POST, 
>  some people do a form POST with a special key and the JSON as the value.
>
> There appear to be a number of theories in the wild.   I am not an 
> expert I just looked up code examples from several sources stack 
> overflow and the like.
>
> We probably need to get input from developers who have experience 
> working with different frameworks.   I think the differences have to 
> do with decoding it at the receiver.
>
> We originally had registration posting JSON but we changed form 
> encoding as that worked in all environments.   We just need to be sure 
> we are not creating problems for people with the change back.
>
>
> John B.
>
> On 2013-02-12, at 4:48 PM, Tim Bray  > wrote:
>
>>
>>
>> On Tue, Feb 12, 2013 at 11:44 AM, John Bradley > > wrote:
>>
>>     Nat and I hashed out the pro's and cons of JSON requests.
>>
>>     If we POST or PUT a JSON object we need to be specific as there
>>     rare several ways to do it that may work better or worse
>>     depending on the receiver.
>>     This needs to be looked over and one picked.
>>
>>
>> Hm?  Not following on �several ways�, I�d have thought that POSTing 
>> JSON is just POSTing JSON, must be missing something. -T
>>
>>
>>     In the other thread about the server returning the update URI and
>>     being able to encode the client in that if it needs to takes care
>>     of Servers that need that info in query parameters or the path to
>>     do the routing.
>>
>>     The use of structure can be used to enhance readability and
>>     parsing of the input, and output.
>>
>>     However we need to temper our urge to apply structure to everything.
>>
>>     IT needs to be applied carefully otherwise we start looking like
>>     crazies.
>>
>>     If we do it cautiously I am in favour of JSON as input.
>>
>>     John B.
>>
>>     On 2013-02-12, at 4:32 PM, Justin Richer >     > wrote:
>>
>>>     Thanks for forwarding that, Mike. I'll paste in my response to
>>>     Nat's concern here as well:
>>>
>>>         It's an increasingly well known pattern that has reasonable
>>>         support on the server side. For PHP, I was able to find the
>>>         above example via the top hit on Stack Overflow. In Ruby,
>>>         it's a matter of something like:
>>>
>>>         JSON.parse(request.body.read)
>>>
>>>         depending on the web app framework. On Java/Spring, it's a
>>>         matter of injecting the entity body as a string and handing
>>>         it to a parser (Gson in this case):
>>>
>>>         public String doApi(@RequestBody String jsonString) {
>>>         JsonObject json = new
>>>         JsonParser().parse(jsonString).getAsJsonObject();
>>>
>>>         It's a similar read/parse setup in Node.js as well.
>>>
>>>         It's true that in all of these cases you don't get to make
>>>         use of the routing or data binding facilities (though in
>>>         Spring you can do that for simpler domain objects using a
>>>         ModelBinding), so you don't get niceities like the $_POST
>>>         array in PHP handed to you. This is why I don't think it's a
>>>         good idea at all to switch functionality based on the
>>>         contents of the JSON object. It should be a domain object
>>>         only, which is what it would be in this case.
>>>
>>>         I think that the positives of using JSON from the client's
>>>         perspective and the overall protocol design far outweigh the
>>>         slightly increased implementation cost at the server.
>>>
>>>
>>>
>>>      -- Justin
>>>
>>>     On 02/12/2013 02:11 PM, Mike Jones wrote:
>>>>
>>>>     FYI, this issue is also being discussed as an OpenID Connect
>>>>     issue at https://bitbucket.org/openid/connect/issue/747. I
>>>>     think that Nat's recent comment there bears repeating on this list:
>>>>
>>>>     Nat Sakimura:
>>>>
>>>>     Not so sure. For example, PHP cannot get the JSON object form
>>>>     application/json POST in $_POST.
>>>>
>>>>     It is OK to have a parameter like "request" that holds JSON.
>>>>     Then, you can get to it from $_POST['request']. However, if you
>>>>     POST the JSON as the POST body, then you would have to call a
>>>>     low level function in the form of:
>>>>
>>>>     ```
>>>>
>>>>     #!php
>>>>
>>>>     $file = file_get_contents('php://input'); $x =
>>>>     json_decode($file); ```
>>>>
>>>>     Not that it is harder, but it is much less known. Many PHP
>>>>     programmers will certainly goes "???".
>>>>
>>>>     We need to check what would be the cases for other scripting
>>>>     languages before making the final decision.
>>>>
>>>>     -- Mike
>>>>
>>>>     -----Original Message-----
>>>>     From: oauth-bounces@ietf.org 
>>>>     [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
>>>>     Sent: Monday, February 11, 2013 1:15 PM
>>>>     To: oauth@ietf.org 
>>>>     Subject: [OAUTH-WG] Registration: JSON Encoded Input
>>>>
>>>>     Draft -05 of OAuth Dynamic Client Registration [1] switched
>>>>     from a form-encoded input that had been used by drafts -01
>>>>     through -04 to a JSON encoded input that was used originally in
>>>>     -00. Note that all versions keep JSON-encoded output from all
>>>>     operations.
>>>>
>>>>     Pro:
>>>>
>>>>       - JSON gives us a rich data structure so that things such as
>>>>     lists, numbers, nulls, and objects can be represented natively
>>>>
>>>>       - Allows for parallelism between the input to the endpoint
>>>>     and output from the endpoint, reducing possible translation
>>>>     errors between the two
>>>>
>>>>       - JSON specifies UTF8 encoding for all strings, forms may
>>>>     have many different encodings
>>>>
>>>>       - JSON has minimal character escaping required for most
>>>>     strings, forms require escaping for common characters such as
>>>>     space, slash, comma, etc.
>>>>
>>>>     Con:
>>>>
>>>>       - the rest of OAuth is form-in/JSON-out
>>>>
>>>>       - nothing else in OAuth requires the Client to create a JSON
>>>>     object, merely to parse one
>>>>
>>>>       - form-in/JSON-out is a very widely established pattern on
>>>>     the web today
>>>>
>>>>       - Client information (client_name, client_id, etc.) is
>>>>     conflated with access information (registration_access_token,
>>>>     _links, expires_at, etc.) in root level of the same JSON
>>>>     object, leaving the client to decide what needs to (can?) be
>>>>     sent back to the server for update operations.
>>>>
>>>>     Alternatives include any number of data encoding schemes,
>>>>     including form (like the old drafts), XML, ASN.1, etc.
>>>>
>>>>       -- Justin
>>>>
>>>>     [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>>>>
>>>>     _______________________________________________
>>>>
>>>>     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
>>
>>
>

--------------070103050401010102030600
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit

    If that's the question, then my proposal is the Content-type is
    "application/json" and the HTTP Entity Body is the JSON document. No
    form posts or parameter names to be had here.

    �-- Justin

    On 02/12/2013 02:58 PM, John Bradley
      wrote:

      Some people apparently encode the JSON as the key in a form POST,
      �some people do a form POST with a special key and the JSON as the
      value.�

      There appear to be a number of theories in the wild. � I am
        not an expert I just looked up code examples from several
        sources stack overflow and the like.

      We probably need to get input from developers who have
        experience working with different frameworks. � I think the
        differences have to do with decoding it at the receiver.

      We originally had registration posting JSON but we changed
        form encoding as that worked in all environments. � We just need
        to be sure we are not creating problems for people with the
        change back.

      John B.

          On 2013-02-12, at 4:48 PM, Tim Bray <twbray@google.com>
            wrote:

            On Tue, Feb 12, 2013 at 11:44 AM,
              John Bradley <ve7jtb@ve7jtb.com>
              wrote:

                Nat and I hashed out
                  the pro's and cons of JSON requests. �

                  If we POST or PUT a JSON object we need to be
                    specific as there rare several ways to do it that
                    may work better or worse depending on the receiver.
                  This needs to be looked over and one picked.

              Hm? �Not following on �several ways�, I�d have
                thought that POSTing JSON is just POSTing JSON, must be
                missing something. -T
              �

                  In the other thread about the server returning
                    the update URI and being able to encode the client
                    in that if it needs to takes care of Servers that
                    need that info in query parameters or the path to do
                    the routing.

                  The use of structure can be used to enhance
                    readability and parsing of the input, and output.

                  However we need to temper our urge to apply
                    structure to everything. �

                  IT needs to be applied carefully otherwise we
                    start looking like crazies.

                  If we do it cautiously I am in favour of JSON as
                    input.

                  John B.

                          On 2013-02-12, at 4:32 PM, Justin Richer
                            <jricher@mitre.org>
                            wrote:

                              Thanks for forwarding that, Mike. I'll
                              paste in my response to Nat's concern here
                              as well:

                              It's an increasingly well
                                known pattern that has reasonable
                                support on the server side. For PHP, I
                                was able to find the above example via
                                the top hit on Stack Overflow. In Ruby,
                                it's a matter of something like:

                                JSON.parse(request.body.read)

                                depending on the web app framework. On
                                Java/Spring, it's a matter of injecting
                                the entity body as a string and handing
                                it to a parser (Gson in this case):

                                public String doApi(@RequestBody String
                                jsonString) { JsonObject json = new
                                JsonParser().parse(jsonString).getAsJsonObject();

                                It's a similar read/parse setup in
                                Node.js as well.

                                It's true that in all of these cases you
                                don't get to make use of the routing or
                                data binding facilities (though in
                                Spring you can do that for simpler
                                domain objects using a ModelBinding), so
                                you don't get niceities like the $_POST
                                array in PHP handed to you. This is why
                                I don't think it's a good idea at all to
                                switch functionality based on the
                                contents of the JSON object. It should
                                be a domain object only, which is what
                                it would be in this case.

                                I think that the positives of using JSON
                                from the client's perspective and the
                                overall protocol design far outweigh the
                                slightly increased implementation cost
                                at the server.

                              �-- Justin

                              On 02/12/2013 02:11 PM, Mike Jones
                                wrote:

                                  FYI, this issue is also being
                                    discussed as an OpenID Connect issue
                                    at https://bitbucket.org/openid/connect/issue/747.�

                                    I think that Nat's recent comment
                                    there bears repeating on this list:
                                  �
                                  Nat
                                    Sakimura:
                                  �
                                  Not so
                                    sure. For example, PHP cannot get
                                    the JSON object form
                                    application/json POST in $_POST. 
                                  �
                                  It is OK
                                    to have a parameter like "request"
                                    that holds JSON. Then, you can get
                                    to it from $_POST['request'].
                                    However, if you POST the JSON as the
                                    POST body, then you would have to
                                    call a low level function in the
                                    form of: 
                                  �
                                  �
                                  ```

                                    #!php
                                  �
                                  $file =
                                    file_get_contents('php://input');
                                    $x = json_decode($file); ```
                                  �
                                  Not that
                                    it is harder, but it is much less
                                    known. Many PHP programmers will
                                    certainly goes "???". 
                                  �
                                  We need to
                                    check what would be the cases for
                                    other scripting languages before
                                    making the final decision.
                                  �
                                  �����������������������������������������������������������

                                    -- Mike
                                  �
                                  -----Original Message-----

                                    From: oauth-bounces@ietf.org
                                    [mailto:oauth-bounces@ietf.org]
                                    On Behalf Of Justin Richer

                                    Sent: Monday, February 11, 2013 1:15
                                    PM

                                    To: oauth@ietf.org

                                    Subject: [OAUTH-WG] Registration:
                                    JSON Encoded Input
                                  �
                                  Draft -05 of OAuth Dynamic Client
                                    Registration [1] switched from a
                                    form-encoded input that had been
                                    used by drafts -01 through -04 to a
                                    JSON encoded input that was used
                                    originally in -00. Note that all
                                    versions keep JSON-encoded output
                                    from all operations.
                                  �
                                  Pro:
                                  � - JSON gives us a rich data
                                    structure so that things such as
                                    lists, numbers, nulls, and objects
                                    can be represented natively
                                  � - Allows for parallelism between
                                    the input to the endpoint and output
                                    from the endpoint, reducing possible
                                    translation errors between the two
                                  � - JSON specifies UTF8 encoding
                                    for all strings, forms may have many
                                    different encodings
                                  � - JSON has minimal character
                                    escaping required for most strings,
                                    forms require escaping for common
                                    characters such as space, slash,
                                    comma, etc.
                                  �
                                  Con:
                                  � - the rest of OAuth is
                                    form-in/JSON-out
                                  � - nothing else in OAuth requires
                                    the Client to create a JSON object,
                                    merely to parse one
                                  � - form-in/JSON-out is a very
                                    widely established pattern on the
                                    web today
                                  � - Client information
                                    (client_name, client_id, etc.) is
                                    conflated with access information
                                    (registration_access_token, _links,
                                    expires_at, etc.) in root level of
                                    the same JSON object, leaving the
                                    client to decide what needs to
                                    (can?) be sent back to the server
                                    for update operations.
                                  �
                                  �
                                  Alternatives include any number of
                                    data encoding schemes, including
                                    form (like the old drafts), XML,
                                    ASN.1, etc.
                                  �
                                  �
                                  � -- Justin
                                  �
                                  [1]  http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
                                  _______________________________________________
                                  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

--------------070103050401010102030600--

From ppatterson@salesforce.com  Tue Feb 12 12:04:25 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35BC21F9027 for ; Tue, 12 Feb 2013 12:04:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOqXNCezkDAg for ; Tue, 12 Feb 2013 12:04:23 -0800 (PST)
Received: from exprod8og102.obsmtp.com (exprod8og102.obsmtp.com [64.18.3.84]) by ietfa.amsl.com (Postfix) with SMTP id 1CFE521F8E92 for ; Tue, 12 Feb 2013 12:04:23 -0800 (PST)
Received: from exsfm-hub5.internal.salesforce.com ([204.14.239.233]) by exprod8ob102.postini.com ([64.18.7.12]) with SMTP ID DSNKURqgRi/PG0Mm4Kofmcq8bc3m/oNYdfjN@postini.com; Tue, 12 Feb 2013 12:04:23 PST
Received: from EXSFM-MB03.internal.salesforce.com ([10.1.127.57]) by exsfm-hub5.internal.salesforce.com ([10.1.127.5]) with mapi; Tue, 12 Feb 2013 12:04:22 -0800
From: Pat Patterson 
To: John Bradley 
Date: Tue, 12 Feb 2013 12:04:19 -0800
Thread-Topic: [OAUTH-WG] Registration: JSON Encoded Input
Thread-Index: Ac4JXCXMX29dq+jqSpiXjxPKurH6sg==
Message-ID: <07D5BBD9-15C0-4796-B944-2A3241829994@salesforce.com>
References: <51195F3B.1010701@mitre.org> <4E1F6AAD24975D4BA5B168042967394367443A16@TK5EX14MBXC285.redmond.corp.microsoft.com> <511A98DE.4030507@mitre.org> <9309CDB3-8AEE-428D-A7F0-5DAC45EFD44C@ve7jtb.com>  <040A3633-A51F-4B17-8019-5DEEC349F39C@ve7jtb.com>
In-Reply-To: <040A3633-A51F-4B17-8019-5DEEC349F39C@ve7jtb.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_07D5BBD915C04796B9442A3241829994salesforcecom_"
MIME-Version: 1.0
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: JSON Encoded Input
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 20:04:25 -0000

--_000_07D5BBD915C04796B9442A3241829994salesforcecom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Just POST the JSON as the HTTP payload with mime-type application/json:

$ curl -v -H "Content-Type: application/json" -X POST -d '{"Hello": "World"=
}' http://requestb.in/19qit4u1
* About to connect() to requestb.in port 80 (#0)
*   Trying 107.20.236.186... connected
* Connected to requestb.in (107.20.236.186) port 80 (#0)
> POST /19qit4u1 HTTP/1.1
> User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenS=
SL/0.9.8r zlib/1.2.3
> Host: requestb.in
> Accept: */*
> Content-Type: application/json
> Content-Length: 18
>
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=3Dutf-8
< Date: Tue, 12 Feb 2013 20:03:39 GMT
< Content-Length: 3
< Connection: keep-alive
<
ok
* Connection #0 to host requestb.in left intact
* Closing connection #0

Cheers,

Pat
--
Pat Patterson | Principal Developer Evangelist | 408-849-4681 | http://abou=
t.me/patpatterson

On Feb 12, 2013, at 11:58 AM, John Bradley wrote:

Some people apparently encode the JSON as the key in a form POST,  some peo=
ple do a form POST with a special key and the JSON as the value.

There appear to be a number of theories in the wild.   I am not an expert I=
 just looked up code examples from several sources stack overflow and the l=
ike.

We probably need to get input from developers who have experience working w=
ith different frameworks.   I think the differences have to do with decodin=
g it at the receiver.

We originally had registration posting JSON but we changed form encoding as=
 that worked in all environments.   We just need to be sure we are not crea=
ting problems for people with the change back.

John B.

On 2013-02-12, at 4:48 PM, Tim Bray > wrote:

On Tue, Feb 12, 2013 at 11:44 AM, John Bradley > wrote:
Nat and I hashed out the pro's and cons of JSON requests.

If we POST or PUT a JSON object we need to be specific as there rare severa=
l ways to do it that may work better or worse depending on the receiver.
This needs to be looked over and one picked.

Hm?  Not following on =93several ways=94, I=92d have thought that POSTing J=
SON is just POSTing JSON, must be missing something. -T

In the other thread about the server returning the update URI and being abl=
e to encode the client in that if it needs to takes care of Servers that ne=
ed that info in query parameters or the path to do the routing.

The use of structure can be used to enhance readability and parsing of the =
input, and output.

However we need to temper our urge to apply structure to everything.

IT needs to be applied carefully otherwise we start looking like crazies.

If we do it cautiously I am in favour of JSON as input.

John B.

On 2013-02-12, at 4:32 PM, Justin Richer > wrote:

Thanks for forwarding that, Mike. I'll paste in my response to Nat's concer=
n here as well:
It's an increasingly well known pattern that has reasonable support on the =
server side. For PHP, I was able to find the above example via the top hit =
on Stack Overflow. In Ruby, it's a matter of something like:

JSON.parse(request.body.read)

depending on the web app framework. On Java/Spring, it's a matter of inject=
ing the entity body as a string and handing it to a parser (Gson in this ca=
se):

public String doApi(@RequestBody String jsonString) { JsonObject json =3D n=
ew JsonParser().parse(jsonString).getAsJsonObject();

It's a similar read/parse setup in Node.js as well.

It's true that in all of these cases you don't get to make use of the routi=
ng or data binding facilities (though in Spring you can do that for simpler=
 domain objects using a ModelBinding), so you don't get niceities like the =
$_POST array in PHP handed to you. This is why I don't think it's a good id=
ea at all to switch functionality based on the contents of the JSON object.=
 It should be a domain object only, which is what it would be in this case.

I think that the positives of using JSON from the client's perspective and =
the overall protocol design far outweigh the slightly increased implementat=
ion cost at the server.

 -- Justin

On 02/12/2013 02:11 PM, Mike Jones wrote:

FYI, this issue is also being discussed as an OpenID Connect issue at https=
://bitbucket.org/openid/connect/issue/747.  I think that Nat's recent comme=
nt there bears repeating on this list:

Nat Sakimura:

Not so sure. For example, PHP cannot get the JSON object form application/j=
son POST in $_POST.

It is OK to have a parameter like "request" that holds JSON. Then, you can =
get to it from $_POST['request']. However, if you POST the JSON as the POST=
 body, then you would have to call a low level function in the form of:

```

#!php

$file =3D file_get_contents('php://input'); $x =3D json_decode($file); ```

Not that it is harder, but it is much less known. Many PHP programmers will=
 certainly goes "???".

We need to check what would be the cases for other scripting languages befo=
re making the final decision.

                                                            -- Mike

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Justin Richer
Sent: Monday, February 11, 2013 1:15 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Registration: JSON Encoded Input

Draft -05 of OAuth Dynamic Client Registration [1] switched from a form-enc=
oded input that had been used by drafts -01 through -04 to a JSON encoded i=
nput that was used originally in -00. Note that all versions keep JSON-enco=
ded output from all operations.

Pro:

  - JSON gives us a rich data structure so that things such as lists, numbe=
rs, nulls, and objects can be represented natively

  - Allows for parallelism between the input to the endpoint and output fro=
m the endpoint, reducing possible translation errors between the two

  - JSON specifies UTF8 encoding for all strings, forms may have many diffe=
rent encodings

  - JSON has minimal character escaping required for most strings, forms re=
quire escaping for common characters such as space, slash, comma, etc.

Con:

  - the rest of OAuth is form-in/JSON-out

  - nothing else in OAuth requires the Client to create a JSON object, mere=
ly to parse one

  - form-in/JSON-out is a very widely established pattern on the web today

  - Client information (client_name, client_id, etc.) is conflated with acc=
ess information (registration_access_token, _links, expires_at, etc.) in ro=
ot level of the same JSON object, leaving the client to decide what needs t=
o (can?) be sent back to the server for update operations.

Alternatives include any number of data encoding schemes, including form (l=
ike the old drafts), XML, ASN.1, etc.

  -- Justin

[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05

_______________________________________________

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

--_000_07D5BBD915C04796B9442A3241829994salesforcecom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Just POST the JSON as=
 the HTTP payload with mime-type application/json:

$ curl -v -H "Content-Type: application/json" -X POST -d '{"Hello": "=
World"}' http://requestb.in/19qit4u=
1
* About to connect() to requestb.in port 80 (#0)
=
*   Trying 107.20.236.186... connected
* Connected to reques=
tb.in (107.20.236.186) port 80 (#0)
> POST /19qit4u1 HTTP/1.1<=
/div>> User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl=
/7.19.7 OpenSSL/0.9.8r zlib/1.2.3
> Host: requestb.in
> Accept: */*
> Content-Type: application/json
=
> Content-Length: 18
> 
< HTTP/1.1 200 OK=
< Content-Type: text/html; charset=3Dutf-8
< Dat=
e: Tue, 12 Feb 2013 20:03:39 GMT
< Content-Length: 3
< Connection: keep-alive< 
ok
* =
Connection #0 to host requestb.in left intact
* Closing connectio=
n #0

Cheers,

Pat
-- 
Pat Patterson | Princi=
pal Developer Evangelist | 408-849-4681 | http://about.me/patpatterson

On Feb 12, 2013, at 11:58 AM, John Bradley wrote:

Some people apparently encode the JSON as the key in a form POST,  som=
e people do a form POST with a special key and the JSON as the value. 

There appear to be a number of theories in the wild.   I am not a=
n expert I just looked up code examples from several sources stack overflow=
 and the like.

We probably need to get input from developers who have experience work=
ing with different frameworks.   I think the differences have to do wi=
th decoding it at the receiver.

We originally had registration posting JSON but we changed form encodi=
ng as that worked in all environments.   We just need to be sure we ar=
e not creating problems for people with the change back.

John B.

On 2013-02-12, at 4:48 PM, Tim Bray <twbray@google.com> wrote:

On Tue, Feb 12, 2013 at 11:44 AM, John Bradley <=
span dir=3D"ltr">
<ve7jtb@ve7jtb.co=
m> wrote:

Nat and I hashed out the pro's and cons=
 of JSON requests.  

If we POST or PUT a JSON object we need to be specific as there rare s=
everal ways to do it that may work better or worse depending on the receive=
r.
This needs to be looked over and one picked.

Hm?  Not following on =93several ways=94, I=92d have thought that=
 POSTing JSON is just POSTing JSON, must be missing something. -T

In the other thread about the server returning the update URI and bein=
g able to encode the client in that if it needs to takes care of Servers th=
at need that info in query parameters or the path to do the routing.

The use of structure can be used to enhance readability and parsing of=
 the input, and output.

However we need to temper our urge to apply structure to everything. &=
nbsp;

IT needs to be applied carefully otherwise we start looking like crazi=
es.

If we do it cautiously I am in favour of JSON as input.

John B.

On 2013-02-12, at 4:32 PM, Justin Richer <jricher@mitre.org> wrote:

Thanks for forwarding that, Mike.=
 I'll paste in my response to Nat's concern here as well:

It's an increasingly well known pattern that has reasonable sup=
port on the server side. For PHP, I was able to find the above example via =
the top hit on Stack Overflow. In Ruby, it's a matter of something like:

JSON.parse(request.body.read)

depending on the web app framework. On Java/Spring, it's a matter of inject=
ing the entity body as a string and handing it to a parser (Gson in this ca=
se):

public String doApi(@RequestBody String jsonString) { JsonObject json =3D n=
ew JsonParser().parse(jsonString).getAsJsonObject();

It's a similar read/parse setup in Node.js as well.

It's true that in all of these cases you don't get to make use of the routi=
ng or data binding facilities (though in Spring you can do that for simpler=
 domain objects using a ModelBinding), so you don't get niceities like the =
$_POST array in PHP handed to you.
 This is why I don't think it's a good idea at all to switch functionality =
based on the contents of the JSON object. It should be a domain object only=
, which is what it would be in this case.

I think that the positives of using JSON from the client's perspective and =
the overall protocol design far outweigh the slightly increased implementat=
ion cost at the server.

 -- Justin

On 02/12/2013 02:11 PM, Mike Jones wrote:

FYI, this issue is also being discussed as an OpenID Connect issue =
at 
https://bitbucket.org/openid/connect/issue/747.  I think that Nat'=
s recent comment there bears repeating on this list:

Nat Sakimura:=

Not so sure. For example, PHP cannot get the JSON object f=
orm application/json POST in $_POST.

It is OK to have a parameter like "request" that=
 holds JSON. Then, you can get to it from $_POST['request']. However, if yo=
u POST the JSON as the POST body, then you would have to call a low level f=
unction in the form of:

```
#!php

$file =3D file_get_contents('php://input'); $x =3D jso=
n_decode($file); ```
=

Not that it is harder, but i=
t is much less known. Many PHP programmers will certainly goes "???".

We need to check what would be the cases for oth=
er scripting languages before making the final decision.
<=
p> 
       &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;  -- Mike

-----Origin=
al Message-----

From: oauth-bou=
nces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer

Sent: Monday, February 11, 2013 1:15 PM

To: oauth@ietf.org<=
br>
Subject: [OAUTH-WG] Registration: JSON Encoded Input
 =
Draft -05 of OAuth Dynamic Client Registration [1] switched from=
 a form-encoded input that had been used by drafts -01 through -04 to a JSO=
N encoded input that was used originally in -00. Note that all versions kee=
p JSON-encoded output from all operations.
 =
;
Pro:
  - JSON gives us a rich data =
structure so that things such as lists, numbers, nulls, and objects can be =
represented natively
  - Allows for parallelism be=
tween the input to the endpoint and output from the endpoint, reducing poss=
ible translation errors between the two
  - JSON s=
pecifies UTF8 encoding for all strings, forms may have many different encod=
ings
  - JSON has minimal character escaping requi=
red for most strings, forms require escaping for common characters such as =
space, slash, comma, etc.

Co=
n:
  - the rest of OAuth is form-in/JSON-out
  - nothing else in OAuth requires the Client to create=
 a JSON object, merely to parse one
  - form-in/JS=
ON-out is a very widely established pattern on the web today<=
/p>
  - Client information (client_name, client_id, etc.) is conflat=
ed with access information (registration_access_token, _links, expires_at, =
etc.) in root level of the same JSON object, leaving the client to decide w=
hat needs to (can?) be sent back to the
 server for update operations.

=
 Alternatives include any number of data encod=
ing schemes, including form (like the old drafts), XML, ASN.1, etc.<=
u>

  -=
- Justin

[1] 
http://tools.ietf.org=
/html/draft-ietf-oauth-dyn-reg-05
__________=
_____________________________________
OAuth mailing lis=
t
<=
span style=3D"color:windowtext;text-decoration:none">OAuth@ietf.org<=
/a>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

=

--_000_07D5BBD915C04796B9442A3241829994salesforcecom_--

From ve7jtb@ve7jtb.com  Tue Feb 12 12:05:16 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E666F21F8DCF for ; Tue, 12 Feb 2013 12:05:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.992
X-Spam-Level: 
X-Spam-Status: No, score=-2.992 tagged_above=-999 required=5 tests=[AWL=0.007,  BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qubef9Fwxnje for ; Tue, 12 Feb 2013 12:05:15 -0800 (PST)
Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) by ietfa.amsl.com (Postfix) with ESMTP id 2143821F8B97 for ; Tue, 12 Feb 2013 12:05:14 -0800 (PST)
Received: by mail-qc0-f180.google.com with SMTP id v28so171577qcm.39 for ; Tue, 12 Feb 2013 12:05:14 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=UxqjvZEITYImXg6ESgteREmhA4Lnd8IE0JXawg6u+dg=; b=Rgr56RXwFD/bYfiO6JZq/MOyXub2BT7BLMFfpWDYrujFL8OtFKD2cH7i/MNyci/+oA LZ05joW1VZWwYs7OVR/X1QBJTlKNfeZ85HhjddRVtNwmDlW/oNgXmvh0xv2ZniNB0Ig4 CUmED72ZvpiFf0drq92ZCg9Szm8B5zoZqTPilrz9rAldpvMfHat4jPevq37Z+qZnV/AJ YeWxsIFNmEutv5lkRSMRQgu6fhCl8pqHtMAr5s0xsjuPwAcOGRFPVuYZwIo1epcJCRU7 Ez95KcFQT7m85V0QOa4qBMsn169P1AhnN75y5v0c3o8EYhAd8IHAQ8R2t82Yp4WaHDu7 Crxg==
X-Received: by 10.49.107.4 with SMTP id gy4mr8580233qeb.63.1360699514093; Tue, 12 Feb 2013 12:05:14 -0800 (PST)
Received: from [192.168.1.213] (190-20-23-212.baf.movistar.cl. [190.20.23.212]) by mx.google.com with ESMTPS id t2sm16800043qav.1.2013.02.12.12.05.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 12:05:12 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <511A9E58.1040606@mitre.org>
Date: Tue, 12 Feb 2013 17:04:44 -0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <715762BE-886B-4E93-8E35-6356F0A18224@ve7jtb.com>
References: <51195F3D.1050006@mitre.org> <222C28CB-7F6F-4BC3-8692-40404C2DC2D3@maymount.com> <511A50C7.8080102@mitre.org> 	<511A6C49.50801@mitre.org>  <4E1F6AAD24975D4BA5B168042967394367443A52@TK5EX14MBXC285.redmond.corp.microsoft.com> <9EDD79AA-5104-49CC-A528-C5A1A1777106@ve7jtb.com> <511A9E58.1040606@mitre.org>
To: Justin Richer 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQncT2+oT/iQ9mVO8RNObg+yHM3I5wgiGYgTxS/GGx1jOcwHMbqQ3RDoHZdD85V2UMpnNNYn
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client	self-URL
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 20:05:17 -0000

There are two TOS and privacy policies.

One for the AS that the client is agreeing to by registering.  Will it =
hold up in court?  don't know Facebook is doing this.
The link would be a reference to a human readable file that the client =
(RP) can have someone look over before using the connection.
This policy may relate to how long the client can cache info etc.

The other is the privacy policy of the client that may be presented as a =
click through from the Authorization server.  In general the user is not =
explicitly accepting this, only implicitly accepting it by continuing to =
the RP after having been given a chance to look at it if they want.

These are very US fuse on privacy but ignoring them is probably a =
mistake.

John B.
On 2013-02-12, at 4:56 PM, Justin Richer  wrote:

> One question though: How exactly would the client, a software =
application, agree to the TOS? Is it supposed to fetch the content of =
the tos_url and do some processing on it? I wasn't under the impression =
that the tos_url contents were machine readable. Is it supposed to =
present that to the user somehow? It seems that's a better thing for the =
server to do at Authorization time, since it's got the user's attention.
>=20
> Remember, this is meant to be for *automated* registration. The =
developer of the Client has no say at this stage of the game.
>=20
> So, I think this is a bit of a red herring, to be honest.
>=20
> -- Justin
>=20
> On 02/12/2013 02:52 PM, John Bradley wrote:
>> The current privacy policy and TOS URL in registration are the ones =
for the Client.
>>=20
>> Nat and I discussed adding ones for the Authorization server that the =
client agrees to as separate from ones that the user is agreeing to.
>>=20
>> The Authorization servers TOS would be in discovery and perhaps in =
the registration response to indicate what the client is agreeing to.
>>=20
>> As there rare standard relationships that cover this links Nat was =
speculating that they could be part of the _links object.
>>=20
>> That aside confirming the terms of service that the client has agreed =
to in some way is probably a good thing in the registration response.
>>=20
>> John B.
>>=20
>> On 2013-02-12, at 4:25 PM, Mike Jones  =
wrote:
>>=20
>>> Part of the REST/JSON philosophy is that interfaces should be as =
simple and developer-friendly as possible.  XML was rejected by =
developers, in part, because of the self-describing nature of the =
structure, which required extra syntax that was often not useful in =
practice.  Trying to re-impose that structure using extra JSON syntax =
conventions is just asking developers to have an allergic reaction to =
our specs upon encountering them.  The syntactic complexity and =
*surprise factor* isn't worth the limited semantic benefits of using =
"_links".
>>>=20
>>> Since you bring up privacy policy and terms of service, I'll note =
that the OAuth Dynamic Registration spec already has these fields to =
address those:
>>> 	policy_url
>>> 	tos_url
>>>=20
>>> Those have been working fine for OpenID Connect too.  There's no =
need to likewise convolve them to add the extra syntax that you describe =
below.
>>>=20
>>> (BTW, in a private thread, John Bradley pointed out that what the =
two of you talked about in person was actually the possibility of adding =
privacy policy and terms of service declarations at *discovery time*, =
rather than registration time.  That's a different topic, which we =
should discuss separately, if you want to pursue that.)
>>>=20
>>> 				Best wishes,
>>> 				-- Mike
>>>=20
>>> -----Original Message-----
>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf Of Nat Sakimura
>>> Sent: Tuesday, February 12, 2013 9:11 AM
>>> To: Justin Richer; oauth@ietf.org
>>> Subject: Re: [OAUTH-WG] Registration: HAL _links structure and =
client self-URL
>>>=20
>>> Actually, if it is to return it in the HTTP header, then it should =
also use the RFC5988 Web Linking format.
>>> Now, that is nice to have, but for many JSON programmers, I agree =
that it would be a hassle to obtain the header and store them in =
addition to the JSON. So, it is nicer to have it in JSON body.
>>>=20
>>> Re: Is "_links.self.href" grossly complex over =
"registration_access_url"?
>>>=20
>>> I do not think so. Accessing a flat top level parameter such as =
registration_access_url and _links.self.href does not make any =
difference from a client programmers point of view. That's a beauty of =
JSON. Both can be treated as a parameter name. Doing a group operation =
on the links makes difference though: the structured one is easier since =
you can just operate on _links while in case of the top level =
parameters, you have to have an explicit list of them and do the =
matches. (See below for the necessity for the grouping).
>>>=20
>>> I and John discussed this for at least half an hour F2F last week, =
both technically and from operation/legal point of view, for OpenID =
Connect Registration.
>>> Similar points could be made to OAuth dyn reg.
>>>=20
>>> Here is what we have discussed:
>>>=20
>>> When dynamically registering the client to the server, the server =
probably needs to return the following:
>>>=20
>>>  * terms-of-service (terms of service of the server to the client)
>>>  * privacy-policy (privacy policy of the server to the client)
>>>=20
>>> Both are defined in RFC5988/IANA Link Relations registry.
>>>=20
>>>=20
>>> They should be returned together with
>>>=20
>>>  * self.href
>>>=20
>>> which is also defined in RFC5988/IANA Link Relations registry.
>>>=20
>>> There are several ways to do it.
>>>=20
>>>  * Return these using RFC5988 (HTTP Header)
>>>  * Return these in entity body
>>>      * Use HAL (or OAuth-meta)/JSON Schema
>>>      * Use something else (e.g., a top level items)
>>>=20
>>> Returning it in the entity body has several advantage over HTTP =
header:
>>>=20
>>>  * They can be captured in one call;
>>>  * They are protocol agnostic;
>>>=20
>>> We determined that these advantages outweighs the disadvantage of =
creating a new standard.
>>>=20
>>> The question becomes then whether to:
>>>=20
>>>  * Use HAL (or OAuth-meta)/JSON Schema
>>>  * Use something else (e.g., a top level items)
>>>=20
>>> First, we have to consider what needs to be returned in the =
link/relationship category. If it were just _links.self.href, then =
grouping probably does not make sense. However, since we have =
terms-of-service and privacy-policy as well already, it may well make =
sense.
>>>=20
>>> Moreover, when we think of a multi-tenant authorization server that =
may want to use different OAuth authz and token endpoints for different =
tennants, it would be better to be able to return those in the =
registration response. Then, it would make sense to register OAuth authz =
and token endpoints as rel type in the IANA registry (like Bill Mills is =
trying to
>>> do) and use them in a uniform manner. Note: these per tenant =
endpoints may support different scopes etc. as well. Then, these has to =
be coupled with the URIs. That is why all of RFC5988/HAL/JSON Schema =
uses href instead of just having the URL as the value of the parameter. =
The semantic relationship would often have an associated URI, and other =
parameters that goes with it.
>>>=20
>>> e.g.:
>>>=20
>>> {
>>>    "_links": {
>>>        "terms-of-service": {
>>>            "href": "https: //server.example.com/tos"
>>>        },
>>>        "privacy-policy": {
>>>            "href": "https: //server.example.com/pp"
>>>        },
>>>        "self": {
>>>            "href": "https: //server.example.com/clients/1234",
>>>            "authorize": "Bearer"
>>>        },
>>>        "oauth_authz": {
>>>            "href": "https: //server.example.com/authz",
>>>            "scopes": "openid profile email",
>>>            "response_types": [
>>>                "token id_token",
>>>                "code id_token",
>>>                "token",
>>>                "code"
>>>            ]
>>>        },
>>>        "oauth_token": {
>>>            "href": "https: //server.example.com/token",
>>>            "authorize": "Basic"
>>>        }
>>>    }
>>> }
>>>=20
>>> In short, there are bunch of link relations that needs to be =
returned with additional parameters.
>>> Grouping them seems to make sense.
>>>=20
>>> Considering all these, John and I came to the conclusion that the =
HAL type syntax would probably make more sense.
>>> (Note: JSON Schema syntax does not make the parameter access as easy =
as HAL.)
>>>=20
>>> In fact, Mike Kelly (the author of HAL) and I have just submit a new =
version of draft-sakimura-oauth-meta
>>>=20
>>>   http://tools.ietf.org/html/draft-sakimura-oauth-meta-02
>>>=20
>>> The proposal was discussed at IETF 85 OAuth WG and the chairs asked =
to submit the draft.
>>> The -00 appeared in December, and this -02 has some simplification =
and the addition of the "operations" inspired by
>>> https://tools.ietf.org/html/draft-ietf-scim-api-00#section-3.5 .
>>> It is arguably a subset of HAL plus some OAuth specifics.
>>> I have not added Discovery response example, but adding them would =
makes even more sense, I think.
>>>=20
>>> Cheers,
>>>=20
>>> Nat
>>>=20
>>>=20
>>> 2013/2/13 Justin Richer 
>>>> Agreed - I didn't think that header-only was the proposal, but =
let's be explicit about the returned body always containing the URL. The =
way I read the 201 definition, it suggests (SHOULD) that you use the =
location header, but also says that the entity should refer to the new =
resource. It was my assumption that the returned JSON would still have =
some form of client-entity management URL (whether it's the HAL _links =
structure or registration_management_url or something else is still up =
for debate).
>>>>=20
>>>> -- Justin
>>>>=20
>>>>=20
>>>>=20
>>>> On 02/12/2013 10:28 AM, John Bradley wrote:
>>>>=20
>>>> Returning a location header in the 201 ids fine as long as we also =
have the same info as a claim.
>>>>=20
>>>> I think most clients will want to process the JSON and store all =
the parameters together.  Making them fish out a header makes the W3C =
happy and is the correct thing to do but taking it from a claim is what =
developers are more comfortable with.
>>>>=20
>>>> John B.
>>>>=20
>>>> On 2013-02-12, at 11:25 AM, Justin Richer  =
wrote:
>>>>=20
>>>> I'd be fine with the return from a creation request being a 201 =
instead of a 200.
>>>>=20
>>>> -- Justin
>>>>=20
>>>> On 02/11/2013 06:33 PM, Richard Harrington wrote:
>>>>=20
>>>> Since the request is an HTTP POST and a resource is created =
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5) the =
response should be an HTTP 201 Created =
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.2) which =
is supposed to include the location of the newly created resource.
>>>>=20
>>>> This is a good pattern to follow since, as you say, it does provide =
flexibility.
>>>>=20
>>>>=20
>>>>=20
>>>> On Feb 11, 2013, at 1:14 PM, Justin Richer  =
wrote:
>>>>=20
>>>> Draft -05 of OAuth Dynamic Client Registration [1] returns a URL =
pointer for the client to perform update and secret rotation actions. =
This functionality arose from discussions on the list about moving =
towards a more RESTful pattern, and Nat Sakimura proposed this approach =
in the OpenID Connect Working Group. This URL may be distinct from the =
Client Registration Endpoint URL, but draft -05 makes no promises as to =
its content, form, or structure, though it does contain implementor's =
notes on possible methods.
>>>>=20
>>>> Two questions arise from this change:
>>>> - The semantics of returning the client manipulation URL
>>>> - The syntax (derived from HAL for JSON [2], an individual I-D
>>>> submission)
>>>>=20
>>>> On semantics:
>>>>=20
>>>> Pro:
>>>> - The server has flexibility on how to define the "update" =
endpoint,
>>>> sending all clients to one URL, sending different clients to =
different
>>>> URLs, or sending clients to a URL with a baked-in query parameter
>>>> - The client can take the URL as-is and use it for all management
>>>> operations (ie, it doesn't have to generate or compose the URL =
based
>>>> on component parts)
>>>>=20
>>>> Con:
>>>> - The client must remember one more piece of information from the
>>>> server at runtime if it wants to do manipulation and management of
>>>> itself at the server (in addition to client_id, client_secret,
>>>> registration_access_token, and others)
>>>>=20
>>>> Alternatives include specifying a URL pattern for the server to use =
and all clients to follow, specifying a query parameter for the update =
action, and specifying a separate endpoint entirely and using the =
presence of items such as client_id and the registration access token to =
differentiate the requests. Note that *all* of these alternatives can be =
accommodated using the semantics described above, with the same actions =
on the client's part.
>>>>=20
>>>>=20
>>>> On syntax:
>>>>=20
>>>> Pro:
>>>> - Follows the designs of RFC5988 for link relations
>>>> - The HAL format is general, and allows for all kinds of other
>>>> information to be placed inside the _links structure
>>>> - Allows for full use of the JSON object to specify advanced
>>>> operations on the returned endpoint if desired
>>>>=20
>>>> Con:
>>>> - The rest of OAuth doesn't follow link relation guidelines (though
>>>> it's been brought up)
>>>> - The HAL format is general, and allows for all kinds of other
>>>> information to be placed inside the _links structure
>>>> - The HAL-JSON document is an expired individual I-D, and it's =
unclear
>>>> what wider adoption looks like right now
>>>>=20
>>>> Alternatives include returning the URL as a separate data member =
(registration_update_url), using HTTP headers, or using JSON Schema.
>>>>=20
>>>> -- Justin
>>>>=20
>>>>=20
>>>>=20
>>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>>>> [2] http://tools.ietf.org/html/draft-kelly-json-hal-03
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>=20
>>>=20
>>>=20
>>> --
>>> Nat Sakimura (=3Dnat)
>>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/
>>> @_nat_en
>>> _______________________________________________
>>> 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
>=20

From jricher@mitre.org  Tue Feb 12 12:06:45 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B609921F9033 for ; Tue, 12 Feb 2013 12:06:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.27
X-Spam-Level: 
X-Spam-Status: No, score=-6.27 tagged_above=-999 required=5 tests=[AWL=-0.271,  BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRC8wrmaGpZg for ; Tue, 12 Feb 2013 12:06:44 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 116E821F8DCF for ; Tue, 12 Feb 2013 12:06:44 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8E0955313053; Tue, 12 Feb 2013 15:06:43 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 75BBC531304C; Tue, 12 Feb 2013 15:06:43 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 12 Feb 2013 15:06:42 -0500
Message-ID: <511AA0A7.30302@mitre.org>
Date: Tue, 12 Feb 2013 15:05:59 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: John Bradley 
References: <51195F3D.1050006@mitre.org> <222C28CB-7F6F-4BC3-8692-40404C2DC2D3@maymount.com> <511A50C7.8080102@mitre.org> 	<511A6C49.50801@mitre.org>  <4E1F6AAD24975D4BA5B168042967394367443A52@TK5EX14MBXC285.redmond.corp.microsoft.com> <9EDD79AA-5104-49CC-A528-C5A1A1777106@ve7jtb.com> <511A9E58.1040606@mitre.org> <715762BE-886B-4E93-8E35-6356F0A18224@ve7jtb.com>
In-Reply-To: <715762BE-886B-4E93-8E35-6356F0A18224@ve7jtb.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client	self-URL
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 20:06:45 -0000

I agree with the previous statement that the AS's privacy/TOS would be 
better handled through discovery, since it's not likely to change per 
client instance.

  -- Justin

On 02/12/2013 03:04 PM, John Bradley wrote:
> There are two TOS and privacy policies.
>
> One for the AS that the client is agreeing to by registering.  Will it hold up in court?  don't know Facebook is doing this.
> The link would be a reference to a human readable file that the client (RP) can have someone look over before using the connection.
> This policy may relate to how long the client can cache info etc.
>
> The other is the privacy policy of the client that may be presented as a click through from the Authorization server.  In general the user is not explicitly accepting this, only implicitly accepting it by continuing to the RP after having been given a chance to look at it if they want.
>
> These are very US fuse on privacy but ignoring them is probably a mistake.
>
> John B.
> On 2013-02-12, at 4:56 PM, Justin Richer  wrote:
>
>> One question though: How exactly would the client, a software application, agree to the TOS? Is it supposed to fetch the content of the tos_url and do some processing on it? I wasn't under the impression that the tos_url contents were machine readable. Is it supposed to present that to the user somehow? It seems that's a better thing for the server to do at Authorization time, since it's got the user's attention.
>>
>> Remember, this is meant to be for *automated* registration. The developer of the Client has no say at this stage of the game.
>>
>> So, I think this is a bit of a red herring, to be honest.
>>
>> -- Justin
>>
>> On 02/12/2013 02:52 PM, John Bradley wrote:
>>> The current privacy policy and TOS URL in registration are the ones for the Client.
>>>
>>> Nat and I discussed adding ones for the Authorization server that the client agrees to as separate from ones that the user is agreeing to.
>>>
>>> The Authorization servers TOS would be in discovery and perhaps in the registration response to indicate what the client is agreeing to.
>>>
>>> As there rare standard relationships that cover this links Nat was speculating that they could be part of the _links object.
>>>
>>> That aside confirming the terms of service that the client has agreed to in some way is probably a good thing in the registration response.
>>>
>>> John B.
>>>
>>> On 2013-02-12, at 4:25 PM, Mike Jones  wrote:
>>>
>>>> Part of the REST/JSON philosophy is that interfaces should be as simple and developer-friendly as possible.  XML was rejected by developers, in part, because of the self-describing nature of the structure, which required extra syntax that was often not useful in practice.  Trying to re-impose that structure using extra JSON syntax conventions is just asking developers to have an allergic reaction to our specs upon encountering them.  The syntactic complexity and *surprise factor* isn't worth the limited semantic benefits of using "_links".
>>>>
>>>> Since you bring up privacy policy and terms of service, I'll note that the OAuth Dynamic Registration spec already has these fields to address those:
>>>> 	policy_url
>>>> 	tos_url
>>>>
>>>> Those have been working fine for OpenID Connect too.  There's no need to likewise convolve them to add the extra syntax that you describe below.
>>>>
>>>> (BTW, in a private thread, John Bradley pointed out that what the two of you talked about in person was actually the possibility of adding privacy policy and terms of service declarations at *discovery time*, rather than registration time.  That's a different topic, which we should discuss separately, if you want to pursue that.)
>>>>
>>>> 				Best wishes,
>>>> 				-- Mike
>>>>
>>>> -----Original Message-----
>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura
>>>> Sent: Tuesday, February 12, 2013 9:11 AM
>>>> To: Justin Richer; oauth@ietf.org
>>>> Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL
>>>>
>>>> Actually, if it is to return it in the HTTP header, then it should also use the RFC5988 Web Linking format.
>>>> Now, that is nice to have, but for many JSON programmers, I agree that it would be a hassle to obtain the header and store them in addition to the JSON. So, it is nicer to have it in JSON body.
>>>>
>>>> Re: Is "_links.self.href" grossly complex over "registration_access_url"?
>>>>
>>>> I do not think so. Accessing a flat top level parameter such as registration_access_url and _links.self.href does not make any difference from a client programmers point of view. That's a beauty of JSON. Both can be treated as a parameter name. Doing a group operation on the links makes difference though: the structured one is easier since you can just operate on _links while in case of the top level parameters, you have to have an explicit list of them and do the matches. (See below for the necessity for the grouping).
>>>>
>>>> I and John discussed this for at least half an hour F2F last week, both technically and from operation/legal point of view, for OpenID Connect Registration.
>>>> Similar points could be made to OAuth dyn reg.
>>>>
>>>> Here is what we have discussed:
>>>>
>>>> When dynamically registering the client to the server, the server probably needs to return the following:
>>>>
>>>>   * terms-of-service (terms of service of the server to the client)
>>>>   * privacy-policy (privacy policy of the server to the client)
>>>>
>>>> Both are defined in RFC5988/IANA Link Relations registry.
>>>>
>>>>
>>>> They should be returned together with
>>>>
>>>>   * self.href
>>>>
>>>> which is also defined in RFC5988/IANA Link Relations registry.
>>>>
>>>> There are several ways to do it.
>>>>
>>>>   * Return these using RFC5988 (HTTP Header)
>>>>   * Return these in entity body
>>>>       * Use HAL (or OAuth-meta)/JSON Schema
>>>>       * Use something else (e.g., a top level items)
>>>>
>>>> Returning it in the entity body has several advantage over HTTP header:
>>>>
>>>>   * They can be captured in one call;
>>>>   * They are protocol agnostic;
>>>>
>>>> We determined that these advantages outweighs the disadvantage of creating a new standard.
>>>>
>>>> The question becomes then whether to:
>>>>
>>>>   * Use HAL (or OAuth-meta)/JSON Schema
>>>>   * Use something else (e.g., a top level items)
>>>>
>>>> First, we have to consider what needs to be returned in the link/relationship category. If it were just _links.self.href, then grouping probably does not make sense. However, since we have terms-of-service and privacy-policy as well already, it may well make sense.
>>>>
>>>> Moreover, when we think of a multi-tenant authorization server that may want to use different OAuth authz and token endpoints for different tennants, it would be better to be able to return those in the registration response. Then, it would make sense to register OAuth authz and token endpoints as rel type in the IANA registry (like Bill Mills is trying to
>>>> do) and use them in a uniform manner. Note: these per tenant endpoints may support different scopes etc. as well. Then, these has to be coupled with the URIs. That is why all of RFC5988/HAL/JSON Schema uses href instead of just having the URL as the value of the parameter. The semantic relationship would often have an associated URI, and other parameters that goes with it.
>>>>
>>>> e.g.:
>>>>
>>>> {
>>>>     "_links": {
>>>>         "terms-of-service": {
>>>>             "href": "https: //server.example.com/tos"
>>>>         },
>>>>         "privacy-policy": {
>>>>             "href": "https: //server.example.com/pp"
>>>>         },
>>>>         "self": {
>>>>             "href": "https: //server.example.com/clients/1234",
>>>>             "authorize": "Bearer"
>>>>         },
>>>>         "oauth_authz": {
>>>>             "href": "https: //server.example.com/authz",
>>>>             "scopes": "openid profile email",
>>>>             "response_types": [
>>>>                 "token id_token",
>>>>                 "code id_token",
>>>>                 "token",
>>>>                 "code"
>>>>             ]
>>>>         },
>>>>         "oauth_token": {
>>>>             "href": "https: //server.example.com/token",
>>>>             "authorize": "Basic"
>>>>         }
>>>>     }
>>>> }
>>>>
>>>> In short, there are bunch of link relations that needs to be returned with additional parameters.
>>>> Grouping them seems to make sense.
>>>>
>>>> Considering all these, John and I came to the conclusion that the HAL type syntax would probably make more sense.
>>>> (Note: JSON Schema syntax does not make the parameter access as easy as HAL.)
>>>>
>>>> In fact, Mike Kelly (the author of HAL) and I have just submit a new version of draft-sakimura-oauth-meta
>>>>
>>>>    http://tools.ietf.org/html/draft-sakimura-oauth-meta-02
>>>>
>>>> The proposal was discussed at IETF 85 OAuth WG and the chairs asked to submit the draft.
>>>> The -00 appeared in December, and this -02 has some simplification and the addition of the "operations" inspired by
>>>> https://tools.ietf.org/html/draft-ietf-scim-api-00#section-3.5 .
>>>> It is arguably a subset of HAL plus some OAuth specifics.
>>>> I have not added Discovery response example, but adding them would makes even more sense, I think.
>>>>
>>>> Cheers,
>>>>
>>>> Nat
>>>>
>>>>
>>>> 2013/2/13 Justin Richer 
>>>>> Agreed - I didn't think that header-only was the proposal, but let's be explicit about the returned body always containing the URL. The way I read the 201 definition, it suggests (SHOULD) that you use the location header, but also says that the entity should refer to the new resource. It was my assumption that the returned JSON would still have some form of client-entity management URL (whether it's the HAL _links structure or registration_management_url or something else is still up for debate).
>>>>>
>>>>> -- Justin
>>>>>
>>>>>
>>>>>
>>>>> On 02/12/2013 10:28 AM, John Bradley wrote:
>>>>>
>>>>> Returning a location header in the 201 ids fine as long as we also have the same info as a claim.
>>>>>
>>>>> I think most clients will want to process the JSON and store all the parameters together.  Making them fish out a header makes the W3C happy and is the correct thing to do but taking it from a claim is what developers are more comfortable with.
>>>>>
>>>>> John B.
>>>>>
>>>>> On 2013-02-12, at 11:25 AM, Justin Richer  wrote:
>>>>>
>>>>> I'd be fine with the return from a creation request being a 201 instead of a 200.
>>>>>
>>>>> -- Justin
>>>>>
>>>>> On 02/11/2013 06:33 PM, Richard Harrington wrote:
>>>>>
>>>>> Since the request is an HTTP POST and a resource is created (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5) the response should be an HTTP 201 Created (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.2) which is supposed to include the location of the newly created resource.
>>>>>
>>>>> This is a good pattern to follow since, as you say, it does provide flexibility.
>>>>>
>>>>>
>>>>>
>>>>> On Feb 11, 2013, at 1:14 PM, Justin Richer  wrote:
>>>>>
>>>>> Draft -05 of OAuth Dynamic Client Registration [1] returns a URL pointer for the client to perform update and secret rotation actions. This functionality arose from discussions on the list about moving towards a more RESTful pattern, and Nat Sakimura proposed this approach in the OpenID Connect Working Group. This URL may be distinct from the Client Registration Endpoint URL, but draft -05 makes no promises as to its content, form, or structure, though it does contain implementor's notes on possible methods.
>>>>>
>>>>> Two questions arise from this change:
>>>>> - The semantics of returning the client manipulation URL
>>>>> - The syntax (derived from HAL for JSON [2], an individual I-D
>>>>> submission)
>>>>>
>>>>> On semantics:
>>>>>
>>>>> Pro:
>>>>> - The server has flexibility on how to define the "update" endpoint,
>>>>> sending all clients to one URL, sending different clients to different
>>>>> URLs, or sending clients to a URL with a baked-in query parameter
>>>>> - The client can take the URL as-is and use it for all management
>>>>> operations (ie, it doesn't have to generate or compose the URL based
>>>>> on component parts)
>>>>>
>>>>> Con:
>>>>> - The client must remember one more piece of information from the
>>>>> server at runtime if it wants to do manipulation and management of
>>>>> itself at the server (in addition to client_id, client_secret,
>>>>> registration_access_token, and others)
>>>>>
>>>>> Alternatives include specifying a URL pattern for the server to use and all clients to follow, specifying a query parameter for the update action, and specifying a separate endpoint entirely and using the presence of items such as client_id and the registration access token to differentiate the requests. Note that *all* of these alternatives can be accommodated using the semantics described above, with the same actions on the client's part.
>>>>>
>>>>>
>>>>> On syntax:
>>>>>
>>>>> Pro:
>>>>> - Follows the designs of RFC5988 for link relations
>>>>> - The HAL format is general, and allows for all kinds of other
>>>>> information to be placed inside the _links structure
>>>>> - Allows for full use of the JSON object to specify advanced
>>>>> operations on the returned endpoint if desired
>>>>>
>>>>> Con:
>>>>> - The rest of OAuth doesn't follow link relation guidelines (though
>>>>> it's been brought up)
>>>>> - The HAL format is general, and allows for all kinds of other
>>>>> information to be placed inside the _links structure
>>>>> - The HAL-JSON document is an expired individual I-D, and it's unclear
>>>>> what wider adoption looks like right now
>>>>>
>>>>> Alternatives include returning the URL as a separate data member (registration_update_url), using HTTP headers, or using JSON Schema.
>>>>>
>>>>> -- Justin
>>>>>
>>>>>
>>>>>
>>>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>>>>> [2] http://tools.ietf.org/html/draft-kelly-json-hal-03
>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>>
>>>> --
>>>> Nat Sakimura (=nat)
>>>> Chairman, OpenID Foundation
>>>> http://nat.sakimura.org/
>>>> @_nat_en
>>>> _______________________________________________
>>>> 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

From ve7jtb@ve7jtb.com  Tue Feb 12 12:07:57 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F2121F9059 for ; Tue, 12 Feb 2013 12:07:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.292
X-Spam-Level: 
X-Spam-Status: No, score=-3.292 tagged_above=-999 required=5 tests=[AWL=0.306,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCdKRenQfqre for ; Tue, 12 Feb 2013 12:07:56 -0800 (PST)
Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by ietfa.amsl.com (Postfix) with ESMTP id C6B4B21F9058 for ; Tue, 12 Feb 2013 12:07:55 -0800 (PST)
Received: by mail-qa0-f47.google.com with SMTP id j8so1829105qah.20 for ; Tue, 12 Feb 2013 12:07:55 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=xe0Y8z8QNrrKxLCrg+b1nEb0RAen0rIKgxpyJNqOorY=; b=Tbn5wvYULfvIqKFKj4kyGavre0cVDdYwpBRnIE2IHrubvWlWZ150VvXrWBffr1PuS1 +KEy0z2eXi0+kG96mTF4C/eFnzyD/lv/06Z9+BRJrBFpQMHIYDHpUSGuT60MZQ9RsoHB MAouy40W9LqeH2WspqlEcaYODlKESNBzINEZgANVMotWTPnEpz8/ZNoq+spRsJRGHS2Y ZMjA/kq360mld2k9l+qE2J9E1L1+O6y8xywaR2aDJ1MXt+oALTxu5KbLr48/3dOvZtjK 1b366THQiKYJRy/+q/eer1XyqsYwIlmo9ZVkKbEyS8vg1PBlz9X2JhI7J/gQ1SS5dQZV bWFg==
X-Received: by 10.229.176.216 with SMTP id bf24mr357345qcb.110.1360699675029;  Tue, 12 Feb 2013 12:07:55 -0800 (PST)
Received: from [192.168.1.213] (190-20-23-212.baf.movistar.cl. [190.20.23.212]) by mx.google.com with ESMTPS id u8sm16051616qeu.2.2013.02.12.12.07.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 12:07:53 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_5A8A8034-ECD6-424D-B487-6E68310DC5B2"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <511A9F1C.1010504@mitre.org>
Date: Tue, 12 Feb 2013 17:07:46 -0300
Message-Id: <025E3AC8-7F84-410A-A4FF-5FBBD305EA83@ve7jtb.com>
References: <51195F3B.1010701@mitre.org> <4E1F6AAD24975D4BA5B168042967394367443A16@TK5EX14MBXC285.redmond.corp.microsoft.com> <511A98DE.4030507@mitre.org> <9309CDB3-8AEE-428D-A7F0-5DAC45EFD44C@ve7jtb.com>  <040A3633-A51F-4B17-8019-5DEEC349F39C@ve7jtb.com> <511A9F1C.1010504@mitre.org>
To: Justin Richer 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQnt7I66Tpf6BwNkewy9FYvNWD4eaGlovMreFsP9wkaZKWgj7sIGZNGo9FspGAqeYAKDWlv7
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: JSON Encoded Input
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 20:07:57 -0000

--Apple-Mail=_5A8A8034-ECD6-424D-B487-6E68310DC5B2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I am fine with that as long as all the IdP tools have access to the =
entity body in some reasonable way.   That seems like the most sensible =
thing.

However given the number of people talking about encoding it in a form =
to get access to it,  we should check that it works for everyone.

John B.
On 2013-02-12, at 4:59 PM, Justin Richer  wrote:

> If that's the question, then my proposal is the Content-type is =
"application/json" and the HTTP Entity Body is the JSON document. No =
form posts or parameter names to be had here.
>=20
>  -- Justin
>=20
> On 02/12/2013 02:58 PM, John Bradley wrote:
>> Some people apparently encode the JSON as the key in a form POST,  =
some people do a form POST with a special key and the JSON as the value.=20=

>>=20
>> There appear to be a number of theories in the wild.   I am not an =
expert I just looked up code examples from several sources stack =
overflow and the like.
>>=20
>> We probably need to get input from developers who have experience =
working with different frameworks.   I think the differences have to do =
with decoding it at the receiver.
>>=20
>> We originally had registration posting JSON but we changed form =
encoding as that worked in all environments.   We just need to be sure =
we are not creating problems for people with the change back.
>>=20
>>=20
>> John B.
>>=20
>> On 2013-02-12, at 4:48 PM, Tim Bray  wrote:
>>=20
>>>=20
>>>=20
>>> On Tue, Feb 12, 2013 at 11:44 AM, John Bradley  =
wrote:
>>> Nat and I hashed out the pro's and cons of JSON requests. =20
>>>=20
>>> If we POST or PUT a JSON object we need to be specific as there rare =
several ways to do it that may work better or worse depending on the =
receiver.
>>> This needs to be looked over and one picked.
>>>=20
>>> Hm?  Not following on =93several ways=94, I=92d have thought that =
POSTing JSON is just POSTing JSON, must be missing something. -T
>>> =20
>>>=20
>>> In the other thread about the server returning the update URI and =
being able to encode the client in that if it needs to takes care of =
Servers that need that info in query parameters or the path to do the =
routing.
>>>=20
>>> The use of structure can be used to enhance readability and parsing =
of the input, and output.
>>>=20
>>> However we need to temper our urge to apply structure to everything. =
=20
>>>=20
>>> IT needs to be applied carefully otherwise we start looking like =
crazies.
>>>=20
>>> If we do it cautiously I am in favour of JSON as input.
>>>=20
>>> John B.
>>>=20
>>> On 2013-02-12, at 4:32 PM, Justin Richer  wrote:
>>>=20
>>>> Thanks for forwarding that, Mike. I'll paste in my response to =
Nat's concern here as well:
>>>> It's an increasingly well known pattern that has reasonable support =
on the server side. For PHP, I was able to find the above example via =
the top hit on Stack Overflow. In Ruby, it's a matter of something like:
>>>>=20
>>>> JSON.parse(request.body.read)
>>>>=20
>>>> depending on the web app framework. On Java/Spring, it's a matter =
of injecting the entity body as a string and handing it to a parser =
(Gson in this case):
>>>>=20
>>>> public String doApi(@RequestBody String jsonString) { JsonObject =
json =3D new JsonParser().parse(jsonString).getAsJsonObject();
>>>>=20
>>>> It's a similar read/parse setup in Node.js as well.
>>>>=20
>>>> It's true that in all of these cases you don't get to make use of =
the routing or data binding facilities (though in Spring you can do that =
for simpler domain objects using a ModelBinding), so you don't get =
niceities like the $_POST array in PHP handed to you. This is why I =
don't think it's a good idea at all to switch functionality based on the =
contents of the JSON object. It should be a domain object only, which is =
what it would be in this case.
>>>>=20
>>>> I think that the positives of using JSON from the client's =
perspective and the overall protocol design far outweigh the slightly =
increased implementation cost at the server.
>>>>=20
>>>>=20
>>>>  -- Justin
>>>>=20
>>>> On 02/12/2013 02:11 PM, Mike Jones wrote:
>>>>> FYI, this issue is also being discussed as an OpenID Connect issue =
at https://bitbucket.org/openid/connect/issue/747.  I think that Nat's =
recent comment there bears repeating on this list:
>>>>>=20
>>>>> =20
>>>>> Nat Sakimura:
>>>>>=20
>>>>> =20
>>>>> Not so sure. For example, PHP cannot get the JSON object form =
application/json POST in $_POST.
>>>>>=20
>>>>> =20
>>>>> It is OK to have a parameter like "request" that holds JSON. Then, =
you can get to it from $_POST['request']. However, if you POST the JSON =
as the POST body, then you would have to call a low level function in =
the form of:
>>>>>=20
>>>>> =20
>>>>> =20
>>>>> ```
>>>>>=20
>>>>> #!php
>>>>>=20
>>>>> =20
>>>>> $file =3D file_get_contents('php://input'); $x =3D =
json_decode($file); ```
>>>>>=20
>>>>> =20
>>>>> Not that it is harder, but it is much less known. Many PHP =
programmers will certainly goes "???".
>>>>>=20
>>>>> =20
>>>>> We need to check what would be the cases for other scripting =
languages before making the final decision.
>>>>>=20
>>>>> =20
>>>>>                                                             -- =
Mike
>>>>>=20
>>>>> =20
>>>>> -----Original Message-----
>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf Of Justin Richer
>>>>> Sent: Monday, February 11, 2013 1:15 PM
>>>>> To: oauth@ietf.org
>>>>> Subject: [OAUTH-WG] Registration: JSON Encoded Input
>>>>>=20
>>>>> =20
>>>>> Draft -05 of OAuth Dynamic Client Registration [1] switched from a =
form-encoded input that had been used by drafts -01 through -04 to a =
JSON encoded input that was used originally in -00. Note that all =
versions keep JSON-encoded output from all operations.
>>>>>=20
>>>>> =20
>>>>> Pro:
>>>>>=20
>>>>>   - JSON gives us a rich data structure so that things such as =
lists, numbers, nulls, and objects can be represented natively
>>>>>=20
>>>>>   - Allows for parallelism between the input to the endpoint and =
output from the endpoint, reducing possible translation errors between =
the two
>>>>>=20
>>>>>   - JSON specifies UTF8 encoding for all strings, forms may have =
many different encodings
>>>>>=20
>>>>>   - JSON has minimal character escaping required for most strings, =
forms require escaping for common characters such as space, slash, =
comma, etc.
>>>>>=20
>>>>> =20
>>>>> Con:
>>>>>=20
>>>>>   - the rest of OAuth is form-in/JSON-out
>>>>>=20
>>>>>   - nothing else in OAuth requires the Client to create a JSON =
object, merely to parse one
>>>>>=20
>>>>>   - form-in/JSON-out is a very widely established pattern on the =
web today
>>>>>=20
>>>>>   - Client information (client_name, client_id, etc.) is conflated =
with access information (registration_access_token, _links, expires_at, =
etc.) in root level of the same JSON object, leaving the client to =
decide what needs to (can?) be sent back to the server for update =
operations.
>>>>>=20
>>>>> =20
>>>>> =20
>>>>> Alternatives include any number of data encoding schemes, =
including form (like the old drafts), XML, ASN.1, etc.
>>>>>=20
>>>>> =20
>>>>> =20
>>>>>   -- Justin
>>>>>=20
>>>>> =20
>>>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>>>>>=20
>>>>> _______________________________________________
>>>>>=20
>>>>> OAuth mailing list
>>>>>=20
>>>>> OAuth@ietf.org
>>>>>=20
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>>=20
>>=20
>=20

--Apple-Mail=_5A8A8034-ECD6-424D-B487-6E68310DC5B2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

I am =
fine with that as long as all the IdP tools have access to the entity =
body in some reasonable way.   That seems like the most sensible =
thing.
However given the number of people talking =
about encoding it in a form to get access to it,  we should check =
that it works for everyone.

John =
B.
On 2013-02-12, at 4:59 PM, Justin Richer <jricher@mitre.org> =
wrote:

 =20

 =20

    If that's the question, then my proposal is the Content-type is
    "application/json" and the HTTP Entity Body is the JSON document. No
    form posts or parameter names to be had here.

     -- Justin

    On 02/12/2013 02:58 PM, John Bradley
      wrote:

      Some people apparently encode the JSON as the key in a form POST,
       some people do a form POST with a special key and the JSON =
as the
      value. 

      There appear to be a number of theories in the wild.   I =
am
        not an expert I just looked up code examples from several
        sources stack overflow and the like.

      We probably need to get input from developers who have
        experience working with different frameworks.   I think the
        differences have to do with decoding it at the receiver.

      We originally had registration posting JSON but we changed
        form encoding as that worked in all environments.   We just =
need
        to be sure we are not creating problems for people with the
        change back.

      John B.

          On 2013-02-12, at 4:48 PM, Tim Bray <twbray@google.com>
            wrote:

            On Tue, Feb 12, 2013 at 11:44 AM,
              John Bradley <ve7jtb@ve7jtb.com>
              wrote:

                Nat and I hashed out
                  the pro's and cons of JSON requests.  

                  If we POST or PUT a JSON object we need to be
                    specific as there rare several ways to do it that
                    may work better or worse depending on the =
receiver.
                  This needs to be looked over and one =
picked.

              Hm?  Not following on =93several ways=94, I=92d =
have
                thought that POSTing JSON is just POSTing JSON, must be
                missing something. -T

                  In the other thread about the server returning
                    the update URI and being able to encode the client
                    in that if it needs to takes care of Servers that
                    need that info in query parameters or the path to do
                    the routing.

                  The use of structure can be used to enhance
                    readability and parsing of the input, and =
output.

                  However we need to temper our urge to apply
                    structure to everything.  

                  IT needs to be applied carefully otherwise we
                    start looking like crazies.

                  If we do it cautiously I am in favour of JSON as
                    input.

                  John B.

                          On 2013-02-12, at 4:32 PM, Justin Richer
                            <jricher@mitre.org>
                            wrote:

                              Thanks for forwarding that, Mike. I'll
                              paste in my response to Nat's concern here
                              as well:

                              It's an increasingly well
                                known pattern that has reasonable
                                support on the server side. For PHP, I
                                was able to find the above example via
                                the top hit on Stack Overflow. In Ruby,
                                it's a matter of something like:

                                JSON.parse(request.body.read)

                                depending on the web app framework. On
                                Java/Spring, it's a matter of injecting
                                the entity body as a string and handing
                                it to a parser (Gson in this case):

                                public String doApi(@RequestBody String
                                jsonString) { JsonObject json =3D new
                                =
JsonParser().parse(jsonString).getAsJsonObject();

                                It's a similar read/parse setup in
                                Node.js as well.

                                It's true that in all of these cases you
                                don't get to make use of the routing or
                                data binding facilities (though in
                                Spring you can do that for simpler
                                domain objects using a ModelBinding), so
                                you don't get niceities like the $_POST
                                array in PHP handed to you. This is why
                                I don't think it's a good idea at all to
                                switch functionality based on the
                                contents of the JSON object. It should
                                be a domain object only, which is what
                                it would be in this case.

                                I think that the positives of using JSON
                                from the client's perspective and the
                                overall protocol design far outweigh the
                                slightly increased implementation cost
                                at the server.

                               -- Justin

                              On 02/12/2013 02:11 PM, Mike Jones
                                wrote:

                                FYI, this issue is also being
                                    discussed as an OpenID Connect issue
                                    at https://bitbucket.org/openid/connect/issue/747. =
;

                                    I think that Nat's recent comment
                                    there bears repeating on this =
list:

Nat
                                    Sakimura:

Not=
 so
                                    sure. For example, PHP cannot get
                                    the JSON object form
                                    application/json POST in $_POST. =

It =
is OK
                                    to have a parameter like "request"
                                    that holds JSON. Then, you can get
                                    to it from $_POST['request'].
                                    However, if you POST the JSON as the
                                    POST body, then you would have to
                                    call a low level function in the
                                    form of: 

```

                                    #!php

$file =3D
                                    file_get_contents('php://input');
                                    $x =3D json_decode($file); =
```

Not=
 that
                                    it is harder, but it is much less
                                    known. Many PHP programmers will
                                    certainly goes "???". 

We =
need to
                                    check what would be the cases for
                                    other scripting languages before
                                    making the final =
decision.

     =
            &n=
bsp;           &nbs=
p;            =
            &n=
bsp;    

                                    -- Mike

-----Original =
Message-----

                                    From: oauth-bounces@ietf.org
                                    [mailto:oauth-bounces@ietf.org]
                                    On Behalf Of Justin Richer

                                    Sent: Monday, February 11, 2013 1:15
                                    PM

                                    To: oauth@ietf.org

                                    Subject: [OAUTH-WG] Registration:
                                    JSON Encoded Input

Draft -05 of OAuth Dynamic =
Client
                                    Registration [1] switched from a
                                    form-encoded input that had been
                                    used by drafts -01 through -04 to a
                                    JSON encoded input that was used
                                    originally in -00. Note that all
                                    versions keep JSON-encoded output
                                    from all =
operations.

Pro:
  - JSON =
gives us a rich data
                                    structure so that things such as
                                    lists, numbers, nulls, and objects
                                    can be represented =
natively
  - Allows for parallelism between
                                    the input to the endpoint and output
                                    from the endpoint, reducing possible
                                    translation errors between the =
two
  - JSON specifies UTF8 encoding
                                    for all strings, forms may have many
                                    different encodings
  - =
JSON has minimal character
                                    escaping required for most strings,
                                    forms require escaping for common
                                    characters such as space, slash,
                                    comma, etc.

Con:
  - the rest =
of OAuth is
                                    form-in/JSON-out
  - =
nothing else in OAuth requires
                                    the Client to create a JSON object,
                                    merely to parse one
  - =
form-in/JSON-out is a very
                                    widely established pattern on the
                                    web today
  - Client =
information
                                    (client_name, client_id, etc.) is
                                    conflated with access information
                                    (registration_access_token, _links,
                                    expires_at, etc.) in root level of
                                    the same JSON object, leaving the
                                    client to decide what needs to
                                    (can?) be sent back to the server
                                    for update =
operations.

Alternatives include any =
number of
                                    data encoding schemes, including
                                    form (like the old drafts), XML,
                                    ASN.1, etc.

  -- =
Justin

[1] =
 http://tools.ietf.org/html=
/draft-ietf-oauth-dyn-reg-05
____________________________=
___________________
OAuth mailing list
OAuth@ietf.org<=
/p>
https://www.ietf.org/mailm=
an/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

=

--Apple-Mail=_5A8A8034-ECD6-424D-B487-6E68310DC5B2--

From bcampbell@pingidentity.com  Tue Feb 12 12:15:05 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6ECC21F86DA for ; Tue, 12 Feb 2013 12:15:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.986
X-Spam-Level: 
X-Spam-Status: No, score=-5.986 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Y7bLrQ5x0CU for ; Tue, 12 Feb 2013 12:15:04 -0800 (PST)
Received: from na3sys009aog106.obsmtp.com (na3sys009aob106.obsmtp.com [74.125.149.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5568921F86F2 for ; Tue, 12 Feb 2013 12:14:45 -0800 (PST)
Received: from mail-ie0-f198.google.com ([209.85.223.198]) (using TLSv1) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKURqitbJ/mw3/GXyVwmXhPAv/KH/TUxXL@postini.com; Tue, 12 Feb 2013 12:14:45 PST
Received: by mail-ie0-f198.google.com with SMTP id 17so2169677iea.5 for ; Tue, 12 Feb 2013 12:14:44 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=F0692LZSvlS/8FSHDtZBxqv76VTB65rg9NqGxLnvhhw=; b=bq+5p+wizP96D1P9cO598JGM8RD+/mB9lXeKHSpKKW7rb0PujJkUhoZoc+6dNg3+0K oERWLOWu0on2vXBVrsmcZ91rLhuiwXbRdKjvj8DC7eb8ROuTLjpaLQ7NnkSuqUoWCw9N pebkf2EaARhNnvDA6C7pkkJhXK+DbzHgyy6UF4PohihorNKik0a+r4rgieViibsSmgVO Kj7G1wywEGhW8bO8UdCbUkwK83/qrcptlzpaZkM+JdzVJQ3ZysxkOxMUnwhcMnC07whK Q+OsenpYzKlPj69Suk6LJ8FLoVuHecJzom23jMjAhU1RW0+SDRaXdIxYVaPSw/v43IsP IMrQ==
X-Received: by 10.50.169.106 with SMTP id ad10mr5931044igc.88.1360699780553; Tue, 12 Feb 2013 12:09:40 -0800 (PST)
X-Received: by 10.50.169.106 with SMTP id ad10mr5931011igc.88.1360699780376; Tue, 12 Feb 2013 12:09:40 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.139.8 with HTTP; Tue, 12 Feb 2013 12:09:10 -0800 (PST)
In-Reply-To: <511A9F1C.1010504@mitre.org>
References: <51195F3B.1010701@mitre.org> <4E1F6AAD24975D4BA5B168042967394367443A16@TK5EX14MBXC285.redmond.corp.microsoft.com> <511A98DE.4030507@mitre.org> <9309CDB3-8AEE-428D-A7F0-5DAC45EFD44C@ve7jtb.com>  <040A3633-A51F-4B17-8019-5DEEC349F39C@ve7jtb.com> <511A9F1C.1010504@mitre.org>
From: Brian Campbell 
Date: Tue, 12 Feb 2013 13:09:10 -0700
Message-ID: 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=e89a8f2346bb0e27d904d58c9b66
X-Gm-Message-State: ALoCoQnC5Gjif5iJLzaasYacDke7yT1Y8P14LvSAhHnZDodtViwmO3zqhhQBVAdoxwNnB2vkPT4zc6B9aLQRPDQHOLvUNwf3Ki0fYK6ydJxpqU8wnP1yhSqsnA81gwQGUrIe7yfjutod
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: JSON Encoded Input
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 20:15:06 -0000

--e89a8f2346bb0e27d904d58c9b66
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

+1 to what Pat and Justin said.

On Tue, Feb 12, 2013 at 12:59 PM, Justin Richer  wrote:

>  If that's the question, then my proposal is the Content-type is
> "application/json" and the HTTP Entity Body is the JSON document. No form
> posts or parameter names to be had here.
>
>  -- Justin
>
>
> On 02/12/2013 02:58 PM, John Bradley wrote:
>
> Some people apparently encode the JSON as the key in a form POST,  some
> people do a form POST with a special key and the JSON as the value.
>
>  There appear to be a number of theories in the wild.   I am not an
> expert I just looked up code examples from several sources stack overflow
> and the like.
>
>  We probably need to get input from developers who have experience
> working with different frameworks.   I think the differences have to do
> with decoding it at the receiver.
>
>  We originally had registration posting JSON but we changed form encoding
> as that worked in all environments.   We just need to be sure we are not
> creating problems for people with the change back.
>
>
>  John B.
>
>  On 2013-02-12, at 4:48 PM, Tim Bray  wrote:
>
>
>
> On Tue, Feb 12, 2013 at 11:44 AM, John Bradley  wrote:
>
>> Nat and I hashed out the pro's and cons of JSON requests.
>>
>>  If we POST or PUT a JSON object we need to be specific as there rare
>> several ways to do it that may work better or worse depending on the
>> receiver.
>> This needs to be looked over and one picked.
>>
>
>  Hm?  Not following on =93several ways=94, I=92d have thought that POSTin=
g JSON
> is just POSTing JSON, must be missing something. -T
>
>
>>
>>  In the other thread about the server returning the update URI and being
>> able to encode the client in that if it needs to takes care of Servers t=
hat
>> need that info in query parameters or the path to do the routing.
>>
>>  The use of structure can be used to enhance readability and parsing of
>> the input, and output.
>>
>>  However we need to temper our urge to apply structure to everything.
>>
>>  IT needs to be applied carefully otherwise we start looking like
>> crazies.
>>
>>  If we do it cautiously I am in favour of JSON as input.
>>
>>  John B.
>>
>>  On 2013-02-12, at 4:32 PM, Justin Richer  wrote:
>>
>>  Thanks for forwarding that, Mike. I'll paste in my response to Nat's
>> concern here as well:
>>
>> It's an increasingly well known pattern that has reasonable support on
>> the server side. For PHP, I was able to find the above example via the t=
op
>> hit on Stack Overflow. In Ruby, it's a matter of something like:
>>
>> JSON.parse(request.body.read)
>>
>> depending on the web app framework. On Java/Spring, it's a matter of
>> injecting the entity body as a string and handing it to a parser (Gson i=
n
>> this case):
>>
>> public String doApi(@RequestBody String jsonString) { JsonObject json =
=3D
>> new JsonParser().parse(jsonString).getAsJsonObject();
>>
>> It's a similar read/parse setup in Node.js as well.
>>
>> It's true that in all of these cases you don't get to make use of the
>> routing or data binding facilities (though in Spring you can do that for
>> simpler domain objects using a ModelBinding), so you don't get niceities
>> like the $_POST array in PHP handed to you. This is why I don't think it=
's
>> a good idea at all to switch functionality based on the contents of the
>> JSON object. It should be a domain object only, which is what it would b=
e
>> in this case.
>>
>> I think that the positives of using JSON from the client's perspective
>> and the overall protocol design far outweigh the slightly increased
>> implementation cost at the server.
>>
>>
>>
>>  -- Justin
>>
>> On 02/12/2013 02:11 PM, Mike Jones wrote:
>>
>>  FYI, this issue is also being discussed as an OpenID Connect issue at
>> https://bitbucket.org/openid/connect/issue/747.  I think that Nat's
>> recent comment there bears repeating on this list:
>>
>>
>>
>> Nat Sakimura:
>>
>>
>>
>> Not so sure. For example, PHP cannot get the JSON object form
>> application/json POST in $_POST.
>>
>>
>>
>> It is OK to have a parameter like "request" that holds JSON. Then, you
>> can get to it from $_POST['request']. However, if you POST the JSON as t=
he
>> POST body, then you would have to call a low level function in the form =
of:
>>
>>
>>
>>
>>
>> ```
>>
>> #!php
>>
>>
>>
>> $file =3D file_get_contents('php://input'); $x =3D json_decode($file); `=
``
>>
>>
>>
>> Not that it is harder, but it is much less known. Many PHP programmers
>> will certainly goes "???".
>>
>>
>>
>> We need to check what would be the cases for other scripting languages
>> before making the final decision.
>>
>>
>>
>>                                                             -- Mike
>>
>>
>>
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]
>> On Behalf Of Justin Richer
>> Sent: Monday, February 11, 2013 1:15 PM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Registration: JSON Encoded Input
>>
>>
>>
>> Draft -05 of OAuth Dynamic Client Registration [1] switched from a
>> form-encoded input that had been used by drafts -01 through -04 to a JSO=
N
>> encoded input that was used originally in -00. Note that all versions ke=
ep
>> JSON-encoded output from all operations.
>>
>>
>>
>> Pro:
>>
>>   - JSON gives us a rich data structure so that things such as lists,
>> numbers, nulls, and objects can be represented natively
>>
>>   - Allows for parallelism between the input to the endpoint and output
>> from the endpoint, reducing possible translation errors between the two
>>
>>   - JSON specifies UTF8 encoding for all strings, forms may have many
>> different encodings
>>
>>   - JSON has minimal character escaping required for most strings, forms
>> require escaping for common characters such as space, slash, comma, etc.
>>
>>
>>
>> Con:
>>
>>   - the rest of OAuth is form-in/JSON-out
>>
>>   - nothing else in OAuth requires the Client to create a JSON object,
>> merely to parse one
>>
>>   - form-in/JSON-out is a very widely established pattern on the web tod=
ay
>>
>>   - Client information (client_name, client_id, etc.) is conflated with
>> access information (registration_access_token, _links, expires_at, etc.)=
 in
>> root level of the same JSON object, leaving the client to decide what ne=
eds
>> to (can?) be sent back to the server for update operations.
>>
>>
>>
>>
>>
>> Alternatives include any number of data encoding schemes, including form
>> (like the old drafts), XML, ASN.1, etc.
>>
>>
>>
>>
>>
>>   -- Justin
>>
>>
>>
>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>>
>> _______________________________________________
>>
>> 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
>
>

--e89a8f2346bb0e27d904d58c9b66
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

+1 to what Pat and Justin said.=A0 

=

On Tue,=
 Feb 12, 2013 at 12:59 PM, Justin Richer <jricher@mitre.org>=
 wrote:

 =20
   =20
 =20

    If that's the question, then my proposal is the Content-type is
    "application/json" and the HTTP Entity Body is the JSON docum=
ent. No
    form posts or parameter names to be had here.

    =A0-- Justin

    On 02/12/2013 02:58 PM, John Bradley
      wrote:

     =20
      Some people apparently encode the JSON as the key in a form POST,
      =A0some people do a form POST with a special key and the JSON as the
      value.=A0

      There appear to be a number of theories in the wild. =A0 I am
        not an expert I just looked up code examples from several
        sources stack overflow and the like.

      We probably need to get input from developers who have
        experience working with different frameworks. =A0 I think the
        differences have to do with decoding it at the receiver.

      We originally had registration posting JSON but we changed
        form encoding as that worked in all environments. =A0 We just need
        to be sure we are not creating problems for people with the
        change back.

      John B.

          On 2013-02-12, at 4:48 PM, Tim Bray <twbray@google.com>
            wrote:

            On Tue, Feb 12, 2013 at 11:44 AM,
              John Bradley <ve7jtb@ve7jtb.com>
              wrote:

                Nat and I hashed out
                  the pro's and cons of JSON requests. =A0

                  If we POST or PUT a JSON object we need to be
                    specific as there rare several ways to do it that
                    may work better or worse depending on the receiver.
                  This needs to be looked over and one picked.

              Hm? =A0Not following on =93several ways=94, I=92d have
                thought that POSTing JSON is just POSTing JSON, must be
                missing something. -T
              =A0

                  In the other thread about the server returning
                    the update URI and being able to encode the client
                    in that if it needs to takes care of Servers that
                    need that info in query parameters or the path to do
                    the routing.

                  The use of structure can be used to enhance
                    readability and parsing of the input, and output.

                  However we need to temper our urge to apply
                    structure to everything. =A0

                  IT needs to be applied carefully otherwise we
                    start looking like crazies.

                  If we do it cautiously I am in favour of JSON as
                    input.

                  John B.

                          On 2013-02-12, at 4:32 PM, Justin Richer
                            <jricher@mitre.org>
                            wrote:

                              Thanks for forwarding that, Mike. I'll
                              paste in my response to Nat's concern her=
e
                              as well:

                              It's an increasingly well
                                known pattern that has reasonable
                                support on the server side. For PHP, I
                                was able to find the above example via
                                the top hit on Stack Overflow. In Ruby,
                                it's a matter of something like:

                                JSON.parse(request.body.read)

                                depending on the web app framework. On
                                Java/Spring, it's a matter of injecting
                                the entity body as a string and handing
                                it to a parser (Gson in this case):

                                public String doApi(@RequestBody String
                                jsonString) { JsonObject json =3D new
                                JsonParser().parse(jsonString).getAsJsonObj=
ect();

                                It's a similar read/parse setup in
                                Node.js as well.

                                It's true that in all of these cases yo=
u
                                don't get to make use of the routing or
                                data binding facilities (though in
                                Spring you can do that for simpler
                                domain objects using a ModelBinding), so
                                you don't get niceities like the $_POST
                                array in PHP handed to you. This is why
                                I don't think it's a good idea at a=
ll to
                                switch functionality based on the
                                contents of the JSON object. It should
                                be a domain object only, which is what
                                it would be in this case.

                                I think that the positives of using JSON
                                from the client's perspective and the
                                overall protocol design far outweigh the
                                slightly increased implementation cost
                                at the server.

                              =A0-- Justin

                              On 02/12/2013 02:11 PM, Mike Jones
                                wrote:

                                  FYI, this issue is also being
                                    discussed as an OpenID Connect issue
                                    at https://bitbucket.org/openid/conne=
ct/issue/747.=A0

                                    I think that Nat's recent comment
                                    there bears repeating on this list:
                                  =A0
                                  Nat
                                    Sakimura:
                                  =A0
                                  Not so
                                    sure. For example, PHP cannot get
                                    the JSON object form
                                    application/json POST in $_POST. 
                                  =A0
                                  It is OK
                                    to have a parameter like "request&=
quot;
                                    that holds JSON. Then, you can get
                                    to it from $_POST['request'].
                                    However, if you POST the JSON as the
                                    POST body, then you would have to
                                    call a low level function in the
                                    form of: 
                                  =A0
                                  =A0
                                  ```

                                    #!php
                                  =A0
                                  $file =3D
                                    file_get_contents('php://input&#=
39;);
                                    $x =3D json_decode($file); ```
                                  =A0
                                  Not that
                                    it is harder, but it is much less
                                    known. Many PHP programmers will
                                    certainly goes "???". 
                                  =A0
                                  We need to
                                    check what would be the cases for
                                    other scripting languages before
                                    making the final decision.
                                  =A0
                                  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

                                    -- Mike
                                  =A0
                                  -----Original Message-----

                                    From: oauth-bounces@ietf.org
                                    [mailto:oauth-bounces@ietf.org]
                                    On Behalf Of Justin Richer

                                    Sent: Monday, February 11, 2013 1:15
                                    PM

                                    To: oauth@ietf.org

                                    Subject: [OAUTH-WG] Registration:
                                    JSON Encoded Input
                                  =A0
                                  Draft -05 of OAuth Dynamic Client
                                    Registration [1] switched from a
                                    form-encoded input that had been
                                    used by drafts -01 through -04 to a
                                    JSON encoded input that was used
                                    originally in -00. Note that all
                                    versions keep JSON-encoded output
                                    from all operations.
                                  =A0
                                  Pro:
                                  =A0 - JSON gives us a rich data
                                    structure so that things such as
                                    lists, numbers, nulls, and objects
                                    can be represented natively
                                  =A0 - Allows for parallelism between
                                    the input to the endpoint and output
                                    from the endpoint, reducing possible
                                    translation errors between the two
                                  =A0 - JSON specifies UTF8 encoding
                                    for all strings, forms may have many
                                    different encodings
                                  =A0 - JSON has minimal character
                                    escaping required for most strings,
                                    forms require escaping for common
                                    characters such as space, slash,
                                    comma, etc.
                                  =A0
                                  Con:
                                  =A0 - the rest of OAuth is
                                    form-in/JSON-out
                                  =A0 - nothing else in OAuth requires
                                    the Client to create a JSON object,
                                    merely to parse one
                                  =A0 - form-in/JSON-out is a very
                                    widely established pattern on the
                                    web today
                                  =A0 - Client information
                                    (client_name, client_id, etc.) is
                                    conflated with access information
                                    (registration_access_token, _links,
                                    expires_at, etc.) in root level of
                                    the same JSON object, leaving the
                                    client to decide what needs to
                                    (can?) be sent back to the server
                                    for update operations.
                                  =A0
                                  =A0
                                  Alternatives include any number of
                                    data encoding schemes, including
                                    form (like the old drafts), XML,
                                    ASN.1, etc.
                                  =A0
                                  =A0
                                  =A0 -- Justin
                                  =A0
                                  [1]  http://tools.ietf.org/html/draft-ietf-oauth-=
dyn-reg-05

                                  ______________________________________=
_________
                                  OAuth mailing list
                                  OAuth@i=
etf.org
                                  https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________

                            OAuth mailing list

                            OAuth@ietf.org

                            https://www.ietf.org/mailman/listinfo/oauth<=
br>

                _______________________________________________

                OAuth mailing list

                OAuth@i=
etf.org

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

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

--e89a8f2346bb0e27d904d58c9b66--

From jricher@mitre.org  Tue Feb 12 12:17:35 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A903C21F8AED for ; Tue, 12 Feb 2013 12:17:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.565
X-Spam-Level: 
X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.033,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJCCljJxU0bn for ; Tue, 12 Feb 2013 12:17:34 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9004F21F8AC1 for ; Tue, 12 Feb 2013 12:17:33 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1EDD05313053; Tue, 12 Feb 2013 15:17:33 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 007725313061; Tue, 12 Feb 2013 15:17:32 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 12 Feb 2013 15:17:32 -0500
Message-ID: <511AA331.2060207@mitre.org>
Date: Tue, 12 Feb 2013 15:16:49 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: John Bradley 
References: <51195F3B.1010701@mitre.org> <4E1F6AAD24975D4BA5B168042967394367443A16@TK5EX14MBXC285.redmond.corp.microsoft.com> <511A98DE.4030507@mitre.org> <9309CDB3-8AEE-428D-A7F0-5DAC45EFD44C@ve7jtb.com>  <040A3633-A51F-4B17-8019-5DEEC349F39C@ve7jtb.com> <511A9F1C.1010504@mitre.org> <025E3AC8-7F84-410A-A4FF-5FBBD305EA83@ve7jtb.com>
In-Reply-To: <025E3AC8-7F84-410A-A4FF-5FBBD305EA83@ve7jtb.com>
Content-Type: multipart/alternative; boundary="------------060702060607070906070901"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: JSON Encoded Input
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 20:17:35 -0000

--------------060702060607070906070901
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit

I would then request that people come up with a real example of where it 
*won't* work. I've seen workable solutions, and even some automagic 
ones, on several major platforms in which one would write a web 
server/AS: PHP, Java (Spring and raw servlets), Ruby (rails and 
sinatra), and Node.js can all do it.

I would suggest the following text (adapted from what's in -05 right 
now) to address this:

    The Client sends an HTTP POST to the Client Registration Endpoint
    with a content type of "application/json". The HTTP Entity Payload is
    a JSON document consisting of a JSON object and all parameters as top-
    level members of that JSON object.

(Would have to be tweaked for the PUT/PATCH verbs but it's effectively 
the same.)

  -- Justin

On 02/12/2013 03:07 PM, John Bradley wrote:
> I am fine with that as long as all the IdP tools have access to the 
> entity body in some reasonable way.   That seems like the most 
> sensible thing.
>
> However given the number of people talking about encoding it in a form 
> to get access to it,  we should check that it works for everyone.
>
> John B.
> On 2013-02-12, at 4:59 PM, Justin Richer  > wrote:
>
>> If that's the question, then my proposal is the Content-type is 
>> "application/json" and the HTTP Entity Body is the JSON document. No 
>> form posts or parameter names to be had here.
>>
>>  -- Justin
>>
>> On 02/12/2013 02:58 PM, John Bradley wrote:
>>> Some people apparently encode the JSON as the key in a form POST, 
>>>  some people do a form POST with a special key and the JSON as the 
>>> value.
>>>
>>> There appear to be a number of theories in the wild.   I am not an 
>>> expert I just looked up code examples from several sources stack 
>>> overflow and the like.
>>>
>>> We probably need to get input from developers who have experience 
>>> working with different frameworks.   I think the differences have to 
>>> do with decoding it at the receiver.
>>>
>>> We originally had registration posting JSON but we changed form 
>>> encoding as that worked in all environments.   We just need to be 
>>> sure we are not creating problems for people with the change back.
>>>
>>>
>>> John B.
>>>
>>> On 2013-02-12, at 4:48 PM, Tim Bray >> > wrote:
>>>
>>>>
>>>>
>>>> On Tue, Feb 12, 2013 at 11:44 AM, John Bradley >>> > wrote:
>>>>
>>>>     Nat and I hashed out the pro's and cons of JSON requests.
>>>>
>>>>     If we POST or PUT a JSON object we need to be specific as there
>>>>     rare several ways to do it that may work better or worse
>>>>     depending on the receiver.
>>>>     This needs to be looked over and one picked.
>>>>
>>>>
>>>> Hm?  Not following on �several ways�, I�d have thought that POSTing 
>>>> JSON is just POSTing JSON, must be missing something. -T
>>>>
>>>>
>>>>     In the other thread about the server returning the update URI
>>>>     and being able to encode the client in that if it needs to
>>>>     takes care of Servers that need that info in query parameters
>>>>     or the path to do the routing.
>>>>
>>>>     The use of structure can be used to enhance readability and
>>>>     parsing of the input, and output.
>>>>
>>>>     However we need to temper our urge to apply structure to
>>>>     everything.
>>>>
>>>>     IT needs to be applied carefully otherwise we start looking
>>>>     like crazies.
>>>>
>>>>     If we do it cautiously I am in favour of JSON as input.
>>>>
>>>>     John B.
>>>>
>>>>     On 2013-02-12, at 4:32 PM, Justin Richer >>>     > wrote:
>>>>
>>>>>     Thanks for forwarding that, Mike. I'll paste in my response to
>>>>>     Nat's concern here as well:
>>>>>
>>>>>         It's an increasingly well known pattern that has
>>>>>         reasonable support on the server side. For PHP, I was able
>>>>>         to find the above example via the top hit on Stack
>>>>>         Overflow. In Ruby, it's a matter of something like:
>>>>>
>>>>>         JSON.parse(request.body.read)
>>>>>
>>>>>         depending on the web app framework. On Java/Spring, it's a
>>>>>         matter of injecting the entity body as a string and
>>>>>         handing it to a parser (Gson in this case):
>>>>>
>>>>>         public String doApi(@RequestBody String jsonString) {
>>>>>         JsonObject json = new
>>>>>         JsonParser().parse(jsonString).getAsJsonObject();
>>>>>
>>>>>         It's a similar read/parse setup in Node.js as well.
>>>>>
>>>>>         It's true that in all of these cases you don't get to make
>>>>>         use of the routing or data binding facilities (though in
>>>>>         Spring you can do that for simpler domain objects using a
>>>>>         ModelBinding), so you don't get niceities like the $_POST
>>>>>         array in PHP handed to you. This is why I don't think it's
>>>>>         a good idea at all to switch functionality based on the
>>>>>         contents of the JSON object. It should be a domain object
>>>>>         only, which is what it would be in this case.
>>>>>
>>>>>         I think that the positives of using JSON from the client's
>>>>>         perspective and the overall protocol design far outweigh
>>>>>         the slightly increased implementation cost at the server.
>>>>>
>>>>>
>>>>>
>>>>>      -- Justin
>>>>>
>>>>>     On 02/12/2013 02:11 PM, Mike Jones wrote:
>>>>>>
>>>>>>     FYI, this issue is also being discussed as an OpenID Connect
>>>>>>     issue at https://bitbucket.org/openid/connect/issue/747. I
>>>>>>     think that Nat's recent comment there bears repeating on this
>>>>>>     list:
>>>>>>
>>>>>>
>>>>>>     Nat Sakimura:
>>>>>>
>>>>>>
>>>>>>     Not so sure. For example, PHP cannot get the JSON object form
>>>>>>     application/json POST in $_POST.
>>>>>>
>>>>>>
>>>>>>     It is OK to have a parameter like "request" that holds JSON.
>>>>>>     Then, you can get to it from $_POST['request']. However, if
>>>>>>     you POST the JSON as the POST body, then you would have to
>>>>>>     call a low level function in the form of:
>>>>>>
>>>>>>
>>>>>>
>>>>>>     ```
>>>>>>
>>>>>>     #!php
>>>>>>
>>>>>>
>>>>>>     $file = file_get_contents('php://input'); $x =
>>>>>>     json_decode($file); ```
>>>>>>
>>>>>>
>>>>>>     Not that it is harder, but it is much less known. Many PHP
>>>>>>     programmers will certainly goes "???".
>>>>>>
>>>>>>
>>>>>>     We need to check what would be the cases for other scripting
>>>>>>     languages before making the final decision.
>>>>>>
>>>>>>
>>>>>>     -- Mike
>>>>>>
>>>>>>
>>>>>>     -----Original Message-----
>>>>>>     From: oauth-bounces@ietf.org 
>>>>>>     [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
>>>>>>     Sent: Monday, February 11, 2013 1:15 PM
>>>>>>     To: oauth@ietf.org 
>>>>>>     Subject: [OAUTH-WG] Registration: JSON Encoded Input
>>>>>>
>>>>>>
>>>>>>     Draft -05 of OAuth Dynamic Client Registration [1] switched
>>>>>>     from a form-encoded input that had been used by drafts -01
>>>>>>     through -04 to a JSON encoded input that was used originally
>>>>>>     in -00. Note that all versions keep JSON-encoded output from
>>>>>>     all operations.
>>>>>>
>>>>>>
>>>>>>     Pro:
>>>>>>
>>>>>>       - JSON gives us a rich data structure so that things such
>>>>>>     as lists, numbers, nulls, and objects can be represented natively
>>>>>>
>>>>>>       - Allows for parallelism between the input to the endpoint
>>>>>>     and output from the endpoint, reducing possible translation
>>>>>>     errors between the two
>>>>>>
>>>>>>       - JSON specifies UTF8 encoding for all strings, forms may
>>>>>>     have many different encodings
>>>>>>
>>>>>>       - JSON has minimal character escaping required for most
>>>>>>     strings, forms require escaping for common characters such as
>>>>>>     space, slash, comma, etc.
>>>>>>
>>>>>>
>>>>>>     Con:
>>>>>>
>>>>>>       - the rest of OAuth is form-in/JSON-out
>>>>>>
>>>>>>       - nothing else in OAuth requires the Client to create a
>>>>>>     JSON object, merely to parse one
>>>>>>
>>>>>>       - form-in/JSON-out is a very widely established pattern on
>>>>>>     the web today
>>>>>>
>>>>>>       - Client information (client_name, client_id, etc.) is
>>>>>>     conflated with access information (registration_access_token,
>>>>>>     _links, expires_at, etc.) in root level of the same JSON
>>>>>>     object, leaving the client to decide what needs to (can?) be
>>>>>>     sent back to the server for update operations.
>>>>>>
>>>>>>
>>>>>>
>>>>>>     Alternatives include any number of data encoding schemes,
>>>>>>     including form (like the old drafts), XML, ASN.1, etc.
>>>>>>
>>>>>>
>>>>>>
>>>>>>       -- Justin
>>>>>>
>>>>>>
>>>>>>     [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>>>>>>
>>>>>>     _______________________________________________
>>>>>>
>>>>>>     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
>>>>
>>>>
>>>
>>
>

--------------060702060607070906070901
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit

    I would then request that people come up with a real example of
    where it *won't* work. I've seen workable solutions, and even some
    automagic ones, on several major platforms in which one would write
    a web server/AS: PHP, Java (Spring and raw servlets), Ruby (rails
    and sinatra), and Node.js can all do it.

    I would suggest the following text (adapted from what's in -05 right
    now) to address this:

       The Client sends an HTTP POST to the Client Registration Endpoint
   with a content type of "application/json". The HTTP Entity Payload is
   a JSON document consisting of a JSON object and all parameters as top-
   level members of that JSON object.

    (Would have to be tweaked for the PUT/PATCH verbs but it's
    effectively the same.)

    �-- Justin

    On 02/12/2013 03:07 PM, John Bradley
      wrote:

      I am fine with that as long as all the IdP tools have access to
      the entity body in some reasonable way. � That seems like the most
      sensible thing.

      However given the number of people talking about encoding it
        in a form to get access to it, �we should check that it works
        for everyone.

      John B.

          On 2013-02-12, at 4:59 PM, Justin Richer <jricher@mitre.org>
            wrote:

             If that's the
              question, then my proposal is the Content-type is
              "application/json" and the HTTP Entity Body is the JSON
              document. No form posts or parameter names to be had here.

              �-- Justin

              On 02/12/2013 02:58 PM, John
                Bradley wrote:

               Some people apparently encode the JSON as
                the key in a form POST, �some people do a form POST with
                a special key and the JSON as the value.�

                There appear to be a number of theories in the
                  wild. � I am not an expert I just looked up code
                  examples from several sources stack overflow and the
                  like.

                We probably need to get input from developers who
                  have experience working with different frameworks. � I
                  think the differences have to do with decoding it at
                  the receiver.

                We originally had registration posting JSON but we
                  changed form encoding as that worked in all
                  environments. � We just need to be sure we are not
                  creating problems for people with the change back.

                John B.

                    On 2013-02-12, at 4:48 PM, Tim Bray <twbray@google.com>

                      wrote:

                      On Tue, Feb 12, 2013 at
                        11:44 AM, John Bradley <ve7jtb@ve7jtb.com>
                        wrote:

                          Nat and I
                            hashed out the pro's and cons of JSON
                            requests. �

                            If we POST or PUT a JSON object we need
                              to be specific as there rare several ways
                              to do it that may work better or worse
                              depending on the receiver.
                            This needs to be looked over and one
                              picked.

                        Hm? �Not following on �several ways�, I�d
                          have thought that POSTing JSON is just POSTing
                          JSON, must be missing something. -T
                        �

                            In the other thread about the server
                              returning the update URI and being able to
                              encode the client in that if it needs to
                              takes care of Servers that need that info
                              in query parameters or the path to do the
                              routing.

                            The use of structure can be used to
                              enhance readability and parsing of the
                              input, and output.

                            However we need to temper our urge to
                              apply structure to everything. �

                            IT needs to be applied carefully
                              otherwise we start looking like crazies.

                            If we do it cautiously I am in favour
                              of JSON as input.

                            John B.

                                    On 2013-02-12, at 4:32 PM,
                                      Justin Richer <jricher@mitre.org>

                                      wrote:

                                       Thanks for
                                        forwarding that, Mike. I'll
                                        paste in my response to Nat's
                                        concern here as well:

                                        It's an increasingly
                                          well known pattern that has
                                          reasonable support on the
                                          server side. For PHP, I was
                                          able to find the above example
                                          via the top hit on Stack
                                          Overflow. In Ruby, it's a
                                          matter of something like:

                                          JSON.parse(request.body.read)

                                          depending on the web app
                                          framework. On Java/Spring,
                                          it's a matter of injecting the
                                          entity body as a string and
                                          handing it to a parser (Gson
                                          in this case):

                                          public String
                                          doApi(@RequestBody String
                                          jsonString) { JsonObject json
                                          = new
                                          JsonParser().parse(jsonString).getAsJsonObject();

                                          It's a similar read/parse
                                          setup in Node.js as well.

                                          It's true that in all of these
                                          cases you don't get to make
                                          use of the routing or data
                                          binding facilities (though in
                                          Spring you can do that for
                                          simpler domain objects using a
                                          ModelBinding), so you don't
                                          get niceities like the $_POST
                                          array in PHP handed to you.
                                          This is why I don't think it's
                                          a good idea at all to switch
                                          functionality based on the
                                          contents of the JSON object.
                                          It should be a domain object
                                          only, which is what it would
                                          be in this case.

                                          I think that the positives of
                                          using JSON from the client's
                                          perspective and the overall
                                          protocol design far outweigh
                                          the slightly increased
                                          implementation cost at the
                                          server.

                                        �-- Justin

                                        On 02/12/2013 02:11 PM,
                                          Mike Jones wrote:

                                            FYI, this issue is also
                                              being discussed as an
                                              OpenID Connect issue at https://bitbucket.org/openid/connect/issue/747.�

                                              I think that Nat's recent
                                              comment there bears
                                              repeating on this list:
                                            �

                                            Nat

                                              Sakimura:
                                            �

                                            Not
                                              so sure. For example, PHP
                                              cannot get the JSON object
                                              form application/json POST
                                              in $_POST. 
                                            �

                                            It
                                              is OK to have a parameter
                                              like "request" that holds
                                              JSON. Then, you can get to
                                              it from $_POST['request'].
                                              However, if you POST the
                                              JSON as the POST body,
                                              then you would have to
                                              call a low level function
                                              in the form of: 
                                            �

                                            �

                                            ```

                                              #!php
                                            �

                                            $file
                                              = file_get_contents('php://input');

                                              $x = json_decode($file);
                                              ```
                                            �

                                            Not
                                              that it is harder, but it
                                              is much less known. Many
                                              PHP programmers will
                                              certainly goes "???". 
                                            �

                                            We
                                              need to check what would
                                              be the cases for other
                                              scripting languages before
                                              making the final decision.
                                            �

                                            �����������������������������������������������������������

                                              -- Mike
                                            �

                                            -----Original
                                              Message-----

                                              From: oauth-bounces@ietf.org
                                              [mailto:oauth-bounces@ietf.org]
                                              On Behalf Of Justin Richer

                                              Sent: Monday, February 11,
                                              2013 1:15 PM

                                              To: oauth@ietf.org

                                              Subject: [OAUTH-WG]
                                              Registration: JSON Encoded
                                              Input
                                            �

                                            Draft -05 of OAuth
                                              Dynamic Client
                                              Registration [1] switched
                                              from a form-encoded input
                                              that had been used by
                                              drafts -01 through -04 to
                                              a JSON encoded input that
                                              was used originally in
                                              -00. Note that all
                                              versions keep JSON-encoded
                                              output from all
                                              operations.
                                            �

                                            Pro:
                                            � - JSON gives us a rich
                                              data structure so that
                                              things such as lists,
                                              numbers, nulls, and
                                              objects can be represented
                                              natively
                                            � - Allows for
                                              parallelism between the
                                              input to the endpoint and
                                              output from the endpoint,
                                              reducing possible
                                              translation errors between
                                              the two
                                            � - JSON specifies UTF8
                                              encoding for all strings,
                                              forms may have many
                                              different encodings
                                            � - JSON has minimal
                                              character escaping
                                              required for most strings,
                                              forms require escaping for
                                              common characters such as
                                              space, slash, comma, etc.
                                            �

                                            Con:
                                            � - the rest of OAuth is
                                              form-in/JSON-out
                                            � - nothing else in OAuth
                                              requires the Client to
                                              create a JSON object,
                                              merely to parse one
                                            � - form-in/JSON-out is a
                                              very widely established
                                              pattern on the web today
                                            � - Client information
                                              (client_name, client_id,
                                              etc.) is conflated with
                                              access information
                                              (registration_access_token,
                                              _links, expires_at, etc.)
                                              in root level of the same
                                              JSON object, leaving the
                                              client to decide what
                                              needs to (can?) be sent
                                              back to the server for
                                              update operations.
                                            �

                                            �

                                            Alternatives include any
                                              number of data encoding
                                              schemes, including form
                                              (like the old drafts),
                                              XML, ASN.1, etc.
                                            �

                                            �

                                            � -- Justin
                                            �

                                            [1]  http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
                                            _______________________________________________
                                            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

--------------060702060607070906070901--

From sakimura@gmail.com  Tue Feb 12 12:26:40 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796C821F8B6D for ; Tue, 12 Feb 2013 12:26:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.907
X-Spam-Level: 
X-Spam-Status: No, score=-2.907 tagged_above=-999 required=5 tests=[AWL=0.092,  BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6NXeZsHmd4j for ; Tue, 12 Feb 2013 12:26:38 -0800 (PST)
Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by ietfa.amsl.com (Postfix) with ESMTP id 1079421F8B69 for ; Tue, 12 Feb 2013 12:26:37 -0800 (PST)
Received: by mail-lb0-f179.google.com with SMTP id j14so419966lbo.38 for ; Tue, 12 Feb 2013 12:26:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Wh2DMVGkXL/0dUdTftaiB2sdu0symN/I88hJuTti02U=; b=Bhea13ggeGyI1sPSlemfW3Dfz2kITbnlaBqbAEMm4qk0g2WbbTo5MFUkYs/sfAnGQW 31I8u6HNJ8aIGjwH3I0osNzRnMH8iUVtD3N+NagwegmpBKBL23Qi9eVzoXge9RGPS++a T1TKByju2vpK4xUuXmWY9n7JJZqHTIyDemGTqThkKWle0Lo6Mk/lib6QigGXlX3fVyZM rPl6mVxQcroGKj4FJRLem2PDiK2aC2Y1Yu93106U2ZWoXmkaXM9RoHmnSWhry5/3MfYO Rqo0A8idGYXTD3HgdTi840JOv3mU1TGhtvNoOSLJfsvtQFcKbTsTDivJDgFb2SjoduJH pFWw==
MIME-Version: 1.0
X-Received: by 10.152.109.112 with SMTP id hr16mr14732034lab.38.1360700791995;  Tue, 12 Feb 2013 12:26:31 -0800 (PST)
Received: by 10.112.14.44 with HTTP; Tue, 12 Feb 2013 12:26:31 -0800 (PST)
In-Reply-To: <511AA0A7.30302@mitre.org>
References: <51195F3D.1050006@mitre.org> <222C28CB-7F6F-4BC3-8692-40404C2DC2D3@maymount.com> <511A50C7.8080102@mitre.org>  <511A6C49.50801@mitre.org>  <4E1F6AAD24975D4BA5B168042967394367443A52@TK5EX14MBXC285.redmond.corp.microsoft.com> <9EDD79AA-5104-49CC-A528-C5A1A1777106@ve7jtb.com> <511A9E58.1040606@mitre.org> <715762BE-886B-4E93-8E35-6356F0A18224@ve7jtb.com> <511AA0A7.30302@mitre.org>
Date: Wed, 13 Feb 2013 05:26:31 +0900
Message-ID: 
From: Nat Sakimura 
To: Justin Richer 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 20:26:42 -0000

Let me explain a bit more.

A trust framework may supply several ToS and Privacy Policy options
much like CC licenses.
If we want to really automate the things, you really need it.
Otherwise, the service's owner need to go read the ToS and Privacy
Policy in person and makes the dynamic registration not so dynamic.
Those option should be available through Discovery.

In Discovery, the server may provide multiple options,
out of which the client picks one. Think of something like Basic and
Premium service. In the Registration response, then, should be
the one that was picked by the client / assigned by the server.

(The notion is closely related to the implicit consent model for the
end users, which is in active discussion in bunch of places, by the way.)

Nat

2013/2/13 Justin Richer :
> I agree with the previous statement that the AS's privacy/TOS would be
> better handled through discovery, since it's not likely to change per client
> instance.
>
>  -- Justin
>
>
> On 02/12/2013 03:04 PM, John Bradley wrote:
>>
>> There are two TOS and privacy policies.
>>
>> One for the AS that the client is agreeing to by registering.  Will it
>> hold up in court?  don't know Facebook is doing this.
>> The link would be a reference to a human readable file that the client
>> (RP) can have someone look over before using the connection.
>> This policy may relate to how long the client can cache info etc.
>>
>> The other is the privacy policy of the client that may be presented as a
>> click through from the Authorization server.  In general the user is not
>> explicitly accepting this, only implicitly accepting it by continuing to the
>> RP after having been given a chance to look at it if they want.
>>
>> These are very US fuse on privacy but ignoring them is probably a mistake.
>>
>> John B.
>> On 2013-02-12, at 4:56 PM, Justin Richer  wrote:
>>
>>> One question though: How exactly would the client, a software
>>> application, agree to the TOS? Is it supposed to fetch the content of the
>>> tos_url and do some processing on it? I wasn't under the impression that the
>>> tos_url contents were machine readable. Is it supposed to present that to
>>> the user somehow? It seems that's a better thing for the server to do at
>>> Authorization time, since it's got the user's attention.
>>>
>>> Remember, this is meant to be for *automated* registration. The developer
>>> of the Client has no say at this stage of the game.
>>>
>>> So, I think this is a bit of a red herring, to be honest.
>>>
>>> -- Justin
>>>
>>> On 02/12/2013 02:52 PM, John Bradley wrote:
>>>>
>>>> The current privacy policy and TOS URL in registration are the ones for
>>>> the Client.
>>>>
>>>> Nat and I discussed adding ones for the Authorization server that the
>>>> client agrees to as separate from ones that the user is agreeing to.
>>>>
>>>> The Authorization servers TOS would be in discovery and perhaps in the
>>>> registration response to indicate what the client is agreeing to.
>>>>
>>>> As there rare standard relationships that cover this links Nat was
>>>> speculating that they could be part of the _links object.
>>>>
>>>> That aside confirming the terms of service that the client has agreed to
>>>> in some way is probably a good thing in the registration response.
>>>>
>>>> John B.
>>>>
>>>> On 2013-02-12, at 4:25 PM, Mike Jones 
>>>> wrote:
>>>>
>>>>> Part of the REST/JSON philosophy is that interfaces should be as simple
>>>>> and developer-friendly as possible.  XML was rejected by developers, in
>>>>> part, because of the self-describing nature of the structure, which required
>>>>> extra syntax that was often not useful in practice.  Trying to re-impose
>>>>> that structure using extra JSON syntax conventions is just asking developers
>>>>> to have an allergic reaction to our specs upon encountering them.  The
>>>>> syntactic complexity and *surprise factor* isn't worth the limited semantic
>>>>> benefits of using "_links".
>>>>>
>>>>> Since you bring up privacy policy and terms of service, I'll note that
>>>>> the OAuth Dynamic Registration spec already has these fields to address
>>>>> those:
>>>>>         policy_url
>>>>>         tos_url
>>>>>
>>>>> Those have been working fine for OpenID Connect too.  There's no need
>>>>> to likewise convolve them to add the extra syntax that you describe below.
>>>>>
>>>>> (BTW, in a private thread, John Bradley pointed out that what the two
>>>>> of you talked about in person was actually the possibility of adding privacy
>>>>> policy and terms of service declarations at *discovery time*, rather than
>>>>> registration time.  That's a different topic, which we should discuss
>>>>> separately, if you want to pursue that.)
>>>>>
>>>>>                                 Best wishes,
>>>>>                                 -- Mike
>>>>>
>>>>> -----Original Message-----
>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>>>>> Of Nat Sakimura
>>>>> Sent: Tuesday, February 12, 2013 9:11 AM
>>>>> To: Justin Richer; oauth@ietf.org
>>>>> Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client
>>>>> self-URL
>>>>>
>>>>> Actually, if it is to return it in the HTTP header, then it should also
>>>>> use the RFC5988 Web Linking format.
>>>>> Now, that is nice to have, but for many JSON programmers, I agree that
>>>>> it would be a hassle to obtain the header and store them in addition to the
>>>>> JSON. So, it is nicer to have it in JSON body.
>>>>>
>>>>> Re: Is "_links.self.href" grossly complex over
>>>>> "registration_access_url"?
>>>>>
>>>>> I do not think so. Accessing a flat top level parameter such as
>>>>> registration_access_url and _links.self.href does not make any difference
>>>>> from a client programmers point of view. That's a beauty of JSON. Both can
>>>>> be treated as a parameter name. Doing a group operation on the links makes
>>>>> difference though: the structured one is easier since you can just operate
>>>>> on _links while in case of the top level parameters, you have to have an
>>>>> explicit list of them and do the matches. (See below for the necessity for
>>>>> the grouping).
>>>>>
>>>>> I and John discussed this for at least half an hour F2F last week, both
>>>>> technically and from operation/legal point of view, for OpenID Connect
>>>>> Registration.
>>>>> Similar points could be made to OAuth dyn reg.
>>>>>
>>>>> Here is what we have discussed:
>>>>>
>>>>> When dynamically registering the client to the server, the server
>>>>> probably needs to return the following:
>>>>>
>>>>>   * terms-of-service (terms of service of the server to the client)
>>>>>   * privacy-policy (privacy policy of the server to the client)
>>>>>
>>>>> Both are defined in RFC5988/IANA Link Relations registry.
>>>>>
>>>>>
>>>>> They should be returned together with
>>>>>
>>>>>   * self.href
>>>>>
>>>>> which is also defined in RFC5988/IANA Link Relations registry.
>>>>>
>>>>> There are several ways to do it.
>>>>>
>>>>>   * Return these using RFC5988 (HTTP Header)
>>>>>   * Return these in entity body
>>>>>       * Use HAL (or OAuth-meta)/JSON Schema
>>>>>       * Use something else (e.g., a top level items)
>>>>>
>>>>> Returning it in the entity body has several advantage over HTTP header:
>>>>>
>>>>>   * They can be captured in one call;
>>>>>   * They are protocol agnostic;
>>>>>
>>>>> We determined that these advantages outweighs the disadvantage of
>>>>> creating a new standard.
>>>>>
>>>>> The question becomes then whether to:
>>>>>
>>>>>   * Use HAL (or OAuth-meta)/JSON Schema
>>>>>   * Use something else (e.g., a top level items)
>>>>>
>>>>> First, we have to consider what needs to be returned in the
>>>>> link/relationship category. If it were just _links.self.href, then grouping
>>>>> probably does not make sense. However, since we have terms-of-service and
>>>>> privacy-policy as well already, it may well make sense.
>>>>>
>>>>> Moreover, when we think of a multi-tenant authorization server that may
>>>>> want to use different OAuth authz and token endpoints for different
>>>>> tennants, it would be better to be able to return those in the registration
>>>>> response. Then, it would make sense to register OAuth authz and token
>>>>> endpoints as rel type in the IANA registry (like Bill Mills is trying to
>>>>> do) and use them in a uniform manner. Note: these per tenant endpoints
>>>>> may support different scopes etc. as well. Then, these has to be coupled
>>>>> with the URIs. That is why all of RFC5988/HAL/JSON Schema uses href instead
>>>>> of just having the URL as the value of the parameter. The semantic
>>>>> relationship would often have an associated URI, and other parameters that
>>>>> goes with it.
>>>>>
>>>>> e.g.:
>>>>>
>>>>> {
>>>>>     "_links": {
>>>>>         "terms-of-service": {
>>>>>             "href": "https: //server.example.com/tos"
>>>>>         },
>>>>>         "privacy-policy": {
>>>>>             "href": "https: //server.example.com/pp"
>>>>>         },
>>>>>         "self": {
>>>>>             "href": "https: //server.example.com/clients/1234",
>>>>>             "authorize": "Bearer"
>>>>>         },
>>>>>         "oauth_authz": {
>>>>>             "href": "https: //server.example.com/authz",
>>>>>             "scopes": "openid profile email",
>>>>>             "response_types": [
>>>>>                 "token id_token",
>>>>>                 "code id_token",
>>>>>                 "token",
>>>>>                 "code"
>>>>>             ]
>>>>>         },
>>>>>         "oauth_token": {
>>>>>             "href": "https: //server.example.com/token",
>>>>>             "authorize": "Basic"
>>>>>         }
>>>>>     }
>>>>> }
>>>>>
>>>>> In short, there are bunch of link relations that needs to be returned
>>>>> with additional parameters.
>>>>> Grouping them seems to make sense.
>>>>>
>>>>> Considering all these, John and I came to the conclusion that the HAL
>>>>> type syntax would probably make more sense.
>>>>> (Note: JSON Schema syntax does not make the parameter access as easy as
>>>>> HAL.)
>>>>>
>>>>> In fact, Mike Kelly (the author of HAL) and I have just submit a new
>>>>> version of draft-sakimura-oauth-meta
>>>>>
>>>>>    http://tools.ietf.org/html/draft-sakimura-oauth-meta-02
>>>>>
>>>>> The proposal was discussed at IETF 85 OAuth WG and the chairs asked to
>>>>> submit the draft.
>>>>> The -00 appeared in December, and this -02 has some simplification and
>>>>> the addition of the "operations" inspired by
>>>>> https://tools.ietf.org/html/draft-ietf-scim-api-00#section-3.5 .
>>>>> It is arguably a subset of HAL plus some OAuth specifics.
>>>>> I have not added Discovery response example, but adding them would
>>>>> makes even more sense, I think.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Nat
>>>>>
>>>>>
>>>>> 2013/2/13 Justin Richer 
>>>>>>
>>>>>> Agreed - I didn't think that header-only was the proposal, but let's
>>>>>> be explicit about the returned body always containing the URL. The way I
>>>>>> read the 201 definition, it suggests (SHOULD) that you use the location
>>>>>> header, but also says that the entity should refer to the new resource. It
>>>>>> was my assumption that the returned JSON would still have some form of
>>>>>> client-entity management URL (whether it's the HAL _links structure or
>>>>>> registration_management_url or something else is still up for debate).
>>>>>>
>>>>>> -- Justin
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 02/12/2013 10:28 AM, John Bradley wrote:
>>>>>>
>>>>>> Returning a location header in the 201 ids fine as long as we also
>>>>>> have the same info as a claim.
>>>>>>
>>>>>> I think most clients will want to process the JSON and store all the
>>>>>> parameters together.  Making them fish out a header makes the W3C happy and
>>>>>> is the correct thing to do but taking it from a claim is what developers are
>>>>>> more comfortable with.
>>>>>>
>>>>>> John B.
>>>>>>
>>>>>> On 2013-02-12, at 11:25 AM, Justin Richer  wrote:
>>>>>>
>>>>>> I'd be fine with the return from a creation request being a 201
>>>>>> instead of a 200.
>>>>>>
>>>>>> -- Justin
>>>>>>
>>>>>> On 02/11/2013 06:33 PM, Richard Harrington wrote:
>>>>>>
>>>>>> Since the request is an HTTP POST and a resource is created
>>>>>> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5) the response
>>>>>> should be an HTTP 201 Created
>>>>>> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.2) which is
>>>>>> supposed to include the location of the newly created resource.
>>>>>>
>>>>>> This is a good pattern to follow since, as you say, it does provide
>>>>>> flexibility.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Feb 11, 2013, at 1:14 PM, Justin Richer  wrote:
>>>>>>
>>>>>> Draft -05 of OAuth Dynamic Client Registration [1] returns a URL
>>>>>> pointer for the client to perform update and secret rotation actions. This
>>>>>> functionality arose from discussions on the list about moving towards a more
>>>>>> RESTful pattern, and Nat Sakimura proposed this approach in the OpenID
>>>>>> Connect Working Group. This URL may be distinct from the Client Registration
>>>>>> Endpoint URL, but draft -05 makes no promises as to its content, form, or
>>>>>> structure, though it does contain implementor's notes on possible methods.
>>>>>>
>>>>>> Two questions arise from this change:
>>>>>> - The semantics of returning the client manipulation URL
>>>>>> - The syntax (derived from HAL for JSON [2], an individual I-D
>>>>>> submission)
>>>>>>
>>>>>> On semantics:
>>>>>>
>>>>>> Pro:
>>>>>> - The server has flexibility on how to define the "update" endpoint,
>>>>>> sending all clients to one URL, sending different clients to different
>>>>>> URLs, or sending clients to a URL with a baked-in query parameter
>>>>>> - The client can take the URL as-is and use it for all management
>>>>>> operations (ie, it doesn't have to generate or compose the URL based
>>>>>> on component parts)
>>>>>>
>>>>>> Con:
>>>>>> - The client must remember one more piece of information from the
>>>>>> server at runtime if it wants to do manipulation and management of
>>>>>> itself at the server (in addition to client_id, client_secret,
>>>>>> registration_access_token, and others)
>>>>>>
>>>>>> Alternatives include specifying a URL pattern for the server to use
>>>>>> and all clients to follow, specifying a query parameter for the update
>>>>>> action, and specifying a separate endpoint entirely and using the presence
>>>>>> of items such as client_id and the registration access token to
>>>>>> differentiate the requests. Note that *all* of these alternatives can be
>>>>>> accommodated using the semantics described above, with the same actions on
>>>>>> the client's part.
>>>>>>
>>>>>>
>>>>>> On syntax:
>>>>>>
>>>>>> Pro:
>>>>>> - Follows the designs of RFC5988 for link relations
>>>>>> - The HAL format is general, and allows for all kinds of other
>>>>>> information to be placed inside the _links structure
>>>>>> - Allows for full use of the JSON object to specify advanced
>>>>>> operations on the returned endpoint if desired
>>>>>>
>>>>>> Con:
>>>>>> - The rest of OAuth doesn't follow link relation guidelines (though
>>>>>> it's been brought up)
>>>>>> - The HAL format is general, and allows for all kinds of other
>>>>>> information to be placed inside the _links structure
>>>>>> - The HAL-JSON document is an expired individual I-D, and it's unclear
>>>>>> what wider adoption looks like right now
>>>>>>
>>>>>> Alternatives include returning the URL as a separate data member
>>>>>> (registration_update_url), using HTTP headers, or using JSON Schema.
>>>>>>
>>>>>> -- Justin
>>>>>>
>>>>>>
>>>>>>
>>>>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>>>>>> [2] http://tools.ietf.org/html/draft-kelly-json-hal-03
>>>>>> _______________________________________________
>>>>>> 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
>>>>>>
>>>>>
>>>>> --
>>>>> Nat Sakimura (=nat)
>>>>> Chairman, OpenID Foundation
>>>>> http://nat.sakimura.org/
>>>>> @_nat_en
>>>>> _______________________________________________
>>>>> 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
>
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

From ve7jtb@ve7jtb.com  Tue Feb 12 12:35:54 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7638921F8B0E for ; Tue, 12 Feb 2013 12:35:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.307
X-Spam-Level: 
X-Spam-Status: No, score=-3.307 tagged_above=-999 required=5 tests=[AWL=0.291,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORXYYd5VwDtC for ; Tue, 12 Feb 2013 12:35:52 -0800 (PST)
Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7297221F8AC1 for ; Tue, 12 Feb 2013 12:35:52 -0800 (PST)
Received: by mail-qa0-f54.google.com with SMTP id hg5so255098qab.13 for ; Tue, 12 Feb 2013 12:35:51 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=S3ottP8JdjNDPi0IU6orLs+57B8RiZtbjpUnDB0o+Wk=; b=OUxw1i3WL43CIMmHlRAW38v3nOjedSh6O4acN1MJfPI1eeMMEGmn2EQf5dq8x/H+i3 VfPfqqfCUva05iJ8jQOMzwUigXSlq7epGL5s2Bm4xNI81k1kWMXrUtzvLqPqM4FnP9Od AuCAXmu+9RbSa4IlVssWvxL7/762gCkCt/fd9+KZZY8qzJbul44B75JWWG1CEDDEr0Lh GuL0PB5BarSl5gwzKFCYa+VDio+T+QD5M23gya9dxAKesqnOGNxL3lTOzapFUyIWkqzG GBgWkrehfu42s10eaiXAW7hEJhZ06j388JrfT0NbqB80PAneuvHLAzPeJAQkxeObTfqo G/Wg==
X-Received: by 10.224.216.65 with SMTP id hh1mr7160432qab.43.1360701351361; Tue, 12 Feb 2013 12:35:51 -0800 (PST)
Received: from [192.168.1.213] (190-20-23-212.baf.movistar.cl. [190.20.23.212]) by mx.google.com with ESMTPS id 8sm16098713qed.6.2013.02.12.12.35.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 12:35:49 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_F02EC937-EB24-4D0F-818B-A78F8B8E522F"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <511AA331.2060207@mitre.org>
Date: Tue, 12 Feb 2013 17:35:42 -0300
Message-Id: <498782B5-9FFA-47F2-A21D-5FDF842C7B6B@ve7jtb.com>
References: <51195F3B.1010701@mitre.org> <4E1F6AAD24975D4BA5B168042967394367443A16@TK5EX14MBXC285.redmond.corp.microsoft.com> <511A98DE.4030507@mitre.org> <9309CDB3-8AEE-428D-A7F0-5DAC45EFD44C@ve7jtb.com>  <040A3633-A51F-4B17-8019-5DEEC349F39C@ve7jtb.com> <511A9F1C.1010504@mitre.org> <025E3AC8-7F84-410A-A4FF-5FBBD305EA83@ve7jtb.com> <511AA331.2060207@mitre.org>
To: Justin Richer 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQlDy5o9A/QRky47Galmeu72kg27TR+VOLdMIMMiKbEyF48CRwehd3WFRB+WPOrdmSgsEUrZ
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: JSON Encoded Input
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 20:35:54 -0000

--Apple-Mail=_F02EC937-EB24-4D0F-818B-A78F8B8E522F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I am OK with that language.

On 2013-02-12, at 5:16 PM, Justin Richer  wrote:

> I would then request that people come up with a real example of where =
it *won't* work. I've seen workable solutions, and even some automagic =
ones, on several major platforms in which one would write a web =
server/AS: PHP, Java (Spring and raw servlets), Ruby (rails and =
sinatra), and Node.js can all do it.
>=20
> I would suggest the following text (adapted from what's in -05 right =
now) to address this:
>=20
>    The Client sends an HTTP POST to the Client Registration Endpoint
>    with a content type of "application/json". The HTTP Entity Payload =
is
>    a JSON document consisting of a JSON object and all parameters as =
top-
>    level members of that JSON object.
>=20
> (Would have to be tweaked for the PUT/PATCH verbs but it's effectively =
the same.)
>=20
>=20
>  -- Justin
>=20
> On 02/12/2013 03:07 PM, John Bradley wrote:
>> I am fine with that as long as all the IdP tools have access to the =
entity body in some reasonable way.   That seems like the most sensible =
thing.
>>=20
>> However given the number of people talking about encoding it in a =
form to get access to it,  we should check that it works for everyone.
>>=20
>> John B.
>> On 2013-02-12, at 4:59 PM, Justin Richer  wrote:
>>=20
>>> If that's the question, then my proposal is the Content-type is =
"application/json" and the HTTP Entity Body is the JSON document. No =
form posts or parameter names to be had here.
>>>=20
>>>  -- Justin
>>>=20
>>> On 02/12/2013 02:58 PM, John Bradley wrote:
>>>> Some people apparently encode the JSON as the key in a form POST,  =
some people do a form POST with a special key and the JSON as the value.=20=

>>>>=20
>>>> There appear to be a number of theories in the wild.   I am not an =
expert I just looked up code examples from several sources stack =
overflow and the like.
>>>>=20
>>>> We probably need to get input from developers who have experience =
working with different frameworks.   I think the differences have to do =
with decoding it at the receiver.
>>>>=20
>>>> We originally had registration posting JSON but we changed form =
encoding as that worked in all environments.   We just need to be sure =
we are not creating problems for people with the change back.
>>>>=20
>>>>=20
>>>> John B.
>>>>=20
>>>> On 2013-02-12, at 4:48 PM, Tim Bray  wrote:
>>>>=20
>>>>>=20
>>>>>=20
>>>>> On Tue, Feb 12, 2013 at 11:44 AM, John Bradley  =
wrote:
>>>>> Nat and I hashed out the pro's and cons of JSON requests. =20
>>>>>=20
>>>>> If we POST or PUT a JSON object we need to be specific as there =
rare several ways to do it that may work better or worse depending on =
the receiver.
>>>>> This needs to be looked over and one picked.
>>>>>=20
>>>>> Hm?  Not following on =93several ways=94, I=92d have thought that =
POSTing JSON is just POSTing JSON, must be missing something. -T
>>>>> =20
>>>>>=20
>>>>> In the other thread about the server returning the update URI and =
being able to encode the client in that if it needs to takes care of =
Servers that need that info in query parameters or the path to do the =
routing.
>>>>>=20
>>>>> The use of structure can be used to enhance readability and =
parsing of the input, and output.
>>>>>=20
>>>>> However we need to temper our urge to apply structure to =
everything. =20
>>>>>=20
>>>>> IT needs to be applied carefully otherwise we start looking like =
crazies.
>>>>>=20
>>>>> If we do it cautiously I am in favour of JSON as input.
>>>>>=20
>>>>> John B.
>>>>>=20
>>>>> On 2013-02-12, at 4:32 PM, Justin Richer  =
wrote:
>>>>>=20
>>>>>> Thanks for forwarding that, Mike. I'll paste in my response to =
Nat's concern here as well:
>>>>>> It's an increasingly well known pattern that has reasonable =
support on the server side. For PHP, I was able to find the above =
example via the top hit on Stack Overflow. In Ruby, it's a matter of =
something like:
>>>>>>=20
>>>>>> JSON.parse(request.body.read)
>>>>>>=20
>>>>>> depending on the web app framework. On Java/Spring, it's a matter =
of injecting the entity body as a string and handing it to a parser =
(Gson in this case):
>>>>>>=20
>>>>>> public String doApi(@RequestBody String jsonString) { JsonObject =
json =3D new JsonParser().parse(jsonString).getAsJsonObject();
>>>>>>=20
>>>>>> It's a similar read/parse setup in Node.js as well.
>>>>>>=20
>>>>>> It's true that in all of these cases you don't get to make use of =
the routing or data binding facilities (though in Spring you can do that =
for simpler domain objects using a ModelBinding), so you don't get =
niceities like the $_POST array in PHP handed to you. This is why I =
don't think it's a good idea at all to switch functionality based on the =
contents of the JSON object. It should be a domain object only, which is =
what it would be in this case.
>>>>>>=20
>>>>>> I think that the positives of using JSON from the client's =
perspective and the overall protocol design far outweigh the slightly =
increased implementation cost at the server.
>>>>>>=20
>>>>>>=20
>>>>>>  -- Justin
>>>>>>=20
>>>>>> On 02/12/2013 02:11 PM, Mike Jones wrote:
>>>>>>> FYI, this issue is also being discussed as an OpenID Connect =
issue at https://bitbucket.org/openid/connect/issue/747.  I think that =
Nat's recent comment there bears repeating on this list:
>>>>>>>=20
>>>>>>> =20
>>>>>>> Nat Sakimura:
>>>>>>>=20
>>>>>>> =20
>>>>>>> Not so sure. For example, PHP cannot get the JSON object form =
application/json POST in $_POST.
>>>>>>>=20
>>>>>>> =20
>>>>>>> It is OK to have a parameter like "request" that holds JSON. =
Then, you can get to it from $_POST['request']. However, if you POST the =
JSON as the POST body, then you would have to call a low level function =
in the form of:
>>>>>>>=20
>>>>>>> =20
>>>>>>> =20
>>>>>>> ```
>>>>>>>=20
>>>>>>> #!php
>>>>>>>=20
>>>>>>> =20
>>>>>>> $file =3D file_get_contents('php://input'); $x =3D =
json_decode($file); ```
>>>>>>>=20
>>>>>>> =20
>>>>>>> Not that it is harder, but it is much less known. Many PHP =
programmers will certainly goes "???".
>>>>>>>=20
>>>>>>> =20
>>>>>>> We need to check what would be the cases for other scripting =
languages before making the final decision.
>>>>>>>=20
>>>>>>> =20
>>>>>>>                                                             -- =
Mike
>>>>>>>=20
>>>>>>> =20
>>>>>>> -----Original Message-----
>>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf Of Justin Richer
>>>>>>> Sent: Monday, February 11, 2013 1:15 PM
>>>>>>> To: oauth@ietf.org
>>>>>>> Subject: [OAUTH-WG] Registration: JSON Encoded Input
>>>>>>>=20
>>>>>>> =20
>>>>>>> Draft -05 of OAuth Dynamic Client Registration [1] switched from =
a form-encoded input that had been used by drafts -01 through -04 to a =
JSON encoded input that was used originally in -00. Note that all =
versions keep JSON-encoded output from all operations.
>>>>>>>=20
>>>>>>> =20
>>>>>>> Pro:
>>>>>>>=20
>>>>>>>   - JSON gives us a rich data structure so that things such as =
lists, numbers, nulls, and objects can be represented natively
>>>>>>>=20
>>>>>>>   - Allows for parallelism between the input to the endpoint and =
output from the endpoint, reducing possible translation errors between =
the two
>>>>>>>=20
>>>>>>>   - JSON specifies UTF8 encoding for all strings, forms may have =
many different encodings
>>>>>>>=20
>>>>>>>   - JSON has minimal character escaping required for most =
strings, forms require escaping for common characters such as space, =
slash, comma, etc.
>>>>>>>=20
>>>>>>> =20
>>>>>>> Con:
>>>>>>>=20
>>>>>>>   - the rest of OAuth is form-in/JSON-out
>>>>>>>=20
>>>>>>>   - nothing else in OAuth requires the Client to create a JSON =
object, merely to parse one
>>>>>>>=20
>>>>>>>   - form-in/JSON-out is a very widely established pattern on the =
web today
>>>>>>>=20
>>>>>>>   - Client information (client_name, client_id, etc.) is =
conflated with access information (registration_access_token, _links, =
expires_at, etc.) in root level of the same JSON object, leaving the =
client to decide what needs to (can?) be sent back to the server for =
update operations.
>>>>>>>=20
>>>>>>> =20
>>>>>>> =20
>>>>>>> Alternatives include any number of data encoding schemes, =
including form (like the old drafts), XML, ASN.1, etc.
>>>>>>>=20
>>>>>>> =20
>>>>>>> =20
>>>>>>>   -- Justin
>>>>>>>=20
>>>>>>> =20
>>>>>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>>=20
>>>>>>> OAuth mailing list
>>>>>>>=20
>>>>>>> OAuth@ietf.org
>>>>>>>=20
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>=20
>>>>>=20
>>>>=20
>>>=20
>>=20
>=20

--Apple-Mail=_F02EC937-EB24-4D0F-818B-A78F8B8E522F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

I am =
OK with that language.
On 2013-02-12, at 5:16 PM, =
Justin Richer <jricher@mitre.org> =
wrote:

 =20

 =20

    I would then request that people come up with a real example of
    where it *won't* work. I've seen workable solutions, and even some
    automagic ones, on several major platforms in which one would write
    a web server/AS: PHP, Java (Spring and raw servlets), Ruby (rails
    and sinatra), and Node.js can all do it.

    I would suggest the following text (adapted from what's in -05 right
    now) to address this:

       The Client sends an HTTP POST to the =
Client Registration Endpoint
   with a content type of "application/json". The HTTP Entity Payload is
   a JSON document consisting of a JSON object and all parameters as =
top-
   level members of that JSON object.

    (Would have to be tweaked for the PUT/PATCH verbs but it's
    effectively the same.)

     -- Justin

    On 02/12/2013 03:07 PM, John Bradley
      wrote:

      I am fine with that as long as all the IdP tools have access to
      the entity body in some reasonable way.   That seems like the =
most
      sensible thing.

      However given the number of people talking about encoding it
        in a form to get access to it,  we should check that it =
works
        for everyone.

      John B.

          On 2013-02-12, at 4:59 PM, Justin Richer <jricher@mitre.org>
            wrote:

             If that's the
              question, then my proposal is the Content-type is
              "application/json" and the HTTP Entity Body is the JSON
              document. No form posts or parameter names to be had =
here.

               -- Justin

              On 02/12/2013 02:58 PM, =
John
                Bradley wrote:

               Some people apparently encode the JSON as
                the key in a form POST,  some people do a form POST =
with
                a special key and the JSON as the value. 

                There appear to be a number of theories in the
                  wild.   I am not an expert I just looked up code
                  examples from several sources stack overflow and the
                  like.

                We probably need to get input from developers who
                  have experience working with different frameworks. =
  I
                  think the differences have to do with decoding it at
                  the receiver.

                We originally had registration posting JSON but we
                  changed form encoding as that worked in all
                  environments.   We just need to be sure we are =
not
                  creating problems for people with the change =
back.

                John B.

                    On 2013-02-12, at 4:48 PM, Tim Bray <twbray@google.com>

                      wrote:

                      On Tue, Feb 12, 2013 at
                        11:44 AM, John Bradley <ve7jtb@ve7jtb.com>
                        wrote:

                          Nat and I
                            hashed out the pro's and cons of JSON
                            requests.  

                            If we POST or PUT a JSON object we need
                              to be specific as there rare several ways
                              to do it that may work better or worse
                              depending on the receiver.
                            This needs to be looked over and one
                              picked.

                        Hm?  Not following on =93several =
ways=94, I=92d
                          have thought that POSTing JSON is just POSTing
                          JSON, must be missing something. -T

                            In the other thread about the server
                              returning the update URI and being able to
                              encode the client in that if it needs to
                              takes care of Servers that need that info
                              in query parameters or the path to do the
                              routing.

                            The use of structure can be used to
                              enhance readability and parsing of the
                              input, and output.

                            However we need to temper our urge to
                              apply structure to everything. =

                            IT needs to be applied carefully
                              otherwise we start looking like =
crazies.

                            If we do it cautiously I am in favour
                              of JSON as input.

                            John B.

                                    On 2013-02-12, at 4:32 PM,
                                      Justin Richer <jricher@mitre.org>

                                      wrote:

                                       Thanks for
                                        forwarding that, Mike. I'll
                                        paste in my response to Nat's
                                        concern here as well:

                                        It's an increasingly
                                          well known pattern that has
                                          reasonable support on the
                                          server side. For PHP, I was
                                          able to find the above example
                                          via the top hit on Stack
                                          Overflow. In Ruby, it's a
                                          matter of something like:

                                          =
JSON.parse(request.body.read)

                                          depending on the web app
                                          framework. On Java/Spring,
                                          it's a matter of injecting the
                                          entity body as a string and
                                          handing it to a parser (Gson
                                          in this case):

                                          public String
                                          doApi(@RequestBody String
                                          jsonString) { JsonObject json
                                          =3D new
                                          =
JsonParser().parse(jsonString).getAsJsonObject();

                                          It's a similar read/parse
                                          setup in Node.js as well.

                                          It's true that in all of these
                                          cases you don't get to make
                                          use of the routing or data
                                          binding facilities (though in
                                          Spring you can do that for
                                          simpler domain objects using a
                                          ModelBinding), so you don't
                                          get niceities like the $_POST
                                          array in PHP handed to you.
                                          This is why I don't think it's
                                          a good idea at all to switch
                                          functionality based on the
                                          contents of the JSON object.
                                          It should be a domain object
                                          only, which is what it would
                                          be in this case.

                                          I think that the positives of
                                          using JSON from the client's
                                          perspective and the overall
                                          protocol design far outweigh
                                          the slightly increased
                                          implementation cost at the
                                          server.

                                         -- Justin

                                        On 02/12/2013 02:11 PM,
                                          Mike Jones wrote:

                                          FYI, this issue is =
also
                                              being discussed as an
                                              OpenID Connect issue at https://bitbucket.org/openid/connect/issue/747. =
;

                                              I think that Nat's recent
                                              comment there bears
                                              repeating on this =
list:

Nat

                                              Sakimura:

Not
                                              so sure. For example, PHP
                                              cannot get the JSON object
                                              form application/json POST
                                              in $_POST. 

It
                                              is OK to have a parameter
                                              like "request" that holds
                                              JSON. Then, you can get to
                                              it from $_POST['request'].
                                              However, if you POST the
                                              JSON as the POST body,
                                              then you would have to
                                              call a low level function
                                              in the form of: 

```

                                              #!php

$file
                                              =3D file_get_contents('php://input');

                                              $x =3D json_decode($file);
                                              ```

Not
                                              that it is harder, but it
                                              is much less known. Many
                                              PHP programmers will
                                              certainly goes "???". 

We
                                              need to check what would
                                              be the cases for other
                                              scripting languages before
                                              making the final =
decision.

                                            =
           =
;            &=
nbsp;           &nb=
sp;            =
;           

                                              -- Mike

-----Original
                                              Message-----

                                              From: oauth-bounces@ietf.org
                                              [mailto:oauth-bounces@ietf.org]
                                              On Behalf Of Justin =
Richer

                                              Sent: Monday, February 11,
                                              2013 1:15 PM

                                              To: oauth@ietf.org

                                              Subject: [OAUTH-WG]
                                              Registration: JSON Encoded
                                              Input

Draft -05 of OAuth
                                              Dynamic Client
                                              Registration [1] switched
                                              from a form-encoded input
                                              that had been used by
                                              drafts -01 through -04 to
                                              a JSON encoded input that
                                              was used originally in
                                              -00. Note that all
                                              versions keep JSON-encoded
                                              output from all
                                              operations.

Pro:
  - =
JSON gives us a rich
                                              data structure so that
                                              things such as lists,
                                              numbers, nulls, and
                                              objects can be represented
                                              natively
  - =
Allows for
                                              parallelism between the
                                              input to the endpoint and
                                              output from the endpoint,
                                              reducing possible
                                              translation errors between
                                              the two
  - =
JSON specifies UTF8
                                              encoding for all strings,
                                              forms may have many
                                              different =
encodings
  - JSON has minimal
                                              character escaping
                                              required for most strings,
                                              forms require escaping for
                                              common characters such as
                                              space, slash, comma, =
etc.

Con:
  - =
the rest of OAuth is
                                              =
form-in/JSON-out
  - nothing else in OAuth
                                              requires the Client to
                                              create a JSON object,
                                              merely to parse =
one
  - form-in/JSON-out is a
                                              very widely established
                                              pattern on the web =
today
  - Client information
                                              (client_name, client_id,
                                              etc.) is conflated with
                                              access information
                                              =
(registration_access_token,
                                              _links, expires_at, etc.)
                                              in root level of the same
                                              JSON object, leaving the
                                              client to decide what
                                              needs to (can?) be sent
                                              back to the server for
                                              update operations.

Alternatives =
include any
                                              number of data encoding
                                              schemes, including form
                                              (like the old drafts),
                                              XML, ASN.1, etc.

  -- =
Justin

[1]  http://tools.ietf.org/html=
/draft-ietf-oauth-dyn-reg-05
____________________________=
___________________
OAuth mailing list
OAuth@ietf.org<=
/p>
https://www.ietf.org/mailm=
an/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

=

--Apple-Mail=_F02EC937-EB24-4D0F-818B-A78F8B8E522F--

From sakimura@gmail.com  Tue Feb 12 12:49:00 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6EA521F8BB9 for ; Tue, 12 Feb 2013 12:49:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.93
X-Spam-Level: 
X-Spam-Status: No, score=-2.93 tagged_above=-999 required=5 tests=[AWL=0.069,  BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iteXFkfnWM8S for ; Tue, 12 Feb 2013 12:48:59 -0800 (PST)
Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by ietfa.amsl.com (Postfix) with ESMTP id 11A4421F8BAF for ; Tue, 12 Feb 2013 12:48:58 -0800 (PST)
Received: by mail-lb0-f179.google.com with SMTP id j14so434342lbo.38 for ; Tue, 12 Feb 2013 12:48:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=JQ1/bmcB7VSbyPOfUONSEPuEel89N8QUFqf8OLNrL98=; b=CluRZNRwZwL/zUdQD/QMde/pCZxNgzB5sxaXhXFYJDIN4VGXHNjbz7ajsVqblUBFXf 5fslp2irc+2U2AFAIMsdvKlHziGQ5e+gRWfpVZQj0hy2ARGvGIgZRLSZmORfHXE/67eH KOQfxyb1eKXFBMqX1xhWEVl3xugxaflpDlNZLE3a24CZL4zq2t2qy57b2NC2ADuF/TOh rLvDQuL2zbTT7BJ+L39dDAzb8sIefPwo7n+icpC1woJ3Yv0vc0RRJjs/i0sAtxkInf0i xjOgogoaUyUnpAgv9Pp5BhnVYDnxWnpbx+cbA1lp4RM6VdMFN8h+AcnQiKLZLrJmRLWH 9tsw==
MIME-Version: 1.0
X-Received: by 10.152.48.45 with SMTP id i13mr7744191lan.11.1360702137789; Tue, 12 Feb 2013 12:48:57 -0800 (PST)
Received: by 10.112.14.44 with HTTP; Tue, 12 Feb 2013 12:48:57 -0800 (PST)
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367443A52@TK5EX14MBXC285.redmond.corp.microsoft.com>
References: <51195F3D.1050006@mitre.org> <222C28CB-7F6F-4BC3-8692-40404C2DC2D3@maymount.com> <511A50C7.8080102@mitre.org>  <511A6C49.50801@mitre.org>  <4E1F6AAD24975D4BA5B168042967394367443A52@TK5EX14MBXC285.redmond.corp.microsoft.com>
Date: Wed, 13 Feb 2013 05:48:57 +0900
Message-ID: 
From: Nat Sakimura 
To: Mike Jones 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 20:49:01 -0000

Like bunch of people expressed their opinion in the Thursday's OpenID
call, I honestly do not understand why you think this is complex.
It is JSON.
It is not a surprise.

Compare

obj =3D {
  "registration_access_url":"http://example.com/"
};

obj =3D {
  "_links":{"self":{"href":"http://example.com/"}}
};

In the former case, the client accesses it as obj.registration_access_url.
In the later case, the client accesses it as obj._links.self.href.

As far as programming easiness is concerned, they are more or less the same=
.

Now, introduce other link relationships.
Say you want to store the link/rel metadata in one table and other
data in another table.
The flat one (the former) gets significantly harder.

We human being categorizes things into buckets, and we handle those buckets=
.
If we do not need those categorization power, then why do we use JSON?

One of the beauty of JSON is that while it has the categorization power,
you can just access as if you are in a flat name space when you are
accessing individual items.

So, while you characterize it as "complex", "hard", etc., in fact it
is "simpler" and "easier".

Also, I think you misquote the REST/JSON philosophy.

One of the most fundamental philosophy of REST is to drive the states
through hyper-links and media-types.
As a result, it also asks for a uniform interface. JSON lacks this
hyper-link and uniform interface capability.
Proposals like HAL/OAuth-meta and JSON Hyper-Schema are attempts to
address this shortcoming.
It is trying to provide a uniform interface over hyper-links.
Ad-hoc variable like registration_access_url fails this test because
it is only useable in this particular instance.
(I dislike the name as well as it does not represent the resource
representation that it returns, but that is another issue.)

2013/2/13 Mike Jones :
> Part of the REST/JSON philosophy is that interfaces should be as simple a=
nd developer-friendly as possible.  XML was rejected by developers, in part=
, because of the self-describing nature of the structure, which required ex=
tra syntax that was often not useful in practice.  Trying to re-impose that=
 structure using extra JSON syntax conventions is just asking developers to=
 have an allergic reaction to our specs upon encountering them.  The syntac=
tic complexity and *surprise factor* isn't worth the limited semantic benef=
its of using "_links".
>
> Since you bring up privacy policy and terms of service, I'll note that th=
e OAuth Dynamic Registration spec already has these fields to address those=
:
>         policy_url
>         tos_url
>
> Those have been working fine for OpenID Connect too.  There's no need to =
likewise convolve them to add the extra syntax that you describe below.

As John said, and as I said in the private email yesterday, they are
totally different.

>
> (BTW, in a private thread, John Bradley pointed out that what the two of =
you talked about in person was actually the possibility of adding privacy p=
olicy and terms of service declarations at *discovery time*, rather than re=
gistration time.  That's a different topic, which we should discuss separat=
ely, if you want to pursue that.)

No, that is not right, as John's previous mail indicates. There are
ones for discovery and the ones in registration responses.

Nat

>
>                                 Best wishes,
>                                 -- Mike
>
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of=
 Nat Sakimura
> Sent: Tuesday, February 12, 2013 9:11 AM
> To: Justin Richer; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client sel=
f-URL
>
> Actually, if it is to return it in the HTTP header, then it should also u=
se the RFC5988 Web Linking format.
> Now, that is nice to have, but for many JSON programmers, I agree that it=
 would be a hassle to obtain the header and store them in addition to the J=
SON. So, it is nicer to have it in JSON body.
>
> Re: Is "_links.self.href" grossly complex over "registration_access_url"?
>
> I do not think so. Accessing a flat top level parameter such as registrat=
ion_access_url and _links.self.href does not make any difference from a cli=
ent programmers point of view. That's a beauty of JSON. Both can be treated=
 as a parameter name. Doing a group operation on the links makes difference=
 though: the structured one is easier since you can just operate on _links =
while in case of the top level parameters, you have to have an explicit lis=
t of them and do the matches. (See below for the necessity for the grouping=
).
>
> I and John discussed this for at least half an hour F2F last week, both t=
echnically and from operation/legal point of view, for OpenID Connect Regis=
tration.
> Similar points could be made to OAuth dyn reg.
>
> Here is what we have discussed:
>
> When dynamically registering the client to the server, the server probabl=
y needs to return the following:
>
>   * terms-of-service (terms of service of the server to the client)
>   * privacy-policy (privacy policy of the server to the client)
>
> Both are defined in RFC5988/IANA Link Relations registry.
>
>
> They should be returned together with
>
>   * self.href
>
> which is also defined in RFC5988/IANA Link Relations registry.
>
> There are several ways to do it.
>
>   * Return these using RFC5988 (HTTP Header)
>   * Return these in entity body
>       * Use HAL (or OAuth-meta)/JSON Schema
>       * Use something else (e.g., a top level items)
>
> Returning it in the entity body has several advantage over HTTP header:
>
>   * They can be captured in one call;
>   * They are protocol agnostic;
>
> We determined that these advantages outweighs the disadvantage of creatin=
g a new standard.
>
> The question becomes then whether to:
>
>   * Use HAL (or OAuth-meta)/JSON Schema
>   * Use something else (e.g., a top level items)
>
> First, we have to consider what needs to be returned in the link/relation=
ship category. If it were just _links.self.href, then grouping probably doe=
s not make sense. However, since we have terms-of-service and privacy-polic=
y as well already, it may well make sense.
>
> Moreover, when we think of a multi-tenant authorization server that may w=
ant to use different OAuth authz and token endpoints for different tennants=
, it would be better to be able to return those in the registration respons=
e. Then, it would make sense to register OAuth authz and token endpoints as=
 rel type in the IANA registry (like Bill Mills is trying to
> do) and use them in a uniform manner. Note: these per tenant endpoints ma=
y support different scopes etc. as well. Then, these has to be coupled with=
 the URIs. That is why all of RFC5988/HAL/JSON Schema uses href instead of =
just having the URL as the value of the parameter. The semantic relationshi=
p would often have an associated URI, and other parameters that goes with i=
t.
>
> e.g.:
>
> {
>     "_links": {
>         "terms-of-service": {
>             "href": "https: //server.example.com/tos"
>         },
>         "privacy-policy": {
>             "href": "https: //server.example.com/pp"
>         },
>         "self": {
>             "href": "https: //server.example.com/clients/1234",
>             "authorize": "Bearer"
>         },
>         "oauth_authz": {
>             "href": "https: //server.example.com/authz",
>             "scopes": "openid profile email",
>             "response_types": [
>                 "token id_token",
>                 "code id_token",
>                 "token",
>                 "code"
>             ]
>         },
>         "oauth_token": {
>             "href": "https: //server.example.com/token",
>             "authorize": "Basic"
>         }
>     }
> }
>
> In short, there are bunch of link relations that needs to be returned wit=
h additional parameters.
> Grouping them seems to make sense.
>
> Considering all these, John and I came to the conclusion that the HAL typ=
e syntax would probably make more sense.
> (Note: JSON Schema syntax does not make the parameter access as easy as H=
AL.)
>
> In fact, Mike Kelly (the author of HAL) and I have just submit a new vers=
ion of draft-sakimura-oauth-meta
>
>    http://tools.ietf.org/html/draft-sakimura-oauth-meta-02
>
> The proposal was discussed at IETF 85 OAuth WG and the chairs asked to su=
bmit the draft.
> The -00 appeared in December, and this -02 has some simplification and th=
e addition of the "operations" inspired by
> https://tools.ietf.org/html/draft-ietf-scim-api-00#section-3.5 .
> It is arguably a subset of HAL plus some OAuth specifics.
> I have not added Discovery response example, but adding them would makes =
even more sense, I think.
>
> Cheers,
>
> Nat
>
>
> 2013/2/13 Justin Richer 
>>
>> Agreed - I didn't think that header-only was the proposal, but let's be =
explicit about the returned body always containing the URL. The way I read =
the 201 definition, it suggests (SHOULD) that you use the location header, =
but also says that the entity should refer to the new resource. It was my a=
ssumption that the returned JSON would still have some form of client-entit=
y management URL (whether it's the HAL _links structure or registration_man=
agement_url or something else is still up for debate).
>>
>>  -- Justin
>>
>>
>>
>> On 02/12/2013 10:28 AM, John Bradley wrote:
>>
>> Returning a location header in the 201 ids fine as long as we also have =
the same info as a claim.
>>
>> I think most clients will want to process the JSON and store all the par=
ameters together.  Making them fish out a header makes the W3C happy and is=
 the correct thing to do but taking it from a claim is what developers are =
more comfortable with.
>>
>> John B.
>>
>> On 2013-02-12, at 11:25 AM, Justin Richer  wrote:
>>
>> I'd be fine with the return from a creation request being a 201 instead =
of a 200.
>>
>>  -- Justin
>>
>> On 02/11/2013 06:33 PM, Richard Harrington wrote:
>>
>> Since the request is an HTTP POST and a resource is created (http://www.=
w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5) the response should be a=
n HTTP 201 Created (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#=
sec10.2.2) which is supposed to include the location of the newly created r=
esource.
>>
>> This is a good pattern to follow since, as you say, it does provide flex=
ibility.
>>
>>
>>
>> On Feb 11, 2013, at 1:14 PM, Justin Richer  wrote:
>>
>> Draft -05 of OAuth Dynamic Client Registration [1] returns a URL pointer=
 for the client to perform update and secret rotation actions. This functio=
nality arose from discussions on the list about moving towards a more RESTf=
ul pattern, and Nat Sakimura proposed this approach in the OpenID Connect W=
orking Group. This URL may be distinct from the Client Registration Endpoin=
t URL, but draft -05 makes no promises as to its content, form, or structur=
e, though it does contain implementor's notes on possible methods.
>>
>> Two questions arise from this change:
>> - The semantics of returning the client manipulation URL
>> - The syntax (derived from HAL for JSON [2], an individual I-D
>> submission)
>>
>> On semantics:
>>
>> Pro:
>> - The server has flexibility on how to define the "update" endpoint,
>> sending all clients to one URL, sending different clients to different
>> URLs, or sending clients to a URL with a baked-in query parameter
>> - The client can take the URL as-is and use it for all management
>> operations (ie, it doesn't have to generate or compose the URL based
>> on component parts)
>>
>> Con:
>> - The client must remember one more piece of information from the
>> server at runtime if it wants to do manipulation and management of
>> itself at the server (in addition to client_id, client_secret,
>> registration_access_token, and others)
>>
>> Alternatives include specifying a URL pattern for the server to use and =
all clients to follow, specifying a query parameter for the update action, =
and specifying a separate endpoint entirely and using the presence of items=
 such as client_id and the registration access token to differentiate the r=
equests. Note that *all* of these alternatives can be accommodated using th=
e semantics described above, with the same actions on the client's part.
>>
>>
>> On syntax:
>>
>> Pro:
>> - Follows the designs of RFC5988 for link relations
>> - The HAL format is general, and allows for all kinds of other
>> information to be placed inside the _links structure
>> - Allows for full use of the JSON object to specify advanced
>> operations on the returned endpoint if desired
>>
>> Con:
>> - The rest of OAuth doesn't follow link relation guidelines (though
>> it's been brought up)
>> - The HAL format is general, and allows for all kinds of other
>> information to be placed inside the _links structure
>> - The HAL-JSON document is an expired individual I-D, and it's unclear
>> what wider adoption looks like right now
>>
>> Alternatives include returning the URL as a separate data member (regist=
ration_update_url), using HTTP headers, or using JSON Schema.
>>
>> -- Justin
>>
>>
>>
>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>> [2] http://tools.ietf.org/html/draft-kelly-json-hal-03
>> _______________________________________________
>> 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
>>
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--=20
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

From sakimura@gmail.com  Tue Feb 12 13:07:52 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58A521F8C2B for ; Tue, 12 Feb 2013 13:07:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.222
X-Spam-Level: 
X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.378,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCmtrbpvYhYN for ; Tue, 12 Feb 2013 13:07:51 -0800 (PST)
Received: from mail-la0-x236.google.com (la-in-x0236.1e100.net [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 24A3821F8BC9 for ; Tue, 12 Feb 2013 13:07:49 -0800 (PST)
Received: by mail-la0-f54.google.com with SMTP id gw10so510705lab.41 for ; Tue, 12 Feb 2013 13:07:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=3RNR2N51prPHMxN7g53F8VM1pxxGCi0XK1OinFb9TpQ=; b=N2foU8G+zHwP/oNdIa5vAuKRCrbb6GdVDt/Rg3cr1uWxGI6ESjGVP7t0S1QTzVtv8w +6+vuKD3A79/4b04miP75YE9h5n4ZRrimeZEou7nr3zdKTwj3Cxk6nK0S09TEqytyVLb 4Ge/BoZkpYqUWfZJwv5qYfvR4UFE+GsTPJvdt3I/CGZRcSekQqeKivTrlrY3WSDCCWZ1 3savqKECGoh1fjnAqXbT7bldFZpoAKuc8odUS5MflEVUZtBc9amSH2b5C9i0sVB4fEGb y1M06RZ04LIhyY+cascGlaUWL0lDjrD+NyrBdQRMz3lpJ71voreXDs2YxgQ3y7dNcUVk X3VA==
MIME-Version: 1.0
X-Received: by 10.112.29.1 with SMTP id f1mr4892462lbh.30.1360703267349; Tue, 12 Feb 2013 13:07:47 -0800 (PST)
Received: by 10.112.14.44 with HTTP; Tue, 12 Feb 2013 13:07:47 -0800 (PST)
In-Reply-To: <498782B5-9FFA-47F2-A21D-5FDF842C7B6B@ve7jtb.com>
References: <51195F3B.1010701@mitre.org> <4E1F6AAD24975D4BA5B168042967394367443A16@TK5EX14MBXC285.redmond.corp.microsoft.com> <511A98DE.4030507@mitre.org> <9309CDB3-8AEE-428D-A7F0-5DAC45EFD44C@ve7jtb.com>  <040A3633-A51F-4B17-8019-5DEEC349F39C@ve7jtb.com> <511A9F1C.1010504@mitre.org> <025E3AC8-7F84-410A-A4FF-5FBBD305EA83@ve7jtb.com> <511AA331.2060207@mitre.org> <498782B5-9FFA-47F2-A21D-5FDF842C7B6B@ve7jtb.com>
Date: Wed, 13 Feb 2013 06:07:47 +0900
Message-ID: 
From: Nat Sakimura 
To: John Bradley 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: JSON Encoded Input
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 21:07:52 -0000

If we are sending JSON, then the content-type should be application/json, o=
r
some variant of it if needed be (e.g. application/oauthreg+json etc.
-- I do not think we need it, though.)

I do not like posting it with other content-type unless we explicitly
create a variable and
define a serialization method (such as JWT).

My original comment was just asking to get some feedback from the developer=
s.
Depending on the answer, we may want to put some explanatory notes on it.

My preference is to send JSON.

BTW, would there be a need for signing the registration data?

Nat

2013/2/13 John Bradley :
> I am OK with that language.
>
> On 2013-02-12, at 5:16 PM, Justin Richer  wrote:
>
> I would then request that people come up with a real example of where it
> *won't* work. I've seen workable solutions, and even some automagic ones,=
 on
> several major platforms in which one would write a web server/AS: PHP, Ja=
va
> (Spring and raw servlets), Ruby (rails and sinatra), and Node.js can all =
do
> it.
>
> I would suggest the following text (adapted from what's in -05 right now)=
 to
> address this:
>
>    The Client sends an HTTP POST to the Client Registration Endpoint
>    with a content type of "application/json". The HTTP Entity Payload is
>    a JSON document consisting of a JSON object and all parameters as top-
>    level members of that JSON object.
>
>
> (Would have to be tweaked for the PUT/PATCH verbs but it's effectively th=
e
> same.)
>
>
>  -- Justin
>
> On 02/12/2013 03:07 PM, John Bradley wrote:
>
> I am fine with that as long as all the IdP tools have access to the entit=
y
> body in some reasonable way.   That seems like the most sensible thing.
>
> However given the number of people talking about encoding it in a form to
> get access to it,  we should check that it works for everyone.
>
> John B.
> On 2013-02-12, at 4:59 PM, Justin Richer  wrote:
>
> If that's the question, then my proposal is the Content-type is
> "application/json" and the HTTP Entity Body is the JSON document. No form
> posts or parameter names to be had here.
>
>  -- Justin
>
> On 02/12/2013 02:58 PM, John Bradley wrote:
>
> Some people apparently encode the JSON as the key in a form POST,  some
> people do a form POST with a special key and the JSON as the value.
>
> There appear to be a number of theories in the wild.   I am not an expert=
 I
> just looked up code examples from several sources stack overflow and the
> like.
>
> We probably need to get input from developers who have experience working
> with different frameworks.   I think the differences have to do with
> decoding it at the receiver.
>
> We originally had registration posting JSON but we changed form encoding =
as
> that worked in all environments.   We just need to be sure we are not
> creating problems for people with the change back.
>
>
> John B.
>
> On 2013-02-12, at 4:48 PM, Tim Bray  wrote:
>
>
>
> On Tue, Feb 12, 2013 at 11:44 AM, John Bradley  wrote:
>>
>> Nat and I hashed out the pro's and cons of JSON requests.
>>
>> If we POST or PUT a JSON object we need to be specific as there rare
>> several ways to do it that may work better or worse depending on the
>> receiver.
>> This needs to be looked over and one picked.
>
>
> Hm?  Not following on =93several ways=94, I=92d have thought that POSTing=
 JSON is
> just POSTing JSON, must be missing something. -T
>
>>
>>
>> In the other thread about the server returning the update URI and being
>> able to encode the client in that if it needs to takes care of Servers t=
hat
>> need that info in query parameters or the path to do the routing.
>>
>> The use of structure can be used to enhance readability and parsing of t=
he
>> input, and output.
>>
>> However we need to temper our urge to apply structure to everything.
>>
>> IT needs to be applied carefully otherwise we start looking like crazies=
.
>>
>> If we do it cautiously I am in favour of JSON as input.
>>
>> John B.
>>
>> On 2013-02-12, at 4:32 PM, Justin Richer  wrote:
>>
>> Thanks for forwarding that, Mike. I'll paste in my response to Nat's
>> concern here as well:
>>
>> It's an increasingly well known pattern that has reasonable support on t=
he
>> server side. For PHP, I was able to find the above example via the top h=
it
>> on Stack Overflow. In Ruby, it's a matter of something like:
>>
>> JSON.parse(request.body.read)
>>
>> depending on the web app framework. On Java/Spring, it's a matter of
>> injecting the entity body as a string and handing it to a parser (Gson i=
n
>> this case):
>>
>> public String doApi(@RequestBody String jsonString) { JsonObject json =
=3D
>> new JsonParser().parse(jsonString).getAsJsonObject();
>>
>> It's a similar read/parse setup in Node.js as well.
>>
>> It's true that in all of these cases you don't get to make use of the
>> routing or data binding facilities (though in Spring you can do that for
>> simpler domain objects using a ModelBinding), so you don't get niceities
>> like the $_POST array in PHP handed to you. This is why I don't think it=
's a
>> good idea at all to switch functionality based on the contents of the JS=
ON
>> object. It should be a domain object only, which is what it would be in =
this
>> case.
>>
>> I think that the positives of using JSON from the client's perspective a=
nd
>> the overall protocol design far outweigh the slightly increased
>> implementation cost at the server.
>>
>>
>>
>>  -- Justin
>>
>> On 02/12/2013 02:11 PM, Mike Jones wrote:
>>
>> FYI, this issue is also being discussed as an OpenID Connect issue at
>> https://bitbucket.org/openid/connect/issue/747.  I think that Nat's rece=
nt
>> comment there bears repeating on this list:
>>
>>
>>
>> Nat Sakimura:
>>
>>
>>
>> Not so sure. For example, PHP cannot get the JSON object form
>> application/json POST in $_POST.
>>
>>
>>
>> It is OK to have a parameter like "request" that holds JSON. Then, you c=
an
>> get to it from $_POST['request']. However, if you POST the JSON as the P=
OST
>> body, then you would have to call a low level function in the form of:
>>
>>
>>
>>
>> ```
>>
>> #!php
>>
>>
>>
>> $file =3D file_get_contents('php://input'); $x =3D json_decode($file); `=
``
>>
>>
>>
>> Not that it is harder, but it is much less known. Many PHP programmers
>> will certainly goes "???".
>>
>>
>>
>> We need to check what would be the cases for other scripting languages
>> before making the final decision.
>>
>>
>>
>>                                                             -- Mike
>>
>>
>>
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O=
f
>> Justin Richer
>> Sent: Monday, February 11, 2013 1:15 PM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Registration: JSON Encoded Input
>>
>>
>>
>> Draft -05 of OAuth Dynamic Client Registration [1] switched from a
>> form-encoded input that had been used by drafts -01 through -04 to a JSO=
N
>> encoded input that was used originally in -00. Note that all versions ke=
ep
>> JSON-encoded output from all operations.
>>
>>
>>
>> Pro:
>>
>>   - JSON gives us a rich data structure so that things such as lists,
>> numbers, nulls, and objects can be represented natively
>>
>>   - Allows for parallelism between the input to the endpoint and output
>> from the endpoint, reducing possible translation errors between the two
>>
>>   - JSON specifies UTF8 encoding for all strings, forms may have many
>> different encodings
>>
>>   - JSON has minimal character escaping required for most strings, forms
>> require escaping for common characters such as space, slash, comma, etc.
>>
>>
>>
>> Con:
>>
>>   - the rest of OAuth is form-in/JSON-out
>>
>>   - nothing else in OAuth requires the Client to create a JSON object,
>> merely to parse one
>>
>>   - form-in/JSON-out is a very widely established pattern on the web tod=
ay
>>
>>   - Client information (client_name, client_id, etc.) is conflated with
>> access information (registration_access_token, _links, expires_at, etc.)=
 in
>> root level of the same JSON object, leaving the client to decide what ne=
eds
>> to (can?) be sent back to the server for update operations.
>>
>>
>>
>>
>> Alternatives include any number of data encoding schemes, including form
>> (like the old drafts), XML, ASN.1, etc.
>>
>>
>>
>>
>>   -- Justin
>>
>>
>>
>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>>
>> _______________________________________________
>>
>> 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
>

--=20
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

From tonynad@microsoft.com  Tue Feb 12 14:52:32 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3651E21F8BC5 for ; Tue, 12 Feb 2013 14:52:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.833
X-Spam-Level: 
X-Spam-Status: No, score=0.833 tagged_above=-999 required=5 tests=[AWL=-0.300,  BAYES_00=-2.599, J_CHICKENPOX_44=0.6, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZGls5-o3S3n for ; Tue, 12 Feb 2013 14:52:30 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.25]) by ietfa.amsl.com (Postfix) with ESMTP id A299B21F89D5 for ; Tue, 12 Feb 2013 14:52:20 -0800 (PST)
Received: from BY2FFO11FD006.protection.gbl (10.1.15.204) by BY2FFO11HUB021.protection.gbl (10.1.14.108) with Microsoft SMTP Server (TLS) id 15.0.620.12; Tue, 12 Feb 2013 22:51:33 +0000
Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD006.mail.protection.outlook.com (10.1.14.127) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Tue, 12 Feb 2013 22:51:26 +0000
Received: from db3outboundpool.messaging.microsoft.com (157.54.51.112) by mail.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.2.318.3; Tue, 12 Feb 2013 22:43:31 +0000
Received: from mail50-db3-R.bigfish.com (10.3.81.229) by DB3EHSOBE004.bigfish.com (10.3.84.24) with Microsoft SMTP Server id 14.1.225.23; Tue, 12 Feb 2013 22:42:09 +0000
Received: from mail50-db3 (localhost [127.0.0.1])	by mail50-db3-R.bigfish.com (Postfix) with ESMTP id C670C48030F	for ; Tue, 12 Feb 2013 22:42:09 +0000 (UTC)
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -24
X-BigFish: PS-24(zzbb2dIdb82h98dI9371I936eI542I1432I1453I77f5h609Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz1033IL17326ah8275bh8275dh15d4Iz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h9a9j1155h)
Received-SPF: softfail (mail50-db3: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT005.namprd03.prod.outlook.com ; .outlook.com ; 
X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB043; H:BY2PR03MB041.namprd03.prod.outlook.com; LANG:en; 
Received: from mail50-db3 (localhost.localdomain [127.0.0.1]) by mail50-db3 (MessageSwitch) id 1360708927901266_24579; Tue, 12 Feb 2013 22:42:07 +0000 (UTC)
Received: from DB3EHSMHS007.bigfish.com (unknown [10.3.81.245])	by mail50-db3.bigfish.com (Postfix) with ESMTP id D83D6200065; Tue, 12 Feb 2013 22:42:07 +0000 (UTC)
Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by DB3EHSMHS007.bigfish.com (10.3.87.107) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 12 Feb 2013 22:42:06 +0000
Received: from BY2PR03MB043.namprd03.prod.outlook.com (10.255.241.147) by BL2PRD0310HT005.namprd03.prod.outlook.com (10.255.97.40) with Microsoft SMTP Server (TLS) id 14.16.263.1; Tue, 12 Feb 2013 22:42:05 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB043.namprd03.prod.outlook.com (10.255.241.147) with Microsoft SMTP Server (TLS) id 15.0.620.10; Tue, 12 Feb 2013 22:42:02 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.69]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.69]) with mapi id 15.00.0620.005; Tue, 12 Feb 2013 22:42:02 +0000
From: Anthony Nadalin 
To: Nat Sakimura , Justin Richer 
Thread-Topic: [OAUTH-WG] Registration: HAL _links structure and client self-URL
Thread-Index: AQHOCV96qns/IysTqUmgABLfw3CUSph20RhQ
Date: Tue, 12 Feb 2013 22:42:01 +0000
Message-ID: <0100c90514ff45a2b1a659784c992c91@BY2PR03MB041.namprd03.prod.outlook.com>
References: <51195F3D.1050006@mitre.org> <222C28CB-7F6F-4BC3-8692-40404C2DC2D3@maymount.com> <511A50C7.8080102@mitre.org> 	<511A6C49.50801@mitre.org>  <4E1F6AAD24975D4BA5B168042967394367443A52@TK5EX14MBXC285.redmond.corp.microsoft.com> <9EDD79AA-5104-49CC-A528-C5A1A1777106@ve7jtb.com> <511A9E58.1040606@mitre.org> <715762BE-886B-4E93-8E35-6356F0A18224@ve7jtb.com>	<511AA0A7.30302@mitre.org> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.255.124.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OrganizationHeadersPreserved: BY2PR03MB043.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%MITRE.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14HUBC101.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14HUBC101.redmond.corp.microsoft.com
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(24454001)(15454002)(52034002)(199002)(55885001)(377454001)(377424002)(479174001)(13464002)(51704002)(16676001)(79102001)(44976002)(33646001)(15202345001)(20776003)(23726001)(74502001)(47446002)(4396001)(49866001)(47736001)(76482001)(74662001)(46102001)(80022001)(47976001)(46406002)(47776003)(65816001)(50986001)(54356001)(63696002)(51856001)(50466001)(56816002)(307094002)(6806001)(56776001)(31966008)(5343635001)(5343655001)(54316002)(53806001)(59766001)(77982001)(561944001)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB021; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0755F54DD9
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client	self-URL
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Feb 2013 22:52:32 -0000

I doubt that the ToS and Privacy Policy will be different for a given Trust=
 Framework provider, as these are all bilateral agreements, I do expect the=
se to be different between trust framework providers though

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of N=
at Sakimura
Sent: Tuesday, February 12, 2013 12:27 PM
To: Justin Richer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client self-=
URL

Let me explain a bit more.

A trust framework may supply several ToS and Privacy Policy options much li=
ke CC licenses.
If we want to really automate the things, you really need it.
Otherwise, the service's owner need to go read the ToS and Privacy Policy i=
n person and makes the dynamic registration not so dynamic.
Those option should be available through Discovery.

In Discovery, the server may provide multiple options, out of which the cli=
ent picks one. Think of something like Basic and Premium service. In the Re=
gistration response, then, should be the one that was picked by the client =
/ assigned by the server.

(The notion is closely related to the implicit consent model for the end us=
ers, which is in active discussion in bunch of places, by the way.)

Nat

2013/2/13 Justin Richer :
> I agree with the previous statement that the AS's privacy/TOS would be=20
> better handled through discovery, since it's not likely to change per=20
> client instance.
>
>  -- Justin
>
>
> On 02/12/2013 03:04 PM, John Bradley wrote:
>>
>> There are two TOS and privacy policies.
>>
>> One for the AS that the client is agreeing to by registering.  Will=20
>> it hold up in court?  don't know Facebook is doing this.
>> The link would be a reference to a human readable file that the=20
>> client
>> (RP) can have someone look over before using the connection.
>> This policy may relate to how long the client can cache info etc.
>>
>> The other is the privacy policy of the client that may be presented=20
>> as a click through from the Authorization server.  In general the=20
>> user is not explicitly accepting this, only implicitly accepting it=20
>> by continuing to the RP after having been given a chance to look at it i=
f they want.
>>
>> These are very US fuse on privacy but ignoring them is probably a mistak=
e.
>>
>> John B.
>> On 2013-02-12, at 4:56 PM, Justin Richer  wrote:
>>
>>> One question though: How exactly would the client, a software=20
>>> application, agree to the TOS? Is it supposed to fetch the content=20
>>> of the tos_url and do some processing on it? I wasn't under the=20
>>> impression that the tos_url contents were machine readable. Is it=20
>>> supposed to present that to the user somehow? It seems that's a=20
>>> better thing for the server to do at Authorization time, since it's got=
 the user's attention.
>>>
>>> Remember, this is meant to be for *automated* registration. The=20
>>> developer of the Client has no say at this stage of the game.
>>>
>>> So, I think this is a bit of a red herring, to be honest.
>>>
>>> -- Justin
>>>
>>> On 02/12/2013 02:52 PM, John Bradley wrote:
>>>>
>>>> The current privacy policy and TOS URL in registration are the ones=20
>>>> for the Client.
>>>>
>>>> Nat and I discussed adding ones for the Authorization server that=20
>>>> the client agrees to as separate from ones that the user is agreeing t=
o.
>>>>
>>>> The Authorization servers TOS would be in discovery and perhaps in=20
>>>> the registration response to indicate what the client is agreeing to.
>>>>
>>>> As there rare standard relationships that cover this links Nat was=20
>>>> speculating that they could be part of the _links object.
>>>>
>>>> That aside confirming the terms of service that the client has=20
>>>> agreed to in some way is probably a good thing in the registration res=
ponse.
>>>>
>>>> John B.
>>>>
>>>> On 2013-02-12, at 4:25 PM, Mike Jones 
>>>> wrote:
>>>>
>>>>> Part of the REST/JSON philosophy is that interfaces should be as=20
>>>>> simple and developer-friendly as possible.  XML was rejected by=20
>>>>> developers, in part, because of the self-describing nature of the=20
>>>>> structure, which required extra syntax that was often not useful=20
>>>>> in practice.  Trying to re-impose that structure using extra JSON=20
>>>>> syntax conventions is just asking developers to have an allergic=20
>>>>> reaction to our specs upon encountering them.  The syntactic=20
>>>>> complexity and *surprise factor* isn't worth the limited semantic ben=
efits of using "_links".
>>>>>
>>>>> Since you bring up privacy policy and terms of service, I'll note=20
>>>>> that the OAuth Dynamic Registration spec already has these fields=20
>>>>> to address
>>>>> those:
>>>>>         policy_url
>>>>>         tos_url
>>>>>
>>>>> Those have been working fine for OpenID Connect too.  There's no=20
>>>>> need to likewise convolve them to add the extra syntax that you descr=
ibe below.
>>>>>
>>>>> (BTW, in a private thread, John Bradley pointed out that what the=20
>>>>> two of you talked about in person was actually the possibility of=20
>>>>> adding privacy policy and terms of service declarations at=20
>>>>> *discovery time*, rather than registration time.  That's a=20
>>>>> different topic, which we should discuss separately, if you want=20
>>>>> to pursue that.)
>>>>>
>>>>>                                 Best wishes,
>>>>>                                 -- Mike
>>>>>
>>>>> -----Original Message-----
>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=20
>>>>> Behalf Of Nat Sakimura
>>>>> Sent: Tuesday, February 12, 2013 9:11 AM
>>>>> To: Justin Richer; oauth@ietf.org
>>>>> Subject: Re: [OAUTH-WG] Registration: HAL _links structure and=20
>>>>> client self-URL
>>>>>
>>>>> Actually, if it is to return it in the HTTP header, then it should=20
>>>>> also use the RFC5988 Web Linking format.
>>>>> Now, that is nice to have, but for many JSON programmers, I agree=20
>>>>> that it would be a hassle to obtain the header and store them in=20
>>>>> addition to the JSON. So, it is nicer to have it in JSON body.
>>>>>
>>>>> Re: Is "_links.self.href" grossly complex over=20
>>>>> "registration_access_url"?
>>>>>
>>>>> I do not think so. Accessing a flat top level parameter such as=20
>>>>> registration_access_url and _links.self.href does not make any=20
>>>>> difference from a client programmers point of view. That's a=20
>>>>> beauty of JSON. Both can be treated as a parameter name. Doing a=20
>>>>> group operation on the links makes difference though: the=20
>>>>> structured one is easier since you can just operate on _links=20
>>>>> while in case of the top level parameters, you have to have an=20
>>>>> explicit list of them and do the matches. (See below for the necessit=
y for the grouping).
>>>>>
>>>>> I and John discussed this for at least half an hour F2F last week,=20
>>>>> both technically and from operation/legal point of view, for=20
>>>>> OpenID Connect Registration.
>>>>> Similar points could be made to OAuth dyn reg.
>>>>>
>>>>> Here is what we have discussed:
>>>>>
>>>>> When dynamically registering the client to the server, the server=20
>>>>> probably needs to return the following:
>>>>>
>>>>>   * terms-of-service (terms of service of the server to the client)
>>>>>   * privacy-policy (privacy policy of the server to the client)
>>>>>
>>>>> Both are defined in RFC5988/IANA Link Relations registry.
>>>>>
>>>>>
>>>>> They should be returned together with
>>>>>
>>>>>   * self.href
>>>>>
>>>>> which is also defined in RFC5988/IANA Link Relations registry.
>>>>>
>>>>> There are several ways to do it.
>>>>>
>>>>>   * Return these using RFC5988 (HTTP Header)
>>>>>   * Return these in entity body
>>>>>       * Use HAL (or OAuth-meta)/JSON Schema
>>>>>       * Use something else (e.g., a top level items)
>>>>>
>>>>> Returning it in the entity body has several advantage over HTTP heade=
r:
>>>>>
>>>>>   * They can be captured in one call;
>>>>>   * They are protocol agnostic;
>>>>>
>>>>> We determined that these advantages outweighs the disadvantage of=20
>>>>> creating a new standard.
>>>>>
>>>>> The question becomes then whether to:
>>>>>
>>>>>   * Use HAL (or OAuth-meta)/JSON Schema
>>>>>   * Use something else (e.g., a top level items)
>>>>>
>>>>> First, we have to consider what needs to be returned in the=20
>>>>> link/relationship category. If it were just _links.self.href, then=20
>>>>> grouping probably does not make sense. However, since we have=20
>>>>> terms-of-service and privacy-policy as well already, it may well make=
 sense.
>>>>>
>>>>> Moreover, when we think of a multi-tenant authorization server=20
>>>>> that may want to use different OAuth authz and token endpoints for=20
>>>>> different tennants, it would be better to be able to return those=20
>>>>> in the registration response. Then, it would make sense to=20
>>>>> register OAuth authz and token endpoints as rel type in the IANA=20
>>>>> registry (like Bill Mills is trying to
>>>>> do) and use them in a uniform manner. Note: these per tenant=20
>>>>> endpoints may support different scopes etc. as well. Then, these=20
>>>>> has to be coupled with the URIs. That is why all of=20
>>>>> RFC5988/HAL/JSON Schema uses href instead of just having the URL=20
>>>>> as the value of the parameter. The semantic relationship would=20
>>>>> often have an associated URI, and other parameters that goes with it.
>>>>>
>>>>> e.g.:
>>>>>
>>>>> {
>>>>>     "_links": {
>>>>>         "terms-of-service": {
>>>>>             "href": "https: //server.example.com/tos"
>>>>>         },
>>>>>         "privacy-policy": {
>>>>>             "href": "https: //server.example.com/pp"
>>>>>         },
>>>>>         "self": {
>>>>>             "href": "https: //server.example.com/clients/1234",
>>>>>             "authorize": "Bearer"
>>>>>         },
>>>>>         "oauth_authz": {
>>>>>             "href": "https: //server.example.com/authz",
>>>>>             "scopes": "openid profile email",
>>>>>             "response_types": [
>>>>>                 "token id_token",
>>>>>                 "code id_token",
>>>>>                 "token",
>>>>>                 "code"
>>>>>             ]
>>>>>         },
>>>>>         "oauth_token": {
>>>>>             "href": "https: //server.example.com/token",
>>>>>             "authorize": "Basic"
>>>>>         }
>>>>>     }
>>>>> }
>>>>>
>>>>> In short, there are bunch of link relations that needs to be=20
>>>>> returned with additional parameters.
>>>>> Grouping them seems to make sense.
>>>>>
>>>>> Considering all these, John and I came to the conclusion that the=20
>>>>> HAL type syntax would probably make more sense.
>>>>> (Note: JSON Schema syntax does not make the parameter access as=20
>>>>> easy as
>>>>> HAL.)
>>>>>
>>>>> In fact, Mike Kelly (the author of HAL) and I have just submit a=20
>>>>> new version of draft-sakimura-oauth-meta
>>>>>
>>>>>    http://tools.ietf.org/html/draft-sakimura-oauth-meta-02
>>>>>
>>>>> The proposal was discussed at IETF 85 OAuth WG and the chairs=20
>>>>> asked to submit the draft.
>>>>> The -00 appeared in December, and this -02 has some simplification=20
>>>>> and the addition of the "operations" inspired by
>>>>> https://tools.ietf.org/html/draft-ietf-scim-api-00#section-3.5 .
>>>>> It is arguably a subset of HAL plus some OAuth specifics.
>>>>> I have not added Discovery response example, but adding them would=20
>>>>> makes even more sense, I think.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Nat
>>>>>
>>>>>
>>>>> 2013/2/13 Justin Richer 
>>>>>>
>>>>>> Agreed - I didn't think that header-only was the proposal, but=20
>>>>>> let's be explicit about the returned body always containing the=20
>>>>>> URL. The way I read the 201 definition, it suggests (SHOULD) that=20
>>>>>> you use the location header, but also says that the entity should=20
>>>>>> refer to the new resource. It was my assumption that the returned=20
>>>>>> JSON would still have some form of client-entity management URL=20
>>>>>> (whether it's the HAL _links structure or registration_management_ur=
l or something else is still up for debate).
>>>>>>
>>>>>> -- Justin
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 02/12/2013 10:28 AM, John Bradley wrote:
>>>>>>
>>>>>> Returning a location header in the 201 ids fine as long as we=20
>>>>>> also have the same info as a claim.
>>>>>>
>>>>>> I think most clients will want to process the JSON and store all=20
>>>>>> the parameters together.  Making them fish out a header makes the=20
>>>>>> W3C happy and is the correct thing to do but taking it from a=20
>>>>>> claim is what developers are more comfortable with.
>>>>>>
>>>>>> John B.
>>>>>>
>>>>>> On 2013-02-12, at 11:25 AM, Justin Richer  wrote:
>>>>>>
>>>>>> I'd be fine with the return from a creation request being a 201=20
>>>>>> instead of a 200.
>>>>>>
>>>>>> -- Justin
>>>>>>
>>>>>> On 02/11/2013 06:33 PM, Richard Harrington wrote:
>>>>>>
>>>>>> Since the request is an HTTP POST and a resource is created
>>>>>> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5)=20
>>>>>> the response should be an HTTP 201 Created
>>>>>> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.2
>>>>>> ) which is supposed to include the location of the newly created res=
ource.
>>>>>>
>>>>>> This is a good pattern to follow since, as you say, it does=20
>>>>>> provide flexibility.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Feb 11, 2013, at 1:14 PM, Justin Richer  wrote=
:
>>>>>>
>>>>>> Draft -05 of OAuth Dynamic Client Registration [1] returns a URL=20
>>>>>> pointer for the client to perform update and secret rotation=20
>>>>>> actions. This functionality arose from discussions on the list=20
>>>>>> about moving towards a more RESTful pattern, and Nat Sakimura=20
>>>>>> proposed this approach in the OpenID Connect Working Group. This=20
>>>>>> URL may be distinct from the Client Registration Endpoint URL,=20
>>>>>> but draft -05 makes no promises as to its content, form, or structur=
e, though it does contain implementor's notes on possible methods.
>>>>>>
>>>>>> Two questions arise from this change:
>>>>>> - The semantics of returning the client manipulation URL
>>>>>> - The syntax (derived from HAL for JSON [2], an individual I-D
>>>>>> submission)
>>>>>>
>>>>>> On semantics:
>>>>>>
>>>>>> Pro:
>>>>>> - The server has flexibility on how to define the "update"=20
>>>>>> endpoint, sending all clients to one URL, sending different=20
>>>>>> clients to different URLs, or sending clients to a URL with a=20
>>>>>> baked-in query parameter
>>>>>> - The client can take the URL as-is and use it for all management=20
>>>>>> operations (ie, it doesn't have to generate or compose the URL=20
>>>>>> based on component parts)
>>>>>>
>>>>>> Con:
>>>>>> - The client must remember one more piece of information from the=20
>>>>>> server at runtime if it wants to do manipulation and management=20
>>>>>> of itself at the server (in addition to client_id, client_secret,=20
>>>>>> registration_access_token, and others)
>>>>>>
>>>>>> Alternatives include specifying a URL pattern for the server to=20
>>>>>> use and all clients to follow, specifying a query parameter for=20
>>>>>> the update action, and specifying a separate endpoint entirely=20
>>>>>> and using the presence of items such as client_id and the=20
>>>>>> registration access token to differentiate the requests. Note=20
>>>>>> that *all* of these alternatives can be accommodated using the=20
>>>>>> semantics described above, with the same actions on the client's par=
t.
>>>>>>
>>>>>>
>>>>>> On syntax:
>>>>>>
>>>>>> Pro:
>>>>>> - Follows the designs of RFC5988 for link relations
>>>>>> - The HAL format is general, and allows for all kinds of other=20
>>>>>> information to be placed inside the _links structure
>>>>>> - Allows for full use of the JSON object to specify advanced=20
>>>>>> operations on the returned endpoint if desired
>>>>>>
>>>>>> Con:
>>>>>> - The rest of OAuth doesn't follow link relation guidelines=20
>>>>>> (though it's been brought up)
>>>>>> - The HAL format is general, and allows for all kinds of other=20
>>>>>> information to be placed inside the _links structure
>>>>>> - The HAL-JSON document is an expired individual I-D, and it's=20
>>>>>> unclear what wider adoption looks like right now
>>>>>>
>>>>>> Alternatives include returning the URL as a separate data member=20
>>>>>> (registration_update_url), using HTTP headers, or using JSON Schema.
>>>>>>
>>>>>> -- Justin
>>>>>>
>>>>>>
>>>>>>
>>>>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>>>>>> [2] http://tools.ietf.org/html/draft-kelly-json-hal-03
>>>>>> _______________________________________________
>>>>>> 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
>>>>>>
>>>>>
>>>>> --
>>>>> Nat Sakimura (=3Dnat)
>>>>> Chairman, OpenID Foundation
>>>>> http://nat.sakimura.org/
>>>>> @_nat_en
>>>>> _______________________________________________
>>>>> 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
>
>

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

From jricher@mitre.org  Wed Feb 13 07:01:21 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 516AF21F8639 for ; Wed, 13 Feb 2013 07:01:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.566
X-Spam-Level: 
X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWX-WbuP5Vnm for ; Wed, 13 Feb 2013 07:01:18 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id BD3D321F862E for ; Wed, 13 Feb 2013 07:01:17 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E64671F1DB7; Wed, 13 Feb 2013 10:01:14 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B291A531325E; Wed, 13 Feb 2013 10:01:12 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 13 Feb 2013 10:01:12 -0500
Message-ID: <511BAA8B.8030309@mitre.org>
Date: Wed, 13 Feb 2013 10:00:27 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: John Bradley 
References: <51195F36.6040705@mitre.org> <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com>
In-Reply-To: <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Feb 2013 15:01:21 -0000

Would it be reasonable to mark the PUT and DELETE methods as optional 
for the server to implement, but with defined semantics if they do? I 
want to keep GET and POST(create) as mandatory, as I think that's the 
minimal set of functionality required.

  -- Justin

On 02/11/2013 08:51 PM, John Bradley wrote:
> I would always include the client_id on update.
>
> I think it is also us full to have other tokens used at the update endpoint.  I can see the master token used to update all the clients it has registered as part of API management.
> Relying on the registration_access_token is probably a design that will cause trouble down the road.
>
> I think GET and POST are relatively clear.   I don't know about expelling PUT to developers.  I think POST with a client_id to a (separate discussion) update_uri works without restricting it to PUT.
>
> I think DELETE needs to be better understood.   I think a status that can be set for client lifecycle is better than letting a client delete a entry.
> In some cases there will be more than one instance of a client and letting them know they have been turned off for a reason is better than making there registration disappear.
> So for the moment I would levee out DELETE.
>
> John B.
>
> On 2013-02-11, at 6:14 PM, Justin Richer  wrote:
>
>> Draft -05 of OAuth Dynamic Client Registration [1] defines several operations that the client can take on its behalf as part of the registration process. These boil down to the basic CRUD operations that you find in many APIs: Create, Read, Update, Delete. Draft -00 defined only the "Create" operation, draft -01 through -04 added the "Update" operation, switched using the "operation=" parameter.
>>
>> Following several suggestions to do so on the list, the -05 draft defines these operations in terms of a RESTful API for the client. Namely:
>>
>> - HTTP POST to registration endpoint => Create (register) a new client
>> - HTTP PUT to update endpoint (with registration_access_token) => Update the registered information for this client
>> - HTTP GET to update endpoint (with registration_access_token) => read the registered information for this client
>> - HTTP DELETE to update endpoint (with registration_access_token) => Delete (unregister/de-provision) this client
>>
>> The two main issues at stake here are: the addition of the READ and DELETE methods, and the use of HTTP verbs following a RESTful design philosophy.
>>
>> Pro:
>> - RESTful APIs (with HTTP verbs to differentiate functionality) are the norm today
>> - Full lifecycle management is common and is going to be expected by many users of this protocol in the wild
>>
>> Cons:
>> - Update semantics are still under debate (full replace? patch?)
>> - Somewhat increased complexity on the server to support all operations
>> - Client has to understand all HTTP verbs for full access (though plain registration is just POST)
>>
>>
>> Alternatives include using an operational switch parameter (like the old drafts), defining separate endpoints for every action, or doing all operations on a single endpoint using verbs to switch.
>>
>> -- Justin
>>
>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth

From ve7jtb@ve7jtb.com  Wed Feb 13 07:10:01 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E66321F8821 for ; Wed, 13 Feb 2013 07:10:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.333
X-Spam-Level: 
X-Spam-Status: No, score=-3.333 tagged_above=-999 required=5 tests=[AWL=0.266,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zx0XnhXKSNVN for ; Wed, 13 Feb 2013 07:09:59 -0800 (PST)
Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) by ietfa.amsl.com (Postfix) with ESMTP id 582FE21F87CE for ; Wed, 13 Feb 2013 07:09:59 -0800 (PST)
Received: by mail-qa0-f41.google.com with SMTP id hy16so2185137qab.0 for ; Wed, 13 Feb 2013 07:09:58 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=ES2snSYkH8a8PE77iVs7HDwFrhFmvlT03Uk6jDF0u5s=; b=F1trEoWRgk1SNWg6eC582jjpmC64ruta9mcoN5egxgxrNkeH/RQ1cmo7z2FDNxtCwV gzYVhbtgLla3fJiLoMZYlzxaNEebvDDf2y12st1KHPs0y746UEfoJ2nMiEsXd2GVPCoy a1RPbtj8ZGedskX4HBrQ9wQPtmrRUV3ayCwfJ3beyRg6FBE65Aob77QeZINJqu87DHTt VH2AzntIma3qLMaQjjQY+WsemWsMbiNlq8wjFUGuM7AilGrsdy1O8bA01MZTm/ZOkrPm nx+z6MhYjAyiseHWL1Nn2m4rRMoepuuYOaDwM30PP6PSVrTh+jRpinRJXD9L2THS6f6q lg7w==
X-Received: by 10.49.71.178 with SMTP id w18mr10021588qeu.11.1360768190753; Wed, 13 Feb 2013 07:09:50 -0800 (PST)
Received: from [192.168.1.213] ([190.20.26.0]) by mx.google.com with ESMTPS id hn9sm17500864qab.8.2013.02.13.07.09.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Feb 2013 07:09:49 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <511BAA8B.8030309@mitre.org>
Date: Wed, 13 Feb 2013 12:09:42 -0300
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <51195F36.6040705@mitre.org> <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com> <511BAA8B.8030309@mitre.org>
To: Justin Richer 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQnihivgkiSRZN7YGU6ZZYAnjUNptDlc5fA8kEjfkmoOETaw3DxBPbOd1wc85/6cVMTqnFbY
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Feb 2013 15:10:01 -0000

I am not violently opposed to PUT as a option that completely replaces =
the resource setting all unsent claims back to the defaults. =20

I don't have a good feeling about DELETE,  I think we still need more =
discussion on what it means, what privileges it takes to invoke it etc.
It could be a bad thing if we get wrong or is not implemented =
consistently.

Personally I don't think a client should ever be able to DELETE it's =
record.  =20

I think marking a client_id as pending provisioning, suspended,  revoked =
etc is better and that can be done with a claim in the update endpoint.

It should only be the server that deletes a record after satisfying it's =
audit requirements.

John B.=20

On 2013-02-13, at 12:00 PM, Justin Richer  wrote:

> Would it be reasonable to mark the PUT and DELETE methods as optional =
for the server to implement, but with defined semantics if they do? I =
want to keep GET and POST(create) as mandatory, as I think that's the =
minimal set of functionality required.
>=20
> -- Justin
>=20
> On 02/11/2013 08:51 PM, John Bradley wrote:
>> I would always include the client_id on update.
>>=20
>> I think it is also us full to have other tokens used at the update =
endpoint.  I can see the master token used to update all the clients it =
has registered as part of API management.
>> Relying on the registration_access_token is probably a design that =
will cause trouble down the road.
>>=20
>> I think GET and POST are relatively clear.   I don't know about =
expelling PUT to developers.  I think POST with a client_id to a =
(separate discussion) update_uri works without restricting it to PUT.
>>=20
>> I think DELETE needs to be better understood.   I think a status that =
can be set for client lifecycle is better than letting a client delete a =
entry.
>> In some cases there will be more than one instance of a client and =
letting them know they have been turned off for a reason is better than =
making there registration disappear.
>> So for the moment I would levee out DELETE.
>>=20
>> John B.
>>=20
>> On 2013-02-11, at 6:14 PM, Justin Richer  wrote:
>>=20
>>> Draft -05 of OAuth Dynamic Client Registration [1] defines several =
operations that the client can take on its behalf as part of the =
registration process. These boil down to the basic CRUD operations that =
you find in many APIs: Create, Read, Update, Delete. Draft -00 defined =
only the "Create" operation, draft -01 through -04 added the "Update" =
operation, switched using the "operation=3D" parameter.
>>>=20
>>> Following several suggestions to do so on the list, the -05 draft =
defines these operations in terms of a RESTful API for the client. =
Namely:
>>>=20
>>> - HTTP POST to registration endpoint =3D> Create (register) a new =
client
>>> - HTTP PUT to update endpoint (with registration_access_token) =3D> =
Update the registered information for this client
>>> - HTTP GET to update endpoint (with registration_access_token) =3D> =
read the registered information for this client
>>> - HTTP DELETE to update endpoint (with registration_access_token) =3D>=
 Delete (unregister/de-provision) this client
>>>=20
>>> The two main issues at stake here are: the addition of the READ and =
DELETE methods, and the use of HTTP verbs following a RESTful design =
philosophy.
>>>=20
>>> Pro:
>>> - RESTful APIs (with HTTP verbs to differentiate functionality) are =
the norm today
>>> - Full lifecycle management is common and is going to be expected by =
many users of this protocol in the wild
>>>=20
>>> Cons:
>>> - Update semantics are still under debate (full replace? patch?)
>>> - Somewhat increased complexity on the server to support all =
operations
>>> - Client has to understand all HTTP verbs for full access (though =
plain registration is just POST)
>>>=20
>>>=20
>>> Alternatives include using an operational switch parameter (like the =
old drafts), defining separate endpoints for every action, or doing all =
operations on a single endpoint using verbs to switch.
>>>=20
>>> -- Justin
>>>=20
>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>=20

From Michael.Jones@microsoft.com  Wed Feb 13 07:32:53 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6BBF21F87D2 for ; Wed, 13 Feb 2013 07:32:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.584
X-Spam-Level: 
X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeUyOf8F-7wg for ; Wed, 13 Feb 2013 07:32:52 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8B96421F86BE for ; Wed, 13 Feb 2013 07:32:52 -0800 (PST)
Received: from BY2FFO11FD001.protection.gbl (10.1.15.201) by BY2FFO11HUB039.protection.gbl (10.1.14.122) with Microsoft SMTP Server (TLS) id 15.0.620.12; Wed, 13 Feb 2013 15:32:50 +0000
Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD001.mail.protection.outlook.com (10.1.14.123) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Wed, 13 Feb 2013 15:32:50 +0000
Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.232]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Wed, 13 Feb 2013 15:32:30 +0000
From: Mike Jones 
To: John Bradley , Justin Richer 
Thread-Topic: [OAUTH-WG] Registration: RESTful client lifecycle management
Thread-Index: AQHOCJzxVGwYODuh3UmktcEEXHrfK5h1dc0AgAJusICAAAKVAIAABf2Q
Date: Wed, 13 Feb 2013 15:32:29 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394367445EBC@TK5EX14MBXC285.redmond.corp.microsoft.com>
References: <51195F36.6040705@mitre.org> <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com> <511BAA8B.8030309@mitre.org> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.34]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(55885001)(24454001)(51444002)(51704002)(189002)(199002)(479174001)(377424002)(13464002)(377454001)(63696002)(76482001)(66066001)(54316002)(79102001)(46102001)(56776001)(33656001)(20776003)(53806001)(15202345001)(46406002)(74502001)(54356001)(47776003)(47446002)(5343655001)(51856001)(47736001)(74662001)(47976001)(44976002)(80022001)(4396001)(50466001)(55846006)(49866001)(23726001)(56816002)(31966008)(16406001)(50986001)(77982001)(65816001)(59766001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB039; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07562C22DA
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Feb 2013 15:32:53 -0000

I agree that DELETE is potentially problematic.  I'd leave it out.

				-- Mike

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J=
ohn Bradley
Sent: Wednesday, February 13, 2013 7:10 AM
To: Justin Richer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management

I am not violently opposed to PUT as a option that completely replaces the =
resource setting all unsent claims back to the defaults. =20

I don't have a good feeling about DELETE,  I think we still need more discu=
ssion on what it means, what privileges it takes to invoke it etc.
It could be a bad thing if we get wrong or is not implemented consistently.

Personally I don't think a client should ever be able to DELETE it's record=
.  =20

I think marking a client_id as pending provisioning, suspended,  revoked et=
c is better and that can be done with a claim in the update endpoint.

It should only be the server that deletes a record after satisfying it's au=
dit requirements.

John B.=20

On 2013-02-13, at 12:00 PM, Justin Richer  wrote:

> Would it be reasonable to mark the PUT and DELETE methods as optional for=
 the server to implement, but with defined semantics if they do? I want to =
keep GET and POST(create) as mandatory, as I think that's the minimal set o=
f functionality required.
>=20
> -- Justin
>=20
> On 02/11/2013 08:51 PM, John Bradley wrote:
>> I would always include the client_id on update.
>>=20
>> I think it is also us full to have other tokens used at the update endpo=
int.  I can see the master token used to update all the clients it has regi=
stered as part of API management.
>> Relying on the registration_access_token is probably a design that will =
cause trouble down the road.
>>=20
>> I think GET and POST are relatively clear.   I don't know about expellin=
g PUT to developers.  I think POST with a client_id to a (separate discussi=
on) update_uri works without restricting it to PUT.
>>=20
>> I think DELETE needs to be better understood.   I think a status that ca=
n be set for client lifecycle is better than letting a client delete a entr=
y.
>> In some cases there will be more than one instance of a client and letti=
ng them know they have been turned off for a reason is better than making t=
here registration disappear.
>> So for the moment I would levee out DELETE.
>>=20
>> John B.
>>=20
>> On 2013-02-11, at 6:14 PM, Justin Richer  wrote:
>>=20
>>> Draft -05 of OAuth Dynamic Client Registration [1] defines several oper=
ations that the client can take on its behalf as part of the registration p=
rocess. These boil down to the basic CRUD operations that you find in many =
APIs: Create, Read, Update, Delete. Draft -00 defined only the "Create" ope=
ration, draft -01 through -04 added the "Update" operation, switched using =
the "operation=3D" parameter.
>>>=20
>>> Following several suggestions to do so on the list, the -05 draft defin=
es these operations in terms of a RESTful API for the client. Namely:
>>>=20
>>> - HTTP POST to registration endpoint =3D> Create (register) a new clien=
t
>>> - HTTP PUT to update endpoint (with registration_access_token) =3D> Upd=
ate the registered information for this client
>>> - HTTP GET to update endpoint (with registration_access_token) =3D> rea=
d the registered information for this client
>>> - HTTP DELETE to update endpoint (with registration_access_token) =3D> =
Delete (unregister/de-provision) this client
>>>=20
>>> The two main issues at stake here are: the addition of the READ and DEL=
ETE methods, and the use of HTTP verbs following a RESTful design philosoph=
y.
>>>=20
>>> Pro:
>>> - RESTful APIs (with HTTP verbs to differentiate functionality) are the=
 norm today
>>> - Full lifecycle management is common and is going to be expected by ma=
ny users of this protocol in the wild
>>>=20
>>> Cons:
>>> - Update semantics are still under debate (full replace? patch?)
>>> - Somewhat increased complexity on the server to support all operations
>>> - Client has to understand all HTTP verbs for full access (though plain=
 registration is just POST)
>>>=20
>>>=20
>>> Alternatives include using an operational switch parameter (like the ol=
d drafts), defining separate endpoints for every action, or doing all opera=
tions on a single endpoint using verbs to switch.
>>>=20
>>> -- Justin
>>>=20
>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>=20

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

From prateek.mishra@oracle.com  Wed Feb 13 08:13:43 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F0521F8869 for ; Wed, 13 Feb 2013 08:13:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnP4MiPJYjIn for ; Wed, 13 Feb 2013 08:13:42 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0637921F877B for ; Wed, 13 Feb 2013 08:13:38 -0800 (PST)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1DGDZCS021041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Feb 2013 16:13:36 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1DGDZbX000979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Feb 2013 16:13:35 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1DGDY2W023219; Wed, 13 Feb 2013 10:13:34 -0600
Received: from [192.168.1.4] (/71.184.95.145) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 13 Feb 2013 08:13:34 -0800
Message-ID: <511BBBAC.9060502@oracle.com>
Date: Wed, 13 Feb 2013 11:13:32 -0500
From: Prateek Mishra 
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: oauth@ietf.org
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net>
In-Reply-To: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Feb 2013 16:13:43 -0000

Hannes,

1) Its not clear to me that we need  to specify exchanges between the AS =

and the RS as part of this work. The core specification leaves this
unspecified. There could be many different ways that the AS and RS=20
collaborate to validate signatures in messages received from the client.

2) Regarding (symmetric) key distribution, dont we need some kind of=20
existing trust relationship between the client and AS to make this=20
possible? I guess it
would be enough to require use of a "confidential" client, that would=20
make it possible for the two parties to agree on a session key at the=20
point where an access token
is  issued by the AS.

3) I think do need an MTI key distribution protocol as part of the=20
specification, leaving that as a choice would hurt interoperability.

- prateek

> Here are my notes.
>
> Participants:
>
> * John Bradley
> * Derek Atkins
> * Phil Hunt
> * Prateek Mishra
> * Hannes Tschofenig
> * Mike Jones
> * Antonio Sanso
> * Justin Richer
>
> Notes:
>
> My slides are available here: http://www.tschofenig.priv.at/OAuth2-Secu=
rity-11Feb2013.ppt
>
> Slide #2 summarizes earlier discussions during the conference calls.
>
> -- HTTP vs. JSON
>
> Phil noted that he does not like to use the MAC Token draft as a starti=
ng point because it does not re-use any of the work done in the JOSE work=
ing group and in particular all the libraries that are available today. H=
e mentioned that earlier attempts to write the MAC Token code lead to pro=
blems for implementers.
>
> Justin responded that he does not agree with using JSON as a transport =
mechanism since this would replicate a SOAP style.
>
> Phil noted that he wants to send JSON but the signature shall be comput=
ed over the HTTP header field.
>
> -- Flexibility for the keyed message digest computation
>
>  From earlier discussion it was clear that the conference call particip=
ants wanted more flexibility regarding the keyed message digest computati=
on. For this purpose Hannes presented the DKIM based approach, which allo=
ws selective header fields to be included in the digest. This is shown in=
 slide #4.
>
> After some discussion the conference call participants thought that thi=
s would meet their needs. Further investigations would still be useful to=
 determine the degree of failed HMAC calculations due to HTTP proxies mod=
ifying the content.
>
> -- Key Distribution
>
> Hannes presented the open issue regarding the choice of key distributio=
n. Slides #6-#8 present three techniques and Hannes asked for feedback re=
garding the preferred style. Justin and others didn't see the need to dec=
ide on one mechanism - they wanted to keep the choice open. Derek indicat=
ed that this will not be an acceptable approach. Since the resource serve=
r and the authorization server may, in the OAuth 2.0 framework, be entiti=
es produced by different vendors there is an interoperability need. Justi=
n responded that he disagrees and that the resource server needs to under=
stand the access token and referred to the recent draft submission for th=
e token introspection endpoint. Derek indicated that the resource server =
has to understand the content of the access token and the token introspec=
tion endpoint just pushes the problem around: the resource server has to =
send the access token to the authorization server and then the resource s=
erver gets the result back (which he then a
>   gain needs to understand) in order to make a meaningful authorization=
 decision.
>
> Everyone agreed that the client must receive the session key from the a=
uthorization server and that this approach has to be standardized. It was=
 also agreed that this is a common approach among all three key distribut=
ion mechanisms.
>
> Hannes asked the participants to think about their preference.
>
> The questions regarding key naming and the indication for the intended =
resource server the client wants to talk to have been postponed.
>  =20
> Ciao
> Hannes
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From sakimura@gmail.com  Wed Feb 13 10:27:43 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0B821E8030 for ; Wed, 13 Feb 2013 10:27:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.367
X-Spam-Level: 
X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=-0.521, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3S0khd1kr5w for ; Wed, 13 Feb 2013 10:27:42 -0800 (PST)
Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF0D21F84FD for ; Wed, 13 Feb 2013 10:27:42 -0800 (PST)
Received: by mail-qa0-f48.google.com with SMTP id j8so688592qah.0 for ; Wed, 13 Feb 2013 10:27:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:from:mime-version:in-reply-to:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=SnP+UZRQENtsIZi+Gxt+DTCIA78Z1AylxTo4hC1izoc=; b=KPoM7SWtJvhTYyFDbIy4AkrFEWdeZ8GTO+ecHlHEdUVtdBBdc88hErvP+6Rcugn+OV CbrrGBlU4A9eFDpaoCzqpKZRIzyowTSiqtO5KWto1poUkd4WsAbDryrwW49m9XBTUXOd aBnADrkDRviehgPcPWgjj56wZuIP84XVzzo9+Ob6QKDIE+W8vaqULi/o/18+HgfzTxsV POQYGn5EfK0Iyrx/ch5yHDQzJ80Svb/fA23WM+Eeq5qaQrfoXq9oP5c+8/zGijAe4JXe O8UsGRrzPwxfI5xuKxuYKmmGXnQIKpEVFYH+pnWCv1xMohh6dYXHY0WYeG/kslkg4Sbh hYUw==
X-Received: by 10.49.121.40 with SMTP id lh8mr10286443qeb.30.1360780061696; Wed, 13 Feb 2013 10:27:41 -0800 (PST)
References: <51195F36.6040705@mitre.org> <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com> <80727F20-A830-4778-B11C-D45389310646@lodderstedt.net> <511A5742.30707@mitre.org>  <511A705F.4070204@mitre.org>  <4E1F6AAD24975D4BA5B168042967394367443862@TK5EX14MBXC285.redmond.corp.microsoft.com>
From: Nat Sakimura 
Mime-Version: 1.0 (1.0)
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367443862@TK5EX14MBXC285.redmond.corp.microsoft.com>
Date: Thu, 14 Feb 2013 03:27:40 +0900
Message-ID: <-7739255357185893925@unknownmsgid>
To: Mike Jones 
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: base64
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Feb 2013 18:27:43 -0000

SSBhbSBhZ2FpbnN0IHRoZSBzeW50YXggb2YgcmVnaXN0cmF0aW9uX2FjY2Vzc191cmwgLg0KDQo9
bmF0IHZpYSBpUGhvbmUNCg0KRmViIDEzLCAyMDEzIDM6MzcbJEIhIhsoQk1pa2UgSm9uZXMgPE1p
Y2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4gGyRCJE4lYSVDJTshPCU4GyhCOg0KDQo+IFRoZW4g
SSB0aGluayB3ZSd2ZSByZWFjaGVkIGFuIGFjY2VwdGFibGUgcmVzb2x1dGlvbiBvbiB0aGlzIG9u
ZS4gIEJ5IGhhdmluZyB0aGUgc2VydmVyIHJldHVybiB0aGUgcmVnaXN0cmF0aW9uX2FjY2Vzc191
cmwgdXBvbiBjcmVhdGUgYW5kIGhhdmluZyB0aGUgY2xpZW50IGJlIHJlcXVpcmVkIHRvIGluY2x1
ZGUgdGhlIGNsaWVudF9pZCB1cG9uIHVwZGF0ZSwgc2VydmVycyBhcmUgZnJlZSB0byBtYW5hZ2Ug
dGhlaXIgcmVnaXN0cmF0aW9uIGVuZHBvaW50KHMpIGFzIHRoZXkgc2VlIGZpdCBhbmQgY2xpZW50
cyBhbHdheXMgZG8gdGhlIHNhbWUgdGhpbmcuDQo+DQo+ICAgICAgICAgICAgICAgIFRoYW5rcyBh
bGwsDQo+ICAgICAgICAgICAgICAgIC0tIE1pa2UNCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS0NCj4gRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5j
ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBOYXQgU2FraW11cmENCj4gU2VudDogVHVlc2RheSwg
RmVicnVhcnkgMTIsIDIwMTMgOToxNSBBTQ0KPiBUbzogSnVzdGluIFJpY2hlcg0KPiBDYzogb2F1
dGhAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtPQVVUSC1XR10gUmVnaXN0cmF0aW9uOiBSRVNU
ZnVsIGNsaWVudCBsaWZlY3ljbGUgbWFuYWdlbWVudA0KPg0KPiAyMDEzLzIvMTMgSnVzdGluIFJp
Y2hlciA8anJpY2hlckBtaXRyZS5vcmc+Og0KPj4NCj4+IE9uIDAyLzEyLzIwMTMgMTE6MzAgQU0s
IEpvaG4gQnJhZGxleSB3cm90ZToNCj4+Pg0KPj4+IFRvIHNvbWUgZXh0ZW50IHdlIHdhbnQgdGhl
IHNlcnZlciB0byBoYXZlIHRoZSBmbGV4aWJpbGl0eSBpdCBuZWVkcy4NCj4+Pg0KPj4+IElmIHRo
ZSBzZXJ2ZXIga25vd3MgaXQgaXMgZ29pbmcgdG8gbmVlZCBjbGllbnRfaWQgZm9yIEdFVCBpdCBu
ZWVkcyB0bw0KPj4+IGVuY29kZSBpdCBpbiB0aGUgcmVzb3VyY2UgVVJJIGV0aGVyIGFzIHBhcnQg
b2YgdGhlIHBhdGggb3IgYXMgYSBxdWVyeQ0KPj4+IHBhcmFtZXRlciAodGhhdCBpcyB1cCB0byB0
aGUgc2VydmVyKQ0KPj4+DQo+Pj4gV2hlbiBkb2luZyB1cGRhdGVzIHRoZSBjbGllbnQgTVVTVCBp
bmNsdWRlIHRoZSBjbGllbnRfaWQgYXMgYW4NCj4+PiBhZGRpdGlvbmFsIGludGVncml0eSBjaGVj
ay4gIFNvbWUgc2VydmVycyBtYXkgc3dpdGNoIG9uIHRoYXQgYnV0IHRoYXQgaXMgdXAgdG8gdGhl
bS4NCj4+DQo+PiBTbyBpZiBieSB0aGlzIHlvdSBtZWFuIHRoYXQgdGhlIGNsaWVudCBzdGlsbCBz
aW1wbHkgZm9sbG93cyB3aGF0ZXZlcg0KPj4gdXBkYXRlIHVybCB0aGUgc2VydmVyIGhhbmRzIGl0
ICh3aGljaCBtYXkgb3IgbWF5IG5vdCBpbmNsdWRlIHRoZQ0KPj4gY2xpZW50X2lkIGluIHNvbWUg
Zm9ybSwgYnV0IHRoZSBjbGllbnQgZG9lc24ndCBjYXJlKSwgYW5kIHRoYXQgdGhlDQo+PiBjbGll
bnQgTVVTVCBpbmNsdWRlIGl0cyBjbGllbnRfaWQgaW4gdGhlIHJlcXVlc3QgYm9keSAodG9wLWxl
dmVsDQo+PiBtZW1iZXIgb2YgYSBKU09OIG9iamVjdCwgYXQgdGhlDQo+PiBtb21lbnQpIHdoZW4g
ZG9pbmcgYSBQVVQgKG9yIFBPU1QvUEFUQ0g/IHNlZSBiZWxvdykgZm9yIHRoZSB1cGRhdGUNCj4+
IGFjdGlvbiwgdGhlbiBJJ20gdG90YWxseSBmaW5lIHdpdGggdGhhdC4gSXMgdGhpcyB3aGF0IHlv
dSdyZSBzdWdnZXN0aW5nPw0KPg0KPiBBcyBmYXIgYXMgSSB1bmRlcnN0YW5kLCB5ZXMuIFRoYXQg
aXMgd2hhdCB3ZSBkaXNjdXNzZWQgbGFzdCBUaHVyc2RheSBmYWNlIHRvIGZhY2UuDQo+DQo+DQo+
IC0tDQo+IE5hdCBTYWtpbXVyYSAoPW5hdCkNCj4gQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9u
DQo+IGh0dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KPiBAX25hdF9lbg0KPiBfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPQXV0aCBtYWlsaW5nIGxpc3QN
Cj4gT0F1dGhAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9vYXV0aA0K

From sakimura@gmail.com  Wed Feb 13 10:31:25 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84A621E8030 for ; Wed, 13 Feb 2013 10:31:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.157
X-Spam-Level: 
X-Spam-Status: No, score=-3.157 tagged_above=-999 required=5 tests=[AWL=0.442,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 568jkU1NrOpY for ; Wed, 13 Feb 2013 10:31:25 -0800 (PST)
Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by ietfa.amsl.com (Postfix) with ESMTP id E7EB721F8468 for ; Wed, 13 Feb 2013 10:31:24 -0800 (PST)
Received: by mail-qe0-f53.google.com with SMTP id 1so681068qee.40 for ; Wed, 13 Feb 2013 10:31:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:from:mime-version:in-reply-to:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=8WrMB23TjVBrap2ixB3pfqADoCIiV3DUnBFiz4IVjSU=; b=OSlQG2qLG3dXPQ718thGRjMjWMRBnf1jLYhvQ+HKsW5JxIfBOiCZULOzAUUWMLJ5fH 4BubzaiLxs30xLU5bWrShe/98ff94eb1Bjh2LitI28s0hTNDCGRgPXawu14neJ7guMIj D/XEwf3+MnPEWIVmA6phDA286+2nS4lYEjqDbR8WoEbwMei4v+lRvXIuTomg16dCfqTi yT4GwWwkEJOAVIXTKA0LAFhHhSrcI9lS6hT9ytWxqdwS/MGPnHoavUKZ3pz51aWsWlX8 aoyqYax6bzgluJ9bMFD5BnoE9gHjjFTE3CRCo71+yDV28phTWlpMiLTiPEJLjP6VE+eR ULVQ==
X-Received: by 10.224.39.210 with SMTP id h18mr8765410qae.15.1360780284085; Wed, 13 Feb 2013 10:31:24 -0800 (PST)
References: <51195F36.6040705@mitre.org> <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com> <511BAA8B.8030309@mitre.org> 
From: Nat Sakimura 
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Date: Thu, 14 Feb 2013 03:31:22 +0900
Message-ID: <-4554688250617930935@unknownmsgid>
To: John Bradley 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Feb 2013 18:31:25 -0000

Generally speaking, mapping PUT to replace and POST to change is an
acceptable practice so I am fine with it.

Now, what I still do not understand is why you think it is fine to do
PUT or POST and not DELETE. Doing PUT with empty content is almost the
same as DELETE. Could you explain?

=3Dnat via iPhone

Feb 14, 2013 0:10=E3=80=81John Bradley  =E3=81=AE=E3=83=
=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8:

> I am not violently opposed to PUT as a option that completely replaces th=
e resource setting all unsent claims back to the defaults.
>
> I don't have a good feeling about DELETE,  I think we still need more dis=
cussion on what it means, what privileges it takes to invoke it etc.
> It could be a bad thing if we get wrong or is not implemented consistentl=
y.
>
> Personally I don't think a client should ever be able to DELETE it's reco=
rd.
>
> I think marking a client_id as pending provisioning, suspended,  revoked =
etc is better and that can be done with a claim in the update endpoint.
>
> It should only be the server that deletes a record after satisfying it's =
audit requirements.
>
> John B.
>
> On 2013-02-13, at 12:00 PM, Justin Richer  wrote:
>
>> Would it be reasonable to mark the PUT and DELETE methods as optional fo=
r the server to implement, but with defined semantics if they do? I want to=
 keep GET and POST(create) as mandatory, as I think that's the minimal set =
of functionality required.
>>
>> -- Justin
>>
>> On 02/11/2013 08:51 PM, John Bradley wrote:
>>> I would always include the client_id on update.
>>>
>>> I think it is also us full to have other tokens used at the update endp=
oint.  I can see the master token used to update all the clients it has reg=
istered as part of API management.
>>> Relying on the registration_access_token is probably a design that will=
 cause trouble down the road.
>>>
>>> I think GET and POST are relatively clear.   I don't know about expelli=
ng PUT to developers.  I think POST with a client_id to a (separate discuss=
ion) update_uri works without restricting it to PUT.
>>>
>>> I think DELETE needs to be better understood.   I think a status that c=
an be set for client lifecycle is better than letting a client delete a ent=
ry.
>>> In some cases there will be more than one instance of a client and lett=
ing them know they have been turned off for a reason is better than making =
there registration disappear.
>>> So for the moment I would levee out DELETE.
>>>
>>> John B.
>>>
>>> On 2013-02-11, at 6:14 PM, Justin Richer  wrote:
>>>
>>>> Draft -05 of OAuth Dynamic Client Registration [1] defines several ope=
rations that the client can take on its behalf as part of the registration =
process. These boil down to the basic CRUD operations that you find in many=
 APIs: Create, Read, Update, Delete. Draft -00 defined only the "Create" op=
eration, draft -01 through -04 added the "Update" operation, switched using=
 the "operation=3D" parameter.
>>>>
>>>> Following several suggestions to do so on the list, the -05 draft defi=
nes these operations in terms of a RESTful API for the client. Namely:
>>>>
>>>> - HTTP POST to registration endpoint =3D> Create (register) a new clie=
nt
>>>> - HTTP PUT to update endpoint (with registration_access_token) =3D> Up=
date the registered information for this client
>>>> - HTTP GET to update endpoint (with registration_access_token) =3D> re=
ad the registered information for this client
>>>> - HTTP DELETE to update endpoint (with registration_access_token) =3D>=
 Delete (unregister/de-provision) this client
>>>>
>>>> The two main issues at stake here are: the addition of the READ and DE=
LETE methods, and the use of HTTP verbs following a RESTful design philosop=
hy.
>>>>
>>>> Pro:
>>>> - RESTful APIs (with HTTP verbs to differentiate functionality) are th=
e norm today
>>>> - Full lifecycle management is common and is going to be expected by m=
any users of this protocol in the wild
>>>>
>>>> Cons:
>>>> - Update semantics are still under debate (full replace? patch?)
>>>> - Somewhat increased complexity on the server to support all operation=
s
>>>> - Client has to understand all HTTP verbs for full access (though plai=
n registration is just POST)
>>>>
>>>>
>>>> Alternatives include using an operational switch parameter (like the o=
ld drafts), defining separate endpoints for every action, or doing all oper=
ations on a single endpoint using verbs to switch.
>>>>
>>>> -- Justin
>>>>
>>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>>>> _______________________________________________
>>>> 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

From jricher@mitre.org  Wed Feb 13 10:41:14 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8849621F85A2 for ; Wed, 13 Feb 2013 10:41:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.567
X-Spam-Level: 
X-Spam-Status: No, score=-6.567 tagged_above=-999 required=5 tests=[AWL=0.032,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UPNfDvxXyxv for ; Wed, 13 Feb 2013 10:41:10 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 361B021F85A0 for ; Wed, 13 Feb 2013 10:41:09 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 968A41F09E7; Wed, 13 Feb 2013 13:41:08 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7F55E1F054A; Wed, 13 Feb 2013 13:41:08 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 13 Feb 2013 13:41:08 -0500
Message-ID: <511BDE17.7060503@mitre.org>
Date: Wed, 13 Feb 2013 13:40:23 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Nat Sakimura 
References: <51195F36.6040705@mitre.org> <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com> <80727F20-A830-4778-B11C-D45389310646@lodderstedt.net> <511A5742.30707@mitre.org>  <511A705F.4070204@mitre.org>  <4E1F6AAD24975D4BA5B168042967394367443862@TK5EX14MBXC285.redmond.corp.microsoft.com> <-7739255357185893925@unknownmsgid>
In-Reply-To: <-7739255357185893925@unknownmsgid>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Feb 2013 18:41:14 -0000

Duly noted, and while there seems to be solid support behind the
semantics of returning a URL, I'm not convinced the syntax argument is
over yet either. I have seen support and good arguments from both sides
and there isn't a clear winner there (see the other thread). Speaking as
an individual member, I could go with either approach and I'd like to
see what the rest of the WG wants.

Speaking now as an editor: It's been suggested off-list that we adopt
the simplified (bespoke) mechanism of the "registration_access_url"
syntax for the next draft and continue to move discussion forward for
the inclusion of the more-general mechanism (beit HAL based or something
similar like JSON-LD) here on the list. Would you and the other HAL
supporters be amenable to this solution? I wouldn't be opposed to adding
a kind of "note for discussion" section to the -06 draft to help
facilitate moving forward in a concrete manner, with the assumption that
the text would be either removed or incorporated in a later draft. I
just have to put a stake down somewhere on the syntax, and I'm leaning
towards the one that doesn't add a normative dependency on an unfinished
(as of right now) work.

-- Justin

On 02/13/2013 01:27 PM, Nat Sakimura wrote:
> I am against the syntax of registration_access_url .
>
> =nat via iPhone
>
> Feb 13, 2013 3:37$B!"(BMike Jones  $B$N%a%C%;!<%8(B:
>
>> Then I think we've reached an acceptable resolution on this one.  By having the server return the registration_access_url upon create and having the client be required to include the client_id upon update, servers are free to manage their registration endpoint(s) as they see fit and clients always do the same thing.
>>
>>                Thanks all,
>>                -- Mike
>>
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura
>> Sent: Tuesday, February 12, 2013 9:15 AM
>> To: Justin Richer
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
>>
>> 2013/2/13 Justin Richer :
>>> On 02/12/2013 11:30 AM, John Bradley wrote:
>>>> To some extent we want the server to have the flexibility it needs.
>>>>
>>>> If the server knows it is going to need client_id for GET it needs to
>>>> encode it in the resource URI ether as part of the path or as a query
>>>> parameter (that is up to the server)
>>>>
>>>> When doing updates the client MUST include the client_id as an
>>>> additional integrity check.  Some servers may switch on that but that is up to them.
>>> So if by this you mean that the client still simply follows whatever
>>> update url the server hands it (which may or may not include the
>>> client_id in some form, but the client doesn't care), and that the
>>> client MUST include its client_id in the request body (top-level
>>> member of a JSON object, at the
>>> moment) when doing a PUT (or POST/PATCH? see below) for the update
>>> action, then I'm totally fine with that. Is this what you're suggesting?
>> As far as I understand, yes. That is what we discussed last Thursday face to face.
>>
>>
>> --
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth

From Michael.Jones@microsoft.com  Wed Feb 13 12:11:23 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573D621F86B8 for ; Wed, 13 Feb 2013 12:11:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.422
X-Spam-Level: 
X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.176,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iqh+fnsequ6V for ; Wed, 13 Feb 2013 12:11:16 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0A78121F8688 for ; Wed, 13 Feb 2013 12:11:15 -0800 (PST)
Received: from BL2FFO11FD011.protection.gbl (10.173.161.202) by BL2FFO11HUB028.protection.gbl (10.173.161.52) with Microsoft SMTP Server (TLS) id 15.0.620.12; Wed, 13 Feb 2013 20:08:46 +0000
Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD011.mail.protection.outlook.com (10.173.161.17) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Wed, 13 Feb 2013 20:08:44 +0000
Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.232]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Wed, 13 Feb 2013 20:04:01 +0000
From: Mike Jones 
To: Justin Richer , Nat Sakimura 
Thread-Topic: [OAUTH-WG] Registration: RESTful client lifecycle management
Thread-Index: AQHOCJzxVGwYODuh3UmktcEEXHrfK5h1dc0AgABcxoCAAH10AIAAG1EAgAACn4CAAAnLAIAAFhgggAGQiACAAAOOgIAAF12M
Date: Wed, 13 Feb 2013 20:04:00 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943674465F3@TK5EX14MBXC285.redmond.corp.microsoft.com>
References: <51195F36.6040705@mitre.org> <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com> <80727F20-A830-4778-B11C-D45389310646@lodderstedt.net> <511A5742.30707@mitre.org>  <511A705F.4070204@mitre.org>  <4E1F6AAD24975D4BA5B168042967394367443862@TK5EX14MBXC285.redmond.corp.microsoft.com> <-7739255357185893925@unknownmsgid>,<511BDE17.7060503@mitre.org>
In-Reply-To: <511BDE17.7060503@mitre.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943674465F3TK5EX14MBXC285r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(479174001)(24454001)(55885001)(377454001)(51704002)(13464002)(33656001)(47446002)(63696002)(44976002)(31966008)(55846006)(53806001)(80022001)(5343635001)(16236675001)(5343655001)(16406001)(74662001)(15202345001)(74502001)(56816002)(65816001)(54356001)(512904001)(79102001)(50986001)(47976001)(56776001)(54316002)(77982001)(51856001)(59766001)(46102001)(76482001)(20776003)(4396001)(47736001)(49866001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB028; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07562C22DA
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Feb 2013 20:11:23 -0000

--_000_4E1F6AAD24975D4BA5B1680429673943674465F3TK5EX14MBXC285r_
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable

+1

________________________________
From: Justin Richer
Sent: 2/13/2013 10:41 AM
To: Nat Sakimura
Cc: Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management

Duly noted, and while there seems to be solid support behind the
semantics of returning a URL, I'm not convinced the syntax argument is
over yet either. I have seen support and good arguments from both sides
and there isn't a clear winner there (see the other thread). Speaking as
an individual member, I could go with either approach and I'd like to
see what the rest of the WG wants.

Speaking now as an editor: It's been suggested off-list that we adopt
the simplified (bespoke) mechanism of the "registration_access_url"
syntax for the next draft and continue to move discussion forward for
the inclusion of the more-general mechanism (beit HAL based or something
similar like JSON-LD) here on the list. Would you and the other HAL
supporters be amenable to this solution? I wouldn't be opposed to adding
a kind of "note for discussion" section to the -06 draft to help
facilitate moving forward in a concrete manner, with the assumption that
the text would be either removed or incorporated in a later draft. I
just have to put a stake down somewhere on the syntax, and I'm leaning
towards the one that doesn't add a normative dependency on an unfinished
(as of right now) work.

-- Justin

On 02/13/2013 01:27 PM, Nat Sakimura wrote:
> I am against the syntax of registration_access_url .
>
> =3Dnat via iPhone
>
> Feb 13, 2013 3:37=1B$B!"=1B(BMike Jones  =1B=
$B$N%a%C%;!<%8=1B(B:
>
>> Then I think we've reached an acceptable resolution on this one.  By hav=
ing the server return the registration_access_url upon create and having th=
e client be required to include the client_id upon update, servers are free=
 to manage their registration endpoint(s) as they see fit and clients alway=
s do the same thing.
>>
>>                Thanks all,
>>                -- Mike
>>
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O=
f Nat Sakimura
>> Sent: Tuesday, February 12, 2013 9:15 AM
>> To: Justin Richer
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle managemen=
t
>>
>> 2013/2/13 Justin Richer :
>>> On 02/12/2013 11:30 AM, John Bradley wrote:
>>>> To some extent we want the server to have the flexibility it needs.
>>>>
>>>> If the server knows it is going to need client_id for GET it needs to
>>>> encode it in the resource URI ether as part of the path or as a query
>>>> parameter (that is up to the server)
>>>>
>>>> When doing updates the client MUST include the client_id as an
>>>> additional integrity check.  Some servers may switch on that but that =
is up to them.
>>> So if by this you mean that the client still simply follows whatever
>>> update url the server hands it (which may or may not include the
>>> client_id in some form, but the client doesn't care), and that the
>>> client MUST include its client_id in the request body (top-level
>>> member of a JSON object, at the
>>> moment) when doing a PUT (or POST/PATCH? see below) for the update
>>> action, then I'm totally fine with that. Is this what you're suggesting=
?
>> As far as I understand, yes. That is what we discussed last Thursday fac=
e to face.
>>
>>
>> --
>> Nat Sakimura (=3Dnat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth

--_000_4E1F6AAD24975D4BA5B1680429673943674465F3TK5EX14MBXC285r_
Content-Type: text/html; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable

+1

From:
Justin=
 Richer

Sent:
2/13/2=
013 10:41 AM

To:
Nat Sa=
kimura

Cc:
Mike J=
ones; oauth@ietf.org

Subject:
Re: [O=
AUTH-WG] Registration: RESTful client lifecycle management

Duly noted, and while there seems to be solid supp=
ort behind the

semantics of returning a URL, I'm not convinced the syntax argument is

over yet either. I have seen support and good arguments from both sides

and there isn't a clear winner there (see the other thread). Speaking as
an individual member, I could go with either approach and I'd like to

see what the rest of the WG wants.

Speaking now as an editor: It's been suggested off-list that we adopt

the simplified (bespoke) mechanism of the "registration_access_url&quo=
t;

syntax for the next draft and continue to move discussion forward for

the inclusion of the more-general mechanism (beit HAL based or something
similar like JSON-LD) here on the list. Would you and the other HAL

supporters be amenable to this solution? I wouldn't be opposed to adding
a kind of "note for discussion" section to the -06 draft to help<=
br>
facilitate moving forward in a concrete manner, with the assumption that
the text would be either removed or incorporated in a later draft. I

just have to put a stake down somewhere on the syntax, and I'm leaning

towards the one that doesn't add a normative dependency on an unfinished
(as of right now) work.

-- Justin

On 02/13/2013 01:27 PM, Nat Sakimura wrote:

> I am against the syntax of registration_access_url .

>

> =3Dnat via iPhone

>

> Feb 13, 2013 3:37=1B$B!"=1B(BMike Jones <Michael.Jones@microsoft.co=
m> =1B$B$N%a%C%;!<%8=1B(B:

>

>> Then I think we've reached an acceptable resolution on this one.&n=
bsp; By having the server return the registration_access_url upon create an=
d having the client be required to include the client_id upon update, serve=
rs are free to manage their registration endpoint(s)
 as they see fit and clients always do the same thing.

>>

>>           &=
nbsp;    Thanks all,

>>           &=
nbsp;    -- Mike

>>

>> -----Original Message-----

>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura

>> Sent: Tuesday, February 12, 2013 9:15 AM

>> To: Justin Richer

>> Cc: oauth@ietf.org

>> Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle man=
agement

>>

>> 2013/2/13 Justin Richer <jricher@mitre.org>:

>>> On 02/12/2013 11:30 AM, John Bradley wrote:

>>>> To some extent we want the server to have the flexibility =
it needs.

>>>>

>>>> If the server knows it is going to need client_id for GET =
it needs to

>>>> encode it in the resource URI ether as part of the path or=
 as a query

>>>> parameter (that is up to the server)

>>>>

>>>> When doing updates the client MUST include the client_id a=
s an

>>>> additional integrity check.  Some servers may switch =
on that but that is up to them.

>>> So if by this you mean that the client still simply follows wh=
atever

>>> update url the server hands it (which may or may not include t=
he

>>> client_id in some form, but the client doesn't care), and that=
 the

>>> client MUST include its client_id in the request body (top-lev=
el

>>> member of a JSON object, at the

>>> moment) when doing a PUT (or POST/PATCH? see below) for the up=
date

>>> action, then I'm totally fine with that. Is this what you're s=
uggesting?

>> As far as I understand, yes. That is what we discussed last Thursd=
ay face to face.

>>

>>

>> --

>> Nat Sakimura (=3Dnat)

>> Chairman, OpenID Foundation

>> http://nat.sakimura.org/<=
br>
>> @_nat_en

>> _______________________________________________

>> OAuth mailing list

>> OAuth@ietf.org

>> https://ww=
w.ietf.org/mailman/listinfo/oauth

--_000_4E1F6AAD24975D4BA5B1680429673943674465F3TK5EX14MBXC285r_--

From ve7jtb@ve7jtb.com  Wed Feb 13 12:18:21 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD1821F84B6 for ; Wed, 13 Feb 2013 12:18:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.344
X-Spam-Level: 
X-Spam-Status: No, score=-3.344 tagged_above=-999 required=5 tests=[AWL=0.255,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eu19D52SFgcK for ; Wed, 13 Feb 2013 12:18:20 -0800 (PST)
Received: from mail-qe0-f52.google.com (mail-qe0-f52.google.com [209.85.128.52]) by ietfa.amsl.com (Postfix) with ESMTP id 1073321F8488 for ; Wed, 13 Feb 2013 12:18:19 -0800 (PST)
Received: by mail-qe0-f52.google.com with SMTP id 6so748097qeb.11 for ; Wed, 13 Feb 2013 12:18:19 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=g2IFdhgFHNySmJ90J/O6am+OWq2HLQY8gQZZPj6+uVY=; b=ZvXPqvDWs+3NVsKv1kPdLDylVzi34rkQuwu0sjoMvdmAatZbKM99J1UdB8JP5V8MNH SKWnQopFMAceWM8uyYvey7lnNWvse73G7CzxNpERqRTlOhzt3fPbgvZUYH5ju0hx2jue XUmL848ExZhaTx7VlnT3mumVXcqglFMQf3W2BtDAvBaM0cHW0VNdFL3480JjWWM8E5lK 4lI2MRlwGR5BwM7cZsnliInKi2S4eb6l8pxBVkQiyJcLiZBHsA1VflVoGAnHse/Lshml 8kDTbF6jDPiwAExWi63dje0u6s/P2php3EpmBh0lY9eTCJGnxrKYf6MZkJRlGR6W84ee 1+fw==
X-Received: by 10.49.37.226 with SMTP id b2mr10476697qek.31.1360786699230; Wed, 13 Feb 2013 12:18:19 -0800 (PST)
Received: from [192.168.1.213] ([190.20.26.0]) by mx.google.com with ESMTPS id f5sm17775184qac.5.2013.02.13.12.18.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Feb 2013 12:18:18 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <-4554688250617930935@unknownmsgid>
Date: Wed, 13 Feb 2013 17:18:12 -0300
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <51195F36.6040705@mitre.org> <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com> <511BAA8B.8030309@mitre.org>  <-4554688250617930935@unknownmsgid>
To: Nat Sakimura 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQkFVRlFNUUcxuVItC+UvZsqf1FRHVjVtQjQ2vc8rpizNpXvH9sX7RLTHn4ZMSnw95Xw4U0h
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Feb 2013 20:18:21 -0000

DELETE is removing the record not resetting it to defaults.  They are =
quite diffrent.

I want to agree on what the expected behaviour of DELETE is.   I think =
we have agreement on PUT and POST.

The general not in that a client can DELETE it's record is a implication =
I don't like.  I think that is for the server to decide and if it is not =
actually deleting it then DELETE is the wrong verb to use.

John B.

On 2013-02-13, at 3:31 PM, Nat Sakimura  wrote:

> Generally speaking, mapping PUT to replace and POST to change is an
> acceptable practice so I am fine with it.
>=20
> Now, what I still do not understand is why you think it is fine to do
> PUT or POST and not DELETE. Doing PUT with empty content is almost the
> same as DELETE. Could you explain?
>=20
> =3Dnat via iPhone
>=20
> Feb 14, 2013 0:10=E3=80=81John Bradley  =
=E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8:
>=20
>> I am not violently opposed to PUT as a option that completely =
replaces the resource setting all unsent claims back to the defaults.
>>=20
>> I don't have a good feeling about DELETE,  I think we still need more =
discussion on what it means, what privileges it takes to invoke it etc.
>> It could be a bad thing if we get wrong or is not implemented =
consistently.
>>=20
>> Personally I don't think a client should ever be able to DELETE it's =
record.
>>=20
>> I think marking a client_id as pending provisioning, suspended,  =
revoked etc is better and that can be done with a claim in the update =
endpoint.
>>=20
>> It should only be the server that deletes a record after satisfying =
it's audit requirements.
>>=20
>> John B.
>>=20
>> On 2013-02-13, at 12:00 PM, Justin Richer  wrote:
>>=20
>>> Would it be reasonable to mark the PUT and DELETE methods as =
optional for the server to implement, but with defined semantics if they =
do? I want to keep GET and POST(create) as mandatory, as I think that's =
the minimal set of functionality required.
>>>=20
>>> -- Justin
>>>=20
>>> On 02/11/2013 08:51 PM, John Bradley wrote:
>>>> I would always include the client_id on update.
>>>>=20
>>>> I think it is also us full to have other tokens used at the update =
endpoint.  I can see the master token used to update all the clients it =
has registered as part of API management.
>>>> Relying on the registration_access_token is probably a design that =
will cause trouble down the road.
>>>>=20
>>>> I think GET and POST are relatively clear.   I don't know about =
expelling PUT to developers.  I think POST with a client_id to a =
(separate discussion) update_uri works without restricting it to PUT.
>>>>=20
>>>> I think DELETE needs to be better understood.   I think a status =
that can be set for client lifecycle is better than letting a client =
delete a entry.
>>>> In some cases there will be more than one instance of a client and =
letting them know they have been turned off for a reason is better than =
making there registration disappear.
>>>> So for the moment I would levee out DELETE.
>>>>=20
>>>> John B.
>>>>=20
>>>> On 2013-02-11, at 6:14 PM, Justin Richer  wrote:
>>>>=20
>>>>> Draft -05 of OAuth Dynamic Client Registration [1] defines several =
operations that the client can take on its behalf as part of the =
registration process. These boil down to the basic CRUD operations that =
you find in many APIs: Create, Read, Update, Delete. Draft -00 defined =
only the "Create" operation, draft -01 through -04 added the "Update" =
operation, switched using the "operation=3D" parameter.
>>>>>=20
>>>>> Following several suggestions to do so on the list, the -05 draft =
defines these operations in terms of a RESTful API for the client. =
Namely:
>>>>>=20
>>>>> - HTTP POST to registration endpoint =3D> Create (register) a new =
client
>>>>> - HTTP PUT to update endpoint (with registration_access_token) =3D> =
Update the registered information for this client
>>>>> - HTTP GET to update endpoint (with registration_access_token) =3D> =
read the registered information for this client
>>>>> - HTTP DELETE to update endpoint (with registration_access_token) =
=3D> Delete (unregister/de-provision) this client
>>>>>=20
>>>>> The two main issues at stake here are: the addition of the READ =
and DELETE methods, and the use of HTTP verbs following a RESTful design =
philosophy.
>>>>>=20
>>>>> Pro:
>>>>> - RESTful APIs (with HTTP verbs to differentiate functionality) =
are the norm today
>>>>> - Full lifecycle management is common and is going to be expected =
by many users of this protocol in the wild
>>>>>=20
>>>>> Cons:
>>>>> - Update semantics are still under debate (full replace? patch?)
>>>>> - Somewhat increased complexity on the server to support all =
operations
>>>>> - Client has to understand all HTTP verbs for full access (though =
plain registration is just POST)
>>>>>=20
>>>>>=20
>>>>> Alternatives include using an operational switch parameter (like =
the old drafts), defining separate endpoints for every action, or doing =
all operations on a single endpoint using verbs to switch.
>>>>>=20
>>>>> -- Justin
>>>>>=20
>>>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth

From twbray@google.com  Wed Feb 13 13:27:06 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E18021E8084 for ; Wed, 13 Feb 2013 13:27:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.769
X-Spam-Level: 
X-Spam-Status: No, score=-101.769 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xie3Qh39jbbf for ; Wed, 13 Feb 2013 13:27:03 -0800 (PST)
Received: from mail-ie0-x22f.google.com (ie-in-x022f.1e100.net [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id B436A21E803D for ; Wed, 13 Feb 2013 13:27:03 -0800 (PST)
Received: by mail-ie0-f175.google.com with SMTP id c12so2330115ieb.6 for ; Wed, 13 Feb 2013 13:27:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=39WoTEOKujqj2qjNQQchF/J7CrflEkMSdISeL5QFjvQ=; b=TGj9QW5t0obh+1Pautyoc1mg4aquFg/Lbz0xnx0ismX5v9dxm3utkhA7h8/cOp4La+ 5H4YFPzwKZhZ44khom3pJT5IVuMF69xK44tHbNO+7ZLYb1KI5NpaHNaedc237cz1ofMe 47viWdEySnggV1CorwZq4WswqpZIBzn2gqQh1bmgJppWQL0kkpxi3Dn4bpiwctSpufm4 EgiH+SGaYKw7J6Iy0LMw+7fTWW2IKwp8xigKUjhBHEr1KUpGcPe401yUoC6E1toNZUEs pbcZmNMzP/qKooR//YhKf0BKCUhVgZhbkLBdHaaBptCk+9/Dwt93/nAhh22G/Xnzdel+ hyEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=39WoTEOKujqj2qjNQQchF/J7CrflEkMSdISeL5QFjvQ=; b=Y3K5wH0zKI1eL79YurgdQIIaim9kEXgUXV2LBAeK+YVyFA4x7BJPj4gIgbul5fXAnM uCfhDGChL1CoknfmmGSLmycQekEq3LtLVvPWKXw+Kqnp6g5cOdeN55RpHB0GrPQZw67D 4LYsfEWvfGns7Y/CwguSfRAo6Zb4lZDYUg5bG2qWBSSwmHIRGmrcR/3BnRpxJ8OZpdB7 K/lY2ENT11b7QM4Z3XuVKInWYq3BY+0MjWL9FzsTXvUbXv/+gDO6yZmUps42zeXlzhJN WS+YyFsyzqQHiVfa6AVYc0LSnPl0RMs/gRXxGuNg+GPRHiYq9RNGmzCHG5De9y6rtr+s OezA==
X-Received: by 10.50.182.234 with SMTP id eh10mr9856695igc.40.1360790823060; Wed, 13 Feb 2013 13:27:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.16.199 with HTTP; Wed, 13 Feb 2013 13:26:32 -0800 (PST)
In-Reply-To: 
References: <51195F36.6040705@mitre.org> <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com> <511BAA8B.8030309@mitre.org>  <-4554688250617930935@unknownmsgid> 
From: Tim Bray 
Date: Wed, 13 Feb 2013 13:26:32 -0800
Message-ID: 
To: John Bradley 
Content-Type: multipart/alternative; boundary=14dae9340ae99f438504d5a1cd62
X-Gm-Message-State: ALoCoQkw3Evsg5frerDshrXaJhKMZrKnSjbs6pLmeHbM3PiwzLHjkmEpRSp3uWpwPqeU+4pfJ+3DmpB9xvyMO34Sh0NLKc4PvzoCWIlP6sHWUd/AMXfSPccRdAVK9teRdqzyNB08KVz3BdxpZr5Z7gN3oNgHBGaekql20xuppULYJwv6NntJqvSFMPQpEAYhWSBrDZjTp8my
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Feb 2013 21:27:07 -0000

--14dae9340ae99f438504d5a1cd62
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

A DELETE is an http request that asks the server to delete something.  We
probably would want to avoid writing a requirement into the standard that
the server has to comply.  So you get back a 204 if it worked, a 404 if
there is no such registration, a 403 if there is but the server declines to
delete, etc. Seems pretty straightforward. -T

On Wed, Feb 13, 2013 at 12:18 PM, John Bradley  wrote:

> DELETE is removing the record not resetting it to defaults.  They are
> quite diffrent.
>
> I want to agree on what the expected behaviour of DELETE is.   I think we
> have agreement on PUT and POST.
>
> The general not in that a client can DELETE it's record is a implication =
I
> don't like.  I think that is for the server to decide and if it is not
> actually deleting it then DELETE is the wrong verb to use.
>
> John B.
>
> On 2013-02-13, at 3:31 PM, Nat Sakimura  wrote:
>
> > Generally speaking, mapping PUT to replace and POST to change is an
> > acceptable practice so I am fine with it.
> >
> > Now, what I still do not understand is why you think it is fine to do
> > PUT or POST and not DELETE. Doing PUT with empty content is almost the
> > same as DELETE. Could you explain?
> >
> > =3Dnat via iPhone
> >
> > Feb 14, 2013 0:10=E3=80=81John Bradley  =E3=81=AE=E3=
=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8:
> >
> >> I am not violently opposed to PUT as a option that completely replaces
> the resource setting all unsent claims back to the defaults.
> >>
> >> I don't have a good feeling about DELETE,  I think we still need more
> discussion on what it means, what privileges it takes to invoke it etc.
> >> It could be a bad thing if we get wrong or is not implemented
> consistently.
> >>
> >> Personally I don't think a client should ever be able to DELETE it's
> record.
> >>
> >> I think marking a client_id as pending provisioning, suspended,
>  revoked etc is better and that can be done with a claim in the update
> endpoint.
> >>
> >> It should only be the server that deletes a record after satisfying
> it's audit requirements.
> >>
> >> John B.
> >>
> >> On 2013-02-13, at 12:00 PM, Justin Richer  wrote:
> >>
> >>> Would it be reasonable to mark the PUT and DELETE methods as optional
> for the server to implement, but with defined semantics if they do? I wan=
t
> to keep GET and POST(create) as mandatory, as I think that's the minimal
> set of functionality required.
> >>>
> >>> -- Justin
> >>>
> >>> On 02/11/2013 08:51 PM, John Bradley wrote:
> >>>> I would always include the client_id on update.
> >>>>
> >>>> I think it is also us full to have other tokens used at the update
> endpoint.  I can see the master token used to update all the clients it h=
as
> registered as part of API management.
> >>>> Relying on the registration_access_token is probably a design that
> will cause trouble down the road.
> >>>>
> >>>> I think GET and POST are relatively clear.   I don't know about
> expelling PUT to developers.  I think POST with a client_id to a (separat=
e
> discussion) update_uri works without restricting it to PUT.
> >>>>
> >>>> I think DELETE needs to be better understood.   I think a status tha=
t
> can be set for client lifecycle is better than letting a client delete a
> entry.
> >>>> In some cases there will be more than one instance of a client and
> letting them know they have been turned off for a reason is better than
> making there registration disappear.
> >>>> So for the moment I would levee out DELETE.
> >>>>
> >>>> John B.
> >>>>
> >>>> On 2013-02-11, at 6:14 PM, Justin Richer  wrote:
> >>>>
> >>>>> Draft -05 of OAuth Dynamic Client Registration [1] defines several
> operations that the client can take on its behalf as part of the
> registration process. These boil down to the basic CRUD operations that y=
ou
> find in many APIs: Create, Read, Update, Delete. Draft -00 defined only t=
he
> "Create" operation, draft -01 through -04 added the "Update" operation,
> switched using the "operation=3D" parameter.
> >>>>>
> >>>>> Following several suggestions to do so on the list, the -05 draft
> defines these operations in terms of a RESTful API for the client. Namely=
:
> >>>>>
> >>>>> - HTTP POST to registration endpoint =3D> Create (register) a new
> client
> >>>>> - HTTP PUT to update endpoint (with registration_access_token) =3D>
> Update the registered information for this client
> >>>>> - HTTP GET to update endpoint (with registration_access_token) =3D>
> read the registered information for this client
> >>>>> - HTTP DELETE to update endpoint (with registration_access_token) =
=3D>
> Delete (unregister/de-provision) this client
> >>>>>
> >>>>> The two main issues at stake here are: the addition of the READ and
> DELETE methods, and the use of HTTP verbs following a RESTful design
> philosophy.
> >>>>>
> >>>>> Pro:
> >>>>> - RESTful APIs (with HTTP verbs to differentiate functionality) are
> the norm today
> >>>>> - Full lifecycle management is common and is going to be expected b=
y
> many users of this protocol in the wild
> >>>>>
> >>>>> Cons:
> >>>>> - Update semantics are still under debate (full replace? patch?)
> >>>>> - Somewhat increased complexity on the server to support all
> operations
> >>>>> - Client has to understand all HTTP verbs for full access (though
> plain registration is just POST)
> >>>>>
> >>>>>
> >>>>> Alternatives include using an operational switch parameter (like th=
e
> old drafts), defining separate endpoints for every action, or doing all
> operations on a single endpoint using verbs to switch.
> >>>>>
> >>>>> -- Justin
> >>>>>
> >>>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
> >>>>> _______________________________________________
> >>>>> 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
>

--14dae9340ae99f438504d5a1cd62
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

A DELETE is an http request that asks the server to delete something. =C2=
=A0We probably would want to avoid writing a requirement into the standard =
that the server has to comply. =C2=A0So you get back a 204 if it worked, a =
404 if there is no such registration, a 403 if there is but the server decl=
ines to delete, etc. Seems pretty straightforward. -T

On Wed, Feb 13, 2013 at 12:18 PM, John Bradl=
ey <ve7jtb@ve7jtb.com> wrote:

DELETE is removing the record not resetting it to defaults. =C2=A0They are =
quite diffrent.

I want to agree on what the expected behaviour of DELETE is. =C2=A0 I think=
 we have agreement on PUT and POST.

The general not in that a client can DELETE it's record is a implicatio=
n I don't like. =C2=A0I think that is for the server to decide and if i=
t is not actually deleting it then DELETE is the wrong verb to use.

John B.

On 2013-02-13, at 3:31 PM, Nat Sakimura <sakimura@gmail.com> wrote:

> Generally speaking, mapping PUT to replace and POST to change is an
> acceptable practice so I am fine with it.

>

> Now, what I still do not understand is why you think it is fine to do<=
br>
> PUT or POST and not DELETE. Doing PUT with empty content is almost the=

> same as DELETE. Could you explain?

>

> =3Dnat via iPhone

>

> Feb 14, 2013 0:10=E3=80=81John Bradley <ve7jtb@ve7jtb.com> =E3=81=AE=E3=83=A1=E3=
=83=83=E3=82=BB=E3=83=BC=E3=82=B8:

>

>> I am not violently opposed to PUT as a option that completely repl=
aces the resource setting all unsent claims back to the defaults.

>>

>> I don't have a good feeling about DELETE, =C2=A0I think we sti=
ll need more discussion on what it means, what privileges it takes to invok=
e it etc.

>> It could be a bad thing if we get wrong or is not implemented cons=
istently.

>>

>> Personally I don't think a client should ever be able to DELET=
E it's record.

>>

>> I think marking a client_id as pending provisioning, suspended, =
=C2=A0revoked etc is better and that can be done with a claim in the update=
 endpoint.

>>

>> It should only be the server that deletes a record after satisfyin=
g it's audit requirements.

>>

>> John B.

>>

>> On 2013-02-13, at 12:00 PM, Justin Richer <jricher@mitre.org> wrote:

>>

>>> Would it be reasonable to mark the PUT and DELETE methods as o=
ptional for the server to implement, but with defined semantics if they do?=
 I want to keep GET and POST(create) as mandatory, as I think that's th=
e minimal set of functionality required.

>>>

>>> -- Justin

>>>

>>> On 02/11/2013 08:51 PM, John Bradley wrote:

>>>> I would always include the client_id on update.

>>>>

>>>> I think it is also us full to have other tokens used at th=
e update endpoint. =C2=A0I can see the master token used to update all the =
clients it has registered as part of API management.

>>>> Relying on the registration_access_token is probably a des=
ign that will cause trouble down the road.

>>>>

>>>> I think GET and POST are relatively clear. =C2=A0 I don=
9;t know about expelling PUT to developers. =C2=A0I think POST with a clien=
t_id to a (separate discussion) update_uri works without restricting it to =
PUT.

>>>>

>>>> I think DELETE needs to be better understood. =C2=A0 I thi=
nk a status that can be set for client lifecycle is better than letting a c=
lient delete a entry.

>>>> In some cases there will be more than one instance of a cl=
ient and letting them know they have been turned off for a reason is better=
 than making there registration disappear.

>>>> So for the moment I would levee out DELETE.

>>>>

>>>> John B.

>>>>

>>>> On 2013-02-11, at 6:14 PM, Justin Richer <jricher@mitre.org> wrote:<=
br>
>>>>

>>>>> Draft -05 of OAuth Dynamic Client Registration [1] def=
ines several operations that the client can take on its behalf as part of t=
he registration process. These boil down to the basic CRUD operations that =
you find in many APIs: Create, Read, Update, Delete. Draft -00 defined only=
 the "Create" operation, draft -01 through -04 added the "Up=
date" operation, switched using the "operation=3D" parameter=
.

>>>>>

>>>>> Following several suggestions to do so on the list, th=
e -05 draft defines these operations in terms of a RESTful API for the clie=
nt. Namely:

>>>>>

>>>>> - HTTP POST to registration endpoint =3D> Create (r=
egister) a new client

>>>>> - HTTP PUT to update endpoint (with registration_acces=
s_token) =3D> Update the registered information for this client

>>>>> - HTTP GET to update endpoint (with registration_acces=
s_token) =3D> read the registered information for this client

>>>>> - HTTP DELETE to update endpoint (with registration_ac=
cess_token) =3D> Delete (unregister/de-provision) this client

>>>>>

>>>>> The two main issues at stake here are: the addition of=
 the READ and DELETE methods, and the use of HTTP verbs following a RESTful=
 design philosophy.

>>>>>

>>>>> Pro:

>>>>> - RESTful APIs (with HTTP verbs to differentiate funct=
ionality) are the norm today

>>>>> - Full lifecycle management is common and is going to =
be expected by many users of this protocol in the wild

>>>>>

>>>>> Cons:

>>>>> - Update semantics are still under debate (full replac=
e? patch?)

>>>>> - Somewhat increased complexity on the server to suppo=
rt all operations

>>>>> - Client has to understand all HTTP verbs for full acc=
ess (though plain registration is just POST)

>>>>>

>>>>>

>>>>> Alternatives include using an operational switch param=
eter (like the old drafts), defining separate endpoints for every action, o=
r doing all operations on a single endpoint using verbs to switch.

>>>>>

>>>>> -- Justin

>>>>>

>>>>> [1] http://tools.ietf.org/html/draft-ietf-oa=
uth-dyn-reg-05

>>>>> _______________________________________________

>>>>> OAuth mailing list

>>>>> OA=
uth@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

h=
ttps://www.ietf.org/mailman/listinfo/oauth

--14dae9340ae99f438504d5a1cd62--

From ve7jtb@ve7jtb.com  Wed Feb 13 13:38:03 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE99521F8578 for ; Wed, 13 Feb 2013 13:38:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.353
X-Spam-Level: 
X-Spam-Status: No, score=-3.353 tagged_above=-999 required=5 tests=[AWL=0.245,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3liDh0EfB9Hj for ; Wed, 13 Feb 2013 13:38:02 -0800 (PST)
Received: from mail-qe0-f42.google.com (mail-qe0-f42.google.com [209.85.128.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7436721F8576 for ; Wed, 13 Feb 2013 13:38:02 -0800 (PST)
Received: by mail-qe0-f42.google.com with SMTP id 2so786268qeb.1 for ; Wed, 13 Feb 2013 13:38:01 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=ZYzP7qaDnUZX9B3aoKrha0m/G1/RlB4aHg3n40OEOFI=; b=JuX+RMYpRJAJ0mdPjzeM+QT619MHfcWv6dIIoxwQZ7/6cLRGD0VCmUcI8++3BQC/1C PmEUcsDoD2htJ+JT3NoZg18Qz2Yd0gkt8heTNBx4Fx3nzoNu1R3BR3DCYiHjSdJFkMcP tsnF5C8I/to1CRBSzzXEHaPkxGxlJEddkINKNZugtV0+RO5ZLEy8Biqq0dnFrok9Ikss PROhY7nVJcY1QmqqSTJ4g+IlRCNrrP+O0m5wDy3qe8DYtnsYlqGl425OwEwzniWm04Dl KbPk7klOrdeZxcPB8tMUDV+KjAFZqC2PVTsPcb7cpaGpXivrQryGOtK3pXVagD7mFIns PvEw==
X-Received: by 10.224.185.148 with SMTP id co20mr9139829qab.94.1360791481706;  Wed, 13 Feb 2013 13:38:01 -0800 (PST)
Received: from [192.168.1.213] ([190.20.26.0]) by mx.google.com with ESMTPS id ei2sm17844325qab.3.2013.02.13.13.37.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Feb 2013 13:38:00 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_0753F585-C3C2-4096-9752-9C6453E02329"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: 
Date: Wed, 13 Feb 2013 18:37:07 -0300
Message-Id: 
References: <51195F36.6040705@mitre.org> <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com> <511BAA8B.8030309@mitre.org>  <-4554688250617930935@unknownmsgid>  
To: Tim Bray 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQnfXNCJ8+n0fMsQalABzdXc6BZh6ialcrELwYrILJ/9zdEuz5ZoOf9haB9LfRsIY6AyuFFr
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Feb 2013 21:38:03 -0000

--Apple-Mail=_0753F585-C3C2-4096-9752-9C6453E02329
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

OK Tim do you think DELETE is a feature that:
a) developers would use
b) that Authorization servers like google would implement.

If we put it in and than have people say you have a bunch of extra stuff =
no line is going to use just to be semantically pure.  I will not be a =
happy bunny.

Just because HTTP has a verb we don't need to use it if we don't have a =
concrete use case.

If you say Google would implement it and use it for x or y than I would =
feel differently about it.

I don't hate DELETE though I think it is probably a bad power to give to =
clients. =20

Feedback on your use case please.

John B.

On 2013-02-13, at 6:26 PM, Tim Bray  wrote:

> A DELETE is an http request that asks the server to delete something.  =
We probably would want to avoid writing a requirement into the standard =
that the server has to comply.  So you get back a 204 if it worked, a =
404 if there is no such registration, a 403 if there is but the server =
declines to delete, etc. Seems pretty straightforward. -T
>=20
> On Wed, Feb 13, 2013 at 12:18 PM, John Bradley  =
wrote:
> DELETE is removing the record not resetting it to defaults.  They are =
quite diffrent.
>=20
> I want to agree on what the expected behaviour of DELETE is.   I think =
we have agreement on PUT and POST.
>=20
> The general not in that a client can DELETE it's record is a =
implication I don't like.  I think that is for the server to decide and =
if it is not actually deleting it then DELETE is the wrong verb to use.
>=20
> John B.
>=20
> On 2013-02-13, at 3:31 PM, Nat Sakimura  wrote:
>=20
> > Generally speaking, mapping PUT to replace and POST to change is an
> > acceptable practice so I am fine with it.
> >
> > Now, what I still do not understand is why you think it is fine to =
do
> > PUT or POST and not DELETE. Doing PUT with empty content is almost =
the
> > same as DELETE. Could you explain?
> >
> > =3Dnat via iPhone
> >
> > Feb 14, 2013 0:10=E3=80=81John Bradley  =
=E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8:
> >
> >> I am not violently opposed to PUT as a option that completely =
replaces the resource setting all unsent claims back to the defaults.
> >>
> >> I don't have a good feeling about DELETE,  I think we still need =
more discussion on what it means, what privileges it takes to invoke it =
etc.
> >> It could be a bad thing if we get wrong or is not implemented =
consistently.
> >>
> >> Personally I don't think a client should ever be able to DELETE =
it's record.
> >>
> >> I think marking a client_id as pending provisioning, suspended,  =
revoked etc is better and that can be done with a claim in the update =
endpoint.
> >>
> >> It should only be the server that deletes a record after satisfying =
it's audit requirements.
> >>
> >> John B.
> >>
> >> On 2013-02-13, at 12:00 PM, Justin Richer  =
wrote:
> >>
> >>> Would it be reasonable to mark the PUT and DELETE methods as =
optional for the server to implement, but with defined semantics if they =
do? I want to keep GET and POST(create) as mandatory, as I think that's =
the minimal set of functionality required.
> >>>
> >>> -- Justin
> >>>
> >>> On 02/11/2013 08:51 PM, John Bradley wrote:
> >>>> I would always include the client_id on update.
> >>>>
> >>>> I think it is also us full to have other tokens used at the =
update endpoint.  I can see the master token used to update all the =
clients it has registered as part of API management.
> >>>> Relying on the registration_access_token is probably a design =
that will cause trouble down the road.
> >>>>
> >>>> I think GET and POST are relatively clear.   I don't know about =
expelling PUT to developers.  I think POST with a client_id to a =
(separate discussion) update_uri works without restricting it to PUT.
> >>>>
> >>>> I think DELETE needs to be better understood.   I think a status =
that can be set for client lifecycle is better than letting a client =
delete a entry.
> >>>> In some cases there will be more than one instance of a client =
and letting them know they have been turned off for a reason is better =
than making there registration disappear.
> >>>> So for the moment I would levee out DELETE.
> >>>>
> >>>> John B.
> >>>>
> >>>> On 2013-02-11, at 6:14 PM, Justin Richer  =
wrote:
> >>>>
> >>>>> Draft -05 of OAuth Dynamic Client Registration [1] defines =
several operations that the client can take on its behalf as part of the =
registration process. These boil down to the basic CRUD operations that =
you find in many APIs: Create, Read, Update, Delete. Draft -00 defined =
only the "Create" operation, draft -01 through -04 added the "Update" =
operation, switched using the "operation=3D" parameter.
> >>>>>
> >>>>> Following several suggestions to do so on the list, the -05 =
draft defines these operations in terms of a RESTful API for the client. =
Namely:
> >>>>>
> >>>>> - HTTP POST to registration endpoint =3D> Create (register) a =
new client
> >>>>> - HTTP PUT to update endpoint (with registration_access_token) =
=3D> Update the registered information for this client
> >>>>> - HTTP GET to update endpoint (with registration_access_token) =
=3D> read the registered information for this client
> >>>>> - HTTP DELETE to update endpoint (with =
registration_access_token) =3D> Delete (unregister/de-provision) this =
client
> >>>>>
> >>>>> The two main issues at stake here are: the addition of the READ =
and DELETE methods, and the use of HTTP verbs following a RESTful design =
philosophy.
> >>>>>
> >>>>> Pro:
> >>>>> - RESTful APIs (with HTTP verbs to differentiate functionality) =
are the norm today
> >>>>> - Full lifecycle management is common and is going to be =
expected by many users of this protocol in the wild
> >>>>>
> >>>>> Cons:
> >>>>> - Update semantics are still under debate (full replace? patch?)
> >>>>> - Somewhat increased complexity on the server to support all =
operations
> >>>>> - Client has to understand all HTTP verbs for full access =
(though plain registration is just POST)
> >>>>>
> >>>>>
> >>>>> Alternatives include using an operational switch parameter (like =
the old drafts), defining separate endpoints for every action, or doing =
all operations on a single endpoint using verbs to switch.
> >>>>>
> >>>>> -- Justin
> >>>>>
> >>>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
> >>>>> _______________________________________________
> >>>>> 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
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20

--Apple-Mail=_0753F585-C3C2-4096-9752-9C6453E02329
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

OK =
Tim do you think DELETE is a feature that:a) developers would =
use
b) that Authorization servers like google would =
implement.

If we put it in and than have people =
say you have a bunch of extra stuff no line is going to use just to be =
semantically pure.  I will not be a happy =
bunny.

Just because HTTP has a verb we don't =
need to use it if we don't have a concrete use =
case.

If you say Google would implement it and =
use it for x or y than I would feel differently about =
it.

I don't hate DELETE though I think it is =
probably a bad power to give to clients. =

Feedback on your use case =
please.

John =
B.

On 2013-02-13, at 6:26 PM, Tim =
Bray <twbray@google.com> =
wrote:

A DELETE is an http request that asks the server to delete =
something.  We probably would want to avoid writing a requirement =
into the standard that the server has to comply.  So you get back a =
204 if it worked, a 404 if there is no such registration, a 403 if there =
is but the server declines to delete, etc. Seems pretty straightforward. =
-T

On Wed, Feb 13, 2013 at 12:18 PM, John =
Bradley <ve7jtb@ve7jtb.com> wrote:

DELETE is removing the record not resetting it to defaults.  They =
are quite diffrent.

I want to agree on what the expected behaviour of DELETE is.   I =
think we have agreement on PUT and POST.

The general not in that a client can DELETE it's record is a implication =
I don't like.  I think that is for the server to decide and if it =
is not actually deleting it then DELETE is the wrong verb to use.

John B.

On 2013-02-13, at 3:31 PM, Nat Sakimura <sakimura@gmail.com> wrote:

> Generally speaking, mapping PUT to replace and POST to change is =
an

> acceptable practice so I am fine with it.

>

> Now, what I still do not understand is why you think it is fine to =
do

> PUT or POST and not DELETE. Doing PUT with empty content is almost =
the

> same as DELETE. Could you explain?

>

> =3Dnat via iPhone

>

> Feb 14, 2013 0:10=E3=80=81John Bradley <ve7jtb@ve7jtb.com> =E3=81=AE=E3=83=A1=E3=83=83=E3=
=82=BB=E3=83=BC=E3=82=B8:

>

>> I am not violently opposed to PUT as a option that completely =
replaces the resource setting all unsent claims back to the =
defaults.

>>

>> I don't have a good feeling about DELETE,  I think we =
still need more discussion on what it means, what privileges it takes to =
invoke it etc.

>> It could be a bad thing if we get wrong or is not implemented =
consistently.

>>

>> Personally I don't think a client should ever be able to DELETE =
it's record.

>>

>> I think marking a client_id as pending provisioning, suspended, =
 revoked etc is better and that can be done with a claim in the =
update endpoint.

>>

>> It should only be the server that deletes a record after =
satisfying it's audit requirements.

>>

>> John B.

>>

>> On 2013-02-13, at 12:00 PM, Justin Richer <jricher@mitre.org> wrote:

>>

>>> Would it be reasonable to mark the PUT and DELETE methods =
as optional for the server to implement, but with defined semantics if =
they do? I want to keep GET and POST(create) as mandatory, as I think =
that's the minimal set of functionality required.

>>>

>>> -- Justin

>>>

>>> On 02/11/2013 08:51 PM, John Bradley wrote:

>>>> I would always include the client_id on update.

>>>>

>>>> I think it is also us full to have other tokens used at =
the update endpoint.  I can see the master token used to update all =
the clients it has registered as part of API management.

>>>> Relying on the registration_access_token is probably a =
design that will cause trouble down the road.

>>>>

>>>> I think GET and POST are relatively clear.   I =
don't know about expelling PUT to developers.  I think POST with a =
client_id to a (separate discussion) update_uri works without =
restricting it to PUT.

>>>>

>>>> I think DELETE needs to be better understood.   I =
think a status that can be set for client lifecycle is better than =
letting a client delete a entry.

>>>> In some cases there will be more than one instance of a =
client and letting them know they have been turned off for a reason is =
better than making there registration disappear.

>>>> So for the moment I would levee out DELETE.

>>>>

>>>> John B.

>>>>

>>>> On 2013-02-11, at 6:14 PM, Justin Richer <jricher@mitre.org> wrote:

>>>>

>>>>> Draft -05 of OAuth Dynamic Client Registration [1] =
defines several operations that the client can take on its behalf as =
part of the registration process. These boil down to the basic CRUD =
operations that you find in many APIs: Create, Read, Update, Delete. =
Draft -00 defined only the "Create" operation, draft -01 through -04 =
added the "Update" operation, switched using the "operation=3D" =
parameter.

>>>>>

>>>>> Following several suggestions to do so on the list, =
the -05 draft defines these operations in terms of a RESTful API for the =
client. Namely:

>>>>>

>>>>> - HTTP POST to registration endpoint =3D> Create =
(register) a new client

>>>>> - HTTP PUT to update endpoint (with =
registration_access_token) =3D> Update the registered information for =
this client

>>>>> - HTTP GET to update endpoint (with =
registration_access_token) =3D> read the registered information for =
this client

>>>>> - HTTP DELETE to update endpoint (with =
registration_access_token) =3D> Delete (unregister/de-provision) this =
client

>>>>>

>>>>> The two main issues at stake here are: the addition =
of the READ and DELETE methods, and the use of HTTP verbs following a =
RESTful design philosophy.

>>>>>

>>>>> Pro:

>>>>> - RESTful APIs (with HTTP verbs to differentiate =
functionality) are the norm today

>>>>> - Full lifecycle management is common and is going =
to be expected by many users of this protocol in the wild

>>>>>

>>>>> Cons:

>>>>> - Update semantics are still under debate (full =
replace? patch?)

>>>>> - Somewhat increased complexity on the server to =
support all operations

>>>>> - Client has to understand all HTTP verbs for full =
access (though plain registration is just POST)

>>>>>

>>>>>

>>>>> Alternatives include using an operational switch =
parameter (like the old drafts), defining separate endpoints for every =
action, or doing all operations on a single endpoint using verbs to =
switch.

>>>>>

>>>>> -- Justin

>>>>>

>>>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05

>>>>> _______________________________________________

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

=

--Apple-Mail=_0753F585-C3C2-4096-9752-9C6453E02329--

From internet-drafts@ietf.org  Wed Feb 13 14:13:27 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7F121F8576; Wed, 13 Feb 2013 14:13:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhgUEDb6Pl6K; Wed, 13 Feb 2013 14:13:26 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9128221F8589; Wed, 13 Feb 2013 14:13:26 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.40
Message-ID: <20130213221326.3987.20729.idtracker@ietfa.amsl.com>
Date: Wed, 13 Feb 2013 14:13:26 -0800
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-05.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Feb 2013 22:13:27 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Web Authorization Protocol Working Group =
of the IETF.

	Title           : Token Revocation
	Author(s)       : Torsten Lodderstedt
                          Stefanie Dronia
                          Marius Scurtescu
	Filename        : draft-ietf-oauth-revocation-05.txt
	Pages           : 9
	Date            : 2013-02-13

Abstract:
   This document proposes an additional endpoint for OAuth authorization
   servers, which allows clients to notify the authorization server that
   a previously obtained refresh or access token is no longer needed.
   This allows the authorization server to cleanup security credentials.
   A revocation request will invalidate the actual token and, if
   applicable, other tokens based on the same authorization grant.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-revocation-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-revocation-05

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

From torsten@lodderstedt.net  Wed Feb 13 14:19:06 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D8F21E8054 for ; Wed, 13 Feb 2013 14:19:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.37
X-Spam-Level: 
X-Spam-Status: No, score=-1.37 tagged_above=-999 required=5 tests=[AWL=-0.413,  BAYES_00=-2.599, HELO_EQ_DE=0.35, MISSING_HEADERS=1.292]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFU9CgTRT4As for ; Wed, 13 Feb 2013 14:19:05 -0800 (PST)
Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.101]) by ietfa.amsl.com (Postfix) with ESMTP id F0DC421E803D for ; Wed, 13 Feb 2013 14:19:04 -0800 (PST)
Received: from [91.2.85.204] (helo=[192.168.71.42]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1U5kfP-0007b6-D6 for oauth@ietf.org; Wed, 13 Feb 2013 23:19:03 +0100
Message-ID: <511C1155.6050709@lodderstedt.net>
Date: Wed, 13 Feb 2013 23:19:01 +0100
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
CC: oauth@ietf.org
References: <20130213221326.3987.20729.idtracker@ietfa.amsl.com>
In-Reply-To: <20130213221326.3987.20729.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-05.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Feb 2013 22:19:06 -0000

Hi all,

I just published a new revision, which should cover all the issues 
raised/dicussed during WGLC.

I applied the following changes:
- introduced a new parameter "token_type_hint", which a client may use 
to give the authorization server a hint about the type of the token to 
be revoked
- replaced "authorization" by "authorization grant"
- an attempt to revoke an invalid token is now handled like a successful 
revocation request (status code 200)
- CORS is now a MAY instead of SHOULD
- extended description of how developer/client may obtain endpoint location
- Improved wording regarding expected client behavior after sucessful 
processing of the revocation request -> "The client must assume the 
revocation is immediate upon the return of the request."
- Explanation of different policies and why having different server 
policies should not cause interop problems
- aligned structure with core spec by introducing sub-sections for 
request and response

regards,
Torsten.

Am 13.02.2013 23:13, schrieb internet-drafts@ietf.org:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the Web Authorization Protocol Working Group of the IETF.
>
> 	Title           : Token Revocation
> 	Author(s)       : Torsten Lodderstedt
>                            Stefanie Dronia
>                            Marius Scurtescu
> 	Filename        : draft-ietf-oauth-revocation-05.txt
> 	Pages           : 9
> 	Date            : 2013-02-13
>
> Abstract:
>     This document proposes an additional endpoint for OAuth authorization
>     servers, which allows clients to notify the authorization server that
>     a previously obtained refresh or access token is no longer needed.
>     This allows the authorization server to cleanup security credentials.
>     A revocation request will invalidate the actual token and, if
>     applicable, other tokens based on the same authorization grant.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-oauth-revocation-05
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-revocation-05
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From prateek.mishra@oracle.com  Wed Feb 13 14:53:57 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE56C21F8778 for ; Wed, 13 Feb 2013 14:53:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aob8Jcvb4A6q for ; Wed, 13 Feb 2013 14:53:57 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE8921F8775 for ; Wed, 13 Feb 2013 14:53:57 -0800 (PST)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1DMrtXa020617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Feb 2013 22:53:56 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1DMrtI3010659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Feb 2013 22:53:55 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1DMrt3A027694; Wed, 13 Feb 2013 16:53:55 -0600
Received: from [10.154.116.110] (/10.154.116.110) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 13 Feb 2013 14:53:54 -0800
Message-ID: <511C1980.6030603@oracle.com>
Date: Wed, 13 Feb 2013 17:53:52 -0500
From: Prateek Mishra 
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: oauth@ietf.org
References: <51195F36.6040705@mitre.org> <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com> <511BAA8B.8030309@mitre.org>  <-4554688250617930935@unknownmsgid>   
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: [OAUTH-WG] comments on draft-ietf-oauth-saml2-bearer-15
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Feb 2013 22:53:58 -0000

It would be helpful if the draft identified the various cases that are 
intended to be supported. For example,
in draft-ietf-oauth-assertions-10, there is a helpful distinction made 
between "Client acting on behalf of a user" vs.
"Client Action on behalf of an anonymous user" (vs. even more advanced 
use-cases). Otherwise, folks
have a hard time figuring out the pieces they need to implement and the 
required behavior.

It feels like Section 3 speaks to all of these cases simultaneously. I 
think this is confusing and
our developers have raised some questions about it.

BTW, it would also help if the rules in Section 3 were numbered.

1) For the case where we have "Client acting on behalf of user" - this 
case seems to be where we
have something like a SAML SSO assertion - complete with Subject 
identifying the
"authorized accessor or delegate". The Client offers this bearer 
instrument as an access grant and the Authorization
server understands that its "acting on behalf a user".

a) As the SAML assertion is a bearer instrument and can be stolen, the 
authorization server should insist on client credentials being present.
In other words, the client should be confidential. What is the value in 
permitting a public client to participate in this exchange?

b) Further, as part of its processing rules, once the client has been 
authenticated
the authorization server should determine whether the particular client 
has the right to present the SAML bearer assertion.

c)  What is the value of including an AuthNStatement? Specifically, what 
does the Authorization server understand by its
presence or absence? What is the guidance to deployers? Should they 
require end-user authentication to have taken place?

2) Bullet 5 (counting from the bottom of Section 3) references a more 
advanced use case based on a SAML delegation
model. Is this the ONLY case where AuthNStatement's are allowed to be 
omitted? If so, that should be stated clearly.

  I think this bullet refers to an advanced use-case and should be moved 
to an independent section.

I think by "the presenter act autonomously on behalf of the subject" you 
mean something like "Client acts on Behalf of Anonymous Users".
as identified in draft-ietf-oauth-assertions-10.

I also found the sentence "The presented SHOULD be identified in the 
 or similar element,.." problematic. Its pretty open ended
and it seems to me it will be difficult to have an interoperable 
implementation based on this text.

Finally, what are the additional processing rules that the authorization 
server needs to implement when processing this class of SAML assertions?

3) Has there been any interoperability testing of this profile? This is 
an activity we would be interested in.

From sakimura@gmail.com  Wed Feb 13 19:26:21 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F062F21F8778 for ; Wed, 13 Feb 2013 19:26:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.343
X-Spam-Level: 
X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=-0.497, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPa9tvIB5hpy for ; Wed, 13 Feb 2013 19:26:21 -0800 (PST)
Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by ietfa.amsl.com (Postfix) with ESMTP id AAA6421F8775 for ; Wed, 13 Feb 2013 19:26:17 -0800 (PST)
Received: by mail-lb0-f173.google.com with SMTP id gf7so1449047lbb.4 for ; Wed, 13 Feb 2013 19:26:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=Jzz6LwujXKqg6QBJzB4xMJsk5MEmatgn6qNcpNAksRk=; b=GtA1hAnG/MBlO9S1lCKspCGhdK3Yoxe56tmZQaOLf3F9qxeXre4p9PS9XtTE7UCngU amysHBIRRIzU8gjHZ3Kornr+EbOXIMLX36QObNV64IvbmH3ijnjygYoM/4305CK9l9lt XQM3qsknm65yKviSnn8SyV0K7Ncp4YGhBQ4gTZgaorHmkT00JwVJJnAgFk166YS6bePi T9Bdhc217N7f2KdlsvlK8hVoT6CjA88tu6Bq07RR790Kek1UrZw70H7zTFw0Y93x8Te8 NRLZUmzeHKqgr6hgiTAIAscGcd+Whk4JXIJHc6kHwBPiYIHKYA0/IV1+zoWHiUa7606W vKLw==
MIME-Version: 1.0
X-Received: by 10.112.29.1 with SMTP id f1mr6792563lbh.30.1360812376624; Wed, 13 Feb 2013 19:26:16 -0800 (PST)
Received: by 10.112.14.44 with HTTP; Wed, 13 Feb 2013 19:26:16 -0800 (PST)
In-Reply-To: <511BDE17.7060503@mitre.org>
References: <51195F36.6040705@mitre.org> <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com> <80727F20-A830-4778-B11C-D45389310646@lodderstedt.net> <511A5742.30707@mitre.org>  <511A705F.4070204@mitre.org>  <4E1F6AAD24975D4BA5B168042967394367443862@TK5EX14MBXC285.redmond.corp.microsoft.com> <-7739255357185893925@unknownmsgid> <511BDE17.7060503@mitre.org>
Date: Thu, 14 Feb 2013 12:26:16 +0900
Message-ID: 
From: Nat Sakimura 
To: Justin Richer 
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: base64
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2013 03:26:22 -0000

MjAxMy8yLzE0IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0cmUub3JnPjoNCj4gRHVseSBub3Rl
ZCwgYW5kIHdoaWxlIHRoZXJlIHNlZW1zIHRvIGJlIHNvbGlkIHN1cHBvcnQgYmVoaW5kIHRoZQ0K
PiBzZW1hbnRpY3Mgb2YgcmV0dXJuaW5nIGEgVVJMLCBJJ20gbm90IGNvbnZpbmNlZCB0aGUgc3lu
dGF4IGFyZ3VtZW50IGlzDQo+IG92ZXIgeWV0IGVpdGhlci4gSSBoYXZlIHNlZW4gc3VwcG9ydCBh
bmQgZ29vZCBhcmd1bWVudHMgZnJvbSBib3RoIHNpZGVzDQo+IGFuZCB0aGVyZSBpc24ndCBhIGNs
ZWFyIHdpbm5lciB0aGVyZSAoc2VlIHRoZSBvdGhlciB0aHJlYWQpLiBTcGVha2luZyBhcw0KPiBh
biBpbmRpdmlkdWFsIG1lbWJlciwgSSBjb3VsZCBnbyB3aXRoIGVpdGhlciBhcHByb2FjaCBhbmQg
SSdkIGxpa2UgdG8NCj4gc2VlIHdoYXQgdGhlIHJlc3Qgb2YgdGhlIFdHIHdhbnRzLg0KDQpUaGFu
ayB5b3UuIEkgd2FudGVkIHRvIHJhaXNlIGEgdm9pY2UgdGhhdCB3aGlsZSB0aGUgbmVlZCBmb3Ig
dGhlDQpyZXR1cm5pbmcgdGhlIFVSTA0Kc2VlbWVkIHRvIGhhdmUgY29tZSB0byBhIGNvbnNlbnN1
cywgdGhlIHN5bnRheCBoYXMgbm90LCB1bmxpa2UgTWlrZSB3cm90ZS4NCg0KPg0KPiBTcGVha2lu
ZyBub3cgYXMgYW4gZWRpdG9yOiBJdCdzIGJlZW4gc3VnZ2VzdGVkIG9mZi1saXN0IHRoYXQgd2Ug
YWRvcHQNCj4gdGhlIHNpbXBsaWZpZWQgKGJlc3Bva2UpIG1lY2hhbmlzbSBvZiB0aGUgInJlZ2lz
dHJhdGlvbl9hY2Nlc3NfdXJsIg0KPiBzeW50YXggZm9yIHRoZSBuZXh0IGRyYWZ0IGFuZCBjb250
aW51ZSB0byBtb3ZlIGRpc2N1c3Npb24gZm9yd2FyZCBmb3INCj4gdGhlIGluY2x1c2lvbiBvZiB0
aGUgbW9yZS1nZW5lcmFsIG1lY2hhbmlzbSAoYmVpdCBIQUwgYmFzZWQgb3Igc29tZXRoaW5nDQo+
IHNpbWlsYXIgbGlrZSBKU09OLUxEKSBoZXJlIG9uIHRoZSBsaXN0LiBXb3VsZCB5b3UgYW5kIHRo
ZSBvdGhlciBIQUwNCj4gc3VwcG9ydGVycyBiZSBhbWVuYWJsZSB0byB0aGlzIHNvbHV0aW9uPyBJ
IHdvdWxkbid0IGJlIG9wcG9zZWQgdG8gYWRkaW5nDQo+IGEga2luZCBvZiAibm90ZSBmb3IgZGlz
Y3Vzc2lvbiIgc2VjdGlvbiB0byB0aGUgLTA2IGRyYWZ0IHRvIGhlbHANCj4gZmFjaWxpdGF0ZSBt
b3ZpbmcgZm9yd2FyZCBpbiBhIGNvbmNyZXRlIG1hbm5lciwgd2l0aCB0aGUgYXNzdW1wdGlvbiB0
aGF0DQo+IHRoZSB0ZXh0IHdvdWxkIGJlIGVpdGhlciByZW1vdmVkIG9yIGluY29ycG9yYXRlZCBp
biBhIGxhdGVyIGRyYWZ0LiBJDQo+IGp1c3QgaGF2ZSB0byBwdXQgYSBzdGFrZSBkb3duIHNvbWV3
aGVyZSBvbiB0aGUgc3ludGF4LCBhbmQgSSdtIGxlYW5pbmcNCj4gdG93YXJkcyB0aGUgb25lIHRo
YXQgZG9lc24ndCBhZGQgYSBub3JtYXRpdmUgZGVwZW5kZW5jeSBvbiBhbiB1bmZpbmlzaGVkDQo+
IChhcyBvZiByaWdodCBub3cpIHdvcmsuDQoNCkZZSSwgSSBoYXZlIG5vdCBzdWdnZXN0ZWQgdG8g
cmVmZXJlbmNlIEhBTCBvciBvdGhlciB1bmZpbmlzaGVkIHNwZWNpZmljYXRpb25zLA0KYnV0IGlu
Y29ycG9yYXRlIHRoZSBzeW50YXguIElmIHRoZXJlIGlzIHRvIGJlIGEgcmVmZXJlbmNlLCB0aGVu
IHRoYXQgaXMgZm9yIHRoZQ0KY3VydGVzeSBhbmQgd2lsbCBiZSBhbiBpbmZvcm1hdGlvbmFsIHJl
ZmVyZW5jZS4NCg0KQXMgdG8gdGhlIGFjdHVhbCBlZGl0aW5nIGlzIGNvbmNlcm5lZCwgbWF5IEkg
c3VnZ2VzdCB0aGUgcmV2ZXJzZTogaS5lLiwNCmtlZXAgdGhlIGN1cnJlbnQgdGV4dCAoLTA1KSBh
bmQgYWRkIGEgbm90ZSBmb3IgZGlzY3Vzc2lvbi4NCkl0IGlzIGN1c3RvbWFyeSBpbiB0aGUgc3Rh
bmRhcmRpemF0aW9uIHByb2Nlc3MgdGhhdCB0aGUgY2hhbmdlIHRvIHRoZSB0ZXh0DQppcyBub3Qg
dG8gYmUgaW5jb3Jwb3JhdGVkIHVudGlsIHRoZSByZXNvbHV0aW9uIGZyb20gdGhlIGNvbW1lbnRz
IGFyZSByZWFjaGVkLg0KSWYgdGhlIHRleHQgaXMgY2hhbmdlZCwgdGhlbiBpdCBtZWFucyB0aGF0
IHRoZSByZXNvbHV0aW9uIGlzIHJlYWNoZWQsDQp3aGljaCBpcyBub3QgdGhlIGNhc2UuIEV2ZW4g
Im5lIGJpcyBpbiBpZGVtIiBtYXkga2ljayBpbiwgd2hpY2ggZWZmZWN0aXZlbHkNCnByb2hpYml0
IHRoZSBjaGFuZ2UgYmFjay4NCg0KTmF0DQoNCj4NCj4gLS0gSnVzdGluDQo+DQo+IE9uIDAyLzEz
LzIwMTMgMDE6MjcgUE0sIE5hdCBTYWtpbXVyYSB3cm90ZToNCj4+IEkgYW0gYWdhaW5zdCB0aGUg
c3ludGF4IG9mIHJlZ2lzdHJhdGlvbl9hY2Nlc3NfdXJsIC4NCj4+DQo+PiA9bmF0IHZpYSBpUGhv
bmUNCj4+DQo+PiBGZWIgMTMsIDIwMTMgMzozNxskQiEiGyhCTWlrZSBKb25lcyA8TWljaGFlbC5K
b25lc0BtaWNyb3NvZnQuY29tPiAbJEIkTiVhJUMlOyE8JTgbKEI6DQo+Pg0KPj4+IFRoZW4gSSB0
aGluayB3ZSd2ZSByZWFjaGVkIGFuIGFjY2VwdGFibGUgcmVzb2x1dGlvbiBvbiB0aGlzIG9uZS4g
IEJ5IGhhdmluZyB0aGUgc2VydmVyIHJldHVybiB0aGUgcmVnaXN0cmF0aW9uX2FjY2Vzc191cmwg
dXBvbiBjcmVhdGUgYW5kIGhhdmluZyB0aGUgY2xpZW50IGJlIHJlcXVpcmVkIHRvIGluY2x1ZGUg
dGhlIGNsaWVudF9pZCB1cG9uIHVwZGF0ZSwgc2VydmVycyBhcmUgZnJlZSB0byBtYW5hZ2UgdGhl
aXIgcmVnaXN0cmF0aW9uIGVuZHBvaW50KHMpIGFzIHRoZXkgc2VlIGZpdCBhbmQgY2xpZW50cyBh
bHdheXMgZG8gdGhlIHNhbWUgdGhpbmcuDQo+Pj4NCj4+PiAgICAgICAgICAgICAgICBUaGFua3Mg
YWxsLA0KPj4+ICAgICAgICAgICAgICAgIC0tIE1pa2UNCj4+Pg0KPj4+IC0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tDQo+Pj4gRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9h
dXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBOYXQgU2FraW11cmENCj4+PiBTZW50
OiBUdWVzZGF5LCBGZWJydWFyeSAxMiwgMjAxMyA5OjE1IEFNDQo+Pj4gVG86IEp1c3RpbiBSaWNo
ZXINCj4+PiBDYzogb2F1dGhAaWV0Zi5vcmcNCj4+PiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBS
ZWdpc3RyYXRpb246IFJFU1RmdWwgY2xpZW50IGxpZmVjeWNsZSBtYW5hZ2VtZW50DQo+Pj4NCj4+
PiAyMDEzLzIvMTMgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXRyZS5vcmc+Og0KPj4+PiBPbiAw
Mi8xMi8yMDEzIDExOjMwIEFNLCBKb2huIEJyYWRsZXkgd3JvdGU6DQo+Pj4+PiBUbyBzb21lIGV4
dGVudCB3ZSB3YW50IHRoZSBzZXJ2ZXIgdG8gaGF2ZSB0aGUgZmxleGliaWxpdHkgaXQgbmVlZHMu
DQo+Pj4+Pg0KPj4+Pj4gSWYgdGhlIHNlcnZlciBrbm93cyBpdCBpcyBnb2luZyB0byBuZWVkIGNs
aWVudF9pZCBmb3IgR0VUIGl0IG5lZWRzIHRvDQo+Pj4+PiBlbmNvZGUgaXQgaW4gdGhlIHJlc291
cmNlIFVSSSBldGhlciBhcyBwYXJ0IG9mIHRoZSBwYXRoIG9yIGFzIGEgcXVlcnkNCj4+Pj4+IHBh
cmFtZXRlciAodGhhdCBpcyB1cCB0byB0aGUgc2VydmVyKQ0KPj4+Pj4NCj4+Pj4+IFdoZW4gZG9p
bmcgdXBkYXRlcyB0aGUgY2xpZW50IE1VU1QgaW5jbHVkZSB0aGUgY2xpZW50X2lkIGFzIGFuDQo+
Pj4+PiBhZGRpdGlvbmFsIGludGVncml0eSBjaGVjay4gIFNvbWUgc2VydmVycyBtYXkgc3dpdGNo
IG9uIHRoYXQgYnV0IHRoYXQgaXMgdXAgdG8gdGhlbS4NCj4+Pj4gU28gaWYgYnkgdGhpcyB5b3Ug
bWVhbiB0aGF0IHRoZSBjbGllbnQgc3RpbGwgc2ltcGx5IGZvbGxvd3Mgd2hhdGV2ZXINCj4+Pj4g
dXBkYXRlIHVybCB0aGUgc2VydmVyIGhhbmRzIGl0ICh3aGljaCBtYXkgb3IgbWF5IG5vdCBpbmNs
dWRlIHRoZQ0KPj4+PiBjbGllbnRfaWQgaW4gc29tZSBmb3JtLCBidXQgdGhlIGNsaWVudCBkb2Vz
bid0IGNhcmUpLCBhbmQgdGhhdCB0aGUNCj4+Pj4gY2xpZW50IE1VU1QgaW5jbHVkZSBpdHMgY2xp
ZW50X2lkIGluIHRoZSByZXF1ZXN0IGJvZHkgKHRvcC1sZXZlbA0KPj4+PiBtZW1iZXIgb2YgYSBK
U09OIG9iamVjdCwgYXQgdGhlDQo+Pj4+IG1vbWVudCkgd2hlbiBkb2luZyBhIFBVVCAob3IgUE9T
VC9QQVRDSD8gc2VlIGJlbG93KSBmb3IgdGhlIHVwZGF0ZQ0KPj4+PiBhY3Rpb24sIHRoZW4gSSdt
IHRvdGFsbHkgZmluZSB3aXRoIHRoYXQuIElzIHRoaXMgd2hhdCB5b3UncmUgc3VnZ2VzdGluZz8N
Cj4+PiBBcyBmYXIgYXMgSSB1bmRlcnN0YW5kLCB5ZXMuIFRoYXQgaXMgd2hhdCB3ZSBkaXNjdXNz
ZWQgbGFzdCBUaHVyc2RheSBmYWNlIHRvIGZhY2UuDQo+Pj4NCj4+Pg0KPj4+IC0tDQo+Pj4gTmF0
IFNha2ltdXJhICg9bmF0KQ0KPj4+IENoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbg0KPj4+IGh0
dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KPj4+IEBfbmF0X2VuDQo+Pj4gX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QN
Cj4+PiBPQXV0aEBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vb2F1dGgNCj4NCg0KDQoNCi0tIA0KTmF0IFNha2ltdXJhICg9bmF0KQ0KQ2hhaXJtYW4s
IE9wZW5JRCBGb3VuZGF0aW9uDQpodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8NCkBfbmF0X2VuDQo=

From sakimura@gmail.com  Wed Feb 13 19:31:18 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC70421E80D6 for ; Wed, 13 Feb 2013 19:31:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.281
X-Spam-Level: 
X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPdlz81Xrzjq for ; Wed, 13 Feb 2013 19:31:17 -0800 (PST)
Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by ietfa.amsl.com (Postfix) with ESMTP id 59E2D21E80D0 for ; Wed, 13 Feb 2013 19:31:17 -0800 (PST)
Received: by mail-lb0-f175.google.com with SMTP id n3so1435943lbo.6 for ; Wed, 13 Feb 2013 19:31:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=UqfNcsUIGEAXZFeZ25B5mKbX8lKTOc5AByGyN/zGVHw=; b=jpq9gRFX4lKU4klapPLJSWEXr2MSVdgwhkr1WdnUzY/gjJ8QzxGN4CClxLVvwoQJuO 0t8AoJxIwCTiVJe3kieHlen0Z2WRKwfg/zIFth1o+tc1L7UI92KTBgf8X4QKD/9cYBUa grn7lOA7Bct66GwAUpOMSRr3/l+fwqKWuH/EhO4t2P9tO864BzDQWdz4eDKT6enAhLCQ fHyWwhs2ip9NuwjqEwL+zMVOXBNRZxGz9pnWGn9SiFzgEGwsvcHnCPnWmH6jP8LD0XHC gKgPvFvXKLyfIE4gK7wHIVAU4Pp2ImMkUSmVxYVzD5tlqI81Em5XkabyOkBJaa+66ZUU 7tuQ==
MIME-Version: 1.0
X-Received: by 10.152.148.133 with SMTP id ts5mr10599038lab.2.1360812675948; Wed, 13 Feb 2013 19:31:15 -0800 (PST)
Received: by 10.112.14.44 with HTTP; Wed, 13 Feb 2013 19:31:15 -0800 (PST)
In-Reply-To: 
References: <51195F36.6040705@mitre.org> <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com> <511BAA8B.8030309@mitre.org>  <-4554688250617930935@unknownmsgid> 
Date: Thu, 14 Feb 2013 12:31:15 +0900
Message-ID: 
From: Nat Sakimura 
To: John Bradley 
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: base64
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2013 03:31:18 -0000

SSB0aG91Z2h0IHlvdXIgY29uY2VybiBhYm91dCBERUxFVEUgd2FzIHdoZXRoZXIgdGhlIGNsaWVu
dCBzaG91bGQgYmUNCmFsbG93ZWQgdG8gZXJhc2UgdGhlIHJlZ2lzdHJhdGlvbiBkYXRhLg0KSSB0
aG91Z2h0IFBVVCB3aXRoIGFuIGVtcHR5IHZhbHVlcyB3b3VsZCBhY2hpZXZlIGEgc2ltaWxhciBl
ZmZlY3QuDQpPciBkaWQgeW91IG1lYW4gdGhhdCB3aXRoIFBVVCwgdGhlIHNlcnZlciBkZWZhdWx0
IGtpY2tzIGluIGFuZA0KcGFyYW1ldGVycyBhcmUgc2V0IHRvIHRoZSBkZWZhdWx0cz8NCklmIHRo
YXQgaXMgdGhlIGNhc2UsIHRoZXkgYXJlIHF1aXRlIGRpZmZlcmVudCwgSSBhZ3JlZS4NCg0KT24g
dGhlIGVmZmVjdCBvZiBERUxFVEUsICsxIHRvIFRpbSdzIGNvbW1lbnQuDQoNCk5hdA0KDQoyMDEz
LzIvMTQgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbT46DQo+IERFTEVURSBpcyByZW1v
dmluZyB0aGUgcmVjb3JkIG5vdCByZXNldHRpbmcgaXQgdG8gZGVmYXVsdHMuICBUaGV5IGFyZSBx
dWl0ZSBkaWZmcmVudC4NCj4NCj4gSSB3YW50IHRvIGFncmVlIG9uIHdoYXQgdGhlIGV4cGVjdGVk
IGJlaGF2aW91ciBvZiBERUxFVEUgaXMuICAgSSB0aGluayB3ZSBoYXZlIGFncmVlbWVudCBvbiBQ
VVQgYW5kIFBPU1QuDQo+DQo+IFRoZSBnZW5lcmFsIG5vdCBpbiB0aGF0IGEgY2xpZW50IGNhbiBE
RUxFVEUgaXQncyByZWNvcmQgaXMgYSBpbXBsaWNhdGlvbiBJIGRvbid0IGxpa2UuICBJIHRoaW5r
IHRoYXQgaXMgZm9yIHRoZSBzZXJ2ZXIgdG8gZGVjaWRlIGFuZCBpZiBpdCBpcyBub3QgYWN0dWFs
bHkgZGVsZXRpbmcgaXQgdGhlbiBERUxFVEUgaXMgdGhlIHdyb25nIHZlcmIgdG8gdXNlLg0KPg0K
PiBKb2huIEIuDQo+DQo+IE9uIDIwMTMtMDItMTMsIGF0IDM6MzEgUE0sIE5hdCBTYWtpbXVyYSA8
c2FraW11cmFAZ21haWwuY29tPiB3cm90ZToNCj4NCj4+IEdlbmVyYWxseSBzcGVha2luZywgbWFw
cGluZyBQVVQgdG8gcmVwbGFjZSBhbmQgUE9TVCB0byBjaGFuZ2UgaXMgYW4NCj4+IGFjY2VwdGFi
bGUgcHJhY3RpY2Ugc28gSSBhbSBmaW5lIHdpdGggaXQuDQo+Pg0KPj4gTm93LCB3aGF0IEkgc3Rp
bGwgZG8gbm90IHVuZGVyc3RhbmQgaXMgd2h5IHlvdSB0aGluayBpdCBpcyBmaW5lIHRvIGRvDQo+
PiBQVVQgb3IgUE9TVCBhbmQgbm90IERFTEVURS4gRG9pbmcgUFVUIHdpdGggZW1wdHkgY29udGVu
dCBpcyBhbG1vc3QgdGhlDQo+PiBzYW1lIGFzIERFTEVURS4gQ291bGQgeW91IGV4cGxhaW4/DQo+
Pg0KPj4gPW5hdCB2aWEgaVBob25lDQo+Pg0KPj4gRmViIDE0LCAyMDEzIDA6MTAbJEIhIhsoQkpv
aG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb20+IBskQiROJWElQyU7ITwlOBsoQjoNCj4+DQo+
Pj4gSSBhbSBub3QgdmlvbGVudGx5IG9wcG9zZWQgdG8gUFVUIGFzIGEgb3B0aW9uIHRoYXQgY29t
cGxldGVseSByZXBsYWNlcyB0aGUgcmVzb3VyY2Ugc2V0dGluZyBhbGwgdW5zZW50IGNsYWltcyBi
YWNrIHRvIHRoZSBkZWZhdWx0cy4NCj4+Pg0KPj4+IEkgZG9uJ3QgaGF2ZSBhIGdvb2QgZmVlbGlu
ZyBhYm91dCBERUxFVEUsICBJIHRoaW5rIHdlIHN0aWxsIG5lZWQgbW9yZSBkaXNjdXNzaW9uIG9u
IHdoYXQgaXQgbWVhbnMsIHdoYXQgcHJpdmlsZWdlcyBpdCB0YWtlcyB0byBpbnZva2UgaXQgZXRj
Lg0KPj4+IEl0IGNvdWxkIGJlIGEgYmFkIHRoaW5nIGlmIHdlIGdldCB3cm9uZyBvciBpcyBub3Qg
aW1wbGVtZW50ZWQgY29uc2lzdGVudGx5Lg0KPj4+DQo+Pj4gUGVyc29uYWxseSBJIGRvbid0IHRo
aW5rIGEgY2xpZW50IHNob3VsZCBldmVyIGJlIGFibGUgdG8gREVMRVRFIGl0J3MgcmVjb3JkLg0K
Pj4+DQo+Pj4gSSB0aGluayBtYXJraW5nIGEgY2xpZW50X2lkIGFzIHBlbmRpbmcgcHJvdmlzaW9u
aW5nLCBzdXNwZW5kZWQsICByZXZva2VkIGV0YyBpcyBiZXR0ZXIgYW5kIHRoYXQgY2FuIGJlIGRv
bmUgd2l0aCBhIGNsYWltIGluIHRoZSB1cGRhdGUgZW5kcG9pbnQuDQo+Pj4NCj4+PiBJdCBzaG91
bGQgb25seSBiZSB0aGUgc2VydmVyIHRoYXQgZGVsZXRlcyBhIHJlY29yZCBhZnRlciBzYXRpc2Z5
aW5nIGl0J3MgYXVkaXQgcmVxdWlyZW1lbnRzLg0KPj4+DQo+Pj4gSm9obiBCLg0KPj4+DQo+Pj4g
T24gMjAxMy0wMi0xMywgYXQgMTI6MDAgUE0sIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0cmUu
b3JnPiB3cm90ZToNCj4+Pg0KPj4+PiBXb3VsZCBpdCBiZSByZWFzb25hYmxlIHRvIG1hcmsgdGhl
IFBVVCBhbmQgREVMRVRFIG1ldGhvZHMgYXMgb3B0aW9uYWwgZm9yIHRoZSBzZXJ2ZXIgdG8gaW1w
bGVtZW50LCBidXQgd2l0aCBkZWZpbmVkIHNlbWFudGljcyBpZiB0aGV5IGRvPyBJIHdhbnQgdG8g
a2VlcCBHRVQgYW5kIFBPU1QoY3JlYXRlKSBhcyBtYW5kYXRvcnksIGFzIEkgdGhpbmsgdGhhdCdz
IHRoZSBtaW5pbWFsIHNldCBvZiBmdW5jdGlvbmFsaXR5IHJlcXVpcmVkLg0KPj4+Pg0KPj4+PiAt
LSBKdXN0aW4NCj4+Pj4NCj4+Pj4gT24gMDIvMTEvMjAxMyAwODo1MSBQTSwgSm9obiBCcmFkbGV5
IHdyb3RlOg0KPj4+Pj4gSSB3b3VsZCBhbHdheXMgaW5jbHVkZSB0aGUgY2xpZW50X2lkIG9uIHVw
ZGF0ZS4NCj4+Pj4+DQo+Pj4+PiBJIHRoaW5rIGl0IGlzIGFsc28gdXMgZnVsbCB0byBoYXZlIG90
aGVyIHRva2VucyB1c2VkIGF0IHRoZSB1cGRhdGUgZW5kcG9pbnQuICBJIGNhbiBzZWUgdGhlIG1h
c3RlciB0b2tlbiB1c2VkIHRvIHVwZGF0ZSBhbGwgdGhlIGNsaWVudHMgaXQgaGFzIHJlZ2lzdGVy
ZWQgYXMgcGFydCBvZiBBUEkgbWFuYWdlbWVudC4NCj4+Pj4+IFJlbHlpbmcgb24gdGhlIHJlZ2lz
dHJhdGlvbl9hY2Nlc3NfdG9rZW4gaXMgcHJvYmFibHkgYSBkZXNpZ24gdGhhdCB3aWxsIGNhdXNl
IHRyb3VibGUgZG93biB0aGUgcm9hZC4NCj4+Pj4+DQo+Pj4+PiBJIHRoaW5rIEdFVCBhbmQgUE9T
VCBhcmUgcmVsYXRpdmVseSBjbGVhci4gICBJIGRvbid0IGtub3cgYWJvdXQgZXhwZWxsaW5nIFBV
VCB0byBkZXZlbG9wZXJzLiAgSSB0aGluayBQT1NUIHdpdGggYSBjbGllbnRfaWQgdG8gYSAoc2Vw
YXJhdGUgZGlzY3Vzc2lvbikgdXBkYXRlX3VyaSB3b3JrcyB3aXRob3V0IHJlc3RyaWN0aW5nIGl0
IHRvIFBVVC4NCj4+Pj4+DQo+Pj4+PiBJIHRoaW5rIERFTEVURSBuZWVkcyB0byBiZSBiZXR0ZXIg
dW5kZXJzdG9vZC4gICBJIHRoaW5rIGEgc3RhdHVzIHRoYXQgY2FuIGJlIHNldCBmb3IgY2xpZW50
IGxpZmVjeWNsZSBpcyBiZXR0ZXIgdGhhbiBsZXR0aW5nIGEgY2xpZW50IGRlbGV0ZSBhIGVudHJ5
Lg0KPj4+Pj4gSW4gc29tZSBjYXNlcyB0aGVyZSB3aWxsIGJlIG1vcmUgdGhhbiBvbmUgaW5zdGFu
Y2Ugb2YgYSBjbGllbnQgYW5kIGxldHRpbmcgdGhlbSBrbm93IHRoZXkgaGF2ZSBiZWVuIHR1cm5l
ZCBvZmYgZm9yIGEgcmVhc29uIGlzIGJldHRlciB0aGFuIG1ha2luZyB0aGVyZSByZWdpc3RyYXRp
b24gZGlzYXBwZWFyLg0KPj4+Pj4gU28gZm9yIHRoZSBtb21lbnQgSSB3b3VsZCBsZXZlZSBvdXQg
REVMRVRFLg0KPj4+Pj4NCj4+Pj4+IEpvaG4gQi4NCj4+Pj4+DQo+Pj4+PiBPbiAyMDEzLTAyLTEx
LCBhdCA2OjE0IFBNLCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdHJlLm9yZz4gd3JvdGU6DQo+
Pj4+Pg0KPj4+Pj4+IERyYWZ0IC0wNSBvZiBPQXV0aCBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRp
b24gWzFdIGRlZmluZXMgc2V2ZXJhbCBvcGVyYXRpb25zIHRoYXQgdGhlIGNsaWVudCBjYW4gdGFr
ZSBvbiBpdHMgYmVoYWxmIGFzIHBhcnQgb2YgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzLiBUaGVz
ZSBib2lsIGRvd24gdG8gdGhlIGJhc2ljIENSVUQgb3BlcmF0aW9ucyB0aGF0IHlvdSBmaW5kIGlu
IG1hbnkgQVBJczogQ3JlYXRlLCBSZWFkLCBVcGRhdGUsIERlbGV0ZS4gRHJhZnQgLTAwIGRlZmlu
ZWQgb25seSB0aGUgIkNyZWF0ZSIgb3BlcmF0aW9uLCBkcmFmdCAtMDEgdGhyb3VnaCAtMDQgYWRk
ZWQgdGhlICJVcGRhdGUiIG9wZXJhdGlvbiwgc3dpdGNoZWQgdXNpbmcgdGhlICJvcGVyYXRpb249
IiBwYXJhbWV0ZXIuDQo+Pj4+Pj4NCj4+Pj4+PiBGb2xsb3dpbmcgc2V2ZXJhbCBzdWdnZXN0aW9u
cyB0byBkbyBzbyBvbiB0aGUgbGlzdCwgdGhlIC0wNSBkcmFmdCBkZWZpbmVzIHRoZXNlIG9wZXJh
dGlvbnMgaW4gdGVybXMgb2YgYSBSRVNUZnVsIEFQSSBmb3IgdGhlIGNsaWVudC4gTmFtZWx5Og0K
Pj4+Pj4+DQo+Pj4+Pj4gLSBIVFRQIFBPU1QgdG8gcmVnaXN0cmF0aW9uIGVuZHBvaW50ID0+IENy
ZWF0ZSAocmVnaXN0ZXIpIGEgbmV3IGNsaWVudA0KPj4+Pj4+IC0gSFRUUCBQVVQgdG8gdXBkYXRl
IGVuZHBvaW50ICh3aXRoIHJlZ2lzdHJhdGlvbl9hY2Nlc3NfdG9rZW4pID0+IFVwZGF0ZSB0aGUg
cmVnaXN0ZXJlZCBpbmZvcm1hdGlvbiBmb3IgdGhpcyBjbGllbnQNCj4+Pj4+PiAtIEhUVFAgR0VU
IHRvIHVwZGF0ZSBlbmRwb2ludCAod2l0aCByZWdpc3RyYXRpb25fYWNjZXNzX3Rva2VuKSA9PiBy
ZWFkIHRoZSByZWdpc3RlcmVkIGluZm9ybWF0aW9uIGZvciB0aGlzIGNsaWVudA0KPj4+Pj4+IC0g
SFRUUCBERUxFVEUgdG8gdXBkYXRlIGVuZHBvaW50ICh3aXRoIHJlZ2lzdHJhdGlvbl9hY2Nlc3Nf
dG9rZW4pID0+IERlbGV0ZSAodW5yZWdpc3Rlci9kZS1wcm92aXNpb24pIHRoaXMgY2xpZW50DQo+
Pj4+Pj4NCj4+Pj4+PiBUaGUgdHdvIG1haW4gaXNzdWVzIGF0IHN0YWtlIGhlcmUgYXJlOiB0aGUg
YWRkaXRpb24gb2YgdGhlIFJFQUQgYW5kIERFTEVURSBtZXRob2RzLCBhbmQgdGhlIHVzZSBvZiBI
VFRQIHZlcmJzIGZvbGxvd2luZyBhIFJFU1RmdWwgZGVzaWduIHBoaWxvc29waHkuDQo+Pj4+Pj4N
Cj4+Pj4+PiBQcm86DQo+Pj4+Pj4gLSBSRVNUZnVsIEFQSXMgKHdpdGggSFRUUCB2ZXJicyB0byBk
aWZmZXJlbnRpYXRlIGZ1bmN0aW9uYWxpdHkpIGFyZSB0aGUgbm9ybSB0b2RheQ0KPj4+Pj4+IC0g
RnVsbCBsaWZlY3ljbGUgbWFuYWdlbWVudCBpcyBjb21tb24gYW5kIGlzIGdvaW5nIHRvIGJlIGV4
cGVjdGVkIGJ5IG1hbnkgdXNlcnMgb2YgdGhpcyBwcm90b2NvbCBpbiB0aGUgd2lsZA0KPj4+Pj4+
DQo+Pj4+Pj4gQ29uczoNCj4+Pj4+PiAtIFVwZGF0ZSBzZW1hbnRpY3MgYXJlIHN0aWxsIHVuZGVy
IGRlYmF0ZSAoZnVsbCByZXBsYWNlPyBwYXRjaD8pDQo+Pj4+Pj4gLSBTb21ld2hhdCBpbmNyZWFz
ZWQgY29tcGxleGl0eSBvbiB0aGUgc2VydmVyIHRvIHN1cHBvcnQgYWxsIG9wZXJhdGlvbnMNCj4+
Pj4+PiAtIENsaWVudCBoYXMgdG8gdW5kZXJzdGFuZCBhbGwgSFRUUCB2ZXJicyBmb3IgZnVsbCBh
Y2Nlc3MgKHRob3VnaCBwbGFpbiByZWdpc3RyYXRpb24gaXMganVzdCBQT1NUKQ0KPj4+Pj4+DQo+
Pj4+Pj4NCj4+Pj4+PiBBbHRlcm5hdGl2ZXMgaW5jbHVkZSB1c2luZyBhbiBvcGVyYXRpb25hbCBz
d2l0Y2ggcGFyYW1ldGVyIChsaWtlIHRoZSBvbGQgZHJhZnRzKSwgZGVmaW5pbmcgc2VwYXJhdGUg
ZW5kcG9pbnRzIGZvciBldmVyeSBhY3Rpb24sIG9yIGRvaW5nIGFsbCBvcGVyYXRpb25zIG9uIGEg
c2luZ2xlIGVuZHBvaW50IHVzaW5nIHZlcmJzIHRvIHN3aXRjaC4NCj4+Pj4+Pg0KPj4+Pj4+IC0t
IEp1c3Rpbg0KPj4+Pj4+DQo+Pj4+Pj4gWzFdIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry
YWZ0LWlldGYtb2F1dGgtZHluLXJlZy0wNQ0KPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4gT0F1dGggbWFpbGluZyBsaXN0DQo+Pj4+
Pj4gT0F1dGhAaWV0Zi5vcmcNCj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29hdXRoDQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KPj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4+IE9BdXRoQGlldGYub3Jn
DQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPg0KDQoN
Cg0KLS0gDQpOYXQgU2FraW11cmEgKD1uYXQpDQpDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24N
Cmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KQF9uYXRfZW4NCg==

From Michael.Jones@microsoft.com  Wed Feb 13 19:46:10 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BADD21E80D5 for ; Wed, 13 Feb 2013 19:46:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.457
X-Spam-Level: 
X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.141,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZpxF5HK41cS for ; Wed, 13 Feb 2013 19:46:09 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.28]) by ietfa.amsl.com (Postfix) with ESMTP id 377B221E80CD for ; Wed, 13 Feb 2013 19:46:08 -0800 (PST)
Received: from BL2FFO11FD024.protection.gbl (10.173.161.201) by BL2FFO11HUB019.protection.gbl (10.173.160.111) with Microsoft SMTP Server (TLS) id 15.0.620.12; Thu, 14 Feb 2013 03:45:59 +0000
Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD024.mail.protection.outlook.com (10.173.161.103) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Thu, 14 Feb 2013 03:45:58 +0000
Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.232]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Thu, 14 Feb 2013 03:45:38 +0000
From: Mike Jones 
To: Nat Sakimura , Justin Richer 
Thread-Topic: [OAUTH-WG] Registration: RESTful client lifecycle management
Thread-Index: AQHOCJzxVGwYODuh3UmktcEEXHrfK5h1dc0AgABcxoCAAH10AIAAG1EAgAACn4CAAAnLAIAAFhgggAGQiACAAAOOgIAAku4AgAAFacU=
Date: Thu, 14 Feb 2013 03:45:38 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394367447CC3@TK5EX14MBXC285.redmond.corp.microsoft.com>
References: <51195F36.6040705@mitre.org> <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com> <80727F20-A830-4778-B11C-D45389310646@lodderstedt.net> <511A5742.30707@mitre.org>	 <511A705F.4070204@mitre.org>  <4E1F6AAD24975D4BA5B168042967394367443862@TK5EX14MBXC285.redmond.corp.microsoft.com> <-7739255357185893925@unknownmsgid> <511BDE17.7060503@mitre.org>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367447CC3TK5EX14MBXC285r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(24454001)(199002)(51704002)(189002)(479174001)(69234002)(55885001)(13464002)(377454001)(54356001)(59766001)(50986001)(80022001)(74502001)(53806001)(15202345001)(16236675001)(31966008)(65816001)(74662001)(55846006)(44976002)(5343655001)(47446002)(16406001)(77982001)(4396001)(49866001)(47976001)(5343635001)(54316002)(512904001)(56816002)(56776001)(79102001)(63696002)(76482001)(33656001)(20776003)(51856001)(46102001)(47736001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB019; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0757EEBDCA
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2013 03:46:10 -0000

--_000_4E1F6AAD24975D4BA5B168042967394367447CC3TK5EX14MBXC285r_
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable

I agree with you that in the standards process, changes should not be intro=
duced until there is consensus on them. However in this particular case, th=
e problem is that in -05, many changes were introduced without consensus, o=
r even prior review by the working group.  Thus, as previously discussed, u=
nless consensus becomes apparent for those changes, the default action shou=
ld be to revert those changes.

The introduction of the baroque _links syntax was one such change.

-- Mike
________________________________
From: Nat Sakimura
Sent: 2/13/2013 7:26 PM
To: Justin Richer
Cc: Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management

2013/2/14 Justin Richer :
> Duly noted, and while there seems to be solid support behind the
> semantics of returning a URL, I'm not convinced the syntax argument is
> over yet either. I have seen support and good arguments from both sides
> and there isn't a clear winner there (see the other thread). Speaking as
> an individual member, I could go with either approach and I'd like to
> see what the rest of the WG wants.

Thank you. I wanted to raise a voice that while the need for the
returning the URL
seemed to have come to a consensus, the syntax has not, unlike Mike wrote.

>
> Speaking now as an editor: It's been suggested off-list that we adopt
> the simplified (bespoke) mechanism of the "registration_access_url"
> syntax for the next draft and continue to move discussion forward for
> the inclusion of the more-general mechanism (beit HAL based or something
> similar like JSON-LD) here on the list. Would you and the other HAL
> supporters be amenable to this solution? I wouldn't be opposed to adding
> a kind of "note for discussion" section to the -06 draft to help
> facilitate moving forward in a concrete manner, with the assumption that
> the text would be either removed or incorporated in a later draft. I
> just have to put a stake down somewhere on the syntax, and I'm leaning
> towards the one that doesn't add a normative dependency on an unfinished
> (as of right now) work.

FYI, I have not suggested to reference HAL or other unfinished specificatio=
ns,
but incorporate the syntax. If there is to be a reference, then that is for=
 the
curtesy and will be an informational reference.

As to the actual editing is concerned, may I suggest the reverse: i.e.,
keep the current text (-05) and add a note for discussion.
It is customary in the standardization process that the change to the text
is not to be incorporated until the resolution from the comments are reache=
d.
If the text is changed, then it means that the resolution is reached,
which is not the case. Even "ne bis in idem" may kick in, which effectively
prohibit the change back.

Nat

>
> -- Justin
>
> On 02/13/2013 01:27 PM, Nat Sakimura wrote:
>> I am against the syntax of registration_access_url .
>>
>> =3Dnat via iPhone
>>
>> Feb 13, 2013 3:37=1B$B!"=1B(BMike Jones  =
=1B$B$N%a%C%;!<%8=1B(B:
>>
>>> Then I think we've reached an acceptable resolution on this one.  By ha=
ving the server return the registration_access_url upon create and having t=
he client be required to include the client_id upon update, servers are fre=
e to manage their registration endpoint(s) as they see fit and clients alwa=
ys do the same thing.
>>>
>>>                Thanks all,
>>>                -- Mike
>>>
>>> -----Original Message-----
>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf =
Of Nat Sakimura
>>> Sent: Tuesday, February 12, 2013 9:15 AM
>>> To: Justin Richer
>>> Cc: oauth@ietf.org
>>> Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle manageme=
nt
>>>
>>> 2013/2/13 Justin Richer :
>>>> On 02/12/2013 11:30 AM, John Bradley wrote:
>>>>> To some extent we want the server to have the flexibility it needs.
>>>>>
>>>>> If the server knows it is going to need client_id for GET it needs to
>>>>> encode it in the resource URI ether as part of the path or as a query
>>>>> parameter (that is up to the server)
>>>>>
>>>>> When doing updates the client MUST include the client_id as an
>>>>> additional integrity check.  Some servers may switch on that but that=
 is up to them.
>>>> So if by this you mean that the client still simply follows whatever
>>>> update url the server hands it (which may or may not include the
>>>> client_id in some form, but the client doesn't care), and that the
>>>> client MUST include its client_id in the request body (top-level
>>>> member of a JSON object, at the
>>>> moment) when doing a PUT (or POST/PATCH? see below) for the update
>>>> action, then I'm totally fine with that. Is this what you're suggestin=
g?
>>> As far as I understand, yes. That is what we discussed last Thursday fa=
ce to face.
>>>
>>>
>>> --
>>> Nat Sakimura (=3Dnat)
>>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/
>>> @_nat_en
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--_000_4E1F6AAD24975D4BA5B168042967394367447CC3TK5EX14MBXC285r_
Content-Type: text/html; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable

I agree with =
you that in the standards process, changes should not be introduced until t=
here is consensus on them. However in this particular case, the problem is =
that in -05, many changes were introduced
 without consensus, or even prior review by the working group.  Thus, =
as previously discussed, unless consensus becomes apparent for those change=
s, the default action should be to revert those changes.

The introduction of the baroque _links syntax was one such change.

-- Mike

From:
Nat Sa=
kimura

Sent:
2/13/2=
013 7:26 PM

To:
Justin=
 Richer

Cc:
Mike J=
ones; oauth@ietf.org

Subject:
Re: [O=
AUTH-WG] Registration: RESTful client lifecycle management

2013/2/14 Justin Richer <jricher@mitre.org>:=

> Duly noted, and while there seems to be solid support behind the

> semantics of returning a URL, I'm not convinced the syntax argument is=

> over yet either. I have seen support and good arguments from both side=
s

> and there isn't a clear winner there (see the other thread). Speaking =
as

> an individual member, I could go with either approach and I'd like to<=
br>
> see what the rest of the WG wants.

Thank you. I wanted to raise a voice that while the need for the

returning the URL

seemed to have come to a consensus, the syntax has not, unlike Mike wrote.<=
br>

>

> Speaking now as an editor: It's been suggested off-list that we adopt<=
br>
> the simplified (bespoke) mechanism of the "registration_access_ur=
l"

> syntax for the next draft and continue to move discussion forward for<=
br>
> the inclusion of the more-general mechanism (beit HAL based or somethi=
ng

> similar like JSON-LD) here on the list. Would you and the other HAL
> supporters be amenable to this solution? I wouldn't be opposed to addi=
ng

> a kind of "note for discussion" section to the -06 draft to =
help

> facilitate moving forward in a concrete manner, with the assumption th=
at

> the text would be either removed or incorporated in a later draft. I
> just have to put a stake down somewhere on the syntax, and I'm leaning=

> towards the one that doesn't add a normative dependency on an unfinish=
ed

> (as of right now) work.

FYI, I have not suggested to reference HAL or other unfinished specificatio=
ns,

but incorporate the syntax. If there is to be a reference, then that is for=
 the

curtesy and will be an informational reference.

As to the actual editing is concerned, may I suggest the reverse: i.e.,

keep the current text (-05) and add a note for discussion.

It is customary in the standardization process that the change to the text<=
br>
is not to be incorporated until the resolution from the comments are reache=
d.

If the text is changed, then it means that the resolution is reached,

which is not the case. Even "ne bis in idem" may kick in, which e=
ffectively

prohibit the change back.

Nat

>

> -- Justin

>

> On 02/13/2013 01:27 PM, Nat Sakimura wrote:

>> I am against the syntax of registration_access_url .

>>

>> =3Dnat via iPhone

>>

>> Feb 13, 2013 3:37=1B$B!"=1B(BMike Jones <Michael.Jones@microsof=
t.com> =1B$B$N%a%C%;!<%8=1B(B:

>>

>>> Then I think we've reached an acceptable resolution on this on=
e.  By having the server return the registration_access_url upon creat=
e and having the client be required to include the client_id upon update, s=
ervers are free to manage their registration endpoint(s)
 as they see fit and clients always do the same thing.

>>>

>>>          &nb=
sp;     Thanks all,

>>>          &nb=
sp;     -- Mike

>>>

>>> -----Original Message-----

>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura

>>> Sent: Tuesday, February 12, 2013 9:15 AM

>>> To: Justin Richer

>>> Cc: oauth@ietf.org

>>> Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle=
 management

>>>

>>> 2013/2/13 Justin Richer <jricher@mitre.org>:

>>>> On 02/12/2013 11:30 AM, John Bradley wrote:

>>>>> To some extent we want the server to have the flexibil=
ity it needs.

>>>>>

>>>>> If the server knows it is going to need client_id for =
GET it needs to

>>>>> encode it in the resource URI ether as part of the pat=
h or as a query

>>>>> parameter (that is up to the server)

>>>>>

>>>>> When doing updates the client MUST include the client_=
id as an

>>>>> additional integrity check.  Some servers may swi=
tch on that but that is up to them.

>>>> So if by this you mean that the client still simply follow=
s whatever

>>>> update url the server hands it (which may or may not inclu=
de the

>>>> client_id in some form, but the client doesn't care), and =
that the

>>>> client MUST include its client_id in the request body (top=
-level

>>>> member of a JSON object, at the

>>>> moment) when doing a PUT (or POST/PATCH? see below) for th=
e update

>>>> action, then I'm totally fine with that. Is this what you'=
re suggesting?

>>> As far as I understand, yes. That is what we discussed last Th=
ursday face to face.

>>>

>>>

>>> --

>>> Nat Sakimura (=3Dnat)

>>> Chairman, OpenID Foundation

>>> http://nat.sakimura.org/<=
/a>

>>> @_nat_en

>>> _______________________________________________

>>> OAuth mailing list

>>> OAuth@ietf.org

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

>

-- 

Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation

http://nat.sakimura.org/

@_nat_en

--_000_4E1F6AAD24975D4BA5B168042967394367447CC3TK5EX14MBXC285r_--

From wmills_92105@yahoo.com  Wed Feb 13 21:41:31 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F77E21E8040 for ; Wed, 13 Feb 2013 21:41:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.948
X-Spam-Level: 
X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdWPRAig7m5l for ; Wed, 13 Feb 2013 21:41:30 -0800 (PST)
Received: from nm13-vm0.bullet.mail.ne1.yahoo.com (nm13-vm0.bullet.mail.ne1.yahoo.com [98.138.91.48]) by ietfa.amsl.com (Postfix) with ESMTP id C8D2F21E8042 for ; Wed, 13 Feb 2013 21:41:29 -0800 (PST)
Received: from [98.138.90.53] by nm13.bullet.mail.ne1.yahoo.com with NNFMP; 14 Feb 2013 05:41:26 -0000
Received: from [98.138.89.199] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 14 Feb 2013 05:41:26 -0000
Received: from [127.0.0.1] by omp1057.mail.ne1.yahoo.com with NNFMP; 14 Feb 2013 05:41:26 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 96579.95611.bm@omp1057.mail.ne1.yahoo.com
Received: (qmail 70560 invoked by uid 60001); 14 Feb 2013 05:41:25 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360820485; bh=RZbmWvEOxYQzm9g6Oprqd7RvGOOc+2xJSLn2JH73jEY=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=UjPIPKaRKLGTNAEhtJXZNId667mdJlpYiXU+U9vr8+77ORKIzEsGZ4EP0h5cZilwLEm9CKejHbbtuKF7mGDoHtbs0A2Vmo0L9IHwoUXk1xeY10rOzB1vKKM1YHA630HN930UOqYoE76T1xfR5pzi7DlYvR+5aLOF0WJdF7Ib1EU=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=BRNxUSAp6Z64to4xCLFADxCXnMwMthjld7vsQ4epf2zjD4kVz5HUxRGuyxbSvLSgbcIFYBdD/Bt6XusCuUtX8GqWNSKizbDbHrWpwhwlipDL9TErxo1wZs1jOyR9ZW6zAplNDiP6LsWqpWD2VfNcWPVSolrKsasXmE/MeiqyeEg=;
X-YMail-OSG: sBcaOQEVM1lrvxpGHsHdLsfn91xOZvNO1gfYYESqK2_ZDhU t09soryyQxep6mb10Hrxv8o5etnPKALxXzt1Kq8jXklytxrTvvxdiP7Lyn0Z blBXrArjdfJP2l_Qs0Nt.u886XDBEaVsebc0x_.vlqUR6EvB8PY_h_y13QwC 8mUjcp4D1IGVoLl_ZwwN1CoC2cNFjPnlyOCx1vWXkq1OXjeub6eTCas3lBg8 tDx96UcHQc3KQNJ2wyGg_RZMG8EURn1XU4fL19WmPAXFyvHf3b.tRn84pe0W 2QZWErTvp656af5QLIEvhw88In9.2Bb3fviS8Om36qFO9CLLCqAH1eA0agiR bru_LUQuVLVzQBUSqDbs0Fhw3v63cBN1i9tp0YT_9f8AH6gUM79_afssBsS1 e1I5GhfjiESOk3UE4gvp8HZR4xfeFJOg.uN7tgEiLoy6L7Wr9.KET5VWxUaa isPRJdiWNk08MwIfL7hMaOtIt4OGL41MgYJtfMoDBZ4FjWxZH4k6ED3eP5jD Ob86Zii8BfED9LkGcPKGjVYQbcvhqWT74Lwro4DDe3KOAuz8tLB5M3PhM5AZ gtUlH4vHazVBDr1ROXsojvgVhTmMjZKdwnmd3WgKjRqM5PFWimTz_rDbS2DZ zf2I-
Received: from [99.31.212.42] by web31805.mail.mud.yahoo.com via HTTP; Wed, 13 Feb 2013 21:41:24 PST
X-Rocket-MIMEInfo: 001.001, WW91IGhhdmUgYSB0cnVzdCByZWxhdGlvbnNoaXAgd2l0aCB0aGUgdXNlciBhbmQgcGVyaGFwcyB3aXRoIHRoZSBjbGllbnQuCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KIEZyb206IFByYXRlZWsgTWlzaHJhIDxwcmF0ZWVrLm1pc2hyYUBvcmFjbGUuY29tPgpUbzogb2F1dGhAaWV0Zi5vcmcgClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMTMsIDIwMTMgODoxMyBBTQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBNaW51dGVzIGZyb20gdGhlIE9BdXRoIERlc2lnbiBUZWFtIENvbmZlcmVuY2UBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.134.513
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net> <511BBBAC.9060502@oracle.com>
Message-ID: <1360820484.70102.YahooMailNeo@web31805.mail.mud.yahoo.com>
Date: Wed, 13 Feb 2013 21:41:24 -0800 (PST)
From: William Mills 
To: Prateek Mishra , "oauth@ietf.org" 
In-Reply-To: <511BBBAC.9060502@oracle.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-551393103-99213868-1360820484=:70102"
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2013 05:41:31 -0000

---551393103-99213868-1360820484=:70102
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

You have a trust relationship with the user and perhaps with the client.=0A=
=0A=0A________________________________=0A From: Prateek Mishra =0ATo: oauth@ietf.org =0ASent: Wednesday, February 13, 2013 =
8:13 AM=0ASubject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Confer=
ence Call - 11th February 2013=0A =0AHannes,=0A=0A1) Its not clear to me th=
at we need=A0 to specify exchanges between the AS =0Aand the RS as part of =
this work. The core specification leaves this=0Aunspecified. There could be=
 many different ways that the AS and RS =0Acollaborate to validate signatur=
es in messages received from the client.=0A=0A2) Regarding (symmetric) key =
distribution, dont we need some kind of =0Aexisting trust relationship betw=
een the client and AS to make this =0Apossible? I guess it=0Awould be enoug=
h to require use of a "confidential" client, that would =0Amake it possible=
 for the two parties to agree on a session key at the =0Apoint where an acc=
ess token=0Ais=A0 issued by the AS.=0A=0A3) I think do need an MTI key dist=
ribution protocol as part of the =0Aspecification, leaving that as a choice=
 would hurt interoperability.=0A=0A- prateek=0A=0A> Here are my notes.=0A>=
=0A> Participants:=0A>=0A> * John Bradley=0A> * Derek Atkins=0A> * Phil Hun=
t=0A> * Prateek Mishra=0A> * Hannes Tschofenig=0A> * Mike Jones=0A> * Anton=
io Sanso=0A> * Justin Richer=0A>=0A> Notes:=0A>=0A> My slides are available=
 here: http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt=0A>=0A> =
Slide #2 summarizes earlier discussions during the conference calls.=0A>=0A=
> -- HTTP vs. JSON=0A>=0A> Phil noted that he does not like to use the MAC =
Token draft as a starting point because it does not re-use any of the work =
done in the JOSE working group and in particular all the libraries that are=
 available today. He mentioned that earlier attempts to write the MAC Token=
 code lead to problems for implementers.=0A>=0A> Justin responded that he d=
oes not agree with using JSON as a transport mechanism since this would rep=
licate a SOAP style.=0A>=0A> Phil noted that he wants to send JSON but the =
signature shall be computed over the HTTP header field.=0A>=0A> -- Flexibil=
ity for the keyed message digest computation=0A>=0A>=A0 From earlier discus=
sion it was clear that the conference call participants wanted more flexibi=
lity regarding the keyed message digest computation. For this purpose Hanne=
s presented the DKIM based approach, which allows selective header fields t=
o be included in the digest. This is shown in slide #4.=0A>=0A> After some =
discussion the conference call participants thought that this would meet th=
eir needs. Further investigations would still be useful to determine the de=
gree of failed HMAC calculations due to HTTP proxies modifying the content.=
=0A>=0A> -- Key Distribution=0A>=0A> Hannes presented the open issue regard=
ing the choice of key distribution. Slides #6-#8 present three techniques a=
nd Hannes asked for feedback regarding the preferred style. Justin and othe=
rs didn't see the need to decide on one mechanism - they wanted to keep the=
 choice open. Derek indicated that this will not be an acceptable approach.=
 Since the resource server and the authorization server may, in the OAuth 2=
.0 framework, be entities produced by different vendors there is an interop=
erability need. Justin responded that he disagrees and that the resource se=
rver needs to understand the access token and referred to the recent draft =
submission for the token introspection endpoint. Derek indicated that the r=
esource server has to understand the content of the access token and the to=
ken introspection endpoint just pushes the problem around: the resource ser=
ver has to send the access token to the authorization server and then the r=
esource server gets the
 result back (which he then=0A=A0 a=0A>=A0  gain needs to understand) in or=
der to make a meaningful authorization decision.=0A>=0A> Everyone agreed th=
at the client must receive the session key from the authorization server an=
d that this approach has to be standardized. It was also agreed that this i=
s a common approach among all three key distribution mechanisms.=0A>=0A> Ha=
nnes asked the participants to think about their preference.=0A>=0A> The qu=
estions regarding key naming and the indication for the intended resource s=
erver the client wants to talk to have been postponed.=0A>=A0 =0A> Ciao=0A>=
 Hannes=0A>=0A>=0A> _______________________________________________=0A> OAu=
th mailing list=0A> OAuth@ietf.org=0A> https://www.ietf.org/mailman/listinf=
o/oauth=0A=0A=0A_______________________________________________=0AOAuth mai=
ling list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth
---551393103-99213868-1360820484=:70102
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

You have a trust relationship with the user and perhaps with the client.<=
/span>

  From: Prateek Mishra <prateek.mishr=
a@oracle.com>
 To: o=
auth@ietf.org 
 Sent: W=
ednesday, February 13, 2013 8:13 AM
 Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Co=
nference Call - 11th February 2013

=0AHannes,
1) Its not clear to me that we need  to specify exchanges between the=
 AS 
and the RS as part of this work. The core specification leaves this=

unspecified. There could be many different ways that the AS and RS 
=
collaborate to validate signatures in messages received from the client.
2) Regarding (symmetric) key distribution, dont we need some kind of <=
br>existing trust relationship between the client and AS to make this 
p=
ossible? I guess it
would be enough to require use of a "confidential" c=
lient, that would 
make it possible for the two parties to agree on a se=
ssion key at the 
point where an access token
is  issued by the =
AS.

3) I think do need an MTI key distribution protocol as part of t=
he 
specification, leaving that as a choice would hurt interoperability.=

- prateek

> Here are my notes.
>
> Participan=
ts:
>
> * John Bradley
> * Derek
 Atkins
> * Phil Hunt
> * Prateek Mishra
> * Hannes Tscho=
fenig
> * Mike Jones
> * Antonio Sanso
> * Justin Richer<=
br>>
> Notes:
>
> My slides are available here: http:/=
/www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
>
> Slide=
 #2 summarizes earlier discussions during the conference calls.
>
=
> -- HTTP vs. JSON
>
> Phil noted that he does not like to u=
se the MAC Token draft as a starting point because it does not re-use any o=
f the work done in the JOSE working group and in particular all the librari=
es that are available today. He mentioned that earlier attempts to write th=
e MAC Token code lead to problems for implementers.
>
> Justin =
responded that he does not agree with using JSON as a transport mechanism s=
ince this would replicate a SOAP style.
>
> Phil noted that he =
wants to send JSON but the signature shall be computed over the HTTP
 header field.
>
> -- Flexibility for the keyed message digest =
computation
>
>  From earlier discussion it was clear that=
 the conference call participants wanted more flexibility regarding the key=
ed message digest computation. For this purpose Hannes presented the DKIM b=
ased approach, which allows selective header fields to be included in the d=
igest. This is shown in slide #4.
>
> After some discussion the=
 conference call participants thought that this would meet their needs. Fur=
ther investigations would still be useful to determine the degree of failed=
 HMAC calculations due to HTTP proxies modifying the content.
>
&g=
t; -- Key Distribution
>
> Hannes presented the open issue rega=
rding the choice of key distribution. Slides #6-#8 present three techniques=
 and Hannes asked for feedback regarding the preferred style. Justin and ot=
hers didn't see the need to decide on one mechanism - they wanted to
 keep the choice open. Derek indicated that this will not be an acceptable =
approach. Since the resource server and the authorization server may, in th=
e OAuth 2.0 framework, be entities produced by different vendors there is a=
n interoperability need. Justin responded that he disagrees and that the re=
source server needs to understand the access token and referred to the rece=
nt draft submission for the token introspection endpoint. Derek indicated t=
hat the resource server has to understand the content of the access token a=
nd the token introspection endpoint just pushes the problem around: the res=
ource server has to send the access token to the authorization server and t=
hen the resource server gets the result back (which he then
  a
=
>   gain needs to understand) in order to make a meaningful authori=
zation decision.
>
> Everyone agreed that the client must recei=
ve the session key from the authorization server and that this
 approach has to be standardized. It was also agreed that this is a common =
approach among all three key distribution mechanisms.
>
> Hanne=
s asked the participants to think about their preference.
>
> T=
he questions regarding key naming and the indication for the intended resou=
rce server the client wants to talk to have been postponed.
>   =

> Ciao
> Hannes
>
>
> ______________________=
_________________________
> OAuth mailing list
> OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth

___________=
____________________________________
OAuth mailing list
OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth

<=
br> 

---551393103-99213868-1360820484=:70102--

From hannes.tschofenig@gmx.net  Wed Feb 13 23:45:45 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8DF21F8871 for ; Wed, 13 Feb 2013 23:45:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.77
X-Spam-Level: 
X-Spam-Status: No, score=-100.77 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXYlWV0ivQID for ; Wed, 13 Feb 2013 23:45:44 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 03E3221F886D for ; Wed, 13 Feb 2013 23:45:43 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.27]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Lflzw-1UhjES3wGA-00pOXi for ; Thu, 14 Feb 2013 08:45:42 +0100
Received: (qmail invoked by alias); 14 Feb 2013 07:45:42 -0000
Received: from unknown (EHLO [10.255.133.10]) [194.251.119.201] by mail.gmx.net (mp027) with SMTP; 14 Feb 2013 08:45:42 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18M0/tkvTgMTy4Wx95kJkCVsCXYDx4mJX1Mj7SU5b NxY+qY1JCtUhT+
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Hannes Tschofenig 
In-Reply-To: <511BBBAC.9060502@oracle.com>
Date: Thu, 14 Feb 2013 09:45:38 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0DF3F088-7F15-4C0F-85C4-35DE80CB01E0@gmx.net>
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net> <511BBBAC.9060502@oracle.com>
To: Prateek Mishra 
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2013 07:45:45 -0000

Hi Prateek,=20

thanks for your questions.=20

On Feb 13, 2013, at 6:13 PM, Prateek Mishra wrote:

> Hannes,
>=20
> 1) Its not clear to me that we need  to specify exchanges between the =
AS and the RS as part of this work. The core specification leaves this
> unspecified. There could be many different ways that the AS and RS =
collaborate to validate signatures in messages received from the client.

It depends what the group wants to accomplish. So far, I thought that =
the goal was to offer the ability to provide a sufficient description in =
our specifications so that the authorization server and the resource =
server can be provided by different vendors and that they still =
interoperate.=20

The group may have changed their mind in the meanwhile.=20

What is your view?=20

>=20
> 2) Regarding (symmetric) key distribution, dont we need some kind of =
existing trust relationship between the client and AS to make this =
possible? I guess it
> would be enough to require use of a "confidential" client, that would =
make it possible for the two parties to agree on a session key at the =
point where an access token
> is  issued by the AS.

That's a very good question. I have not formed an option about this =
issue yet particularly given the recent capability to dynamically =
register clients.

>=20
> 3) I think do need an MTI key distribution protocol as part of the =
specification, leaving that as a choice would hurt interoperability.

That's my impression as well. =20

Ciao
Hannes

>=20
> - prateek
>=20
>> Here are my notes.
>>=20
>> Participants:
>>=20
>> * John Bradley
>> * Derek Atkins
>> * Phil Hunt
>> * Prateek Mishra
>> * Hannes Tschofenig
>> * Mike Jones
>> * Antonio Sanso
>> * Justin Richer
>>=20
>> Notes:
>>=20
>> My slides are available here: =
http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
>>=20
>> Slide #2 summarizes earlier discussions during the conference calls.
>>=20
>> -- HTTP vs. JSON
>>=20
>> Phil noted that he does not like to use the MAC Token draft as a =
starting point because it does not re-use any of the work done in the =
JOSE working group and in particular all the libraries that are =
available today. He mentioned that earlier attempts to write the MAC =
Token code lead to problems for implementers.
>>=20
>> Justin responded that he does not agree with using JSON as a =
transport mechanism since this would replicate a SOAP style.
>>=20
>> Phil noted that he wants to send JSON but the signature shall be =
computed over the HTTP header field.
>>=20
>> -- Flexibility for the keyed message digest computation
>>=20
>> =46rom earlier discussion it was clear that the conference call =
participants wanted more flexibility regarding the keyed message digest =
computation. For this purpose Hannes presented the DKIM based approach, =
which allows selective header fields to be included in the digest. This =
is shown in slide #4.
>>=20
>> After some discussion the conference call participants thought that =
this would meet their needs. Further investigations would still be =
useful to determine the degree of failed HMAC calculations due to HTTP =
proxies modifying the content.
>>=20
>> -- Key Distribution
>>=20
>> Hannes presented the open issue regarding the choice of key =
distribution. Slides #6-#8 present three techniques and Hannes asked for =
feedback regarding the preferred style. Justin and others didn't see the =
need to decide on one mechanism - they wanted to keep the choice open. =
Derek indicated that this will not be an acceptable approach. Since the =
resource server and the authorization server may, in the OAuth 2.0 =
framework, be entities produced by different vendors there is an =
interoperability need. Justin responded that he disagrees and that the =
resource server needs to understand the access token and referred to the =
recent draft submission for the token introspection endpoint. Derek =
indicated that the resource server has to understand the content of the =
access token and the token introspection endpoint just pushes the =
problem around: the resource server has to send the access token to the =
authorization server and then the resource server gets the result back =
(which he then a
>>  gain needs to understand) in order to make a meaningful =
authorization decision.
>>=20
>> Everyone agreed that the client must receive the session key from the =
authorization server and that this approach has to be standardized. It =
was also agreed that this is a common approach among all three key =
distribution mechanisms.
>>=20
>> Hannes asked the participants to think about their preference.
>>=20
>> The questions regarding key naming and the indication for the =
intended resource server the client wants to talk to have been =
postponed.
>>  Ciao
>> Hannes
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20

From sberyozkin@gmail.com  Thu Feb 14 02:32:16 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 072D321F8461 for ; Thu, 14 Feb 2013 02:32:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.362
X-Spam-Level: 
X-Spam-Status: No, score=-3.362 tagged_above=-999 required=5 tests=[AWL=0.237,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nNCaIV9hWOm for ; Thu, 14 Feb 2013 02:32:15 -0800 (PST)
Received: from mail-ea0-f176.google.com (mail-ea0-f176.google.com [209.85.215.176]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFD321F87AA for ; Thu, 14 Feb 2013 02:32:14 -0800 (PST)
Received: by mail-ea0-f176.google.com with SMTP id a13so887268eaa.21 for ; Thu, 14 Feb 2013 02:32:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=VAHctCwNpt7Z4I3vWNc97zhfqQfVBK8Zg1YrRwE64og=; b=mw0bR8UdsVkjsaEpb4VTCKGNuB/24VoYE10dCsjwXy/GWINW2qTajPW5Uk3TgSsP4c UruZV25FGhAkBLl1FGvPJ+Fqj0zjjeCu0NpjWF4XvHY1j8eQOa3u/Sj4IZggZWBvVt7A rPb94GOVEKUKeoFa2q2YL5u/zWJadCdouF0YgzIqgFa5sbDqwGSdDWJV+ypTbrFiVuT2 3TAEAfziB/YjWklcaVvA1s1c2IthsfyntNA8LiuZPo1wiufhr7b5+fwXL48flbGv+7/p 7nafDdELNOKu2BtKccMq1e5j2hMZJJ0IriTC8vy769wBUmuk+rZ/BFtwcO4Hmrx2yjXE gb7A==
X-Received: by 10.14.200.137 with SMTP id z9mr86312886een.20.1360837934168; Thu, 14 Feb 2013 02:32:14 -0800 (PST)
Received: from [192.168.2.5] ([89.100.138.67]) by mx.google.com with ESMTPS id o3sm77762703eem.15.2013.02.14.02.32.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Feb 2013 02:32:13 -0800 (PST)
Message-ID: <511CBD2B.3080000@gmail.com>
Date: Thu, 14 Feb 2013 10:32:11 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: oauth@ietf.org
References: <20130213221326.3987.20729.idtracker@ietfa.amsl.com> <511C1155.6050709@lodderstedt.net>
In-Reply-To: <511C1155.6050709@lodderstedt.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-05.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2013 10:32:16 -0000

Hi
On 13/02/13 22:19, Torsten Lodderstedt wrote:
> Hi all,
>
> I just published a new revision, which should cover all the issues
> raised/dicussed during WGLC.
>
> I applied the following changes:
> - introduced a new parameter "token_type_hint", which a client may use
> to give the authorization server a hint about the type of the token to
> be revoked
> - replaced "authorization" by "authorization grant"
> - an attempt to revoke an invalid token is now handled like a successful
> revocation request (status code 200)
Does it create some precedent, meaning that while people suggest using 
4xx statuses to indicate different sort of failures in this case 200 is 
returned, to eliminate a potential security attack. I mean, should it 
become the recommended practice ?

For example, in the discussion about DELETE, should it be 204 that is 
returned all the time ?

Sergey
> - CORS is now a MAY instead of SHOULD
> - extended description of how developer/client may obtain endpoint location
> - Improved wording regarding expected client behavior after sucessful
> processing of the revocation request -> "The client must assume the
> revocation is immediate upon the return of the request."
> - Explanation of different policies and why having different server
> policies should not cause interop problems
> - aligned structure with core spec by introducing sub-sections for
> request and response
>
> regards,
> Torsten.
>
> Am 13.02.2013 23:13, schrieb internet-drafts@ietf.org:
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Web Authorization Protocol Working
>> Group of the IETF.
>>
>> Title : Token Revocation
>> Author(s) : Torsten Lodderstedt
>> Stefanie Dronia
>> Marius Scurtescu
>> Filename : draft-ietf-oauth-revocation-05.txt
>> Pages : 9
>> Date : 2013-02-13
>>
>> Abstract:
>> This document proposes an additional endpoint for OAuth authorization
>> servers, which allows clients to notify the authorization server that
>> a previously obtained refresh or access token is no longer needed.
>> This allows the authorization server to cleanup security credentials.
>> A revocation request will invalidate the actual token and, if
>> applicable, other tokens based on the same authorization grant.
>>
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-oauth-revocation-05
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-revocation-05
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> 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

From prabath@wso2.com  Thu Feb 14 03:59:55 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE7421F84DC for ; Thu, 14 Feb 2013 03:59:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.585
X-Spam-Level: 
X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.391,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIcVO+BKxJD3 for ; Thu, 14 Feb 2013 03:59:52 -0800 (PST)
Received: from mail-ea0-f178.google.com (mail-ea0-f178.google.com [209.85.215.178]) by ietfa.amsl.com (Postfix) with ESMTP id E5C6721F84B9 for ; Thu, 14 Feb 2013 03:59:51 -0800 (PST)
Received: by mail-ea0-f178.google.com with SMTP id a14so985727eaa.37 for ; Thu, 14 Feb 2013 03:59:50 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=rnCJrVEi2WYEU1CdsSBb5u5tZ+lZ9ogji5VAvuel/N8=; b=G5aF/kHXvwTurVAdDlvIpdCNIdf3n5hfVqIeLJXtGUIgGfw0hqUdBycsIuF4w9uZmZ zifMymV2yeQ8ELodY2iqITvr2S+EqMsfhG0f173t3T97wx4DCO31Jw+06IAemWrYm4uH ZOirtfAZ0JdZToDo9oVtpDKY+7VaCDeYg4p3Sk5E9cFBWYDpx3RIK9lYI5eK/ik/JKBE 8MJc/lYpg6KMaL7eYCUUHHe7VuSALRgBrh1ywhUVzEv9pWjFfwy1EygxJuWIV9rf2OGb qkQCW6wtV8xIc4POPGjY0n/ivSIYlMSwEoW7CRenWRKBpGnUNB4Koa3hnqMubLj+sl1I e7Tg==
MIME-Version: 1.0
X-Received: by 10.14.215.193 with SMTP id e41mr18289520eep.32.1360843190598; Thu, 14 Feb 2013 03:59:50 -0800 (PST)
Received: by 10.223.37.77 with HTTP; Thu, 14 Feb 2013 03:59:50 -0800 (PST)
In-Reply-To: 
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com> <5112AE0B.1080501@mitre.org>  <5113C3AA.1040701@mitre.org>  <5113DDB2.7060805@mitre.org>  <51196777.6000502@mitre.org>   <511A5062.5010108@mitre.org> 
Date: Thu, 14 Feb 2013 17:29:50 +0530
Message-ID: 
From: Prabath Siriwardena 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=e89a8f647ac3f87ae304d5adfea3
X-Gm-Message-State: ALoCoQmJentJRXfqjY6vpIAzLPjCwmC+axAvbobX7o+sB+GtuM5EFasZJDKaT6ek9/tIHEnAnwR8
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2013 11:59:55 -0000

--e89a8f647ac3f87ae304d5adfea3
Content-Type: text/plain; charset=ISO-8859-1

I noticed that the latest Token Revocation draft [1] has introduced the
parameter "token_type_hint". I would suggest the same here, as that would
make what is meant by "valid" much clear..

[1]: http://tools.ietf.org/html/draft-ietf-oauth-revocation-05

Thanks & regards,
-Prabath

On Tue, Feb 12, 2013 at 9:35 PM, Prabath Siriwardena wrote:

> Hi Justin,
>
> I doubt whether valid_token would make a difference..?
>
> My initial argument is what is the validation criteria..? Validation
> criteria depends on the token_type..
>
> If we are talking only about metadata - then I believe "revoked",
> "expired" would be more meaningful..
>
> Thanks & regards,
> -Prabath
>
>
> On Tue, Feb 12, 2013 at 7:53 PM, Justin Richer  wrote:
>
>>  OK, I can see the wisdom in changing this term.
>>
>> I picked "valid" because I wanted a simple "boolean" value that would
>> require no additional parsing or string-matching on the client's behalf,
>> and I'd like to stick with that. OAuth is built with the assumption that
>> clients need to be able to recover from invalid tokens at any stage, so I
>> think a simple yes/no is the right step here.
>>
>> That said, I think you're both right that "valid" seems to have caused a
>> bit of confusion. I don't want to go with "revoked" because I'd rather have
>> the "token is OK" be the positive boolean value.
>>
>> Would "valid_token" be more clear? Or do we need a different adjective
>> all together?
>>
>>  -- Justin
>>
>>
>> On 02/11/2013 08:02 PM, Richard Harrington wrote:
>>
>> Have you considered "status" instead of "valid"?  It could have values
>> like "active", "expired", and "revoked".
>>
>>  Is it worthwhile including the status of the client also?  For example,
>> a client application could be disabled, temporarily or permanently, and
>> thus disabling its access tokens as well.
>>
>>
>> On Feb 11, 2013, at 1:56 PM, Prabath Siriwardena 
>> wrote:
>>
>>  I guess confusion is with 'valid' parameter is in the response..
>>
>>  I thought this will be helpful to standardize the communication between
>> Resource Server and the Authorization Server..
>>
>>  I would suggest we completely remove "valid" from the response - or
>> define it much clearly..
>>
>>  May be can add "revoked" with a boolean attribute..
>>
>>  Thanks & regards,
>> -Prabath
>>
>> On Tue, Feb 12, 2013 at 3:19 AM, Justin Richer  wrote:
>>
>>>
>>> On 02/08/2013 12:51 AM, Prabath Siriwardena wrote:
>>>
>>> Hi Justin,
>>>
>>>  I have couple of questions related to "valid" parameter...
>>>
>>>  This endpoint can be invoked by the Resource Server in runtime...
>>>
>>>
>>> That's correct.
>>>
>>>
>>>
>>>  In that case what is exactly meant by the "resource_id" in request ?
>>>
>>>
>>>  The resource_id field is a service-specific string that basically lets
>>> the resource server provide some context to the request to the auth server.
>>> There have been some other suggestions like client IP address, but I wanted
>>> to put this one in because it seemed to be a common theme. The client is
>>> trying to do *something* with the token, after all, and the rights,
>>> permissions, and metadata associated with the token could change based on
>>> that. Since the Introspection endpoint is all about getting that metadata
>>> back to the PR, this seemed like a good idea.
>>>
>>>
>>>
>>>  IMO a token to be valid depends on set of criteria based on it's type..
>>>
>>>  For a Bearer token..
>>>
>>>  1. Token should not be expired
>>> 2. Token should not be revoked.
>>> 3. The scope the token issued should match with the scope required for
>>> the resource.
>>>
>>>  For a MAC token...
>>>
>>>  1. Token not expired (mac id)
>>> 2. Token should not be revoked
>>> 3. The scope the token issued should match with the scope required for
>>> the resource.
>>> 4. HMAC check should be valid
>>>
>>>  There are similar conditions for SAML bearer too..
>>>
>>>
>>>  This isn't really true. The SAML bearer token is fully self-contained
>>> and doesn't change based on other parameters in the message, unlike MAC.
>>> Same with JWT. When it hands a SAML or JWT token to the AS, the PR has
>>> given *everything* the server needs to check that token's validity and use.
>>>
>>> MAC signatures change with every message, and they're done across
>>> several components of the HTTP message. Therefor, the HMAC check for MAC
>>> style tokens will still need to be done by the protected resource.
>>> Introspection would help in the case that the signature validated just
>>> fine, but the token might have expired. Or you need to know what scopes
>>> apply. Introspection isn't to fully validate the call to the protected
>>> resource -- if that were the case, the PR would have to send some kind of
>>> encapsulated version of the original request. Otherwise, the AS won't have
>>> all of the information it needs to check the MAC.
>>>
>>>
>>> I think what you're describing is ultimately *not* what the
>>> introspection endpoint is intended to do. If that's unclear from the
>>> document, can you please suggest text that would help clear the use case
>>> up? I wouldn't want it to be ambiguous.
>>>
>>>  -- Justin
>>>
>>>
>>>
>>>  Thanks & regards,
>>> -Prabath
>>>
>>>
>>> On Thu, Feb 7, 2013 at 10:30 PM, Justin Richer wrote:
>>>
>>>>  It validates the token, which would be either the token itself in the
>>>> case of Bearer or the token "id" part of something more complex like MAC.
>>>> It doesn't directly validate the usage of the token, that's still up to the
>>>> PR to do that.
>>>>
>>>> I nearly added a "token type" field in this draft, but held back
>>>> because there are several kinds of "token type" that people talk about in
>>>> OAuth. First, there's "Bearer" vs. "MAC" vs. "HOK", or what have you. Then
>>>> within Bearer you have "JWT" or "SAML" or "unstructured blob". Then you've
>>>> also got "access" vs. "refresh" and other flavors of token, like the
>>>> id_token in OpenID Connect.
>>>>
>>>> Thing is, the server running the introspection endpoint will probably
>>>> know *all* of these. But should it tell the client? If so, which of the
>>>> three, and what names should the fields be?
>>>>
>>>>  -- Justin
>>>>
>>>>
>>>> On 02/07/2013 11:26 AM, Prabath Siriwardena wrote:
>>>>
>>>> Okay.. I was thinking this could be used as a way to validate the token
>>>> as well. BTW even in this case shouldn't communicate the type of token to
>>>> AS? For example in the case of SAML profile - it could be SAML token..
>>>>
>>>>  Thanks & regards,
>>>> -Prabath
>>>>
>>>> On Thu, Feb 7, 2013 at 8:39 PM, Justin Richer wrote:
>>>>
>>>>>  "valid" might not be the best term, but it's meant to be a field
>>>>> where the server says "yes this token is still good" or "no this token
>>>>> isn't good anymore". We could instead do this with HTTP codes or something
>>>>> but I went with a pure JSON response.
>>>>>
>>>>>  -- Justin
>>>>>
>>>>>
>>>>> On 02/06/2013 10:47 PM, Prabath Siriwardena wrote:
>>>>>
>>>>> Hi Justin,
>>>>>
>>>>>  I believe this is addressing one of the key missing part in OAuth
>>>>> 2.0...
>>>>>
>>>>>  One question - I guess this was discussed already...
>>>>>
>>>>>  In the spec - in the introspection response it has the attribute
>>>>> "valid" - this is basically the validity of the token provided in the
>>>>> request.
>>>>>
>>>>>  Validation criteria depends on the token and well as token type (
>>>>> Bearer, MAC..).
>>>>>
>>>>>  In the spec it seems like it's coupled with Bearer token type... But
>>>>> I guess, by adding "token_type" to the request we can remove this
>>>>> dependency.
>>>>>
>>>>>  WDYT..?
>>>>>
>>>>>  Thanks & regards,
>>>>> -Prabath
>>>>>
>>>>> On Thu, Feb 7, 2013 at 12:54 AM, Justin Richer wrote:
>>>>>
>>>>>>  Updated introspection draft based on recent comments. Changes
>>>>>> include:
>>>>>>
>>>>>>  - "scope" return parameter now follows RFC6749 format instead of
>>>>>> JSON array
>>>>>>  - "subject" -> "sub", and "audience" -> "aud", to be parallel with
>>>>>> JWT claims
>>>>>>  - clarified what happens if the authentication is bad
>>>>>>
>>>>>>  -- Justin
>>>>>>
>>>>>>
>>>>>> -------- Original Message --------  Subject: New Version
>>>>>> Notification for draft-richer-oauth-introspection-02.txt  Date: Wed,
>>>>>> 6 Feb 2013 11:24:20 -0800  From:   To:
>>>>>>  
>>>>>>
>>>>>> A new version of I-D, draft-richer-oauth-introspection-02.txt
>>>>>> has been successfully submitted by Justin Richer and posted to the
>>>>>> IETF repository.
>>>>>>
>>>>>> Filename:	 draft-richer-oauth-introspection
>>>>>> Revision:	 02
>>>>>> Title:		 OAuth Token Introspection
>>>>>> Creation date:	 2013-02-06
>>>>>> WG ID:		 Individual Submission
>>>>>> Number of pages: 6
>>>>>> URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
>>>>>> Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
>>>>>> Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-02
>>>>>> Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02
>>>>>>
>>>>>> Abstract:
>>>>>>    This specification defines a method for a client or protected
>>>>>>    resource to query an OAuth authorization server to determine meta-
>>>>>>    information about an OAuth token.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> The IETF Secretariat
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>  --
>>>>> Thanks & Regards,
>>>>> Prabath
>>>>>
>>>>>  Mobile : +94 71 809 6732
>>>>>
>>>>> http://blog.facilelogin.com
>>>>> http://RampartFAQ.com
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>  --
>>>> Thanks & Regards,
>>>> Prabath
>>>>
>>>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>>>
>>>> http://blog.facilelogin.com
>>>> http://RampartFAQ.com
>>>>
>>>>
>>>>
>>>
>>>
>>>  --
>>> Thanks & Regards,
>>> Prabath
>>>
>>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>>
>>> http://blog.facilelogin.com
>>> http://RampartFAQ.com
>>>
>>>
>>>
>>
>>
>>  --
>> Thanks & Regards,
>> Prabath
>>
>>  Mobile : +94 71 809 6732
>>
>> http://blog.facilelogin.com
>> http://RampartFAQ.com
>>
>>  _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>
>
> --
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com
>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.com

--e89a8f647ac3f87ae304d5adfea3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I noticed that the latest Token Revocation draft [1] has introduced the par=
ameter "token_type_hint". I would suggest the same here, as that =
would make what is meant by "valid" much clear..

[1]:=A0=
http://tools.ietf.org/html/draft-ietf-oauth-revocation-05

Thanks & regards,
-Prabath

On Tue, Feb 12, 2013 at 9:35 PM, Prabath Siriwardena <p=
rabath@wso2.com> wrote:

Hi Justin,
I doubt whethe=
r valid_token would make a difference..?

My initia=
l argument is what is the validation criteria..? Validation criteria depend=
s on the token_type..

If we are talking only about metadata - then I believe "=
;revoked", "expired" would be more meaningful..
Thanks & regards,
-Prabath

On Tue, Feb 12, 2013 at 7:53 PM, Justin Richer <jricher@mitre.org><=
/span> wrote:

 =20
   =20
 =20

    OK, I can see the wisdom in changing this term. 

    I picked "valid" because I wanted a simple "boolean"=
; value that
    would require no additional parsing or string-matching on the
    client's behalf, and I'd like to stick with that. OAuth is buil=
t
    with the assumption that clients need to be able to recover from
    invalid tokens at any stage, so I think a simple yes/no is the right
    step here. 

    That said, I think you're both right that "valid" seems t=
o have
    caused a bit of confusion. I don't want to go with "revoked&qu=
ot; because
    I'd rather have the "token is OK" be the positive boolean=
 value. 

    Would "valid_token" be more clear? Or do we need a different
    adjective all together?

    =A0-- Justin

    On 02/11/2013 08:02 PM, Richard
      Harrington wrote:

     =20
      Have you considered "status" instead of "valid&qu=
ot;? =A0It could
        have values like "active", "expired", and "=
;revoked".

      Is it worthwhile including the status of the client also?
        =A0For example, a client application could be disabled,
        temporarily or permanently, and thus disabling its access tokens
        as well.

        On Feb 11, 2013, at 1:56 PM, Prabath Siriwardena <prabath@wso2.com>
        wrote:

        I guess confusion is with 'valid' parameter is in the
          response..

          I thought this will be helpful to=A0standardize=A0the
            communication between Resource Server and the Authorization
            Server..

          I would suggest we completely remove "valid" from =
the
            response - or define it much clearly..

          May be can add "revoked" with a boolean attribute.=
.

          Thanks & regards,
          -Prabath

            On Tue, Feb 12, 2013 at 3:19 AM,
              Justin Richer <jricher@mitre.org>
              wrote:

                    On 02/08/2013 12:51 AM, Prabath Siriwardena
                      wrote:

                   Hi=A0Justin,

                      I have couple of questions related to "vali=
d"
                        parameter...

                      This endpoint can be invoked by the Resource
                        Server in runtime...

                  That's correct.

                      In that case what is exactly meant by the
                        "resource_id" in request ?

                  The resource_id field is a service-specific string
                  that basically lets the resource server provide some
                  context to the request to the auth server. There have
                  been some other suggestions like client IP address,
                  but I wanted to put this one in because it seemed to
                  be a common theme. The client is trying to do
                  *something* with the token, after all, and the rights,
                  permissions, and metadata associated with the token
                  could change based on that. Since the Introspection
                  endpoint is all about getting that metadata back to
                  the PR, this seemed like a good idea.

                      IMO a token to be valid depends on set of
                        criteria based on it's type..

                      For a Bearer token..

                      1. Token should not be expired
                      2. Token should not be revoked.
                      3. The scope the token issued should match
                        with the scope required for the resource.

                      For a MAC token...

                      1. Token not expired (mac id)
                      2. Token should not be revoked
                      3. The scope the token issued should match
                        with the scope required for the resource.
                      4. HMAC check should be valid

                      There are similar conditions for SAML bearer too..

                  This isn't really true. The SAML bearer token is full=
y
                  self-contained and doesn't change based on other
                  parameters in the message, unlike MAC. Same with JWT.
                  When it hands a SAML or JWT token to the AS, the PR
                  has given *everything* the server needs to check that
                  token's validity and use. 

                  MAC signatures change with every message, and they're
                  done across several components of the HTTP message.
                  Therefor, the HMAC check for MAC style tokens will
                  still need to be done by the protected resource.
                  Introspection would help in the case that the
                  signature validated just fine, but the token might
                  have expired. Or you need to know what scopes apply.
                  Introspection isn't to fully validate the call to the
                  protected resource -- if that were the case, the PR
                  would have to send some kind of encapsulated version
                  of the original request. Otherwise, the AS won't have
                  all of the information it needs to check the MAC.

                  I think what you're describing is ultimately *not*
                  what the introspection endpoint is intended to do. If
                  that's unclear from the document, can you please
                  suggest text that would help clear the use case up? I
                  wouldn't want it to be ambiguous.

                      =A0-- Justin

                        Thanks & regards,
                        -Prabath

                          On Thu, Feb 7, 2013
                            at 10:30 PM, Justin Richer &l=
t;jricher@mitre.org<=
/a>>
                            wrote:

                               It
                                validates the token, which would be
                                either the token itself in the case of
                                Bearer or the token "id" part of
                                something more complex like MAC. It
                                doesn't directly validate the usage of
                                the token, that's still up to the PR to
                                do that.

                                I nearly added a "token type" fie=
ld in
                                this draft, but held back because there
                                are several kinds of "token type"=
 that
                                people talk about in OAuth. First,
                                there's "Bearer" vs. "MA=
C" vs. "HOK", or
                                what have you. Then within Bearer you
                                have "JWT" or "SAML" or=
 "unstructured
                                blob". Then you've also got "=
access" vs.
                                "refresh" and other flavors of to=
ken,
                                like the id_token in OpenID Connect. 

                                Thing is, the server running the
                                introspection endpoint will probably
                                know *all* of these. But should it tell
                                the client? If so, which of the three,
                                and what names should the fields be?<=
font color=3D"#888888">

                                    =A0-- Justin

                                    On 02/07/2013 11:26 AM, Prabath
                                      Siriwardena wrote:

                                     Okay.. I
                                      was thinking this could be used as
                                      a way to validate the token as
                                      well. BTW even in this case
                                      shouldn't communicate the type of
                                      token to AS? For example in the
                                      case of SAML profile - it could be
                                      SAML token..

                                      Thanks & regards,
                                      -Prabath

                                        On Thu,
                                          Feb 7, 2013 at 8:39 PM, Justin
                                          Richer <jricher@mitre.org>=
;
                                          wrote:

                                             "valid"
                                              might not be the best
                                              term, but it's meant to b=
e
                                              a field where the server
                                              says "yes this token is
                                              still good" or "no =
this
                                              token isn't good anymore&=
quot;.
                                              We could instead do this
                                              with HTTP codes or
                                              something but I went with
                                              a pure JSON response.

                                                  =A0-- Justin

                                                  On 02/06/2013
                                                    10:47 PM, Prabath
                                                    Siriwardena wrote:

                                                   Hi
                                                    Justin,

                                                    I believe this
                                                      is addressing one
                                                      of the key missing
                                                      part in OAuth
                                                      2.0...

                                                    One question -
                                                      I guess this was
                                                      discussed
                                                      already...

                                                    In the spec -
                                                      in the
                                                      introspection
                                                      response it has
                                                      the attribute
                                                      "valid" - t=
his is
                                                      basically the
                                                      validity of the
                                                      token provided in
                                                      the request.

                                                    Validation=A0crite=
ria
                                                      depends on the
                                                      token and well as
                                                      token type (
                                                      Bearer, MAC..).

                                                    In the spec it
                                                      seems like it's
                                                      coupled with
                                                      Bearer token
                                                      type... But I
                                                      guess, by adding
                                                      "token_type"=
; to
                                                      the request we can
                                                      remove this
                                                      dependency.

                                                    WDYT..?

                                                    Thanks &
                                                      regards,
                                                    -Prabath=A0

                                                      On
                                                        Thu, Feb 7, 2013
                                                        at 12:54 AM,
                                                        Justin Richer <jri=
cher@mitre.org>
                                                        wrote:

                                                          Updated
                                                          introspection
                                                          draft based on
                                                          recent
                                                          comments.
                                                          Changes
                                                          include:

                                                          =A0- "scope&=
quot;
                                                          return
                                                          parameter now
                                                          follows
                                                          RFC6749 format
                                                          instead of
                                                          JSON array

                                                          =A0- "subjec=
t"
                                                          -> "sub&q=
uot;,
                                                          and "audienc=
e"
                                                          -> "aud&q=
uot;,
                                                          to be parallel
                                                          with JWT
                                                          claims

                                                          =A0- clarified
                                                          what happens
                                                          if the
                                                          authentication
                                                          is bad

                                                          =A0-- Justin

                                                          --------
                                                          Original
                                                          Message
                                                          --------

                                                          Subject: 
                                                          New
                                                          Version
                                                          Notification
                                                          for
                                                          draft-richer-oaut=
h-introspection-02.txt

                                                          Date: 
                                                          Wed, 6 Feb
                                                          2013 11:24:20
                                                          -0800

                                                          From: 
                                                          <internet-drafts@ietf.o=
rg>

                                                          To: 
                                                          <jricher@mitre.org>

                                                          A new versio=
n of I-D, draft-richer-oauth-introspection-02.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 02
Title:		 OAuth Token Introspection
Creation date:	 2013-02-06
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/interne=
t-drafts/draft-richer-oauth-introspection-02.txt
Status:          http://datatracker.ietf.org/doc/draft-=
richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-=
oauth-introspection-02
Diff:            http://www.ietf.org/rfcdiff?url2=
=3Ddraft-richer-oauth-introspection-02

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.

                                                                           =
      =20

The IETF Secretariat

_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

                                                          https://www.ietf.o=
rg/mailman/listinfo/oauth

                                                      -- 

                                                      Thanks &
                                                      Regards,

                                                      Prabath

                                                      Mobile : +=
94 71 809 6732=A0

                                                        http://blog.facilelogin.com

                                                        http://RampartFAQ.com

                                        -- 

                                        Thanks & Regards,

                                        Prabath

                                        Mobile : +94 71 809
                                            6732=A0

                                          http://blog.facilelogin.com

                                          http://RampartFAQ.com

                          -- 

                          Thanks & Regards,

                          Prabath

                          Mobile : +94
                              71 809 6732=A0

                            http://blog.facilelogin.com

                            http://RampartFAQ.com

            -- 

            Thanks & Regards,

            Prabath

            Mobile : +94 71 809 6732=A0

              htt=
p://blog.facilelogin.com

              http://Ra=
mpartFAQ.com

        _______________________________________________
          OAuth mailing list

          OAuth@i=
etf.org

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

-- 
Thanks &=
 Regards,
Prabath
Mobile : +94 71 809 6732=
=A0

http://blog.f=
acilelogin.com

http://RampartFAQ.com

-- 
Thanks &=
 Regards,
Prabath
Mobile : +94 71 809 6732=A0

=
http://blog.facil=
elogin.com

http://RampartFAQ.com

--e89a8f647ac3f87ae304d5adfea3--

From jricher@mitre.org  Thu Feb 14 05:54:29 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7BD21F84E7 for ; Thu, 14 Feb 2013 05:54:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.567
X-Spam-Level: 
X-Spam-Status: No, score=-6.567 tagged_above=-999 required=5 tests=[AWL=0.031,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B91OZoauqYNd for ; Thu, 14 Feb 2013 05:54:26 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C3E5621F8461 for ; Thu, 14 Feb 2013 05:54:25 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A9CC51F2222; Thu, 14 Feb 2013 08:54:24 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 936DB1F21F6; Thu, 14 Feb 2013 08:54:24 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 14 Feb 2013 08:54:24 -0500
Message-ID: <511CEC63.6090801@mitre.org>
Date: Thu, 14 Feb 2013 08:53:39 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Tim Bray 
References: <51195F36.6040705@mitre.org> <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com> <511BAA8B.8030309@mitre.org>  <-4554688250617930935@unknownmsgid>  
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------010208090306030804040906"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2013 13:54:29 -0000

--------------010208090306030804040906
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

+1 to this. And I'd also be fine if it wasn't MTI (server returns a 405 
Method Not Allowed) for servers that don't want to do it at all.

  -- Justin

On 02/13/2013 04:26 PM, Tim Bray wrote:
> A DELETE is an http request that asks the server to delete something. 
>  We probably would want to avoid writing a requirement into the 
> standard that the server has to comply.  So you get back a 204 if it 
> worked, a 404 if there is no such registration, a 403 if there is but 
> the server declines to delete, etc. Seems pretty straightforward. -T
>
> On Wed, Feb 13, 2013 at 12:18 PM, John Bradley  > wrote:
>
>     DELETE is removing the record not resetting it to defaults.  They
>     are quite diffrent.
>
>     I want to agree on what the expected behaviour of DELETE is. I
>     think we have agreement on PUT and POST.
>
>     The general not in that a client can DELETE it's record is a
>     implication I don't like.  I think that is for the server to
>     decide and if it is not actually deleting it then DELETE is the
>     wrong verb to use.
>
>     John B.
>
>     On 2013-02-13, at 3:31 PM, Nat Sakimura      > wrote:
>
>     > Generally speaking, mapping PUT to replace and POST to change is an
>     > acceptable practice so I am fine with it.
>     >
>     > Now, what I still do not understand is why you think it is fine
>     to do
>     > PUT or POST and not DELETE. Doing PUT with empty content is
>     almost the
>     > same as DELETE. Could you explain?
>     >
>     > =nat via iPhone
>     >
>     > Feb 14, 2013 0:10?John Bradley      > ??????:
>     >
>     >> I am not violently opposed to PUT as a option that completely
>     replaces the resource setting all unsent claims back to the defaults.
>     >>
>     >> I don't have a good feeling about DELETE,  I think we still
>     need more discussion on what it means, what privileges it takes to
>     invoke it etc.
>     >> It could be a bad thing if we get wrong or is not implemented
>     consistently.
>     >>
>     >> Personally I don't think a client should ever be able to DELETE
>     it's record.
>     >>
>     >> I think marking a client_id as pending provisioning, suspended,
>      revoked etc is better and that can be done with a claim in the
>     update endpoint.
>     >>
>     >> It should only be the server that deletes a record after
>     satisfying it's audit requirements.
>     >>
>     >> John B.
>     >>
>     >> On 2013-02-13, at 12:00 PM, Justin Richer      > wrote:
>     >>
>     >>> Would it be reasonable to mark the PUT and DELETE methods as
>     optional for the server to implement, but with defined semantics
>     if they do? I want to keep GET and POST(create) as mandatory, as I
>     think that's the minimal set of functionality required.
>     >>>
>     >>> -- Justin
>     >>>
>     >>> On 02/11/2013 08:51 PM, John Bradley wrote:
>     >>>> I would always include the client_id on update.
>     >>>>
>     >>>> I think it is also us full to have other tokens used at the
>     update endpoint.  I can see the master token used to update all
>     the clients it has registered as part of API management.
>     >>>> Relying on the registration_access_token is probably a design
>     that will cause trouble down the road.
>     >>>>
>     >>>> I think GET and POST are relatively clear.   I don't know
>     about expelling PUT to developers.  I think POST with a client_id
>     to a (separate discussion) update_uri works without restricting it
>     to PUT.
>     >>>>
>     >>>> I think DELETE needs to be better understood.   I think a
>     status that can be set for client lifecycle is better than letting
>     a client delete a entry.
>     >>>> In some cases there will be more than one instance of a
>     client and letting them know they have been turned off for a
>     reason is better than making there registration disappear.
>     >>>> So for the moment I would levee out DELETE.
>     >>>>
>     >>>> John B.
>     >>>>
>     >>>> On 2013-02-11, at 6:14 PM, Justin Richer      > wrote:
>     >>>>
>     >>>>> Draft -05 of OAuth Dynamic Client Registration [1] defines
>     several operations that the client can take on its behalf as part
>     of the registration process. These boil down to the basic CRUD
>     operations that you find in many APIs: Create, Read, Update,
>     Delete. Draft -00 defined only the "Create" operation, draft -01
>     through -04 added the "Update" operation, switched using the
>     "operation=" parameter.
>     >>>>>
>     >>>>> Following several suggestions to do so on the list, the -05
>     draft defines these operations in terms of a RESTful API for the
>     client. Namely:
>     >>>>>
>     >>>>> - HTTP POST to registration endpoint => Create (register) a
>     new client
>     >>>>> - HTTP PUT to update endpoint (with
>     registration_access_token) => Update the registered information
>     for this client
>     >>>>> - HTTP GET to update endpoint (with
>     registration_access_token) => read the registered information for
>     this client
>     >>>>> - HTTP DELETE to update endpoint (with
>     registration_access_token) => Delete (unregister/de-provision)
>     this client
>     >>>>>
>     >>>>> The two main issues at stake here are: the addition of the
>     READ and DELETE methods, and the use of HTTP verbs following a
>     RESTful design philosophy.
>     >>>>>
>     >>>>> Pro:
>     >>>>> - RESTful APIs (with HTTP verbs to differentiate
>     functionality) are the norm today
>     >>>>> - Full lifecycle management is common and is going to be
>     expected by many users of this protocol in the wild
>     >>>>>
>     >>>>> Cons:
>     >>>>> - Update semantics are still under debate (full replace? patch?)
>     >>>>> - Somewhat increased complexity on the server to support all
>     operations
>     >>>>> - Client has to understand all HTTP verbs for full access
>     (though plain registration is just POST)
>     >>>>>
>     >>>>>
>     >>>>> Alternatives include using an operational switch parameter
>     (like the old drafts), defining separate endpoints for every
>     action, or doing all operations on a single endpoint using verbs
>     to switch.
>     >>>>>
>     >>>>> -- Justin
>     >>>>>
>     >>>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>     >>>>> _______________________________________________
>     >>>>> 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

--------------010208090306030804040906
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

    +1 to this. And I'd also be fine if it wasn't MTI (server returns a
    405 Method Not Allowed) for servers that don't want to do it at all.

     -- Justin

    On 02/13/2013 04:26 PM, Tim Bray wrote:

      A DELETE is an http request that asks the server to delete
      something.  We probably would want to avoid writing a requirement
      into the standard that the server has to comply.  So you get back
      a 204 if it worked, a 404 if there is no such registration, a 403
      if there is but the server declines to delete, etc. Seems pretty
      straightforward. -T

      On Wed, Feb 13, 2013 at 12:18 PM, John
        Bradley <ve7jtb@ve7jtb.com>
        wrote:

          DELETE is removing the record not resetting it to defaults.
           They are quite diffrent.

          I want to agree on what the expected behaviour of DELETE is.  
          I think we have agreement on PUT and POST.

          The general not in that a client can DELETE it's record is a
          implication I don't like.  I think that is for the server to
          decide and if it is not actually deleting it then DELETE is
          the wrong verb to use.

          John B.

              On 2013-02-13, at 3:31 PM, Nat Sakimura <sakimura@gmail.com> wrote:

              > Generally speaking, mapping PUT to replace and POST
              to change is an

              > acceptable practice so I am fine with it.

              >

              > Now, what I still do not understand is why you think
              it is fine to do

              > PUT or POST and not DELETE. Doing PUT with empty
              content is almost the

              > same as DELETE. Could you explain?

              >

              > =nat via iPhone

              >

              > Feb 14, 2013 0:10、John Bradley <ve7jtb@ve7jtb.com> のメッセージ:

              >

              >> I am not violently opposed to PUT as a option
              that completely replaces the resource setting all unsent
              claims back to the defaults.

              >>

              >> I don't have a good feeling about DELETE,  I
              think we still need more discussion on what it means, what
              privileges it takes to invoke it etc.

              >> It could be a bad thing if we get wrong or is not
              implemented consistently.

              >>

              >> Personally I don't think a client should ever be
              able to DELETE it's record.

              >>

              >> I think marking a client_id as pending
              provisioning, suspended,  revoked etc is better and that
              can be done with a claim in the update endpoint.

              >>

              >> It should only be the server that deletes a
              record after satisfying it's audit requirements.

              >>

              >> John B.

              >>

              >> On 2013-02-13, at 12:00 PM, Justin Richer <jricher@mitre.org> wrote:

              >>

              >>> Would it be reasonable to mark the PUT and
              DELETE methods as optional for the server to implement,
              but with defined semantics if they do? I want to keep GET
              and POST(create) as mandatory, as I think that's the
              minimal set of functionality required.

              >>>

              >>> -- Justin

              >>>

              >>> On 02/11/2013 08:51 PM, John Bradley wrote:

              >>>> I would always include the client_id on
              update.

              >>>>

              >>>> I think it is also us full to have other
              tokens used at the update endpoint.  I can see the master
              token used to update all the clients it has registered as
              part of API management.

              >>>> Relying on the registration_access_token
              is probably a design that will cause trouble down the
              road.

              >>>>

              >>>> I think GET and POST are relatively
              clear.   I don't know about expelling PUT to developers.
               I think POST with a client_id to a (separate discussion)
              update_uri works without restricting it to PUT.

              >>>>

              >>>> I think DELETE needs to be better
              understood.   I think a status that can be set for client
              lifecycle is better than letting a client delete a entry.

              >>>> In some cases there will be more than one
              instance of a client and letting them know they have been
              turned off for a reason is better than making there
              registration disappear.

              >>>> So for the moment I would levee out
              DELETE.

              >>>>

              >>>> John B.

              >>>>

              >>>> On 2013-02-11, at 6:14 PM, Justin Richer
              <jricher@mitre.org>
              wrote:

              >>>>

              >>>>> Draft -05 of OAuth Dynamic Client
              Registration [1] defines several operations that the
              client can take on its behalf as part of the registration
              process. These boil down to the basic CRUD operations that
              you find in many APIs: Create, Read, Update, Delete. Draft
              -00 defined only the "Create" operation, draft -01 through
              -04 added the "Update" operation, switched using the
              "operation=" parameter.

              >>>>>

              >>>>> Following several suggestions to do
              so on the list, the -05 draft defines these operations in
              terms of a RESTful API for the client. Namely:

              >>>>>

              >>>>> - HTTP POST to registration endpoint
              => Create (register) a new client

              >>>>> - HTTP PUT to update endpoint (with
              registration_access_token) => Update the registered
              information for this client

              >>>>> - HTTP GET to update endpoint (with
              registration_access_token) => read the registered
              information for this client

              >>>>> - HTTP DELETE to update endpoint
              (with registration_access_token) => Delete
              (unregister/de-provision) this client

              >>>>>

              >>>>> The two main issues at stake here
              are: the addition of the READ and DELETE methods, and the
              use of HTTP verbs following a RESTful design philosophy.

              >>>>>

              >>>>> Pro:

              >>>>> - RESTful APIs (with HTTP verbs to
              differentiate functionality) are the norm today

              >>>>> - Full lifecycle management is common
              and is going to be expected by many users of this protocol
              in the wild

              >>>>>

              >>>>> Cons:

              >>>>> - Update semantics are still under
              debate (full replace? patch?)

              >>>>> - Somewhat increased complexity on
              the server to support all operations

              >>>>> - Client has to understand all HTTP
              verbs for full access (though plain registration is just
              POST)

              >>>>>

              >>>>>

              >>>>> Alternatives include using an
              operational switch parameter (like the old drafts),
              defining separate endpoints for every action, or doing all
              operations on a single endpoint using verbs to switch.

              >>>>>

              >>>>> -- Justin

              >>>>>

              >>>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05

              >>>>>
              _______________________________________________

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

--------------010208090306030804040906--

From jricher@mitre.org  Thu Feb 14 06:01:18 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EC021F87C4 for ; Thu, 14 Feb 2013 06:01:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.568
X-Spam-Level: 
X-Spam-Status: No, score=-6.568 tagged_above=-999 required=5 tests=[AWL=0.031,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBXXVYN2hk3Y for ; Thu, 14 Feb 2013 06:01:17 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFF721F87AA for ; Thu, 14 Feb 2013 06:01:13 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D24515310908; Thu, 14 Feb 2013 09:01:12 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 9947B1F2200; Thu, 14 Feb 2013 09:01:12 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 14 Feb 2013 09:01:12 -0500
Message-ID: <511CEDFB.6010908@mitre.org>
Date: Thu, 14 Feb 2013 09:00:27 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Hannes Tschofenig 
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net> <511BBBAC.9060502@oracle.com> <0DF3F088-7F15-4C0F-85C4-35DE80CB01E0@gmx.net>
In-Reply-To: <0DF3F088-7F15-4C0F-85C4-35DE80CB01E0@gmx.net>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [129.83.31.58]
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2013 14:01:18 -0000

On 02/14/2013 02:45 AM, Hannes Tschofenig wrote:
> Hi Prateek,
>
>
> thanks for your questions.
>
>
> On Feb 13, 2013, at 6:13 PM, Prateek Mishra wrote:
>
>> Hannes,
>>
>> 1) Its not clear to me that we need  to specify exchanges between the =
AS and the RS as part of this work. The core specification leaves this
>> unspecified. There could be many different ways that the AS and RS col=
laborate to validate signatures in messages received from the client.
> It depends what the group wants to accomplish. So far, I thought that t=
he goal was to offer the ability to provide a sufficient description in o=
ur specifications so that the authorization server and the resource serve=
r can be provided by different vendors and that they still interoperate.
>
> The group may have changed their mind in the meanwhile.
>
> What is your view?

My view on this, as expressed in the call, is that the interoperability=20
be between the Client and AS and between the Client and RS.=20
Interoperability between AS and RS from different vendors is a different =

question all together, and I don't think it really ought to be in scope=20
for this. I think that with this signed token component we should build=20
something that doesn't *preclude* this kind of AS/RS interop, but that=20
the solution to that is a more general question. This is the motivation=20
behind things like the token introspection draft.

>> 2) Regarding (symmetric) key distribution, dont we need some kind of e=
xisting trust relationship between the client and AS to make this possibl=
e? I guess it
>> would be enough to require use of a "confidential" client, that would =
make it possible for the two parties to agree on a session key at the poi=
nt where an access token
>> is  issued by the AS.
> That's a very good question. I have not formed an option about this iss=
ue yet particularly given the recent capability to dynamically register c=
lients.

I don't think that signing tokens should require confidential clients.=20
This was one of the implementation issues with OAuth 1, as it required a =

"consumer_secret" at all times. This led to Google telling people to use =

"anonymous" as the "consumer_secret" for what were effectively public=20
clients. Even with dynamic registration, there's still a place for=20
public clients, in my opinion.

>> 3) I think do need an MTI key distribution protocol as part of the spe=
cification, leaving that as a choice would hurt interoperability.
> That's my impression as well.

I agree that we need to pick one style that assumes which party needs=20
access to which keys and what time. I disagree that we need to define=20
exactly how all of those keys get there.

  -- Justin

> Ciao
> Hannes
>
>> - prateek
>>
>>> Here are my notes.
>>>
>>> Participants:
>>>
>>> * John Bradley
>>> * Derek Atkins
>>> * Phil Hunt
>>> * Prateek Mishra
>>> * Hannes Tschofenig
>>> * Mike Jones
>>> * Antonio Sanso
>>> * Justin Richer
>>>
>>> Notes:
>>>
>>> My slides are available here: http://www.tschofenig.priv.at/OAuth2-Se=
curity-11Feb2013.ppt
>>>
>>> Slide #2 summarizes earlier discussions during the conference calls.
>>>
>>> -- HTTP vs. JSON
>>>
>>> Phil noted that he does not like to use the MAC Token draft as a star=
ting point because it does not re-use any of the work done in the JOSE wo=
rking group and in particular all the libraries that are available today.=
 He mentioned that earlier attempts to write the MAC Token code lead to p=
roblems for implementers.
>>>
>>> Justin responded that he does not agree with using JSON as a transpor=
t mechanism since this would replicate a SOAP style.
>>>
>>> Phil noted that he wants to send JSON but the signature shall be comp=
uted over the HTTP header field.
>>>
>>> -- Flexibility for the keyed message digest computation
>>>
>>>  From earlier discussion it was clear that the conference call partic=
ipants wanted more flexibility regarding the keyed message digest computa=
tion. For this purpose Hannes presented the DKIM based approach, which al=
lows selective header fields to be included in the digest. This is shown =
in slide #4.
>>>
>>> After some discussion the conference call participants thought that t=
his would meet their needs. Further investigations would still be useful =
to determine the degree of failed HMAC calculations due to HTTP proxies m=
odifying the content.
>>>
>>> -- Key Distribution
>>>
>>> Hannes presented the open issue regarding the choice of key distribut=
ion. Slides #6-#8 present three techniques and Hannes asked for feedback =
regarding the preferred style. Justin and others didn't see the need to d=
ecide on one mechanism - they wanted to keep the choice open. Derek indic=
ated that this will not be an acceptable approach. Since the resource ser=
ver and the authorization server may, in the OAuth 2.0 framework, be enti=
ties produced by different vendors there is an interoperability need. Jus=
tin responded that he disagrees and that the resource server needs to und=
erstand the access token and referred to the recent draft submission for =
the token introspection endpoint. Derek indicated that the resource serve=
r has to understand the content of the access token and the token introsp=
ection endpoint just pushes the problem around: the resource server has t=
o send the access token to the authorization server and then the resource=
 server gets the result back (which he the
>   n a
>>>   gain needs to understand) in order to make a meaningful authorizati=
on decision.
>>>
>>> Everyone agreed that the client must receive the session key from the=
 authorization server and that this approach has to be standardized. It w=
as also agreed that this is a common approach among all three key distrib=
ution mechanisms.
>>>
>>> Hannes asked the participants to think about their preference.
>>>
>>> The questions regarding key naming and the indication for the intende=
d resource server the client wants to talk to have been postponed.
>>>   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

From jricher@mitre.org  Thu Feb 14 06:04:11 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7475E21F87C4 for ; Thu, 14 Feb 2013 06:04:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.568
X-Spam-Level: 
X-Spam-Status: No, score=-6.568 tagged_above=-999 required=5 tests=[AWL=0.030,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaukNOdCp1OL for ; Thu, 14 Feb 2013 06:04:09 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB6D21F87DF for ; Thu, 14 Feb 2013 06:04:09 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9BBCD1F2C9F; Thu, 14 Feb 2013 09:04:08 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 706481F21F6; Thu, 14 Feb 2013 09:04:08 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 14 Feb 2013 09:04:08 -0500
Message-ID: <511CEEAA.3030801@mitre.org>
Date: Thu, 14 Feb 2013 09:03:22 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Prabath Siriwardena 
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com> <5112AE0B.1080501@mitre.org>  <5113C3AA.1040701@mitre.org>  <5113DDB2.7060805@mitre.org>  <51196777.6000502@mitre.org>   <511A5062.5010108@mitre.org>  
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020305030005000806030609"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2013 14:04:11 -0000

--------------020305030005000806030609
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

What exactly are you suggesting be added to introspection? The 
"token_type_hint" is from the client to the server, but what you've 
asked for in terms of "token type" is from the server to the client. And 
there was never an answer to what exactly is meant by "token type" in 
this case, particularly because you seem to want to call out things like 
SAML and Bearer as separate types.

  -- Justin

On 02/14/2013 06:59 AM, Prabath Siriwardena wrote:
> I noticed that the latest Token Revocation draft [1] has introduced 
> the parameter "token_type_hint". I would suggest the same here, as 
> that would make what is meant by "valid" much clear..
>
> [1]: http://tools.ietf.org/html/draft-ietf-oauth-revocation-05
>
> Thanks & regards,
> -Prabath
>
> On Tue, Feb 12, 2013 at 9:35 PM, Prabath Siriwardena  > wrote:
>
>     Hi Justin,
>
>     I doubt whether valid_token would make a difference..?
>
>     My initial argument is what is the validation criteria..?
>     Validation criteria depends on the token_type..
>
>     If we are talking only about metadata - then I believe "revoked",
>     "expired" would be more meaningful..
>
>     Thanks & regards,
>     -Prabath
>
>
>     On Tue, Feb 12, 2013 at 7:53 PM, Justin Richer      > wrote:
>
>         OK, I can see the wisdom in changing this term.
>
>         I picked "valid" because I wanted a simple "boolean" value
>         that would require no additional parsing or string-matching on
>         the client's behalf, and I'd like to stick with that. OAuth is
>         built with the assumption that clients need to be able to
>         recover from invalid tokens at any stage, so I think a simple
>         yes/no is the right step here.
>
>         That said, I think you're both right that "valid" seems to
>         have caused a bit of confusion. I don't want to go with
>         "revoked" because I'd rather have the "token is OK" be the
>         positive boolean value.
>
>         Would "valid_token" be more clear? Or do we need a different
>         adjective all together?
>
>          -- Justin
>
>
>         On 02/11/2013 08:02 PM, Richard Harrington wrote:
>>         Have you considered "status" instead of "valid"?  It could
>>         have values like "active", "expired", and "revoked".
>>
>>         Is it worthwhile including the status of the client also?
>>          For example, a client application could be disabled,
>>         temporarily or permanently, and thus disabling its access
>>         tokens as well.
>>
>>
>>         On Feb 11, 2013, at 1:56 PM, Prabath Siriwardena
>>         > wrote:
>>
>>>         I guess confusion is with 'valid' parameter is in the
>>>         response..
>>>
>>>         I thought this will be helpful to standardize the
>>>         communication between Resource Server and the Authorization
>>>         Server..
>>>
>>>         I would suggest we completely remove "valid" from the
>>>         response - or define it much clearly..
>>>
>>>         May be can add "revoked" with a boolean attribute..
>>>
>>>         Thanks & regards,
>>>         -Prabath
>>>
>>>         On Tue, Feb 12, 2013 at 3:19 AM, Justin Richer
>>>         > wrote:
>>>
>>>
>>>             On 02/08/2013 12:51 AM, Prabath Siriwardena wrote:
>>>>             Hi Justin,
>>>>
>>>>             I have couple of questions related to "valid" parameter...
>>>>
>>>>             This endpoint can be invoked by the Resource Server in
>>>>             runtime...
>>>
>>>             That's correct.
>>>
>>>
>>>>
>>>>             In that case what is exactly meant by the "resource_id"
>>>>             in request ?
>>>
>>>             The resource_id field is a service-specific string that
>>>             basically lets the resource server provide some context
>>>             to the request to the auth server. There have been some
>>>             other suggestions like client IP address, but I wanted
>>>             to put this one in because it seemed to be a common
>>>             theme. The client is trying to do *something* with the
>>>             token, after all, and the rights, permissions, and
>>>             metadata associated with the token could change based on
>>>             that. Since the Introspection endpoint is all about
>>>             getting that metadata back to the PR, this seemed like a
>>>             good idea.
>>>
>>>
>>>>
>>>>             IMO a token to be valid depends on set of criteria
>>>>             based on it's type..
>>>>
>>>>             For a Bearer token..
>>>>
>>>>             1. Token should not be expired
>>>>             2. Token should not be revoked.
>>>>             3. The scope the token issued should match with the
>>>>             scope required for the resource.
>>>>
>>>>             For a MAC token...
>>>>
>>>>             1. Token not expired (mac id)
>>>>             2. Token should not be revoked
>>>>             3. The scope the token issued should match with the
>>>>             scope required for the resource.
>>>>             4. HMAC check should be valid
>>>>
>>>>             There are similar conditions for SAML bearer too..
>>>
>>>             This isn't really true. The SAML bearer token is fully
>>>             self-contained and doesn't change based on other
>>>             parameters in the message, unlike MAC. Same with JWT.
>>>             When it hands a SAML or JWT token to the AS, the PR has
>>>             given *everything* the server needs to check that
>>>             token's validity and use.
>>>
>>>             MAC signatures change with every message, and they're
>>>             done across several components of the HTTP message.
>>>             Therefor, the HMAC check for MAC style tokens will still
>>>             need to be done by the protected resource. Introspection
>>>             would help in the case that the signature validated just
>>>             fine, but the token might have expired. Or you need to
>>>             know what scopes apply. Introspection isn't to fully
>>>             validate the call to the protected resource -- if that
>>>             were the case, the PR would have to send some kind of
>>>             encapsulated version of the original request. Otherwise,
>>>             the AS won't have all of the information it needs to
>>>             check the MAC.
>>>
>>>
>>>             I think what you're describing is ultimately *not* what
>>>             the introspection endpoint is intended to do. If that's
>>>             unclear from the document, can you please suggest text
>>>             that would help clear the use case up? I wouldn't want
>>>             it to be ambiguous.
>>>
>>>              -- Justin
>>>
>>>
>>>>
>>>>             Thanks & regards,
>>>>             -Prabath
>>>>
>>>>
>>>>             On Thu, Feb 7, 2013 at 10:30 PM, Justin Richer
>>>>             > wrote:
>>>>
>>>>                 It validates the token, which would be either the
>>>>                 token itself in the case of Bearer or the token
>>>>                 "id" part of something more complex like MAC. It
>>>>                 doesn't directly validate the usage of the token,
>>>>                 that's still up to the PR to do that.
>>>>
>>>>                 I nearly added a "token type" field in this draft,
>>>>                 but held back because there are several kinds of
>>>>                 "token type" that people talk about in OAuth.
>>>>                 First, there's "Bearer" vs. "MAC" vs. "HOK", or
>>>>                 what have you. Then within Bearer you have "JWT" or
>>>>                 "SAML" or "unstructured blob". Then you've also got
>>>>                 "access" vs. "refresh" and other flavors of token,
>>>>                 like the id_token in OpenID Connect.
>>>>
>>>>                 Thing is, the server running the introspection
>>>>                 endpoint will probably know *all* of these. But
>>>>                 should it tell the client? If so, which of the
>>>>                 three, and what names should the fields be?
>>>>
>>>>                  -- Justin
>>>>
>>>>
>>>>                 On 02/07/2013 11:26 AM, Prabath Siriwardena wrote:
>>>>>                 Okay.. I was thinking this could be used as a way
>>>>>                 to validate the token as well. BTW even in this
>>>>>                 case shouldn't communicate the type of token to
>>>>>                 AS? For example in the case of SAML profile - it
>>>>>                 could be SAML token..
>>>>>
>>>>>                 Thanks & regards,
>>>>>                 -Prabath
>>>>>
>>>>>                 On Thu, Feb 7, 2013 at 8:39 PM, Justin Richer
>>>>>                 > wrote:
>>>>>
>>>>>                     "valid" might not be the best term, but it's
>>>>>                     meant to be a field where the server says "yes
>>>>>                     this token is still good" or "no this token
>>>>>                     isn't good anymore". We could instead do this
>>>>>                     with HTTP codes or something but I went with a
>>>>>                     pure JSON response.
>>>>>
>>>>>                      -- Justin
>>>>>
>>>>>
>>>>>                     On 02/06/2013 10:47 PM, Prabath Siriwardena wrote:
>>>>>>                     Hi Justin,
>>>>>>
>>>>>>                     I believe this is addressing one of the key
>>>>>>                     missing part in OAuth 2.0...
>>>>>>
>>>>>>                     One question - I guess this was discussed
>>>>>>                     already...
>>>>>>
>>>>>>                     In the spec - in the introspection response
>>>>>>                     it has the attribute "valid" - this is
>>>>>>                     basically the validity of the token provided
>>>>>>                     in the request.
>>>>>>
>>>>>>                     Validation criteria depends on the token and
>>>>>>                     well as token type ( Bearer, MAC..).
>>>>>>
>>>>>>                     In the spec it seems like it's coupled with
>>>>>>                     Bearer token type... But I guess, by adding
>>>>>>                     "token_type" to the request we can remove
>>>>>>                     this dependency.
>>>>>>
>>>>>>                     WDYT..?
>>>>>>
>>>>>>                     Thanks & regards,
>>>>>>                     -Prabath
>>>>>>
>>>>>>                     On Thu, Feb 7, 2013 at 12:54 AM, Justin
>>>>>>                     Richer >>>>>                     > wrote:
>>>>>>
>>>>>>                         Updated introspection draft based on
>>>>>>                         recent comments. Changes include:
>>>>>>
>>>>>>                          - "scope" return parameter now follows
>>>>>>                         RFC6749 format instead of JSON array
>>>>>>                          - "subject" -> "sub", and "audience" ->
>>>>>>                         "aud", to be parallel with JWT claims
>>>>>>                          - clarified what happens if the
>>>>>>                         authentication is bad
>>>>>>
>>>>>>                          -- Justin
>>>>>>
>>>>>>
>>>>>>                         -------- Original Message --------
>>>>>>                         Subject: 	New Version Notification for
>>>>>>                         draft-richer-oauth-introspection-02.txt
>>>>>>                         Date: 	Wed, 6 Feb 2013 11:24:20 -0800
>>>>>>                         From: 	
>>>>>>                         
>>>>>>                         To: 	
>>>>>>                         
>>>>>>
>>>>>>
>>>>>>
>>>>>>                         A new version of I-D, draft-richer-oauth-introspection-02.txt
>>>>>>                         has been successfully submitted by Justin Richer and posted to the
>>>>>>                         IETF repository.
>>>>>>
>>>>>>                         Filename:	 draft-richer-oauth-introspection
>>>>>>                         Revision:	 02
>>>>>>                         Title:		 OAuth Token Introspection
>>>>>>                         Creation date:	 2013-02-06
>>>>>>                         WG ID:		 Individual Submission
>>>>>>                         Number of pages: 6
>>>>>>                         URL:http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
>>>>>>                         Status:http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
>>>>>>                         Htmlized:http://tools.ietf.org/html/draft-richer-oauth-introspection-02
>>>>>>                         Diff:http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02
>>>>>>
>>>>>>                         Abstract:
>>>>>>                             This specification defines a method for a client or protected
>>>>>>                             resource to query an OAuth authorization server to determine meta-
>>>>>>                             information about an OAuth token.
>>>>>>
>>>>>>
>>>>>>                                                                                                            
>>>>>>
>>>>>>
>>>>>>                         The IETF Secretariat
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>                         _______________________________________________
>>>>>>                         OAuth mailing list
>>>>>>                         OAuth@ietf.org 
>>>>>>                         https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>                     -- 
>>>>>>                     Thanks & Regards,
>>>>>>                     Prabath
>>>>>>
>>>>>>                     Mobile : +94 71 809 6732
>>>>>>                     
>>>>>>
>>>>>>                     http://blog.facilelogin.com
>>>>>>                     http://RampartFAQ.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>                 -- 
>>>>>                 Thanks & Regards,
>>>>>                 Prabath
>>>>>
>>>>>                 Mobile : +94 71 809 6732
>>>>>                 
>>>>>
>>>>>                 http://blog.facilelogin.com
>>>>>                 http://RampartFAQ.com
>>>>
>>>>
>>>>
>>>>
>>>>             -- 
>>>>             Thanks & Regards,
>>>>             Prabath
>>>>
>>>>             Mobile : +94 71 809 6732 
>>>>
>>>>             http://blog.facilelogin.com
>>>>             http://RampartFAQ.com
>>>
>>>
>>>
>>>
>>>         -- 
>>>         Thanks & Regards,
>>>         Prabath
>>>
>>>         Mobile : +94 71 809 6732 
>>>
>>>         http://blog.facilelogin.com
>>>         http://RampartFAQ.com
>>>         _______________________________________________
>>>         OAuth mailing list
>>>         OAuth@ietf.org 
>>>         https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>     -- 
>     Thanks & Regards,
>     Prabath
>
>     Mobile : +94 71 809 6732 
>
>     http://blog.facilelogin.com
>     http://RampartFAQ.com
>
>
>
>
> -- 
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com

--------------020305030005000806030609
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

    What exactly are you suggesting be added to introspection? The
    "token_type_hint" is from the client to the server, but what you've
    asked for in terms of "token type" is from the server to the client.
    And there was never an answer to what exactly is meant by "token
    type" in this case, particularly because you seem to want to call
    out things like SAML and Bearer as separate types. 

     -- Justin

    On 02/14/2013 06:59 AM, Prabath
      Siriwardena wrote:

      I noticed that the latest Token Revocation draft [1] has
      introduced the parameter "token_type_hint". I would suggest the
      same here, as that would make what is meant by "valid" much
      clear..

      [1]: http://tools.ietf.org/html/draft-ietf-oauth-revocation-05

      Thanks & regards,
      -Prabath

        On Tue, Feb 12, 2013 at 9:35 PM,
          Prabath Siriwardena <prabath@wso2.com> wrote:

          Hi Justin,

            I doubt whether valid_token would make a difference..?

            My initial argument is what is the validation
              criteria..? Validation criteria depends on the
              token_type..

            If we are talking only about metadata - then I believe
              "revoked", "expired" would be more meaningful..

            Thanks & regards,
            -Prabath

                    On Tue, Feb 12, 2013 at 7:53 PM, Justin Richer <jricher@mitre.org>
                    wrote:

                       OK, I can
                        see the wisdom in changing this term. 

                        I picked "valid" because I wanted a simple
                        "boolean" value that would require no additional
                        parsing or string-matching on the client's
                        behalf, and I'd like to stick with that. OAuth
                        is built with the assumption that clients need
                        to be able to recover from invalid tokens at any
                        stage, so I think a simple yes/no is the right
                        step here. 

                        That said, I think you're both right that
                        "valid" seems to have caused a bit of confusion.
                        I don't want to go with "revoked" because I'd
                        rather have the "token is OK" be the positive
                        boolean value. 

                        Would "valid_token" be more clear? Or do we need
                        a different adjective all together?

                             -- Justin

                            On 02/11/2013 08:02 PM, Richard
                              Harrington wrote:

                              Have you considered "status" instead
                                of "valid"?  It could have values like
                                "active", "expired", and "revoked".

                              Is it worthwhile including the status
                                of the client also?  For example, a
                                client application could be disabled,
                                temporarily or permanently, and thus
                                disabling its access tokens as well.

                                On Feb 11, 2013, at 1:56 PM, Prabath
                                Siriwardena <prabath@wso2.com>

                                wrote:

                                I guess confusion is with 'valid'
                                  parameter is in the response..

                                  I thought this will be helpful
                                    to standardize the communication
                                    between Resource Server and the
                                    Authorization Server..

                                  I would suggest we completely
                                    remove "valid" from the response -
                                    or define it much clearly..

                                  May be can add "revoked" with a
                                    boolean attribute..

                                  Thanks & regards,
                                  -Prabath

                                    On Tue, Feb
                                      12, 2013 at 3:19 AM, Justin Richer
                                      <jricher@mitre.org>
                                      wrote:

                                            On 02/08/2013 12:51 AM,
                                              Prabath Siriwardena wrote:

                                            Hi Justin,

                                              I have couple of
                                                questions related to
                                                "valid" parameter...

                                              This endpoint can be
                                                invoked by the Resource
                                                Server in runtime...

                                          That's correct.

                                              In that case what is
                                                exactly meant by the
                                                "resource_id" in request
                                                ?

                                          The resource_id field is a
                                          service-specific string that
                                          basically lets the resource
                                          server provide some context to
                                          the request to the auth
                                          server. There have been some
                                          other suggestions like client
                                          IP address, but I wanted to
                                          put this one in because it
                                          seemed to be a common theme.
                                          The client is trying to do
                                          *something* with the token,
                                          after all, and the rights,
                                          permissions, and metadata
                                          associated with the token
                                          could change based on that.
                                          Since the Introspection
                                          endpoint is all about getting
                                          that metadata back to the PR,
                                          this seemed like a good idea.

                                              IMO a token to be
                                                valid depends on set of
                                                criteria based on it's
                                                type..

                                              For a Bearer token..

                                              1. Token should not
                                                be expired
                                              2. Token should not
                                                be revoked.
                                              3. The scope the
                                                token issued should
                                                match with the scope
                                                required for the
                                                resource.

                                              For a MAC token...

                                              1. Token not expired
                                                (mac id)
                                              2. Token should not
                                                be revoked
                                              3. The scope the
                                                token issued should
                                                match with the scope
                                                required for the
                                                resource.
                                              4. HMAC check should
                                                be valid

                                              There are similar
                                              conditions for SAML bearer
                                              too..

                                          This isn't really true. The
                                          SAML bearer token is fully
                                          self-contained and doesn't
                                          change based on other
                                          parameters in the message,
                                          unlike MAC. Same with JWT.
                                          When it hands a SAML or JWT
                                          token to the AS, the PR has
                                          given *everything* the server
                                          needs to check that token's
                                          validity and use. 

                                          MAC signatures change with
                                          every message, and they're
                                          done across several components
                                          of the HTTP message. Therefor,
                                          the HMAC check for MAC style
                                          tokens will still need to be
                                          done by the protected
                                          resource. Introspection would
                                          help in the case that the
                                          signature validated just fine,
                                          but the token might have
                                          expired. Or you need to know
                                          what scopes apply.
                                          Introspection isn't to fully
                                          validate the call to the
                                          protected resource -- if that
                                          were the case, the PR would
                                          have to send some kind of
                                          encapsulated version of the
                                          original request. Otherwise,
                                          the AS won't have all of the
                                          information it needs to check
                                          the MAC.

                                          I think what you're describing
                                          is ultimately *not* what the
                                          introspection endpoint is
                                          intended to do. If that's
                                          unclear from the document, can
                                          you please suggest text that
                                          would help clear the use case
                                          up? I wouldn't want it to be
                                          ambiguous.

                                               -- Justin

                                                Thanks &
                                                  regards,
                                                -Prabath

                                                  On
                                                    Thu, Feb 7, 2013 at
                                                    10:30 PM, Justin
                                                    Richer <jricher@mitre.org>
                                                    wrote:

                                                        It validates the
                                                        token, which
                                                        would be either
                                                        the token itself
                                                        in the case of
                                                        Bearer or the
                                                        token "id" part
                                                        of something
                                                        more complex
                                                        like MAC. It
                                                        doesn't directly
                                                        validate the
                                                        usage of the
                                                        token, that's
                                                        still up to the
                                                        PR to do that.

                                                        I nearly added a
                                                        "token type"
                                                        field in this
                                                        draft, but held
                                                        back because
                                                        there are
                                                        several kinds of
                                                        "token type"
                                                        that people talk
                                                        about in OAuth.
                                                        First, there's
                                                        "Bearer" vs.
                                                        "MAC" vs. "HOK",
                                                        or what have
                                                        you. Then within
                                                        Bearer you have
                                                        "JWT" or "SAML"
                                                        or "unstructured
                                                        blob". Then
                                                        you've also got
                                                        "access" vs.
                                                        "refresh" and
                                                        other flavors of
                                                        token, like the
                                                        id_token in
                                                        OpenID Connect.

                                                        Thing is, the
                                                        server running
                                                        the
                                                        introspection
                                                        endpoint will
                                                        probably know
                                                        *all* of these.
                                                        But should it
                                                        tell the client?
                                                        If so, which of
                                                        the three, and
                                                        what names
                                                        should the
                                                        fields be?

                                                           -- Justin

                                                          On
                                                          02/07/2013
                                                          11:26 AM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          Okay.. I was
                                                          thinking this
                                                          could be used
                                                          as a way to
                                                          validate the
                                                          token as well.
                                                          BTW even in
                                                          this case
                                                          shouldn't
                                                          communicate
                                                          the type of
                                                          token to AS?
                                                          For example in
                                                          the case of
                                                          SAML profile -
                                                          it could be
                                                          SAML token..

                                                          Thanks
                                                          & regards,
                                                          -Prabath

                                                          On
                                                          Thu, Feb 7,
                                                          2013 at 8:39
                                                          PM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:

                                                          "valid" might
                                                          not be the
                                                          best term, but
                                                          it's meant to
                                                          be a field
                                                          where the
                                                          server says
                                                          "yes this
                                                          token is still
                                                          good" or "no
                                                          this token
                                                          isn't good
                                                          anymore". We
                                                          could instead
                                                          do this with
                                                          HTTP codes or
                                                          something but
                                                          I went with a
                                                          pure JSON
                                                          response.

                                                           -- Justin

                                                          On
                                                          02/06/2013
                                                          10:47 PM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          Hi Justin,

                                                          I believe
                                                          this is
                                                          addressing one
                                                          of the key
                                                          missing part
                                                          in OAuth
                                                          2.0...

                                                          One
                                                          question - I
                                                          guess this was
                                                          discussed
                                                          already...

                                                          In the
                                                          spec - in the
                                                          introspection
                                                          response it
                                                          has the
                                                          attribute
                                                          "valid" - this
                                                          is basically
                                                          the validity
                                                          of the token
                                                          provided in
                                                          the request.

                                                          Validation criteria

                                                          depends on the
                                                          token and well
                                                          as token type
                                                          ( Bearer,
                                                          MAC..).

                                                          In the
                                                          spec it seems
                                                          like it's
                                                          coupled with
                                                          Bearer token
                                                          type... But I
                                                          guess, by
                                                          adding
                                                          "token_type"
                                                          to the request
                                                          we can remove
                                                          this
                                                          dependency.

                                                          WDYT..?

                                                          Thanks
                                                          & regards,
                                                          -Prabath 

                                                          On

                                                          Thu, Feb 7,
                                                          2013 at 12:54
                                                          AM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:

                                                          Updated
                                                          introspection
                                                          draft based on
                                                          recent
                                                          comments.
                                                          Changes
                                                          include:

                                                           - "scope"
                                                          return
                                                          parameter now
                                                          follows
                                                          RFC6749 format
                                                          instead of
                                                          JSON array

                                                           - "subject"
                                                          -> "sub",
                                                          and "audience"
                                                          -> "aud",
                                                          to be parallel
                                                          with JWT
                                                          claims

                                                           - clarified
                                                          what happens
                                                          if the
                                                          authentication
                                                          is bad

                                                           -- Justin

                                                          --------
                                                          Original
                                                          Message
                                                          --------

                                                          Subject: 
                                                          New
                                                          Version
                                                          Notification
                                                          for
                                                          draft-richer-oauth-introspection-02.txt

                                                          Date: 
                                                          Wed, 6 Feb
                                                          2013 11:24:20
                                                          -0800

                                                          From: 
                                                          <internet-drafts@ietf.org>

                                                          To: 
                                                          <jricher@mitre.org>

                                                          A new version of I-D, draft-richer-oauth-introspection-02.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 02
Title:		 OAuth Token Introspection
Creation date:	 2013-02-06
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.

The IETF Secretariat

_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

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

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94
                                                          71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94
                                                          71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                                  -- 

                                                  Thanks & Regards,

                                                  Prabath

                                                  Mobile : +94

                                                      71 809 6732 

                                                    http://blog.facilelogin.com

                                                    http://RampartFAQ.com

                                    -- 

                                    Thanks & Regards,

                                    Prabath

                                    Mobile : +94 71 809 6732 

                                      http://blog.facilelogin.com

                                      http://RampartFAQ.com

                                _______________________________________________

                                  OAuth mailing list

                                  OAuth@ietf.org

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

                  -- 

                  Thanks & Regards,

                  Prabath

                  Mobile : +94 71 809
                      6732 

                    http://blog.facilelogin.com

                    http://RampartFAQ.com

        -- 

        Thanks & Regards,

        Prabath

        Mobile : +94 71 809 6732 

          http://blog.facilelogin.com

          http://RampartFAQ.com

--------------020305030005000806030609--

From ve7jtb@ve7jtb.com  Thu Feb 14 06:05:40 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B65D21F87C4 for ; Thu, 14 Feb 2013 06:05:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.372
X-Spam-Level: 
X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[AWL=0.227,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkUKXxDJi4TA for ; Thu, 14 Feb 2013 06:05:39 -0800 (PST)
Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by ietfa.amsl.com (Postfix) with ESMTP id D983421F8488 for ; Thu, 14 Feb 2013 06:05:38 -0800 (PST)
Received: by mail-qc0-f176.google.com with SMTP id n41so868875qco.7 for ; Thu, 14 Feb 2013 06:05:38 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=oLKFYbjyeT58FDGttp+n+IrzohKSeAjAsKw3/bPJBWI=; b=D/1t4+w3hWFFK3+uchh9TVHxKbZCmmCbWL6ZmGEOifpLV5MZaox7YKsgJh5HZT2CxT G1Qd28AwrU1of9dQZQDhsbN8b357/LCEv+U++wJg+aPc4DdgdpdT3e2LvCnhwiwKpTa+ jxvEW0aFHpwLqcjNJ0eI19/gw9UPyeNDMpclrnwmBubTI1Osa1M0veFYu2Mk976Vjsso 6+Z+iEt5glhEgdJ4+8N52cQSUBrtwdqVfbX30E2mRJOvI7vqGwgfvujjat/NPfTr5tLP 9R3bcvGkViNYlgpGmtpwN0H9d5LKutwoq9giqnvsB3NShS3I84H20p779fzcdwzG2VGx kxyg==
X-Received: by 10.224.168.144 with SMTP id u16mr652814qay.18.1360850738118; Thu, 14 Feb 2013 06:05:38 -0800 (PST)
Received: from [192.168.1.213] (190-20-16-126.baf.movistar.cl. [190.20.16.126]) by mx.google.com with ESMTPS id dt10sm18480046qab.0.2013.02.14.06.05.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Feb 2013 06:05:36 -0800 (PST)
Content-Type: text/plain; charset=iso-2022-jp
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: 
Date: Thu, 14 Feb 2013 11:05:19 -0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <4687F290-4855-49DE-892F-F9694BB211D4@ve7jtb.com>
References: <51195F36.6040705@mitre.org> <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com> <511BAA8B.8030309@mitre.org>  <-4554688250617930935@unknownmsgid>  
To: Nat Sakimura 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQmtKWzQRK3Pn7J8xemjm5012Cs+9NbSUB/Ka8neAMsxpOE9oHeulJs+v5gRYOUQLYMNSJlC
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2013 14:05:40 -0000

I agree with Tim that is the behaviour I would  expect to see with =
DELETE though I have a rd time seeing a server ever honouring it.

I guess that we need to clarify what happens with PUT and claims the =
server has defaults for, perhaps some that are not changeable by the =
client.  =20

Is not including a claim in a PUT the same as not including it in =
registration, and it is set to the default. =20
If you want to set a claim to null then you must explicitly include the =
claim with null as the value. That is the previous logic we had for =
replace as the client wasn't getting back all the config in the response =
and couldn't know about defaults it wasn't setting.

Perhaps PUT causes unsent claims to be interpreted as if they are sent =
with a null value (I think that is a likely to cause tears personally).

In ether case the client is not deleted and can still be recovered and =
the client_id and associated permissions are still active.

DELETE to be used correctly is I think going to delete the client_id and =
all associated tokens and cause a ripple effect in removing grants =
associated with that client_id. =20

It is a big difference and understanding what a AS is supposed to do to =
delete a client still seems a touch vague to me.   I understand the http =
verb but there is more to it than that if we want interoperability.

John

On 2013-02-14, at 12:31 AM, Nat Sakimura  wrote:

> I thought your concern about DELETE was whether the client should be
> allowed to erase the registration data.
> I thought PUT with an empty values would achieve a similar effect.
> Or did you mean that with PUT, the server default kicks in and
> parameters are set to the defaults?
> If that is the case, they are quite different, I agree.
>=20
> On the effect of DELETE, +1 to Tim's comment.
>=20
> Nat
>=20
> 2013/2/14 John Bradley :
>> DELETE is removing the record not resetting it to defaults.  They are =
quite diffrent.
>>=20
>> I want to agree on what the expected behaviour of DELETE is.   I =
think we have agreement on PUT and POST.
>>=20
>> The general not in that a client can DELETE it's record is a =
implication I don't like.  I think that is for the server to decide and =
if it is not actually deleting it then DELETE is the wrong verb to use.
>>=20
>> John B.
>>=20
>> On 2013-02-13, at 3:31 PM, Nat Sakimura  wrote:
>>=20
>>> Generally speaking, mapping PUT to replace and POST to change is an
>>> acceptable practice so I am fine with it.
>>>=20
>>> Now, what I still do not understand is why you think it is fine to =
do
>>> PUT or POST and not DELETE. Doing PUT with empty content is almost =
the
>>> same as DELETE. Could you explain?
>>>=20
>>> =3Dnat via iPhone
>>>=20
>>> Feb 14, 2013 0:10=1B$B!"=1B(BJohn Bradley  =
=1B$B$N%a%C%;!<%8=1B(B:
>>>=20
>>>> I am not violently opposed to PUT as a option that completely =
replaces the resource setting all unsent claims back to the defaults.
>>>>=20
>>>> I don't have a good feeling about DELETE,  I think we still need =
more discussion on what it means, what privileges it takes to invoke it =
etc.
>>>> It could be a bad thing if we get wrong or is not implemented =
consistently.
>>>>=20
>>>> Personally I don't think a client should ever be able to DELETE =
it's record.
>>>>=20
>>>> I think marking a client_id as pending provisioning, suspended,  =
revoked etc is better and that can be done with a claim in the update =
endpoint.
>>>>=20
>>>> It should only be the server that deletes a record after satisfying =
it's audit requirements.
>>>>=20
>>>> John B.
>>>>=20
>>>> On 2013-02-13, at 12:00 PM, Justin Richer  =
wrote:
>>>>=20
>>>>> Would it be reasonable to mark the PUT and DELETE methods as =
optional for the server to implement, but with defined semantics if they =
do? I want to keep GET and POST(create) as mandatory, as I think that's =
the minimal set of functionality required.
>>>>>=20
>>>>> -- Justin
>>>>>=20
>>>>> On 02/11/2013 08:51 PM, John Bradley wrote:
>>>>>> I would always include the client_id on update.
>>>>>>=20
>>>>>> I think it is also us full to have other tokens used at the =
update endpoint.  I can see the master token used to update all the =
clients it has registered as part of API management.
>>>>>> Relying on the registration_access_token is probably a design =
that will cause trouble down the road.
>>>>>>=20
>>>>>> I think GET and POST are relatively clear.   I don't know about =
expelling PUT to developers.  I think POST with a client_id to a =
(separate discussion) update_uri works without restricting it to PUT.
>>>>>>=20
>>>>>> I think DELETE needs to be better understood.   I think a status =
that can be set for client lifecycle is better than letting a client =
delete a entry.
>>>>>> In some cases there will be more than one instance of a client =
and letting them know they have been turned off for a reason is better =
than making there registration disappear.
>>>>>> So for the moment I would levee out DELETE.
>>>>>>=20
>>>>>> John B.
>>>>>>=20
>>>>>> On 2013-02-11, at 6:14 PM, Justin Richer  =
wrote:
>>>>>>=20
>>>>>>> Draft -05 of OAuth Dynamic Client Registration [1] defines =
several operations that the client can take on its behalf as part of the =
registration process. These boil down to the basic CRUD operations that =
you find in many APIs: Create, Read, Update, Delete. Draft -00 defined =
only the "Create" operation, draft -01 through -04 added the "Update" =
operation, switched using the "operation=3D" parameter.
>>>>>>>=20
>>>>>>> Following several suggestions to do so on the list, the -05 =
draft defines these operations in terms of a RESTful API for the client. =
Namely:
>>>>>>>=20
>>>>>>> - HTTP POST to registration endpoint =3D> Create (register) a =
new client
>>>>>>> - HTTP PUT to update endpoint (with registration_access_token) =
=3D> Update the registered information for this client
>>>>>>> - HTTP GET to update endpoint (with registration_access_token) =
=3D> read the registered information for this client
>>>>>>> - HTTP DELETE to update endpoint (with =
registration_access_token) =3D> Delete (unregister/de-provision) this =
client
>>>>>>>=20
>>>>>>> The two main issues at stake here are: the addition of the READ =
and DELETE methods, and the use of HTTP verbs following a RESTful design =
philosophy.
>>>>>>>=20
>>>>>>> Pro:
>>>>>>> - RESTful APIs (with HTTP verbs to differentiate functionality) =
are the norm today
>>>>>>> - Full lifecycle management is common and is going to be =
expected by many users of this protocol in the wild
>>>>>>>=20
>>>>>>> Cons:
>>>>>>> - Update semantics are still under debate (full replace? patch?)
>>>>>>> - Somewhat increased complexity on the server to support all =
operations
>>>>>>> - Client has to understand all HTTP verbs for full access =
(though plain registration is just POST)
>>>>>>>=20
>>>>>>>=20
>>>>>>> Alternatives include using an operational switch parameter (like =
the old drafts), defining separate endpoints for every action, or doing =
all operations on a single endpoint using verbs to switch.
>>>>>>>=20
>>>>>>> -- Justin
>>>>>>>=20
>>>>>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>=20
>=20
>=20
> --=20
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en

From jricher@mitre.org  Thu Feb 14 06:21:45 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C98A21F87DF for ; Thu, 14 Feb 2013 06:21:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.569
X-Spam-Level: 
X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qvo6JjfynSUr for ; Thu, 14 Feb 2013 06:21:44 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id EE1EE21F863C for ; Thu, 14 Feb 2013 06:21:42 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 87BA61F2200; Thu, 14 Feb 2013 09:21:42 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 77FBA1F0535; Thu, 14 Feb 2013 09:21:42 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 14 Feb 2013 09:21:42 -0500
Message-ID: <511CF2C9.9040604@mitre.org>
Date: Thu, 14 Feb 2013 09:20:57 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: John Bradley 
References: <51195F36.6040705@mitre.org> <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com> <511BAA8B.8030309@mitre.org>  <-4554688250617930935@unknownmsgid>   <4687F290-4855-49DE-892F-F9694BB211D4@ve7jtb.com>
In-Reply-To: <4687F290-4855-49DE-892F-F9694BB211D4@ve7jtb.com>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2013 14:21:45 -0000

On 02/14/2013 09:05 AM, John Bradley wrote:
> I agree with Tim that is the behaviour I would  expect to see with DELETE though I have a rd time seeing a server ever honouring it.
>
> I guess that we need to clarify what happens with PUT and claims the server has defaults for, perhaps some that are not changeable by the client.   
>
> Is not including a claim in a PUT the same as not including it in registration, and it is set to the default.  
> If you want to set a claim to null then you must explicitly include the claim with null as the value. That is the previous logic we had for replace as the client wasn't getting back all the config in the response and couldn't know about defaults it wasn't setting.
>
> Perhaps PUT causes unsent claims to be interpreted as if they are sent with a null value (I think that is a likely to cause tears personally).
>
> In ether case the client is not deleted and can still be recovered and the client_id and associated permissions are still active.

What I had in mind from this conversation is something like this:

When sending an update, a client MUST send all metadata fields returned
from the server in its initial registration or previous read or update
call, including its client_id. A server MAY replace any missing or
invalid fields with default values, or it MAY return an error as
described in the Error Response section. A server MUST return all
provisioned fields in its response. A server MUST NOT change the
client_id field. A server MAY change the client_secret and/or
refresh_access_token fields.

>
> DELETE to be used correctly is I think going to delete the client_id and all associated tokens and cause a ripple effect in removing grants associated with that client_id.  

This is how I would interpret it as well. It's de-provisioning the
client, not resetting it.

-- Justin

>
> It is a big difference and understanding what a AS is supposed to do to delete a client still seems a touch vague to me.   I understand the http verb but there is more to it than that if we want interoperability.
>
> John
>
> On 2013-02-14, at 12:31 AM, Nat Sakimura  wrote:
>
>> I thought your concern about DELETE was whether the client should be
>> allowed to erase the registration data.
>> I thought PUT with an empty values would achieve a similar effect.
>> Or did you mean that with PUT, the server default kicks in and
>> parameters are set to the defaults?
>> If that is the case, they are quite different, I agree.
>>
>> On the effect of DELETE, +1 to Tim's comment.
>>
>> Nat
>>
>> 2013/2/14 John Bradley :
>>> DELETE is removing the record not resetting it to defaults.  They are quite diffrent.
>>>
>>> I want to agree on what the expected behaviour of DELETE is.   I think we have agreement on PUT and POST.
>>>
>>> The general not in that a client can DELETE it's record is a implication I don't like.  I think that is for the server to decide and if it is not actually deleting it then DELETE is the wrong verb to use.
>>>
>>> John B.
>>>
>>> On 2013-02-13, at 3:31 PM, Nat Sakimura  wrote:
>>>
>>>> Generally speaking, mapping PUT to replace and POST to change is an
>>>> acceptable practice so I am fine with it.
>>>>
>>>> Now, what I still do not understand is why you think it is fine to do
>>>> PUT or POST and not DELETE. Doing PUT with empty content is almost the
>>>> same as DELETE. Could you explain?
>>>>
>>>> =nat via iPhone
>>>>
>>>> Feb 14, 2013 0:10$B!"(BJohn Bradley  $B$N%a%C%;!<%8(B:
>>>>
>>>>> I am not violently opposed to PUT as a option that completely replaces the resource setting all unsent claims back to the defaults.
>>>>>
>>>>> I don't have a good feeling about DELETE,  I think we still need more discussion on what it means, what privileges it takes to invoke it etc.
>>>>> It could be a bad thing if we get wrong or is not implemented consistently.
>>>>>
>>>>> Personally I don't think a client should ever be able to DELETE it's record.
>>>>>
>>>>> I think marking a client_id as pending provisioning, suspended,  revoked etc is better and that can be done with a claim in the update endpoint.
>>>>>
>>>>> It should only be the server that deletes a record after satisfying it's audit requirements.
>>>>>
>>>>> John B.
>>>>>
>>>>> On 2013-02-13, at 12:00 PM, Justin Richer  wrote:
>>>>>
>>>>>> Would it be reasonable to mark the PUT and DELETE methods as optional for the server to implement, but with defined semantics if they do? I want to keep GET and POST(create) as mandatory, as I think that's the minimal set of functionality required.
>>>>>>
>>>>>> -- Justin
>>>>>>
>>>>>> On 02/11/2013 08:51 PM, John Bradley wrote:
>>>>>>> I would always include the client_id on update.
>>>>>>>
>>>>>>> I think it is also us full to have other tokens used at the update endpoint.  I can see the master token used to update all the clients it has registered as part of API management.
>>>>>>> Relying on the registration_access_token is probably a design that will cause trouble down the road.
>>>>>>>
>>>>>>> I think GET and POST are relatively clear.   I don't know about expelling PUT to developers.  I think POST with a client_id to a (separate discussion) update_uri works without restricting it to PUT.
>>>>>>>
>>>>>>> I think DELETE needs to be better understood.   I think a status that can be set for client lifecycle is better than letting a client delete a entry.
>>>>>>> In some cases there will be more than one instance of a client and letting them know they have been turned off for a reason is better than making there registration disappear.
>>>>>>> So for the moment I would levee out DELETE.
>>>>>>>
>>>>>>> John B.
>>>>>>>
>>>>>>> On 2013-02-11, at 6:14 PM, Justin Richer  wrote:
>>>>>>>
>>>>>>>> Draft -05 of OAuth Dynamic Client Registration [1] defines several operations that the client can take on its behalf as part of the registration process. These boil down to the basic CRUD operations that you find in many APIs: Create, Read, Update, Delete. Draft -00 defined only the "Create" operation, draft -01 through -04 added the "Update" operation, switched using the "operation=" parameter.
>>>>>>>>
>>>>>>>> Following several suggestions to do so on the list, the -05 draft defines these operations in terms of a RESTful API for the client. Namely:
>>>>>>>>
>>>>>>>> - HTTP POST to registration endpoint => Create (register) a new client
>>>>>>>> - HTTP PUT to update endpoint (with registration_access_token) => Update the registered information for this client
>>>>>>>> - HTTP GET to update endpoint (with registration_access_token) => read the registered information for this client
>>>>>>>> - HTTP DELETE to update endpoint (with registration_access_token) => Delete (unregister/de-provision) this client
>>>>>>>>
>>>>>>>> The two main issues at stake here are: the addition of the READ and DELETE methods, and the use of HTTP verbs following a RESTful design philosophy.
>>>>>>>>
>>>>>>>> Pro:
>>>>>>>> - RESTful APIs (with HTTP verbs to differentiate functionality) are the norm today
>>>>>>>> - Full lifecycle management is common and is going to be expected by many users of this protocol in the wild
>>>>>>>>
>>>>>>>> Cons:
>>>>>>>> - Update semantics are still under debate (full replace? patch?)
>>>>>>>> - Somewhat increased complexity on the server to support all operations
>>>>>>>> - Client has to understand all HTTP verbs for full access (though plain registration is just POST)
>>>>>>>>
>>>>>>>>
>>>>>>>> Alternatives include using an operational switch parameter (like the old drafts), defining separate endpoints for every action, or doing all operations on a single endpoint using verbs to switch.
>>>>>>>>
>>>>>>>> -- Justin
>>>>>>>>
>>>>>>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>
>>
>> -- 
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en

From prabath@wso2.com  Thu Feb 14 06:22:31 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA9E21F8802 for ; Thu, 14 Feb 2013 06:22:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.606
X-Spam-Level: 
X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[AWL=0.370,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9V3Aj-qxccVp for ; Thu, 14 Feb 2013 06:22:27 -0800 (PST)
Received: from mail-ea0-f171.google.com (mail-ea0-f171.google.com [209.85.215.171]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDF421F863C for ; Thu, 14 Feb 2013 06:22:24 -0800 (PST)
Received: by mail-ea0-f171.google.com with SMTP id c13so925098eaa.30 for ; Thu, 14 Feb 2013 06:22:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=noBQPz+oLzJh+xNWkGYTWIFqgxuAvJMhuK50y49uqj0=; b=iXsAtY546BUd1+ESVrwcgLqV7ROh3UNqF/mOcQqzVrPP3/5m2d2WlUdiFD/kMQadoe +vueETHhEOZbT7Yq/6GYy7hQHLe7OkbqajLdG3GWmdmfcBaa1vqpwK8QvphaqCkyWXXC JF3Hxkb/Bp0KCZOSSiAQzIC9pvn8wwcvncLg3aZWlHpp3fB6Jn4FrO65bFzMwzjjGUOu 2wP46Az+NqXW9iHUnO5HfiL3RUCFJ3G8G0rBtgWPe3ul+BpqNRDy0MuoSyqC4Xb7Ojxx Y0ALs+cRGBJ0LMJKS2jTTgvLEWZO0nMbAvVIUs8D4pKmhOqwHCq/xwFfw5O058LN0x9t 3RZA==
MIME-Version: 1.0
X-Received: by 10.14.207.73 with SMTP id m49mr18341794eeo.24.1360851743473; Thu, 14 Feb 2013 06:22:23 -0800 (PST)
Received: by 10.223.37.77 with HTTP; Thu, 14 Feb 2013 06:22:23 -0800 (PST)
In-Reply-To: <511CEEAA.3030801@mitre.org>
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com> <5112AE0B.1080501@mitre.org>  <5113C3AA.1040701@mitre.org>  <5113DDB2.7060805@mitre.org>  <51196777.6000502@mitre.org>   <511A5062.5010108@mitre.org>   <511CEEAA.3030801@mitre.org>
Date: Thu, 14 Feb 2013 19:52:23 +0530
Message-ID: 
From: Prabath Siriwardena 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=047d7b343a7cc2fe8e04d5affc91
X-Gm-Message-State: ALoCoQn76MyRyuFlEuoiPJ9qxpveMg+DD6KYp1X68oVtj/HU1WXmxlyeUyfBmzLQq5uH+5O4P2mm
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2013 14:22:31 -0000

--047d7b343a7cc2fe8e04d5affc91
Content-Type: text/plain; charset=ISO-8859-1

Both the client and the resource owner should be aware of the token type.

My argument is, if the authorization server to decide whether the token is
valid or not ( irrespective of who asked the question) - AS needs to know
the token type - because to validate a token AS should know the token type.

The token type could be, bearer or MAC or any other token type.

Thanks & regards,
-Prabath

On Thu, Feb 14, 2013 at 7:33 PM, Justin Richer  wrote:

>  What exactly are you suggesting be added to introspection? The
> "token_type_hint" is from the client to the server, but what you've asked
> for in terms of "token type" is from the server to the client. And there
> was never an answer to what exactly is meant by "token type" in this case,
> particularly because you seem to want to call out things like SAML and
> Bearer as separate types.
>
>  -- Justin
>
>
>
> On 02/14/2013 06:59 AM, Prabath Siriwardena wrote:
>
> I noticed that the latest Token Revocation draft [1] has introduced the
> parameter "token_type_hint". I would suggest the same here, as that would
> make what is meant by "valid" much clear..
>
>  [1]: http://tools.ietf.org/html/draft-ietf-oauth-revocation-05
>
>  Thanks & regards,
> -Prabath
>
> On Tue, Feb 12, 2013 at 9:35 PM, Prabath Siriwardena wrote:
>
>> Hi Justin,
>>
>>  I doubt whether valid_token would make a difference..?
>>
>>  My initial argument is what is the validation criteria..? Validation
>> criteria depends on the token_type..
>>
>>  If we are talking only about metadata - then I believe "revoked",
>> "expired" would be more meaningful..
>>
>>  Thanks & regards,
>> -Prabath
>>
>>
>>  On Tue, Feb 12, 2013 at 7:53 PM, Justin Richer wrote:
>>
>>>  OK, I can see the wisdom in changing this term.
>>>
>>> I picked "valid" because I wanted a simple "boolean" value that would
>>> require no additional parsing or string-matching on the client's behalf,
>>> and I'd like to stick with that. OAuth is built with the assumption that
>>> clients need to be able to recover from invalid tokens at any stage, so I
>>> think a simple yes/no is the right step here.
>>>
>>> That said, I think you're both right that "valid" seems to have caused a
>>> bit of confusion. I don't want to go with "revoked" because I'd rather have
>>> the "token is OK" be the positive boolean value.
>>>
>>> Would "valid_token" be more clear? Or do we need a different adjective
>>> all together?
>>>
>>>  -- Justin
>>>
>>>
>>> On 02/11/2013 08:02 PM, Richard Harrington wrote:
>>>
>>> Have you considered "status" instead of "valid"?  It could have values
>>> like "active", "expired", and "revoked".
>>>
>>>  Is it worthwhile including the status of the client also?  For
>>> example, a client application could be disabled, temporarily or
>>> permanently, and thus disabling its access tokens as well.
>>>
>>>
>>> On Feb 11, 2013, at 1:56 PM, Prabath Siriwardena 
>>> wrote:
>>>
>>>  I guess confusion is with 'valid' parameter is in the response..
>>>
>>>  I thought this will be helpful to standardize the communication
>>> between Resource Server and the Authorization Server..
>>>
>>>  I would suggest we completely remove "valid" from the response - or
>>> define it much clearly..
>>>
>>>  May be can add "revoked" with a boolean attribute..
>>>
>>>  Thanks & regards,
>>> -Prabath
>>>
>>> On Tue, Feb 12, 2013 at 3:19 AM, Justin Richer wrote:
>>>
>>>>
>>>> On 02/08/2013 12:51 AM, Prabath Siriwardena wrote:
>>>>
>>>> Hi Justin,
>>>>
>>>>  I have couple of questions related to "valid" parameter...
>>>>
>>>>  This endpoint can be invoked by the Resource Server in runtime...
>>>>
>>>>
>>>> That's correct.
>>>>
>>>>
>>>>
>>>>  In that case what is exactly meant by the "resource_id" in request ?
>>>>
>>>>
>>>>  The resource_id field is a service-specific string that basically lets
>>>> the resource server provide some context to the request to the auth server.
>>>> There have been some other suggestions like client IP address, but I wanted
>>>> to put this one in because it seemed to be a common theme. The client is
>>>> trying to do *something* with the token, after all, and the rights,
>>>> permissions, and metadata associated with the token could change based on
>>>> that. Since the Introspection endpoint is all about getting that metadata
>>>> back to the PR, this seemed like a good idea.
>>>>
>>>>
>>>>
>>>>  IMO a token to be valid depends on set of criteria based on it's
>>>> type..
>>>>
>>>>  For a Bearer token..
>>>>
>>>>  1. Token should not be expired
>>>> 2. Token should not be revoked.
>>>> 3. The scope the token issued should match with the scope required for
>>>> the resource.
>>>>
>>>>  For a MAC token...
>>>>
>>>>  1. Token not expired (mac id)
>>>> 2. Token should not be revoked
>>>> 3. The scope the token issued should match with the scope required for
>>>> the resource.
>>>> 4. HMAC check should be valid
>>>>
>>>>  There are similar conditions for SAML bearer too..
>>>>
>>>>
>>>>  This isn't really true. The SAML bearer token is fully self-contained
>>>> and doesn't change based on other parameters in the message, unlike MAC.
>>>> Same with JWT. When it hands a SAML or JWT token to the AS, the PR has
>>>> given *everything* the server needs to check that token's validity and use.
>>>>
>>>> MAC signatures change with every message, and they're done across
>>>> several components of the HTTP message. Therefor, the HMAC check for MAC
>>>> style tokens will still need to be done by the protected resource.
>>>> Introspection would help in the case that the signature validated just
>>>> fine, but the token might have expired. Or you need to know what scopes
>>>> apply. Introspection isn't to fully validate the call to the protected
>>>> resource -- if that were the case, the PR would have to send some kind of
>>>> encapsulated version of the original request. Otherwise, the AS won't have
>>>> all of the information it needs to check the MAC.
>>>>
>>>>
>>>> I think what you're describing is ultimately *not* what the
>>>> introspection endpoint is intended to do. If that's unclear from the
>>>> document, can you please suggest text that would help clear the use case
>>>> up? I wouldn't want it to be ambiguous.
>>>>
>>>>  -- Justin
>>>>
>>>>
>>>>
>>>>  Thanks & regards,
>>>> -Prabath
>>>>
>>>>
>>>> On Thu, Feb 7, 2013 at 10:30 PM, Justin Richer wrote:
>>>>
>>>>>  It validates the token, which would be either the token itself in the
>>>>> case of Bearer or the token "id" part of something more complex like MAC.
>>>>> It doesn't directly validate the usage of the token, that's still up to the
>>>>> PR to do that.
>>>>>
>>>>> I nearly added a "token type" field in this draft, but held back
>>>>> because there are several kinds of "token type" that people talk about in
>>>>> OAuth. First, there's "Bearer" vs. "MAC" vs. "HOK", or what have you. Then
>>>>> within Bearer you have "JWT" or "SAML" or "unstructured blob". Then you've
>>>>> also got "access" vs. "refresh" and other flavors of token, like the
>>>>> id_token in OpenID Connect.
>>>>>
>>>>> Thing is, the server running the introspection endpoint will probably
>>>>> know *all* of these. But should it tell the client? If so, which of the
>>>>> three, and what names should the fields be?
>>>>>
>>>>>  -- Justin
>>>>>
>>>>>
>>>>> On 02/07/2013 11:26 AM, Prabath Siriwardena wrote:
>>>>>
>>>>> Okay.. I was thinking this could be used as a way to validate the
>>>>> token as well. BTW even in this case shouldn't communicate the type of
>>>>> token to AS? For example in the case of SAML profile - it could be SAML
>>>>> token..
>>>>>
>>>>>  Thanks & regards,
>>>>> -Prabath
>>>>>
>>>>> On Thu, Feb 7, 2013 at 8:39 PM, Justin Richer wrote:
>>>>>
>>>>>>  "valid" might not be the best term, but it's meant to be a field
>>>>>> where the server says "yes this token is still good" or "no this token
>>>>>> isn't good anymore". We could instead do this with HTTP codes or something
>>>>>> but I went with a pure JSON response.
>>>>>>
>>>>>>  -- Justin
>>>>>>
>>>>>>
>>>>>> On 02/06/2013 10:47 PM, Prabath Siriwardena wrote:
>>>>>>
>>>>>> Hi Justin,
>>>>>>
>>>>>>  I believe this is addressing one of the key missing part in OAuth
>>>>>> 2.0...
>>>>>>
>>>>>>  One question - I guess this was discussed already...
>>>>>>
>>>>>>  In the spec - in the introspection response it has the attribute
>>>>>> "valid" - this is basically the validity of the token provided in the
>>>>>> request.
>>>>>>
>>>>>>  Validation criteria depends on the token and well as token type (
>>>>>> Bearer, MAC..).
>>>>>>
>>>>>>  In the spec it seems like it's coupled with Bearer token type...
>>>>>> But I guess, by adding "token_type" to the request we can remove this
>>>>>> dependency.
>>>>>>
>>>>>>  WDYT..?
>>>>>>
>>>>>>  Thanks & regards,
>>>>>> -Prabath
>>>>>>
>>>>>> On Thu, Feb 7, 2013 at 12:54 AM, Justin Richer wrote:
>>>>>>
>>>>>>>  Updated introspection draft based on recent comments. Changes
>>>>>>> include:
>>>>>>>
>>>>>>>  - "scope" return parameter now follows RFC6749 format instead of
>>>>>>> JSON array
>>>>>>>  - "subject" -> "sub", and "audience" -> "aud", to be parallel with
>>>>>>> JWT claims
>>>>>>>  - clarified what happens if the authentication is bad
>>>>>>>
>>>>>>>  -- Justin
>>>>>>>
>>>>>>>
>>>>>>> -------- Original Message --------  Subject: New Version
>>>>>>> Notification for draft-richer-oauth-introspection-02.txt  Date: Wed,
>>>>>>> 6 Feb 2013 11:24:20 -0800  From:   To:
>>>>>>>  
>>>>>>>
>>>>>>> A new version of I-D, draft-richer-oauth-introspection-02.txt
>>>>>>> has been successfully submitted by Justin Richer and posted to the
>>>>>>> IETF repository.
>>>>>>>
>>>>>>> Filename:	 draft-richer-oauth-introspection
>>>>>>> Revision:	 02
>>>>>>> Title:		 OAuth Token Introspection
>>>>>>> Creation date:	 2013-02-06
>>>>>>> WG ID:		 Individual Submission
>>>>>>> Number of pages: 6
>>>>>>> URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
>>>>>>> Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
>>>>>>> Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-02
>>>>>>> Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02
>>>>>>>
>>>>>>> Abstract:
>>>>>>>    This specification defines a method for a client or protected
>>>>>>>    resource to query an OAuth authorization server to determine meta-
>>>>>>>    information about an OAuth token.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The IETF Secretariat
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>  --
>>>>>> Thanks & Regards,
>>>>>> Prabath
>>>>>>
>>>>>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>>>>>
>>>>>> http://blog.facilelogin.com
>>>>>> http://RampartFAQ.com
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>  --
>>>>> Thanks & Regards,
>>>>> Prabath
>>>>>
>>>>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>>>>
>>>>> http://blog.facilelogin.com
>>>>> http://RampartFAQ.com
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>  --
>>>> Thanks & Regards,
>>>> Prabath
>>>>
>>>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>>>
>>>> http://blog.facilelogin.com
>>>> http://RampartFAQ.com
>>>>
>>>>
>>>>
>>>
>>>
>>>  --
>>> Thanks & Regards,
>>> Prabath
>>>
>>>  Mobile : +94 71 809 6732
>>>
>>> http://blog.facilelogin.com
>>> http://RampartFAQ.com
>>>
>>>  _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>
>>
>>  --
>> Thanks & Regards,
>> Prabath
>>
>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>
>> http://blog.facilelogin.com
>> http://RampartFAQ.com
>>
>
>
>
>  --
> Thanks & Regards,
> Prabath
>
>  Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com
>
>
>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.com

--047d7b343a7cc2fe8e04d5affc91
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Both the client and the resource owner should be aware of the token type.
My argument is, if the authorization server to decide whe=
ther the token is valid or not ( irrespective of who asked the question) - =
AS needs to know the token type - because to validate a token AS should kno=
w the token type.

The token type could be, bearer or MAC or any other tok=
en type.

Thanks & regards,
-Prabath<=
br>
On Thu, Feb 14, 2013 at 7:33 PM, Justin R=
icher <jricher@mitre.org> wrote:

 =20
   =20
 =20

    What exactly are you suggesting be added to introspection? The
    "token_type_hint" is from the client to the server, but what =
you've
    asked for in terms of "token type" is from the server to the =
client.
    And there was never an answer to what exactly is meant by "token
    type" in this case, particularly because you seem to want to call
    out things like SAML and Bearer as separate types. 

    =A0-- Justin

    On 02/14/2013 06:59 AM, Prabath
      Siriwardena wrote:

     =20
      I noticed that the latest Token Revocation draft [1] has
      introduced the parameter "token_type_hint". I would suggest=
 the
      same here, as that would make what is meant by "valid" much
      clear..

      [1]:=A0http://tools.ietf.org/html/d=
raft-ietf-oauth-revocation-05

      Thanks & regards,
      -Prabath

        On Tue, Feb 12, 2013 at 9:35 PM,
          Prabath Siriwardena <prabath@wso2.com> wrote:

          Hi Justin,

            I doubt whether valid_token would make a difference..?

            My initial argument is what is the validation
              criteria..? Validation criteria depends on the
              token_type..

            If we are talking only about metadata - then I believe
              "revoked", "expired" would be more meanin=
gful..

            Thanks & regards,
            -Prabath

                    On Tue, Feb 12, 2013 at 7:53 PM, Justin Richer <jriche=
r@mitre.org>
                    wrote:

                       OK, I can
                        see the wisdom in changing this term. 

                        I picked "valid" because I wanted a simpl=
e
                        "boolean" value that would require no add=
itional
                        parsing or string-matching on the client's
                        behalf, and I'd like to stick with that. OAuth
                        is built with the assumption that clients need
                        to be able to recover from invalid tokens at any
                        stage, so I think a simple yes/no is the right
                        step here. 

                        That said, I think you're both right that
                        "valid" seems to have caused a bit of con=
fusion.
                        I don't want to go with "revoked" bec=
ause I'd
                        rather have the "token is OK" be the posi=
tive
                        boolean value. 

                        Would "valid_token" be more clear? Or do =
we need
                        a different adjective all together?

                            =A0-- Justin

                            On 02/11/2013 08:02 PM, Richard
                              Harrington wrote:

                              Have you considered "status" i=
nstead
                                of "valid"? =A0It could have valu=
es like
                                "active", "expired", an=
d "revoked".

                              Is it worthwhile including the status
                                of the client also? =A0For example, a
                                client application could be disabled,
                                temporarily or permanently, and thus
                                disabling its access tokens as well.

                                On Feb 11, 2013, at 1:56 PM, Prabath
                                Siriwardena <prabath@wso2.com>

                                wrote:

                                I guess confusion is with 'valid&#=
39;
                                  parameter is in the response..

                                  I thought this will be helpful
                                    to=A0standardize=A0the communication
                                    between Resource Server and the
                                    Authorization Server..

                                  I would suggest we completely
                                    remove "valid" from the respo=
nse -
                                    or define it much clearly..

                                  May be can add "revoked" w=
ith a
                                    boolean attribute..

                                  Thanks & regards,
                                  -Prabath

                                    On Tue, Feb
                                      12, 2013 at 3:19 AM, Justin Richer
                                      <jricher@mitre.org>
                                      wrote:

                                            On 02/08/2013 12:51 AM,
                                              Prabath Siriwardena wrote:

                                            Hi=A0Justin,

                                              I have couple of
                                                questions related to
                                                "valid" parameter=
...

                                              This endpoint can be
                                                invoked by the Resource
                                                Server in runtime...

                                          That's correct.

                                              In that case what is
                                                exactly meant by the
                                                "resource_id" in =
request
                                                ?

                                          The resource_id field is a
                                          service-specific string that
                                          basically lets the resource
                                          server provide some context to
                                          the request to the auth
                                          server. There have been some
                                          other suggestions like client
                                          IP address, but I wanted to
                                          put this one in because it
                                          seemed to be a common theme.
                                          The client is trying to do
                                          *something* with the token,
                                          after all, and the rights,
                                          permissions, and metadata
                                          associated with the token
                                          could change based on that.
                                          Since the Introspection
                                          endpoint is all about getting
                                          that metadata back to the PR,
                                          this seemed like a good idea.

                                              IMO a token to be
                                                valid depends on set of
                                                criteria based on it's
                                                type..

                                              For a Bearer token..

                                              1. Token should not
                                                be expired
                                              2. Token should not
                                                be revoked.
                                              3. The scope the
                                                token issued should
                                                match with the scope
                                                required for the
                                                resource.

                                              For a MAC token...

                                              1. Token not expired
                                                (mac id)
                                              2. Token should not
                                                be revoked
                                              3. The scope the
                                                token issued should
                                                match with the scope
                                                required for the
                                                resource.
                                              4. HMAC check should
                                                be valid

                                              There are similar
                                              conditions for SAML bearer
                                              too..

                                          This isn't really true. The
                                          SAML bearer token is fully
                                          self-contained and doesn't
                                          change based on other
                                          parameters in the message,
                                          unlike MAC. Same with JWT.
                                          When it hands a SAML or JWT
                                          token to the AS, the PR has
                                          given *everything* the server
                                          needs to check that token's
                                          validity and use. 

                                          MAC signatures change with
                                          every message, and they're
                                          done across several components
                                          of the HTTP message. Therefor,
                                          the HMAC check for MAC style
                                          tokens will still need to be
                                          done by the protected
                                          resource. Introspection would
                                          help in the case that the
                                          signature validated just fine,
                                          but the token might have
                                          expired. Or you need to know
                                          what scopes apply.
                                          Introspection isn't to fully
                                          validate the call to the
                                          protected resource -- if that
                                          were the case, the PR would
                                          have to send some kind of
                                          encapsulated version of the
                                          original request. Otherwise,
                                          the AS won't have all of the
                                          information it needs to check
                                          the MAC.

                                          I think what you're describin=
g
                                          is ultimately *not* what the
                                          introspection endpoint is
                                          intended to do. If that's
                                          unclear from the document, can
                                          you please suggest text that
                                          would help clear the use case
                                          up? I wouldn't want it to be
                                          ambiguous.

                                              =A0-- Justin

                                                Thanks &
                                                  regards,
                                                -Prabath

                                                  On
                                                    Thu, Feb 7, 2013 at
                                                    10:30 PM, Justin
                                                    Richer <jricher@mitre.=
org>
                                                    wrote:

                                                        It validates the
                                                        token, which
                                                        would be either
                                                        the token itself
                                                        in the case of
                                                        Bearer or the
                                                        token "id"=
; part
                                                        of something
                                                        more complex
                                                        like MAC. It
                                                        doesn't directl=
y
                                                        validate the
                                                        usage of the
                                                        token, that's
                                                        still up to the
                                                        PR to do that.

                                                        I nearly added a
                                                        "token type&qu=
ot;
                                                        field in this
                                                        draft, but held
                                                        back because
                                                        there are
                                                        several kinds of
                                                        "token type&qu=
ot;
                                                        that people talk
                                                        about in OAuth.
                                                        First, there's
                                                        "Bearer" =
vs.
                                                        "MAC" vs.=
 "HOK",
                                                        or what have
                                                        you. Then within
                                                        Bearer you have
                                                        "JWT" or =
"SAML"
                                                        or "unstructur=
ed
                                                        blob". Then
                                                        you've also got
                                                        "access" =
vs.
                                                        "refresh"=
 and
                                                        other flavors of
                                                        token, like the
                                                        id_token in
                                                        OpenID Connect.

                                                        Thing is, the
                                                        server running
                                                        the
                                                        introspection
                                                        endpoint will
                                                        probably know
                                                        *all* of these.
                                                        But should it
                                                        tell the client?
                                                        If so, which of
                                                        the three, and
                                                        what names
                                                        should the
                                                        fields be?

                                                          =A0-- Justin

                                                          On
                                                          02/07/2013
                                                          11:26 AM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          Okay.. I was
                                                          thinking this
                                                          could be used
                                                          as a way to
                                                          validate the
                                                          token as well.
                                                          BTW even in
                                                          this case
                                                          shouldn't
                                                          communicate
                                                          the type of
                                                          token to AS?
                                                          For example in
                                                          the case of
                                                          SAML profile -
                                                          it could be
                                                          SAML token..

                                                          Thanks
                                                          & regards,
                                                          -Prabath

                                                          On
                                                          Thu, Feb 7,
                                                          2013 at 8:39
                                                          PM, Justin
                                                          Richer <jricher=
@mitre.org>
                                                          wrote:

                                                          "valid"=
 might
                                                          not be the
                                                          best term, but
                                                          it's meant to
                                                          be a field
                                                          where the
                                                          server says
                                                          "yes this
                                                          token is still
                                                          good" or &qu=
ot;no
                                                          this token
                                                          isn't good
                                                          anymore". We
                                                          could instead
                                                          do this with
                                                          HTTP codes or
                                                          something but
                                                          I went with a
                                                          pure JSON
                                                          response.

                                                          =A0-- Justin

                                                          On
                                                          02/06/2013
                                                          10:47 PM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          Hi Justin,

                                                          I believe
                                                          this is
                                                          addressing one
                                                          of the key
                                                          missing part
                                                          in OAuth
                                                          2.0...

                                                          One
                                                          question - I
                                                          guess this was
                                                          discussed
                                                          already...

                                                          In the
                                                          spec - in the
                                                          introspection
                                                          response it
                                                          has the
                                                          attribute
                                                          "valid"=
 - this
                                                          is basically
                                                          the validity
                                                          of the token
                                                          provided in
                                                          the request.

                                                          Validation=
=A0criteria

                                                          depends on the
                                                          token and well
                                                          as token type
                                                          ( Bearer,
                                                          MAC..).

                                                          In the
                                                          spec it seems
                                                          like it's
                                                          coupled with
                                                          Bearer token
                                                          type... But I
                                                          guess, by
                                                          adding
                                                          "token_type&=
quot;
                                                          to the request
                                                          we can remove
                                                          this
                                                          dependency.

                                                          WDYT..?

                                                          Thanks
                                                          & regards,
                                                          -Prabath=A0<=
/div>

                                                          On

                                                          Thu, Feb 7,
                                                          2013 at 12:54
                                                          AM, Justin
                                                          Richer <jricher=
@mitre.org>
                                                          wrote:

                                                          Updated
                                                          introspection
                                                          draft based on
                                                          recent
                                                          comments.
                                                          Changes
                                                          include:

                                                          =A0- "scope&=
quot;
                                                          return
                                                          parameter now
                                                          follows
                                                          RFC6749 format
                                                          instead of
                                                          JSON array

                                                          =A0- "subjec=
t"
                                                          -> "sub&q=
uot;,
                                                          and "audienc=
e"
                                                          -> "aud&q=
uot;,
                                                          to be parallel
                                                          with JWT
                                                          claims

                                                          =A0- clarified
                                                          what happens
                                                          if the
                                                          authentication
                                                          is bad

                                                          =A0-- Justin

                                                          --------
                                                          Original
                                                          Message
                                                          --------

                                                          Subject: 
                                                          New
                                                          Version
                                                          Notification
                                                          for
                                                          draft-richer-oaut=
h-introspection-02.txt

                                                          Date: 
                                                          Wed, 6 Feb
                                                          2013 11:24:20
                                                          -0800

                                                          From: 
                                                          <internet-drafts@ietf.o=
rg>

                                                          To: 
                                                          <jricher@mitre.org>

                                                          A new versio=
n of I-D, draft-richer-oauth-introspection-02.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 02
Title:		 OAuth Token Introspection
Creation date:	 2013-02-06
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/interne=
t-drafts/draft-richer-oauth-introspection-02.txt
Status:          http://datatracker.ietf.org/doc/draft-=
richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-=
oauth-introspection-02
Diff:            http://www.ietf.org/rfcdiff?url2=
=3Ddraft-richer-oauth-introspection-02

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.

                                                                           =
      =20

The IETF Secretariat

_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

                                                          https://www.ietf.o=
rg/mailman/listinfo/oauth

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94
                                                          71 809 6732=
=A0

                                                          http://blog.facilelogin.com
                                                          http://RampartFAQ.com

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94
                                                          71 809 6732=
=A0

                                                          http://blog.facilelogin.com
                                                          http://RampartFAQ.com

                                                  -- 

                                                  Thanks & Regards,

                                                  Prabath

                                                  Mobile : +94

                                                      71 809 6732=A0

                                                    http://blog.facilelogin.com

                                                    http://RampartFAQ.com

                                    -- 

                                    Thanks & Regards,

                                    Prabath

                                    Mobile : +94 71 809 6732=
=A0

                                      http://blog.facilelogin.com

                                      http://RampartFAQ.com

                                ________________________________=
_______________

                                  OAuth mailing list

                                  OAuth@ietf.org

                                  https://www.ietf.org/mailman/listinf=
o/oauth

                  -- 

                  Thanks & Regards,

                  Prabath

                  Mobile : +94 71 809
                      6732=A0

                    http://blog.facilelogin.com

                    htt=
p://RampartFAQ.com

        -- 

        Thanks & Regards,

        Prabath

        Mobile : +94 71 809 6732=A0

          http://=
blog.facilelogin.com

          http://Rampar=
tFAQ.com

-- 
Thanks &=
 Regards,
Prabath
Mobile : +94 71 809 6732=A0

=
http://blog.facil=
elogin.com

http://RampartFAQ.com

--047d7b343a7cc2fe8e04d5affc91--

From prabath@wso2.com  Thu Feb 14 06:25:26 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C4621F87FA for ; Thu, 14 Feb 2013 06:25:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.874
X-Spam-Level: 
X-Spam-Status: No, score=-2.874 tagged_above=-999 required=5 tests=[AWL=0.102,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-PbecqchC5r for ; Thu, 14 Feb 2013 06:25:24 -0800 (PST)
Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2D121F8201 for ; Thu, 14 Feb 2013 06:25:23 -0800 (PST)
Received: by mail-ee0-f45.google.com with SMTP id b57so1290788eek.18 for ; Thu, 14 Feb 2013 06:25:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=qd9UoBSVV3s4N4NHfb4Ol6Xfb5zm2+af64nC3SQdV/A=; b=FoiFFYI6ALP+XCFJquUN64vj4qG4f2LGLrUzl6PUSvQo0uupwxS1K3n/020a92k9pw qlZw2qCvZB9MFCez5IsNtahznXudBBIuPYZ5Nq1aY1ur+OYzf9X0tgGjPlcp5IwmXfhP QlMtsH7n7SkwIx9b9w1eyvUWik9eDf4zVvv5NSqCmuTKQ4HL5VFRFFAWRo2U9rgA6rbh 5YAV339JsqsNXK98xbhLz6D5BoRPfCmpAsVQqHobwbyGB7I471z+AGbRzA7VJpqLCkgA oLSuMqYWeWkXbKX4qfQF82JFWzFzukGRjkEkiX896I+iDcmbMNIrqftjoJjP+s/91Zow 2bBg==
MIME-Version: 1.0
X-Received: by 10.14.204.3 with SMTP id g3mr18279142eeo.27.1360851922193; Thu, 14 Feb 2013 06:25:22 -0800 (PST)
Received: by 10.223.37.77 with HTTP; Thu, 14 Feb 2013 06:25:21 -0800 (PST)
In-Reply-To: 
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com> <5112AE0B.1080501@mitre.org>  <5113C3AA.1040701@mitre.org>  <5113DDB2.7060805@mitre.org>  <51196777.6000502@mitre.org>   <511A5062.5010108@mitre.org>   <511CEEAA.3030801@mitre.org> 
Date: Thu, 14 Feb 2013 19:55:21 +0530
Message-ID: 
From: Prabath Siriwardena 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=047d7b3440f86a0b6104d5b007fb
X-Gm-Message-State: ALoCoQkFmJZzSJESleKVC8L4c+rmj+XJUreLMW4SGfK/vab5wjpvSGu7lOj+ldAvtBJ7vO5KjQx9
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2013 14:25:26 -0000

--047d7b3440f86a0b6104d5b007fb
Content-Type: text/plain; charset=ISO-8859-1

To make it clear - my suggestion is to add token_type_hint to the
introspection request. It can be from client to AS or from RS to AS.

Then AS can decide whether the provided token is valid or not and include
"valid" attribute in the introspection response.

Thanks & regards,
-Prabath

On Thu, Feb 14, 2013 at 7:52 PM, Prabath Siriwardena wrote:

> Both the client and the resource owner should be aware of the token type.
>
> My argument is, if the authorization server to decide whether the token is
> valid or not ( irrespective of who asked the question) - AS needs to know
> the token type - because to validate a token AS should know the token type.
>
> The token type could be, bearer or MAC or any other token type.
>
> Thanks & regards,
> -Prabath
>
>
> On Thu, Feb 14, 2013 at 7:33 PM, Justin Richer  wrote:
>
>>  What exactly are you suggesting be added to introspection? The
>> "token_type_hint" is from the client to the server, but what you've asked
>> for in terms of "token type" is from the server to the client. And there
>> was never an answer to what exactly is meant by "token type" in this case,
>> particularly because you seem to want to call out things like SAML and
>> Bearer as separate types.
>>
>>  -- Justin
>>
>>
>>
>> On 02/14/2013 06:59 AM, Prabath Siriwardena wrote:
>>
>> I noticed that the latest Token Revocation draft [1] has introduced the
>> parameter "token_type_hint". I would suggest the same here, as that would
>> make what is meant by "valid" much clear..
>>
>>  [1]: http://tools.ietf.org/html/draft-ietf-oauth-revocation-05
>>
>>  Thanks & regards,
>> -Prabath
>>
>> On Tue, Feb 12, 2013 at 9:35 PM, Prabath Siriwardena wrote:
>>
>>> Hi Justin,
>>>
>>>  I doubt whether valid_token would make a difference..?
>>>
>>>  My initial argument is what is the validation criteria..? Validation
>>> criteria depends on the token_type..
>>>
>>>  If we are talking only about metadata - then I believe "revoked",
>>> "expired" would be more meaningful..
>>>
>>>  Thanks & regards,
>>> -Prabath
>>>
>>>
>>>  On Tue, Feb 12, 2013 at 7:53 PM, Justin Richer wrote:
>>>
>>>>  OK, I can see the wisdom in changing this term.
>>>>
>>>> I picked "valid" because I wanted a simple "boolean" value that would
>>>> require no additional parsing or string-matching on the client's behalf,
>>>> and I'd like to stick with that. OAuth is built with the assumption that
>>>> clients need to be able to recover from invalid tokens at any stage, so I
>>>> think a simple yes/no is the right step here.
>>>>
>>>> That said, I think you're both right that "valid" seems to have caused
>>>> a bit of confusion. I don't want to go with "revoked" because I'd rather
>>>> have the "token is OK" be the positive boolean value.
>>>>
>>>> Would "valid_token" be more clear? Or do we need a different adjective
>>>> all together?
>>>>
>>>>  -- Justin
>>>>
>>>>
>>>> On 02/11/2013 08:02 PM, Richard Harrington wrote:
>>>>
>>>> Have you considered "status" instead of "valid"?  It could have values
>>>> like "active", "expired", and "revoked".
>>>>
>>>>  Is it worthwhile including the status of the client also?  For
>>>> example, a client application could be disabled, temporarily or
>>>> permanently, and thus disabling its access tokens as well.
>>>>
>>>>
>>>> On Feb 11, 2013, at 1:56 PM, Prabath Siriwardena 
>>>> wrote:
>>>>
>>>>  I guess confusion is with 'valid' parameter is in the response..
>>>>
>>>>  I thought this will be helpful to standardize the communication
>>>> between Resource Server and the Authorization Server..
>>>>
>>>>  I would suggest we completely remove "valid" from the response - or
>>>> define it much clearly..
>>>>
>>>>  May be can add "revoked" with a boolean attribute..
>>>>
>>>>  Thanks & regards,
>>>> -Prabath
>>>>
>>>> On Tue, Feb 12, 2013 at 3:19 AM, Justin Richer wrote:
>>>>
>>>>>
>>>>> On 02/08/2013 12:51 AM, Prabath Siriwardena wrote:
>>>>>
>>>>> Hi Justin,
>>>>>
>>>>>  I have couple of questions related to "valid" parameter...
>>>>>
>>>>>  This endpoint can be invoked by the Resource Server in runtime...
>>>>>
>>>>>
>>>>> That's correct.
>>>>>
>>>>>
>>>>>
>>>>>  In that case what is exactly meant by the "resource_id" in request ?
>>>>>
>>>>>
>>>>>  The resource_id field is a service-specific string that basically
>>>>> lets the resource server provide some context to the request to the auth
>>>>> server. There have been some other suggestions like client IP address, but
>>>>> I wanted to put this one in because it seemed to be a common theme. The
>>>>> client is trying to do *something* with the token, after all, and the
>>>>> rights, permissions, and metadata associated with the token could change
>>>>> based on that. Since the Introspection endpoint is all about getting that
>>>>> metadata back to the PR, this seemed like a good idea.
>>>>>
>>>>>
>>>>>
>>>>>  IMO a token to be valid depends on set of criteria based on it's
>>>>> type..
>>>>>
>>>>>  For a Bearer token..
>>>>>
>>>>>  1. Token should not be expired
>>>>> 2. Token should not be revoked.
>>>>> 3. The scope the token issued should match with the scope required for
>>>>> the resource.
>>>>>
>>>>>  For a MAC token...
>>>>>
>>>>>  1. Token not expired (mac id)
>>>>> 2. Token should not be revoked
>>>>> 3. The scope the token issued should match with the scope required for
>>>>> the resource.
>>>>> 4. HMAC check should be valid
>>>>>
>>>>>  There are similar conditions for SAML bearer too..
>>>>>
>>>>>
>>>>>  This isn't really true. The SAML bearer token is fully self-contained
>>>>> and doesn't change based on other parameters in the message, unlike MAC.
>>>>> Same with JWT. When it hands a SAML or JWT token to the AS, the PR has
>>>>> given *everything* the server needs to check that token's validity and use.
>>>>>
>>>>> MAC signatures change with every message, and they're done across
>>>>> several components of the HTTP message. Therefor, the HMAC check for MAC
>>>>> style tokens will still need to be done by the protected resource.
>>>>> Introspection would help in the case that the signature validated just
>>>>> fine, but the token might have expired. Or you need to know what scopes
>>>>> apply. Introspection isn't to fully validate the call to the protected
>>>>> resource -- if that were the case, the PR would have to send some kind of
>>>>> encapsulated version of the original request. Otherwise, the AS won't have
>>>>> all of the information it needs to check the MAC.
>>>>>
>>>>>
>>>>> I think what you're describing is ultimately *not* what the
>>>>> introspection endpoint is intended to do. If that's unclear from the
>>>>> document, can you please suggest text that would help clear the use case
>>>>> up? I wouldn't want it to be ambiguous.
>>>>>
>>>>>  -- Justin
>>>>>
>>>>>
>>>>>
>>>>>  Thanks & regards,
>>>>> -Prabath
>>>>>
>>>>>
>>>>> On Thu, Feb 7, 2013 at 10:30 PM, Justin Richer wrote:
>>>>>
>>>>>>  It validates the token, which would be either the token itself in
>>>>>> the case of Bearer or the token "id" part of something more complex like
>>>>>> MAC. It doesn't directly validate the usage of the token, that's still up
>>>>>> to the PR to do that.
>>>>>>
>>>>>> I nearly added a "token type" field in this draft, but held back
>>>>>> because there are several kinds of "token type" that people talk about in
>>>>>> OAuth. First, there's "Bearer" vs. "MAC" vs. "HOK", or what have you. Then
>>>>>> within Bearer you have "JWT" or "SAML" or "unstructured blob". Then you've
>>>>>> also got "access" vs. "refresh" and other flavors of token, like the
>>>>>> id_token in OpenID Connect.
>>>>>>
>>>>>> Thing is, the server running the introspection endpoint will probably
>>>>>> know *all* of these. But should it tell the client? If so, which of the
>>>>>> three, and what names should the fields be?
>>>>>>
>>>>>>  -- Justin
>>>>>>
>>>>>>
>>>>>> On 02/07/2013 11:26 AM, Prabath Siriwardena wrote:
>>>>>>
>>>>>> Okay.. I was thinking this could be used as a way to validate the
>>>>>> token as well. BTW even in this case shouldn't communicate the type of
>>>>>> token to AS? For example in the case of SAML profile - it could be SAML
>>>>>> token..
>>>>>>
>>>>>>  Thanks & regards,
>>>>>> -Prabath
>>>>>>
>>>>>> On Thu, Feb 7, 2013 at 8:39 PM, Justin Richer wrote:
>>>>>>
>>>>>>>  "valid" might not be the best term, but it's meant to be a field
>>>>>>> where the server says "yes this token is still good" or "no this token
>>>>>>> isn't good anymore". We could instead do this with HTTP codes or something
>>>>>>> but I went with a pure JSON response.
>>>>>>>
>>>>>>>  -- Justin
>>>>>>>
>>>>>>>
>>>>>>> On 02/06/2013 10:47 PM, Prabath Siriwardena wrote:
>>>>>>>
>>>>>>> Hi Justin,
>>>>>>>
>>>>>>>  I believe this is addressing one of the key missing part in OAuth
>>>>>>> 2.0...
>>>>>>>
>>>>>>>  One question - I guess this was discussed already...
>>>>>>>
>>>>>>>  In the spec - in the introspection response it has the attribute
>>>>>>> "valid" - this is basically the validity of the token provided in the
>>>>>>> request.
>>>>>>>
>>>>>>>  Validation criteria depends on the token and well as token type (
>>>>>>> Bearer, MAC..).
>>>>>>>
>>>>>>>  In the spec it seems like it's coupled with Bearer token type...
>>>>>>> But I guess, by adding "token_type" to the request we can remove this
>>>>>>> dependency.
>>>>>>>
>>>>>>>  WDYT..?
>>>>>>>
>>>>>>>  Thanks & regards,
>>>>>>> -Prabath
>>>>>>>
>>>>>>> On Thu, Feb 7, 2013 at 12:54 AM, Justin Richer wrote:
>>>>>>>
>>>>>>>>  Updated introspection draft based on recent comments. Changes
>>>>>>>> include:
>>>>>>>>
>>>>>>>>  - "scope" return parameter now follows RFC6749 format instead of
>>>>>>>> JSON array
>>>>>>>>  - "subject" -> "sub", and "audience" -> "aud", to be parallel with
>>>>>>>> JWT claims
>>>>>>>>  - clarified what happens if the authentication is bad
>>>>>>>>
>>>>>>>>  -- Justin
>>>>>>>>
>>>>>>>>
>>>>>>>> -------- Original Message --------  Subject: New Version
>>>>>>>> Notification for draft-richer-oauth-introspection-02.txt  Date: Wed,
>>>>>>>> 6 Feb 2013 11:24:20 -0800  From:   To:
>>>>>>>>  
>>>>>>>>
>>>>>>>> A new version of I-D, draft-richer-oauth-introspection-02.txt
>>>>>>>> has been successfully submitted by Justin Richer and posted to the
>>>>>>>> IETF repository.
>>>>>>>>
>>>>>>>> Filename:	 draft-richer-oauth-introspection
>>>>>>>> Revision:	 02
>>>>>>>> Title:		 OAuth Token Introspection
>>>>>>>> Creation date:	 2013-02-06
>>>>>>>> WG ID:		 Individual Submission
>>>>>>>> Number of pages: 6
>>>>>>>> URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
>>>>>>>> Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
>>>>>>>> Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-02
>>>>>>>> Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02
>>>>>>>>
>>>>>>>> Abstract:
>>>>>>>>    This specification defines a method for a client or protected
>>>>>>>>    resource to query an OAuth authorization server to determine meta-
>>>>>>>>    information about an OAuth token.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The IETF Secretariat
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> OAuth mailing list
>>>>>>>> OAuth@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  --
>>>>>>> Thanks & Regards,
>>>>>>> Prabath
>>>>>>>
>>>>>>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>>>>>>
>>>>>>> http://blog.facilelogin.com
>>>>>>> http://RampartFAQ.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>  --
>>>>>> Thanks & Regards,
>>>>>> Prabath
>>>>>>
>>>>>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>>>>>
>>>>>> http://blog.facilelogin.com
>>>>>> http://RampartFAQ.com
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>  --
>>>>> Thanks & Regards,
>>>>> Prabath
>>>>>
>>>>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>>>>
>>>>> http://blog.facilelogin.com
>>>>> http://RampartFAQ.com
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>  --
>>>> Thanks & Regards,
>>>> Prabath
>>>>
>>>>  Mobile : +94 71 809 6732
>>>>
>>>> http://blog.facilelogin.com
>>>> http://RampartFAQ.com
>>>>
>>>>  _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>
>>>
>>>  --
>>> Thanks & Regards,
>>> Prabath
>>>
>>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>>
>>> http://blog.facilelogin.com
>>> http://RampartFAQ.com
>>>
>>
>>
>>
>>  --
>> Thanks & Regards,
>> Prabath
>>
>>  Mobile : +94 71 809 6732
>>
>> http://blog.facilelogin.com
>> http://RampartFAQ.com
>>
>>
>>
>
>
> --
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com
>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.com

--047d7b3440f86a0b6104d5b007fb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

To make it clear - my suggestion is to add token_type_hint to the introspec=
tion request. It can be from client to AS or from RS to AS.
<=
div>Then AS can decide whether the provided token is valid or not and inclu=
de "valid" attribute in the introspection response.

Thanks & regards,-Prabath

On Thu, Feb 14, 2013 at 7:52 PM, Prabath Siriwardena <p=
rabath@wso2.com> wrote:

Both the client and the resource owner shoul=
d be aware of the token type.
My argument is, if the aut=
horization server to decide whether the token is valid or not ( irrespectiv=
e of who asked the question) - AS needs to know the token type - because to=
 validate a token AS should know the token type.

The token type could be, bearer or MAC or any other tok=
en type.

Thanks & regards,
-Prabath<=
div>

On Thu, Feb 14, 20=
13 at 7:33 PM, Justin Richer <jricher@mitre.org> wrote:

 =20
   =20
 =20

    What exactly are you suggesting be added to introspection? The
    "token_type_hint" is from the client to the server, but what =
you've
    asked for in terms of "token type" is from the server to the =
client.
    And there was never an answer to what exactly is meant by "token
    type" in this case, particularly because you seem to want to call
    out things like SAML and Bearer as separate types. 

    =A0-- Justin

    On 02/14/2013 06:59 AM, Prabath
      Siriwardena wrote:

     =20
      I noticed that the latest Token Revocation draft [1] has
      introduced the parameter "token_type_hint". I would suggest=
 the
      same here, as that would make what is meant by "valid" much
      clear..

      [1]:=A0http://tools.ietf.org/html/d=
raft-ietf-oauth-revocation-05

      Thanks & regards,
      -Prabath

        On Tue, Feb 12, 2013 at 9:35 PM,
          Prabath Siriwardena <prabath@wso2.com> wrote:

          Hi Justin,

            I doubt whether valid_token would make a difference..?

            My initial argument is what is the validation
              criteria..? Validation criteria depends on the
              token_type..

            If we are talking only about metadata - then I believe
              "revoked", "expired" would be more meanin=
gful..

            Thanks & regards,
            -Prabath

                    On Tue, Feb 12, 2013 at 7:53 PM, Justin Richer <jriche=
r@mitre.org>
                    wrote:

                       OK, I can
                        see the wisdom in changing this term. 

                        I picked "valid" because I wanted a simpl=
e
                        "boolean" value that would require no add=
itional
                        parsing or string-matching on the client's
                        behalf, and I'd like to stick with that. OAuth
                        is built with the assumption that clients need
                        to be able to recover from invalid tokens at any
                        stage, so I think a simple yes/no is the right
                        step here. 

                        That said, I think you're both right that
                        "valid" seems to have caused a bit of con=
fusion.
                        I don't want to go with "revoked" bec=
ause I'd
                        rather have the "token is OK" be the posi=
tive
                        boolean value. 

                        Would "valid_token" be more clear? Or do =
we need
                        a different adjective all together?

                            =A0-- Justin

                            On 02/11/2013 08:02 PM, Richard
                              Harrington wrote:

                              Have you considered "status" i=
nstead
                                of "valid"? =A0It could have valu=
es like
                                "active", "expired", an=
d "revoked".

                              Is it worthwhile including the status
                                of the client also? =A0For example, a
                                client application could be disabled,
                                temporarily or permanently, and thus
                                disabling its access tokens as well.

                                On Feb 11, 2013, at 1:56 PM, Prabath
                                Siriwardena <prabath@wso2.com>

                                wrote:

                                I guess confusion is with 'valid&#=
39;
                                  parameter is in the response..

                                  I thought this will be helpful
                                    to=A0standardize=A0the communication
                                    between Resource Server and the
                                    Authorization Server..

                                  I would suggest we completely
                                    remove "valid" from the respo=
nse -
                                    or define it much clearly..

                                  May be can add "revoked" w=
ith a
                                    boolean attribute..

                                  Thanks & regards,
                                  -Prabath

                                    On Tue, Feb
                                      12, 2013 at 3:19 AM, Justin Richer
                                      <jricher@mitre.org>
                                      wrote:

                                            On 02/08/2013 12:51 AM,
                                              Prabath Siriwardena wrote:

                                            Hi=A0Justin,

                                              I have couple of
                                                questions related to
                                                "valid" parameter=
...

                                              This endpoint can be
                                                invoked by the Resource
                                                Server in runtime...

                                          That's correct.

                                              In that case what is
                                                exactly meant by the
                                                "resource_id" in =
request
                                                ?

                                          The resource_id field is a
                                          service-specific string that
                                          basically lets the resource
                                          server provide some context to
                                          the request to the auth
                                          server. There have been some
                                          other suggestions like client
                                          IP address, but I wanted to
                                          put this one in because it
                                          seemed to be a common theme.
                                          The client is trying to do
                                          *something* with the token,
                                          after all, and the rights,
                                          permissions, and metadata
                                          associated with the token
                                          could change based on that.
                                          Since the Introspection
                                          endpoint is all about getting
                                          that metadata back to the PR,
                                          this seemed like a good idea.

                                              IMO a token to be
                                                valid depends on set of
                                                criteria based on it's
                                                type..

                                              For a Bearer token..

                                              1. Token should not
                                                be expired
                                              2. Token should not
                                                be revoked.
                                              3. The scope the
                                                token issued should
                                                match with the scope
                                                required for the
                                                resource.

                                              For a MAC token...

                                              1. Token not expired
                                                (mac id)
                                              2. Token should not
                                                be revoked
                                              3. The scope the
                                                token issued should
                                                match with the scope
                                                required for the
                                                resource.
                                              4. HMAC check should
                                                be valid

                                              There are similar
                                              conditions for SAML bearer
                                              too..

                                          This isn't really true. The
                                          SAML bearer token is fully
                                          self-contained and doesn't
                                          change based on other
                                          parameters in the message,
                                          unlike MAC. Same with JWT.
                                          When it hands a SAML or JWT
                                          token to the AS, the PR has
                                          given *everything* the server
                                          needs to check that token's
                                          validity and use. 

                                          MAC signatures change with
                                          every message, and they're
                                          done across several components
                                          of the HTTP message. Therefor,
                                          the HMAC check for MAC style
                                          tokens will still need to be
                                          done by the protected
                                          resource. Introspection would
                                          help in the case that the
                                          signature validated just fine,
                                          but the token might have
                                          expired. Or you need to know
                                          what scopes apply.
                                          Introspection isn't to fully
                                          validate the call to the
                                          protected resource -- if that
                                          were the case, the PR would
                                          have to send some kind of
                                          encapsulated version of the
                                          original request. Otherwise,
                                          the AS won't have all of the
                                          information it needs to check
                                          the MAC.

                                          I think what you're describin=
g
                                          is ultimately *not* what the
                                          introspection endpoint is
                                          intended to do. If that's
                                          unclear from the document, can
                                          you please suggest text that
                                          would help clear the use case
                                          up? I wouldn't want it to be
                                          ambiguous.

                                              =A0-- Justin

                                                Thanks &
                                                  regards,
                                                -Prabath

                                                  On
                                                    Thu, Feb 7, 2013 at
                                                    10:30 PM, Justin
                                                    Richer <jricher@mitre.=
org>
                                                    wrote:

                                                        It validates the
                                                        token, which
                                                        would be either
                                                        the token itself
                                                        in the case of
                                                        Bearer or the
                                                        token "id"=
; part
                                                        of something
                                                        more complex
                                                        like MAC. It
                                                        doesn't directl=
y
                                                        validate the
                                                        usage of the
                                                        token, that's
                                                        still up to the
                                                        PR to do that.

                                                        I nearly added a
                                                        "token type&qu=
ot;
                                                        field in this
                                                        draft, but held
                                                        back because
                                                        there are
                                                        several kinds of
                                                        "token type&qu=
ot;
                                                        that people talk
                                                        about in OAuth.
                                                        First, there's
                                                        "Bearer" =
vs.
                                                        "MAC" vs.=
 "HOK",
                                                        or what have
                                                        you. Then within
                                                        Bearer you have
                                                        "JWT" or =
"SAML"
                                                        or "unstructur=
ed
                                                        blob". Then
                                                        you've also got
                                                        "access" =
vs.
                                                        "refresh"=
 and
                                                        other flavors of
                                                        token, like the
                                                        id_token in
                                                        OpenID Connect.

                                                        Thing is, the
                                                        server running
                                                        the
                                                        introspection
                                                        endpoint will
                                                        probably know
                                                        *all* of these.
                                                        But should it
                                                        tell the client?
                                                        If so, which of
                                                        the three, and
                                                        what names
                                                        should the
                                                        fields be?

                                                          =A0-- Justin

                                                          On
                                                          02/07/2013
                                                          11:26 AM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          Okay.. I was
                                                          thinking this
                                                          could be used
                                                          as a way to
                                                          validate the
                                                          token as well.
                                                          BTW even in
                                                          this case
                                                          shouldn't
                                                          communicate
                                                          the type of
                                                          token to AS?
                                                          For example in
                                                          the case of
                                                          SAML profile -
                                                          it could be
                                                          SAML token..

                                                          Thanks
                                                          & regards,
                                                          -Prabath

                                                          On
                                                          Thu, Feb 7,
                                                          2013 at 8:39
                                                          PM, Justin
                                                          Richer <jricher=
@mitre.org>
                                                          wrote:

                                                          "valid"=
 might
                                                          not be the
                                                          best term, but
                                                          it's meant to
                                                          be a field
                                                          where the
                                                          server says
                                                          "yes this
                                                          token is still
                                                          good" or &qu=
ot;no
                                                          this token
                                                          isn't good
                                                          anymore". We
                                                          could instead
                                                          do this with
                                                          HTTP codes or
                                                          something but
                                                          I went with a
                                                          pure JSON
                                                          response.

                                                          =A0-- Justin

                                                          On
                                                          02/06/2013
                                                          10:47 PM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          Hi Justin,

                                                          I believe
                                                          this is
                                                          addressing one
                                                          of the key
                                                          missing part
                                                          in OAuth
                                                          2.0...

                                                          One
                                                          question - I
                                                          guess this was
                                                          discussed
                                                          already...

                                                          In the
                                                          spec - in the
                                                          introspection
                                                          response it
                                                          has the
                                                          attribute
                                                          "valid"=
 - this
                                                          is basically
                                                          the validity
                                                          of the token
                                                          provided in
                                                          the request.

                                                          Validation=
=A0criteria

                                                          depends on the
                                                          token and well
                                                          as token type
                                                          ( Bearer,
                                                          MAC..).

                                                          In the
                                                          spec it seems
                                                          like it's
                                                          coupled with
                                                          Bearer token
                                                          type... But I
                                                          guess, by
                                                          adding
                                                          "token_type&=
quot;
                                                          to the request
                                                          we can remove
                                                          this
                                                          dependency.

                                                          WDYT..?

                                                          Thanks
                                                          & regards,
                                                          -Prabath=A0<=
/div>

                                                          On

                                                          Thu, Feb 7,
                                                          2013 at 12:54
                                                          AM, Justin
                                                          Richer <jricher=
@mitre.org>
                                                          wrote:

                                                          Updated
                                                          introspection
                                                          draft based on
                                                          recent
                                                          comments.
                                                          Changes
                                                          include:

                                                          =A0- "scope&=
quot;
                                                          return
                                                          parameter now
                                                          follows
                                                          RFC6749 format
                                                          instead of
                                                          JSON array

                                                          =A0- "subjec=
t"
                                                          -> "sub&q=
uot;,
                                                          and "audienc=
e"
                                                          -> "aud&q=
uot;,
                                                          to be parallel
                                                          with JWT
                                                          claims

                                                          =A0- clarified
                                                          what happens
                                                          if the
                                                          authentication
                                                          is bad

                                                          =A0-- Justin

                                                          --------
                                                          Original
                                                          Message
                                                          --------

                                                          Subject: 
                                                          New
                                                          Version
                                                          Notification
                                                          for
                                                          draft-richer-oaut=
h-introspection-02.txt

                                                          Date: 
                                                          Wed, 6 Feb
                                                          2013 11:24:20
                                                          -0800

                                                          From: 
                                                          <internet-drafts@ietf.o=
rg>

                                                          To: 
                                                          <jricher@mitre.org>

                                                          A new versio=
n of I-D, draft-richer-oauth-introspection-02.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 02
Title:		 OAuth Token Introspection
Creation date:	 2013-02-06
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/interne=
t-drafts/draft-richer-oauth-introspection-02.txt
Status:          http://datatracker.ietf.org/doc/draft-=
richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-=
oauth-introspection-02
Diff:            http://www.ietf.org/rfcdiff?url2=
=3Ddraft-richer-oauth-introspection-02

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.

                                                                           =
      =20

The IETF Secretariat

_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

                                                          https://www.ietf.o=
rg/mailman/listinfo/oauth

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94
                                                          71 809 6732=
=A0

                                                          http://blog.facilelogin.com
                                                          http://RampartFAQ.com

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94
                                                          71 809 6732=
=A0

                                                          http://blog.facilelogin.com
                                                          http://RampartFAQ.com

                                                  -- 

                                                  Thanks & Regards,

                                                  Prabath

                                                  Mobile : +94

                                                      71 809 6732=A0

                                                    http://blog.facilelogin.com

                                                    http://RampartFAQ.com

                                    -- 

                                    Thanks & Regards,

                                    Prabath

                                    Mobile : +94 71 809 6732=
=A0

                                      http://blog.facilelogin.com

                                      http://RampartFAQ.com

                                ________________________________=
_______________

                                  OAuth mailing list

                                  OAuth@ietf.org

                                  https://www.ietf.org/mailman/listinf=
o/oauth

                  -- 

                  Thanks & Regards,

                  Prabath

                  Mobile : +94 71 809
                      6732=A0

                    http://blog.facilelogin.com

                    htt=
p://RampartFAQ.com

        -- 

        Thanks & Regards,

        Prabath

        Mobile : +94 71 809 6732=A0

          http://=
blog.facilelogin.com

          http://Rampar=
tFAQ.com

-- 
Thanks &=
 Regards,
Prabath
Mobile : +94 71 809 6732=
=A0

http://blog.f=
acilelogin.com

http://RampartFAQ.com

-- 
Thanks &=
 Regards,
Prabath
Mobile : +94 71 809 6732=A0

=
http://blog.facil=
elogin.com

http://RampartFAQ.com

--047d7b3440f86a0b6104d5b007fb--

From jricher@mitre.org  Thu Feb 14 06:25:46 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2ECE21F882C for ; Thu, 14 Feb 2013 06:25:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.569
X-Spam-Level: 
X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.029,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gs2W6alkdcr8 for ; Thu, 14 Feb 2013 06:25:40 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9D86D21F882E for ; Thu, 14 Feb 2013 06:25:39 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 55ED51F2C9F; Thu, 14 Feb 2013 09:25:38 -0500 (EST)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 39CC41F2C88; Thu, 14 Feb 2013 09:25:38 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 14 Feb 2013 09:25:36 -0500
Message-ID: <511CF3B3.7010502@mitre.org>
Date: Thu, 14 Feb 2013 09:24:51 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Prabath Siriwardena 
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com> <5112AE0B.1080501@mitre.org>  <5113C3AA.1040701@mitre.org>  <5113DDB2.7060805@mitre.org>  <51196777.6000502@mitre.org>   <511A5062.5010108@mitre.org>   <511CEEAA.3030801@mitre.org> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030105000502060207030806"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2013 14:25:46 -0000

--------------030105000502060207030806
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

OK, so you mean "token type" as defined by the "token_type" field coming 
back from the Token Endpoint, and *not* as defined by the 
"token_type_hint" in the revocation draft. Right?

The RO probably won't know or care about the token type. The client and 
AS have to know because they need to know how to use and provision it, 
respectively. The RS needs to know the type to be able to validate the 
call at some level.

I'm not opposed to token types being returned, I just want people to be 
very clear about what they mean by "token type" when they say it.

  -- Justin

On 02/14/2013 09:22 AM, Prabath Siriwardena wrote:
> Both the client and the resource owner should be aware of the token type.
>
> My argument is, if the authorization server to decide whether the 
> token is valid or not ( irrespective of who asked the question) - AS 
> needs to know the token type - because to validate a token AS should 
> know the token type.
>
> The token type could be, bearer or MAC or any other token type.
>
> Thanks & regards,
> -Prabath
>
> On Thu, Feb 14, 2013 at 7:33 PM, Justin Richer  > wrote:
>
>     What exactly are you suggesting be added to introspection? The
>     "token_type_hint" is from the client to the server, but what
>     you've asked for in terms of "token type" is from the server to
>     the client. And there was never an answer to what exactly is meant
>     by "token type" in this case, particularly because you seem to
>     want to call out things like SAML and Bearer as separate types.
>
>      -- Justin
>
>
>
>     On 02/14/2013 06:59 AM, Prabath Siriwardena wrote:
>>     I noticed that the latest Token Revocation draft [1] has
>>     introduced the parameter "token_type_hint". I would suggest the
>>     same here, as that would make what is meant by "valid" much clear..
>>
>>     [1]: http://tools.ietf.org/html/draft-ietf-oauth-revocation-05
>>
>>     Thanks & regards,
>>     -Prabath
>>
>>     On Tue, Feb 12, 2013 at 9:35 PM, Prabath Siriwardena
>>     > wrote:
>>
>>         Hi Justin,
>>
>>         I doubt whether valid_token would make a difference..?
>>
>>         My initial argument is what is the validation criteria..?
>>         Validation criteria depends on the token_type..
>>
>>         If we are talking only about metadata - then I believe
>>         "revoked", "expired" would be more meaningful..
>>
>>         Thanks & regards,
>>         -Prabath
>>
>>
>>         On Tue, Feb 12, 2013 at 7:53 PM, Justin Richer
>>         > wrote:
>>
>>             OK, I can see the wisdom in changing this term.
>>
>>             I picked "valid" because I wanted a simple "boolean"
>>             value that would require no additional parsing or
>>             string-matching on the client's behalf, and I'd like to
>>             stick with that. OAuth is built with the assumption that
>>             clients need to be able to recover from invalid tokens at
>>             any stage, so I think a simple yes/no is the right step
>>             here.
>>
>>             That said, I think you're both right that "valid" seems
>>             to have caused a bit of confusion. I don't want to go
>>             with "revoked" because I'd rather have the "token is OK"
>>             be the positive boolean value.
>>
>>             Would "valid_token" be more clear? Or do we need a
>>             different adjective all together?
>>
>>              -- Justin
>>
>>
>>             On 02/11/2013 08:02 PM, Richard Harrington wrote:
>>>             Have you considered "status" instead of "valid"?  It
>>>             could have values like "active", "expired", and "revoked".
>>>
>>>             Is it worthwhile including the status of the client
>>>             also?  For example, a client application could be
>>>             disabled, temporarily or permanently, and thus disabling
>>>             its access tokens as well.
>>>
>>>
>>>             On Feb 11, 2013, at 1:56 PM, Prabath Siriwardena
>>>             > wrote:
>>>
>>>>             I guess confusion is with 'valid' parameter is in the
>>>>             response..
>>>>
>>>>             I thought this will be helpful to standardize the
>>>>             communication between Resource Server and the
>>>>             Authorization Server..
>>>>
>>>>             I would suggest we completely remove "valid" from the
>>>>             response - or define it much clearly..
>>>>
>>>>             May be can add "revoked" with a boolean attribute..
>>>>
>>>>             Thanks & regards,
>>>>             -Prabath
>>>>
>>>>             On Tue, Feb 12, 2013 at 3:19 AM, Justin Richer
>>>>             > wrote:
>>>>
>>>>
>>>>                 On 02/08/2013 12:51 AM, Prabath Siriwardena wrote:
>>>>>                 Hi Justin,
>>>>>
>>>>>                 I have couple of questions related to "valid"
>>>>>                 parameter...
>>>>>
>>>>>                 This endpoint can be invoked by the Resource
>>>>>                 Server in runtime...
>>>>
>>>>                 That's correct.
>>>>
>>>>
>>>>>
>>>>>                 In that case what is exactly meant by the
>>>>>                 "resource_id" in request ?
>>>>
>>>>                 The resource_id field is a service-specific string
>>>>                 that basically lets the resource server provide
>>>>                 some context to the request to the auth server.
>>>>                 There have been some other suggestions like client
>>>>                 IP address, but I wanted to put this one in because
>>>>                 it seemed to be a common theme. The client is
>>>>                 trying to do *something* with the token, after all,
>>>>                 and the rights, permissions, and metadata
>>>>                 associated with the token could change based on
>>>>                 that. Since the Introspection endpoint is all about
>>>>                 getting that metadata back to the PR, this seemed
>>>>                 like a good idea.
>>>>
>>>>
>>>>>
>>>>>                 IMO a token to be valid depends on set of criteria
>>>>>                 based on it's type..
>>>>>
>>>>>                 For a Bearer token..
>>>>>
>>>>>                 1. Token should not be expired
>>>>>                 2. Token should not be revoked.
>>>>>                 3. The scope the token issued should match with
>>>>>                 the scope required for the resource.
>>>>>
>>>>>                 For a MAC token...
>>>>>
>>>>>                 1. Token not expired (mac id)
>>>>>                 2. Token should not be revoked
>>>>>                 3. The scope the token issued should match with
>>>>>                 the scope required for the resource.
>>>>>                 4. HMAC check should be valid
>>>>>
>>>>>                 There are similar conditions for SAML bearer too..
>>>>
>>>>                 This isn't really true. The SAML bearer token is
>>>>                 fully self-contained and doesn't change based on
>>>>                 other parameters in the message, unlike MAC. Same
>>>>                 with JWT. When it hands a SAML or JWT token to the
>>>>                 AS, the PR has given *everything* the server needs
>>>>                 to check that token's validity and use.
>>>>
>>>>                 MAC signatures change with every message, and
>>>>                 they're done across several components of the HTTP
>>>>                 message. Therefor, the HMAC check for MAC style
>>>>                 tokens will still need to be done by the protected
>>>>                 resource. Introspection would help in the case that
>>>>                 the signature validated just fine, but the token
>>>>                 might have expired. Or you need to know what scopes
>>>>                 apply. Introspection isn't to fully validate the
>>>>                 call to the protected resource -- if that were the
>>>>                 case, the PR would have to send some kind of
>>>>                 encapsulated version of the original request.
>>>>                 Otherwise, the AS won't have all of the information
>>>>                 it needs to check the MAC.
>>>>
>>>>
>>>>                 I think what you're describing is ultimately *not*
>>>>                 what the introspection endpoint is intended to do.
>>>>                 If that's unclear from the document, can you please
>>>>                 suggest text that would help clear the use case up?
>>>>                 I wouldn't want it to be ambiguous.
>>>>
>>>>                  -- Justin
>>>>
>>>>
>>>>>
>>>>>                 Thanks & regards,
>>>>>                 -Prabath
>>>>>
>>>>>
>>>>>                 On Thu, Feb 7, 2013 at 10:30 PM, Justin Richer
>>>>>                 > wrote:
>>>>>
>>>>>                     It validates the token, which would be either
>>>>>                     the token itself in the case of Bearer or the
>>>>>                     token "id" part of something more complex like
>>>>>                     MAC. It doesn't directly validate the usage of
>>>>>                     the token, that's still up to the PR to do that.
>>>>>
>>>>>                     I nearly added a "token type" field in this
>>>>>                     draft, but held back because there are several
>>>>>                     kinds of "token type" that people talk about
>>>>>                     in OAuth. First, there's "Bearer" vs. "MAC"
>>>>>                     vs. "HOK", or what have you. Then within
>>>>>                     Bearer you have "JWT" or "SAML" or
>>>>>                     "unstructured blob". Then you've also got
>>>>>                     "access" vs. "refresh" and other flavors of
>>>>>                     token, like the id_token in OpenID Connect.
>>>>>
>>>>>                     Thing is, the server running the introspection
>>>>>                     endpoint will probably know *all* of these.
>>>>>                     But should it tell the client? If so, which of
>>>>>                     the three, and what names should the fields be?
>>>>>
>>>>>                      -- Justin
>>>>>
>>>>>
>>>>>                     On 02/07/2013 11:26 AM, Prabath Siriwardena wrote:
>>>>>>                     Okay.. I was thinking this could be used as a
>>>>>>                     way to validate the token as well. BTW even
>>>>>>                     in this case shouldn't communicate the type
>>>>>>                     of token to AS? For example in the case of
>>>>>>                     SAML profile - it could be SAML token..
>>>>>>
>>>>>>                     Thanks & regards,
>>>>>>                     -Prabath
>>>>>>
>>>>>>                     On Thu, Feb 7, 2013 at 8:39 PM, Justin Richer
>>>>>>                     >>>>>                     > wrote:
>>>>>>
>>>>>>                         "valid" might not be the best term, but
>>>>>>                         it's meant to be a field where the server
>>>>>>                         says "yes this token is still good" or
>>>>>>                         "no this token isn't good anymore". We
>>>>>>                         could instead do this with HTTP codes or
>>>>>>                         something but I went with a pure JSON
>>>>>>                         response.
>>>>>>
>>>>>>                          -- Justin
>>>>>>
>>>>>>
>>>>>>                         On 02/06/2013 10:47 PM, Prabath
>>>>>>                         Siriwardena wrote:
>>>>>>>                         Hi Justin,
>>>>>>>
>>>>>>>                         I believe this is addressing one of the
>>>>>>>                         key missing part in OAuth 2.0...
>>>>>>>
>>>>>>>                         One question - I guess this was
>>>>>>>                         discussed already...
>>>>>>>
>>>>>>>                         In the spec - in the introspection
>>>>>>>                         response it has the attribute "valid" -
>>>>>>>                         this is basically the validity of the
>>>>>>>                         token provided in the request.
>>>>>>>
>>>>>>>                         Validation criteria depends on the token
>>>>>>>                         and well as token type ( Bearer, MAC..).
>>>>>>>
>>>>>>>                         In the spec it seems like it's coupled
>>>>>>>                         with Bearer token type... But I guess,
>>>>>>>                         by adding "token_type" to the request we
>>>>>>>                         can remove this dependency.
>>>>>>>
>>>>>>>                         WDYT..?
>>>>>>>
>>>>>>>                         Thanks & regards,
>>>>>>>                         -Prabath
>>>>>>>
>>>>>>>                         On Thu, Feb 7, 2013 at 12:54 AM, Justin
>>>>>>>                         Richer >>>>>>                         > wrote:
>>>>>>>
>>>>>>>                             Updated introspection draft based on
>>>>>>>                             recent comments. Changes include:
>>>>>>>
>>>>>>>                              - "scope" return parameter now
>>>>>>>                             follows RFC6749 format instead of
>>>>>>>                             JSON array
>>>>>>>                              - "subject" -> "sub", and
>>>>>>>                             "audience" -> "aud", to be parallel
>>>>>>>                             with JWT claims
>>>>>>>                              - clarified what happens if the
>>>>>>>                             authentication is bad
>>>>>>>
>>>>>>>                              -- Justin
>>>>>>>
>>>>>>>
>>>>>>>                             -------- Original Message --------
>>>>>>>                             Subject: 	New Version Notification
>>>>>>>                             for
>>>>>>>                             draft-richer-oauth-introspection-02.txt
>>>>>>>                             Date: 	Wed, 6 Feb 2013 11:24:20 -0800
>>>>>>>                             From: 	
>>>>>>>                             
>>>>>>>                             To: 	
>>>>>>>                             
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                             A new version of I-D, draft-richer-oauth-introspection-02.txt
>>>>>>>                             has been successfully submitted by Justin Richer and posted to the
>>>>>>>                             IETF repository.
>>>>>>>
>>>>>>>                             Filename:	 draft-richer-oauth-introspection
>>>>>>>                             Revision:	 02
>>>>>>>                             Title:		 OAuth Token Introspection
>>>>>>>                             Creation date:	 2013-02-06
>>>>>>>                             WG ID:		 Individual Submission
>>>>>>>                             Number of pages: 6
>>>>>>>                             URL:http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
>>>>>>>                             Status:http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
>>>>>>>                             Htmlized:http://tools.ietf.org/html/draft-richer-oauth-introspection-02
>>>>>>>                             Diff:http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02
>>>>>>>
>>>>>>>                             Abstract:
>>>>>>>                                 This specification defines a method for a client or protected
>>>>>>>                                 resource to query an OAuth authorization server to determine meta-
>>>>>>>                                 information about an OAuth token.
>>>>>>>
>>>>>>>
>>>>>>>                                                                                                                
>>>>>>>
>>>>>>>
>>>>>>>                             The IETF Secretariat
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                             _______________________________________________
>>>>>>>                             OAuth mailing list
>>>>>>>                             OAuth@ietf.org 
>>>>>>>                             https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                         -- 
>>>>>>>                         Thanks & Regards,
>>>>>>>                         Prabath
>>>>>>>
>>>>>>>                         Mobile : +94 71 809 6732
>>>>>>>                         
>>>>>>>
>>>>>>>                         http://blog.facilelogin.com
>>>>>>>                         http://RampartFAQ.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>                     -- 
>>>>>>                     Thanks & Regards,
>>>>>>                     Prabath
>>>>>>
>>>>>>                     Mobile : +94 71 809 6732
>>>>>>                     
>>>>>>
>>>>>>                     http://blog.facilelogin.com
>>>>>>                     http://RampartFAQ.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>                 -- 
>>>>>                 Thanks & Regards,
>>>>>                 Prabath
>>>>>
>>>>>                 Mobile : +94 71 809 6732
>>>>>                 
>>>>>
>>>>>                 http://blog.facilelogin.com
>>>>>                 http://RampartFAQ.com
>>>>
>>>>
>>>>
>>>>
>>>>             -- 
>>>>             Thanks & Regards,
>>>>             Prabath
>>>>
>>>>             Mobile : +94 71 809 6732 
>>>>
>>>>             http://blog.facilelogin.com
>>>>             http://RampartFAQ.com
>>>>             _______________________________________________
>>>>             OAuth mailing list
>>>>             OAuth@ietf.org 
>>>>             https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>>         -- 
>>         Thanks & Regards,
>>         Prabath
>>
>>         Mobile : +94 71 809 6732 
>>
>>         http://blog.facilelogin.com
>>         http://RampartFAQ.com
>>
>>
>>
>>
>>     -- 
>>     Thanks & Regards,
>>     Prabath
>>
>>     Mobile : +94 71 809 6732 
>>
>>     http://blog.facilelogin.com
>>     http://RampartFAQ.com
>
>
>
>
> -- 
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com

--------------030105000502060207030806
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

    OK, so you mean "token type" as defined by the "token_type" field
    coming back from the Token Endpoint, and *not* as defined by the
    "token_type_hint" in the revocation draft. Right?

    The RO probably won't know or care about the token type. The client
    and AS have to know because they need to know how to use and
    provision it, respectively. The RS needs to know the type to be able
    to validate the call at some level.

    I'm not opposed to token types being returned, I just want people to
    be very clear about what they mean by "token type" when they say it.

     -- Justin

    On 02/14/2013 09:22 AM, Prabath
      Siriwardena wrote:

      Both the client and the resource owner should be aware of the
      token type.

      My argument is, if the authorization server to decide whether
        the token is valid or not ( irrespective of who asked the
        question) - AS needs to know the token type - because to
        validate a token AS should know the token type.

      The token type could be, bearer or MAC or any other token
        type.

      Thanks & regards,
      -Prabath

        On Thu, Feb 14, 2013 at 7:33 PM, Justin
          Richer <jricher@mitre.org>
          wrote:

             What exactly are you
              suggesting be added to introspection? The
              "token_type_hint" is from the client to the server, but
              what you've asked for in terms of "token type" is from the
              server to the client. And there was never an answer to
              what exactly is meant by "token type" in this case,
              particularly because you seem to want to call out things
              like SAML and Bearer as separate types. 

                   -- Justin

                  On 02/14/2013 06:59 AM, Prabath Siriwardena
                    wrote:

                   I noticed that the latest
                    Token Revocation draft [1] has introduced the
                    parameter "token_type_hint". I would suggest the
                    same here, as that would make what is meant by
                    "valid" much clear..

                    [1]: http://tools.ietf.org/html/draft-ietf-oauth-revocation-05

                    Thanks & regards,
                    -Prabath

                      On Tue, Feb 12, 2013 at
                        9:35 PM, Prabath Siriwardena <prabath@wso2.com>
                        wrote:

                        Hi Justin,

                          I doubt whether valid_token would make a
                            difference..?

                          My initial argument is what is the
                            validation criteria..? Validation criteria
                            depends on the token_type..

                          If we are talking only about metadata -
                            then I believe "revoked", "expired" would be
                            more meaningful..

                          Thanks & regards,
                          -Prabath

                                 On Tue, Feb
                                  12, 2013 at 7:53 PM, Justin Richer <jricher@mitre.org>
                                  wrote:

                                     OK, I can see the
                                      wisdom in changing this term. 

                                      I picked "valid" because I wanted
                                      a simple "boolean" value that
                                      would require no additional
                                      parsing or string-matching on the
                                      client's behalf, and I'd like to
                                      stick with that. OAuth is built
                                      with the assumption that clients
                                      need to be able to recover from
                                      invalid tokens at any stage, so I
                                      think a simple yes/no is the right
                                      step here. 

                                      That said, I think you're both
                                      right that "valid" seems to have
                                      caused a bit of confusion. I don't
                                      want to go with "revoked" because
                                      I'd rather have the "token is OK"
                                      be the positive boolean value. 

                                      Would "valid_token" be more clear?
                                      Or do we need a different
                                      adjective all together?

                                           -- Justin

                                          On 02/11/2013 08:02 PM,
                                            Richard Harrington wrote:

                                            Have you considered
                                              "status" instead of
                                              "valid"?  It could have
                                              values like "active",
                                              "expired", and "revoked".

                                            Is it worthwhile
                                              including the status of
                                              the client also?  For
                                              example, a client
                                              application could be
                                              disabled, temporarily or
                                              permanently, and thus
                                              disabling its access
                                              tokens as well.

                                              On Feb 11, 2013, at 1:56
                                              PM, Prabath Siriwardena
                                              <prabath@wso2.com>

                                              wrote:

                                              I guess confusion is
                                                with 'valid' parameter
                                                is in the response..

                                                I thought this will
                                                  be helpful
                                                  to standardize the
                                                  communication between
                                                  Resource Server and
                                                  the Authorization
                                                  Server..

                                                I would suggest we
                                                  completely remove
                                                  "valid" from the
                                                  response - or define
                                                  it much clearly..

                                                May be can add
                                                  "revoked" with a
                                                  boolean attribute..

                                                Thanks &
                                                  regards,
                                                -Prabath

                                                  On
                                                    Tue, Feb 12, 2013 at
                                                    3:19 AM, Justin
                                                    Richer <jricher@mitre.org>
                                                    wrote:

                                                          On
                                                          02/08/2013
                                                          12:51 AM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          Hi Justin,

                                                          I have
                                                          couple of
                                                          questions
                                                          related to
                                                          "valid"
                                                          parameter...

                                                          This
                                                          endpoint can
                                                          be invoked by
                                                          the Resource
                                                          Server in
                                                          runtime...

                                                        That's correct.

                                                          In that
                                                          case what is
                                                          exactly meant
                                                          by the
                                                          "resource_id"
                                                          in request ?

                                                        The resource_id
                                                        field is a
                                                        service-specific
                                                        string that
                                                        basically lets
                                                        the resource
                                                        server provide
                                                        some context to
                                                        the request to
                                                        the auth server.
                                                        There have been
                                                        some other
                                                        suggestions like
                                                        client IP
                                                        address, but I
                                                        wanted to put
                                                        this one in
                                                        because it
                                                        seemed to be a
                                                        common theme.
                                                        The client is
                                                        trying to do
                                                        *something* with
                                                        the token, after
                                                        all, and the
                                                        rights,
                                                        permissions, and
                                                        metadata
                                                        associated with
                                                        the token could
                                                        change based on
                                                        that. Since the
                                                        Introspection
                                                        endpoint is all
                                                        about getting
                                                        that metadata
                                                        back to the PR,
                                                        this seemed like
                                                        a good idea.

                                                          IMO a
                                                          token to be
                                                          valid depends
                                                          on set of
                                                          criteria based
                                                          on it's type..

                                                          For a
                                                          Bearer token..

                                                          1. Token
                                                          should not be
                                                          expired
                                                          2. Token
                                                          should not be
                                                          revoked.
                                                          3. The
                                                          scope the
                                                          token issued
                                                          should match
                                                          with the scope
                                                          required for
                                                          the resource.

                                                          For a MAC
                                                          token...

                                                          1. Token
                                                          not expired
                                                          (mac id)
                                                          2. Token
                                                          should not be
                                                          revoked
                                                          3. The
                                                          scope the
                                                          token issued
                                                          should match
                                                          with the scope
                                                          required for
                                                          the resource.
                                                          4. HMAC
                                                          check should
                                                          be valid

                                                          There are
                                                          similar
                                                          conditions for
                                                          SAML bearer
                                                          too..

                                                        This isn't
                                                        really true. The
                                                        SAML bearer
                                                        token is fully
                                                        self-contained
                                                        and doesn't
                                                        change based on
                                                        other parameters
                                                        in the message,
                                                        unlike MAC. Same
                                                        with JWT. When
                                                        it hands a SAML
                                                        or JWT token to
                                                        the AS, the PR
                                                        has given
                                                        *everything* the
                                                        server needs to
                                                        check that
                                                        token's validity
                                                        and use. 

                                                        MAC signatures
                                                        change with
                                                        every message,
                                                        and they're done
                                                        across several
                                                        components of
                                                        the HTTP
                                                        message.
                                                        Therefor, the
                                                        HMAC check for
                                                        MAC style tokens
                                                        will still need
                                                        to be done by
                                                        the protected
                                                        resource.
                                                        Introspection
                                                        would help in
                                                        the case that
                                                        the signature
                                                        validated just
                                                        fine, but the
                                                        token might have
                                                        expired. Or you
                                                        need to know
                                                        what scopes
                                                        apply.
                                                        Introspection
                                                        isn't to fully
                                                        validate the
                                                        call to the
                                                        protected
                                                        resource -- if
                                                        that were the
                                                        case, the PR
                                                        would have to
                                                        send some kind
                                                        of encapsulated
                                                        version of the
                                                        original
                                                        request.
                                                        Otherwise, the
                                                        AS won't have
                                                        all of the
                                                        information it
                                                        needs to check
                                                        the MAC.

                                                        I think what
                                                        you're
                                                        describing is
                                                        ultimately *not*
                                                        what the
                                                        introspection
                                                        endpoint is
                                                        intended to do.
                                                        If that's
                                                        unclear from the
                                                        document, can
                                                        you please
                                                        suggest text
                                                        that would help
                                                        clear the use
                                                        case up? I
                                                        wouldn't want it
                                                        to be ambiguous.

                                                           -- Justin

                                                          Thanks
                                                          & regards,
                                                          -Prabath

                                                          On

                                                          Thu, Feb 7,
                                                          2013 at 10:30
                                                          PM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:

                                                          It validates
                                                          the token,
                                                          which would be
                                                          either the
                                                          token itself
                                                          in the case of
                                                          Bearer or the
                                                          token "id"
                                                          part of
                                                          something more
                                                          complex like
                                                          MAC. It
                                                          doesn't
                                                          directly
                                                          validate the
                                                          usage of the
                                                          token, that's
                                                          still up to
                                                          the PR to do
                                                          that.

                                                          I nearly added
                                                          a "token type"
                                                          field in this
                                                          draft, but
                                                          held back
                                                          because there
                                                          are several
                                                          kinds of
                                                          "token type"
                                                          that people
                                                          talk about in
                                                          OAuth. First,
                                                          there's
                                                          "Bearer" vs.
                                                          "MAC" vs.
                                                          "HOK", or what
                                                          have you. Then
                                                          within Bearer
                                                          you have "JWT"
                                                          or "SAML" or
                                                          "unstructured
                                                          blob". Then
                                                          you've also
                                                          got "access"
                                                          vs. "refresh"
                                                          and other
                                                          flavors of
                                                          token, like
                                                          the id_token
                                                          in OpenID
                                                          Connect. 

                                                          Thing is, the
                                                          server running
                                                          the
                                                          introspection
                                                          endpoint will
                                                          probably know
                                                          *all* of
                                                          these. But
                                                          should it tell
                                                          the client? If
                                                          so, which of
                                                          the three, and
                                                          what names
                                                          should the
                                                          fields be?

                                                           -- Justin

                                                          On
                                                          02/07/2013
                                                          11:26 AM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          Okay.. I was
                                                          thinking this
                                                          could be used
                                                          as a way to
                                                          validate the
                                                          token as well.
                                                          BTW even in
                                                          this case
                                                          shouldn't
                                                          communicate
                                                          the type of
                                                          token to AS?
                                                          For example in
                                                          the case of
                                                          SAML profile -
                                                          it could be
                                                          SAML token..

                                                          Thanks
                                                          & regards,
                                                          -Prabath

                                                          On

                                                          Thu, Feb 7,
                                                          2013 at 8:39
                                                          PM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:

                                                          "valid" might
                                                          not be the
                                                          best term, but
                                                          it's meant to
                                                          be a field
                                                          where the
                                                          server says
                                                          "yes this
                                                          token is still
                                                          good" or "no
                                                          this token
                                                          isn't good
                                                          anymore". We
                                                          could instead
                                                          do this with
                                                          HTTP codes or
                                                          something but
                                                          I went with a
                                                          pure JSON
                                                          response.

                                                           -- Justin

                                                          On
                                                          02/06/2013
                                                          10:47 PM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          Hi Justin,

                                                          I believe
                                                          this is
                                                          addressing one
                                                          of the key
                                                          missing part
                                                          in OAuth
                                                          2.0...

                                                          One
                                                          question - I
                                                          guess this was
                                                          discussed
                                                          already...

                                                          In the
                                                          spec - in the
                                                          introspection
                                                          response it
                                                          has the
                                                          attribute
                                                          "valid" - this
                                                          is basically
                                                          the validity
                                                          of the token
                                                          provided in
                                                          the request.

                                                          Validation criteria

                                                          depends on the
                                                          token and well
                                                          as token type
                                                          ( Bearer,
                                                          MAC..).

                                                          In the
                                                          spec it seems
                                                          like it's
                                                          coupled with
                                                          Bearer token
                                                          type... But I
                                                          guess, by
                                                          adding
                                                          "token_type"
                                                          to the request
                                                          we can remove
                                                          this
                                                          dependency.

                                                          WDYT..?

                                                          Thanks
                                                          & regards,
                                                          -Prabath 

                                                          On

                                                          Thu, Feb 7,
                                                          2013 at 12:54
                                                          AM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:

                                                          Updated
                                                          introspection
                                                          draft based on
                                                          recent
                                                          comments.
                                                          Changes
                                                          include:

                                                           - "scope"
                                                          return
                                                          parameter now
                                                          follows
                                                          RFC6749 format
                                                          instead of
                                                          JSON array

                                                           - "subject"
                                                          -> "sub",
                                                          and "audience"
                                                          -> "aud",
                                                          to be parallel
                                                          with JWT
                                                          claims

                                                           - clarified
                                                          what happens
                                                          if the
                                                          authentication
                                                          is bad

                                                           -- Justin

                                                          --------
                                                          Original
                                                          Message
                                                          --------

                                                          Subject: 
                                                          New
                                                          Version
                                                          Notification
                                                          for
                                                          draft-richer-oauth-introspection-02.txt

                                                          Date: 
                                                          Wed, 6 Feb
                                                          2013 11:24:20
                                                          -0800

                                                          From: 
                                                          <internet-drafts@ietf.org>

                                                          To: 
                                                          <jricher@mitre.org>

                                                          A new version of I-D, draft-richer-oauth-introspection-02.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 02
Title:		 OAuth Token Introspection
Creation date:	 2013-02-06
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.

The IETF Secretariat

_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

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

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                                  -- 

                                                  Thanks & Regards,

                                                  Prabath

                                                  Mobile : +94
                                                      71 809 6732 

                                                    http://blog.facilelogin.com

                                                    http://RampartFAQ.com

                                              _______________________________________________

                                                OAuth mailing list

                                                OAuth@ietf.org

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

                                -- 

                                Thanks & Regards,

                                Prabath

                                Mobile : +94
                                    71 809 6732 

                                  http://blog.facilelogin.com

                                  http://RampartFAQ.com

                      -- 

                      Thanks & Regards,

                      Prabath

                      Mobile : +94 71
                          809 6732 

                        http://blog.facilelogin.com

                        http://RampartFAQ.com

        -- 

        Thanks & Regards,

        Prabath

        Mobile : +94 71 809 6732 

          http://blog.facilelogin.com

          http://RampartFAQ.com

--------------030105000502060207030806--

From jricher@mitre.org  Thu Feb 14 06:26:40 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB9F21F8840 for ; Thu, 14 Feb 2013 06:26:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.569
X-Spam-Level: 
X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.029,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mySPXMZL3a5M for ; Thu, 14 Feb 2013 06:26:38 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9A02921F8201 for ; Thu, 14 Feb 2013 06:26:37 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 26D981F2CAA; Thu, 14 Feb 2013 09:26:37 -0500 (EST)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 0C6961F2C9A; Thu, 14 Feb 2013 09:26:37 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 14 Feb 2013 09:26:36 -0500
Message-ID: <511CF3EF.8040008@mitre.org>
Date: Thu, 14 Feb 2013 09:25:51 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Prabath Siriwardena 
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com> <5112AE0B.1080501@mitre.org>  <5113C3AA.1040701@mitre.org>  <5113DDB2.7060805@mitre.org>  <51196777.6000502@mitre.org>   <511A5062.5010108@mitre.org>   <511CEEAA.3030801@mitre.org>  
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050907000800000603080505"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2013 14:26:40 -0000

--------------050907000800000603080505
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

OK, I don't see the utility in that at all. What would it accomplish?

  -- Justin

On 02/14/2013 09:25 AM, Prabath Siriwardena wrote:
> To make it clear - my suggestion is to add token_type_hint to the 
> introspection request. It can be from client to AS or from RS to AS.
>
> Then AS can decide whether the provided token is valid or not and 
> include "valid" attribute in the introspection response.
>
> Thanks & regards,
> -Prabath
>
> On Thu, Feb 14, 2013 at 7:52 PM, Prabath Siriwardena  > wrote:
>
>     Both the client and the resource owner should be aware of the
>     token type.
>
>     My argument is, if the authorization server to decide whether the
>     token is valid or not ( irrespective of who asked the question) -
>     AS needs to know the token type - because to validate a token AS
>     should know the token type.
>
>     The token type could be, bearer or MAC or any other token type.
>
>     Thanks & regards,
>     -Prabath
>
>
>     On Thu, Feb 14, 2013 at 7:33 PM, Justin Richer      > wrote:
>
>         What exactly are you suggesting be added to introspection? The
>         "token_type_hint" is from the client to the server, but what
>         you've asked for in terms of "token type" is from the server
>         to the client. And there was never an answer to what exactly
>         is meant by "token type" in this case, particularly because
>         you seem to want to call out things like SAML and Bearer as
>         separate types.
>
>          -- Justin
>
>
>
>         On 02/14/2013 06:59 AM, Prabath Siriwardena wrote:
>>         I noticed that the latest Token Revocation draft [1] has
>>         introduced the parameter "token_type_hint". I would suggest
>>         the same here, as that would make what is meant by "valid"
>>         much clear..
>>
>>         [1]: http://tools.ietf.org/html/draft-ietf-oauth-revocation-05
>>
>>         Thanks & regards,
>>         -Prabath
>>
>>         On Tue, Feb 12, 2013 at 9:35 PM, Prabath Siriwardena
>>         > wrote:
>>
>>             Hi Justin,
>>
>>             I doubt whether valid_token would make a difference..?
>>
>>             My initial argument is what is the validation criteria..?
>>             Validation criteria depends on the token_type..
>>
>>             If we are talking only about metadata - then I believe
>>             "revoked", "expired" would be more meaningful..
>>
>>             Thanks & regards,
>>             -Prabath
>>
>>
>>             On Tue, Feb 12, 2013 at 7:53 PM, Justin Richer
>>             > wrote:
>>
>>                 OK, I can see the wisdom in changing this term.
>>
>>                 I picked "valid" because I wanted a simple "boolean"
>>                 value that would require no additional parsing or
>>                 string-matching on the client's behalf, and I'd like
>>                 to stick with that. OAuth is built with the
>>                 assumption that clients need to be able to recover
>>                 from invalid tokens at any stage, so I think a simple
>>                 yes/no is the right step here.
>>
>>                 That said, I think you're both right that "valid"
>>                 seems to have caused a bit of confusion. I don't want
>>                 to go with "revoked" because I'd rather have the
>>                 "token is OK" be the positive boolean value.
>>
>>                 Would "valid_token" be more clear? Or do we need a
>>                 different adjective all together?
>>
>>                  -- Justin
>>
>>
>>                 On 02/11/2013 08:02 PM, Richard Harrington wrote:
>>>                 Have you considered "status" instead of "valid"?  It
>>>                 could have values like "active", "expired", and
>>>                 "revoked".
>>>
>>>                 Is it worthwhile including the status of the client
>>>                 also?  For example, a client application could be
>>>                 disabled, temporarily or permanently, and thus
>>>                 disabling its access tokens as well.
>>>
>>>
>>>                 On Feb 11, 2013, at 1:56 PM, Prabath Siriwardena
>>>                 > wrote:
>>>
>>>>                 I guess confusion is with 'valid' parameter is in
>>>>                 the response..
>>>>
>>>>                 I thought this will be helpful to standardize the
>>>>                 communication between Resource Server and the
>>>>                 Authorization Server..
>>>>
>>>>                 I would suggest we completely remove "valid" from
>>>>                 the response - or define it much clearly..
>>>>
>>>>                 May be can add "revoked" with a boolean attribute..
>>>>
>>>>                 Thanks & regards,
>>>>                 -Prabath
>>>>
>>>>                 On Tue, Feb 12, 2013 at 3:19 AM, Justin Richer
>>>>                 > wrote:
>>>>
>>>>
>>>>                     On 02/08/2013 12:51 AM, Prabath Siriwardena wrote:
>>>>>                     Hi Justin,
>>>>>
>>>>>                     I have couple of questions related to "valid"
>>>>>                     parameter...
>>>>>
>>>>>                     This endpoint can be invoked by the Resource
>>>>>                     Server in runtime...
>>>>
>>>>                     That's correct.
>>>>
>>>>
>>>>>
>>>>>                     In that case what is exactly meant by the
>>>>>                     "resource_id" in request ?
>>>>
>>>>                     The resource_id field is a service-specific
>>>>                     string that basically lets the resource server
>>>>                     provide some context to the request to the auth
>>>>                     server. There have been some other suggestions
>>>>                     like client IP address, but I wanted to put
>>>>                     this one in because it seemed to be a common
>>>>                     theme. The client is trying to do *something*
>>>>                     with the token, after all, and the rights,
>>>>                     permissions, and metadata associated with the
>>>>                     token could change based on that. Since the
>>>>                     Introspection endpoint is all about getting
>>>>                     that metadata back to the PR, this seemed like
>>>>                     a good idea.
>>>>
>>>>
>>>>>
>>>>>                     IMO a token to be valid depends on set of
>>>>>                     criteria based on it's type..
>>>>>
>>>>>                     For a Bearer token..
>>>>>
>>>>>                     1. Token should not be expired
>>>>>                     2. Token should not be revoked.
>>>>>                     3. The scope the token issued should match
>>>>>                     with the scope required for the resource.
>>>>>
>>>>>                     For a MAC token...
>>>>>
>>>>>                     1. Token not expired (mac id)
>>>>>                     2. Token should not be revoked
>>>>>                     3. The scope the token issued should match
>>>>>                     with the scope required for the resource.
>>>>>                     4. HMAC check should be valid
>>>>>
>>>>>                     There are similar conditions for SAML bearer too..
>>>>
>>>>                     This isn't really true. The SAML bearer token
>>>>                     is fully self-contained and doesn't change
>>>>                     based on other parameters in the message,
>>>>                     unlike MAC. Same with JWT. When it hands a SAML
>>>>                     or JWT token to the AS, the PR has given
>>>>                     *everything* the server needs to check that
>>>>                     token's validity and use.
>>>>
>>>>                     MAC signatures change with every message, and
>>>>                     they're done across several components of the
>>>>                     HTTP message. Therefor, the HMAC check for MAC
>>>>                     style tokens will still need to be done by the
>>>>                     protected resource. Introspection would help in
>>>>                     the case that the signature validated just
>>>>                     fine, but the token might have expired. Or you
>>>>                     need to know what scopes apply. Introspection
>>>>                     isn't to fully validate the call to the
>>>>                     protected resource -- if that were the case,
>>>>                     the PR would have to send some kind of
>>>>                     encapsulated version of the original request.
>>>>                     Otherwise, the AS won't have all of the
>>>>                     information it needs to check the MAC.
>>>>
>>>>
>>>>                     I think what you're describing is ultimately
>>>>                     *not* what the introspection endpoint is
>>>>                     intended to do. If that's unclear from the
>>>>                     document, can you please suggest text that
>>>>                     would help clear the use case up? I wouldn't
>>>>                     want it to be ambiguous.
>>>>
>>>>                      -- Justin
>>>>
>>>>
>>>>>
>>>>>                     Thanks & regards,
>>>>>                     -Prabath
>>>>>
>>>>>
>>>>>                     On Thu, Feb 7, 2013 at 10:30 PM, Justin Richer
>>>>>                     >
>>>>>                     wrote:
>>>>>
>>>>>                         It validates the token, which would be
>>>>>                         either the token itself in the case of
>>>>>                         Bearer or the token "id" part of something
>>>>>                         more complex like MAC. It doesn't directly
>>>>>                         validate the usage of the token, that's
>>>>>                         still up to the PR to do that.
>>>>>
>>>>>                         I nearly added a "token type" field in
>>>>>                         this draft, but held back because there
>>>>>                         are several kinds of "token type" that
>>>>>                         people talk about in OAuth. First, there's
>>>>>                         "Bearer" vs. "MAC" vs. "HOK", or what have
>>>>>                         you. Then within Bearer you have "JWT" or
>>>>>                         "SAML" or "unstructured blob". Then you've
>>>>>                         also got "access" vs. "refresh" and other
>>>>>                         flavors of token, like the id_token in
>>>>>                         OpenID Connect.
>>>>>
>>>>>                         Thing is, the server running the
>>>>>                         introspection endpoint will probably know
>>>>>                         *all* of these. But should it tell the
>>>>>                         client? If so, which of the three, and
>>>>>                         what names should the fields be?
>>>>>
>>>>>                          -- Justin
>>>>>
>>>>>
>>>>>                         On 02/07/2013 11:26 AM, Prabath
>>>>>                         Siriwardena wrote:
>>>>>>                         Okay.. I was thinking this could be used
>>>>>>                         as a way to validate the token as well.
>>>>>>                         BTW even in this case shouldn't
>>>>>>                         communicate the type of token to AS? For
>>>>>>                         example in the case of SAML profile - it
>>>>>>                         could be SAML token..
>>>>>>
>>>>>>                         Thanks & regards,
>>>>>>                         -Prabath
>>>>>>
>>>>>>                         On Thu, Feb 7, 2013 at 8:39 PM, Justin
>>>>>>                         Richer >>>>>                         > wrote:
>>>>>>
>>>>>>                             "valid" might not be the best term,
>>>>>>                             but it's meant to be a field where
>>>>>>                             the server says "yes this token is
>>>>>>                             still good" or "no this token isn't
>>>>>>                             good anymore". We could instead do
>>>>>>                             this with HTTP codes or something but
>>>>>>                             I went with a pure JSON response.
>>>>>>
>>>>>>                              -- Justin
>>>>>>
>>>>>>
>>>>>>                             On 02/06/2013 10:47 PM, Prabath
>>>>>>                             Siriwardena wrote:
>>>>>>>                             Hi Justin,
>>>>>>>
>>>>>>>                             I believe this is addressing one of
>>>>>>>                             the key missing part in OAuth 2.0...
>>>>>>>
>>>>>>>                             One question - I guess this was
>>>>>>>                             discussed already...
>>>>>>>
>>>>>>>                             In the spec - in the introspection
>>>>>>>                             response it has the attribute
>>>>>>>                             "valid" - this is basically the
>>>>>>>                             validity of the token provided in
>>>>>>>                             the request.
>>>>>>>
>>>>>>>                             Validation criteria depends on the
>>>>>>>                             token and well as token type (
>>>>>>>                             Bearer, MAC..).
>>>>>>>
>>>>>>>                             In the spec it seems like it's
>>>>>>>                             coupled with Bearer token type...
>>>>>>>                             But I guess, by adding "token_type"
>>>>>>>                             to the request we can remove this
>>>>>>>                             dependency.
>>>>>>>
>>>>>>>                             WDYT..?
>>>>>>>
>>>>>>>                             Thanks & regards,
>>>>>>>                             -Prabath
>>>>>>>
>>>>>>>                             On Thu, Feb 7, 2013 at 12:54 AM,
>>>>>>>                             Justin Richer >>>>>>                             > wrote:
>>>>>>>
>>>>>>>                                 Updated introspection draft
>>>>>>>                                 based on recent comments.
>>>>>>>                                 Changes include:
>>>>>>>
>>>>>>>                                  - "scope" return parameter now
>>>>>>>                                 follows RFC6749 format instead
>>>>>>>                                 of JSON array
>>>>>>>                                  - "subject" -> "sub", and
>>>>>>>                                 "audience" -> "aud", to be
>>>>>>>                                 parallel with JWT claims
>>>>>>>                                  - clarified what happens if the
>>>>>>>                                 authentication is bad
>>>>>>>
>>>>>>>                                  -- Justin
>>>>>>>
>>>>>>>
>>>>>>>                                 -------- Original Message --------
>>>>>>>                                 Subject: 	New Version
>>>>>>>                                 Notification for
>>>>>>>                                 draft-richer-oauth-introspection-02.txt
>>>>>>>
>>>>>>>                                 Date: 	Wed, 6 Feb 2013 11:24:20
>>>>>>>                                 -0800
>>>>>>>                                 From:
>>>>>>>                                 
>>>>>>>                                 
>>>>>>>                                 To: 	
>>>>>>>                                 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                                 A new version of I-D, draft-richer-oauth-introspection-02.txt
>>>>>>>                                 has been successfully submitted by Justin Richer and posted to the
>>>>>>>                                 IETF repository.
>>>>>>>
>>>>>>>                                 Filename:	 draft-richer-oauth-introspection
>>>>>>>                                 Revision:	 02
>>>>>>>                                 Title:		 OAuth Token Introspection
>>>>>>>                                 Creation date:	 2013-02-06
>>>>>>>                                 WG ID:		 Individual Submission
>>>>>>>                                 Number of pages: 6
>>>>>>>                                 URL:http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
>>>>>>>                                 Status:http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
>>>>>>>                                 Htmlized:http://tools.ietf.org/html/draft-richer-oauth-introspection-02
>>>>>>>                                 Diff:http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02
>>>>>>>
>>>>>>>                                 Abstract:
>>>>>>>                                     This specification defines a method for a client or protected
>>>>>>>                                     resource to query an OAuth authorization server to determine meta-
>>>>>>>                                     information about an OAuth token.
>>>>>>>
>>>>>>>
>>>>>>>                                                                                                                    
>>>>>>>
>>>>>>>
>>>>>>>                                 The IETF Secretariat
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                                 _______________________________________________
>>>>>>>                                 OAuth mailing list
>>>>>>>                                 OAuth@ietf.org
>>>>>>>                                 
>>>>>>>                                 https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                             -- 
>>>>>>>                             Thanks & Regards,
>>>>>>>                             Prabath
>>>>>>>
>>>>>>>                             Mobile : +94 71 809 6732
>>>>>>>                             
>>>>>>>
>>>>>>>                             http://blog.facilelogin.com
>>>>>>>                             http://RampartFAQ.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>                         -- 
>>>>>>                         Thanks & Regards,
>>>>>>                         Prabath
>>>>>>
>>>>>>                         Mobile : +94 71 809 6732
>>>>>>                         
>>>>>>
>>>>>>                         http://blog.facilelogin.com
>>>>>>                         http://RampartFAQ.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>                     -- 
>>>>>                     Thanks & Regards,
>>>>>                     Prabath
>>>>>
>>>>>                     Mobile : +94 71 809 6732
>>>>>                     
>>>>>
>>>>>                     http://blog.facilelogin.com
>>>>>                     http://RampartFAQ.com
>>>>
>>>>
>>>>
>>>>
>>>>                 -- 
>>>>                 Thanks & Regards,
>>>>                 Prabath
>>>>
>>>>                 Mobile : +94 71 809 6732 
>>>>
>>>>                 http://blog.facilelogin.com
>>>>                 http://RampartFAQ.com
>>>>                 _______________________________________________
>>>>                 OAuth mailing list
>>>>                 OAuth@ietf.org 
>>>>                 https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>>             -- 
>>             Thanks & Regards,
>>             Prabath
>>
>>             Mobile : +94 71 809 6732 
>>
>>             http://blog.facilelogin.com
>>             http://RampartFAQ.com
>>
>>
>>
>>
>>         -- 
>>         Thanks & Regards,
>>         Prabath
>>
>>         Mobile : +94 71 809 6732 
>>
>>         http://blog.facilelogin.com
>>         http://RampartFAQ.com
>
>
>
>
>     -- 
>     Thanks & Regards,
>     Prabath
>
>     Mobile : +94 71 809 6732 
>
>     http://blog.facilelogin.com
>     http://RampartFAQ.com
>
>
>
>
> -- 
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com

--------------050907000800000603080505
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

    OK, I don't see the utility in that at all. What would it
    accomplish?

     -- Justin

    On 02/14/2013 09:25 AM, Prabath
      Siriwardena wrote:

      To make it clear - my suggestion is to add token_type_hint to the
      introspection request. It can be from client to AS or from RS to
      AS.

      Then AS can decide whether the provided token is valid or not
        and include "valid" attribute in the introspection response.

      Thanks & regards,
      -Prabath

        On Thu, Feb 14, 2013 at 7:52 PM,
          Prabath Siriwardena <prabath@wso2.com> wrote:

          Both the
            client and the resource owner should be aware of the token
            type.

            My argument is, if the authorization server to decide
              whether the token is valid or not ( irrespective of who
              asked the question) - AS needs to know the token type -
              because to validate a token AS should know the token type.

            The token type could be, bearer or MAC or any other
              token type.

            Thanks & regards,
            -Prabath

                  On Thu, Feb 14, 2013 at 7:33
                    PM, Justin Richer <jricher@mitre.org>
                    wrote:

                       What
                        exactly are you suggesting be added to
                        introspection? The "token_type_hint" is from the
                        client to the server, but what you've asked for
                        in terms of "token type" is from the server to
                        the client. And there was never an answer to
                        what exactly is meant by "token type" in this
                        case, particularly because you seem to want to
                        call out things like SAML and Bearer as separate
                        types. 

                             -- Justin

                            On 02/14/2013 06:59 AM, Prabath
                              Siriwardena wrote:

                             I noticed that the
                              latest Token Revocation draft [1] has
                              introduced the parameter
                              "token_type_hint". I would suggest the
                              same here, as that would make what is
                              meant by "valid" much clear..

                              [1]: http://tools.ietf.org/html/draft-ietf-oauth-revocation-05

                              Thanks & regards,
                              -Prabath

                                On Tue, Feb 12,
                                  2013 at 9:35 PM, Prabath Siriwardena <prabath@wso2.com>
                                  wrote:

                                  Hi Justin,

                                    I doubt whether valid_token
                                      would make a difference..?

                                    My initial argument is what is
                                      the validation criteria..?
                                      Validation criteria depends on the
                                      token_type..

                                    If we are talking only about
                                      metadata - then I believe
                                      "revoked", "expired" would be more
                                      meaningful..

                                    Thanks & regards,
                                    -Prabath

                                           On
                                            Tue, Feb 12, 2013 at 7:53
                                            PM, Justin Richer <jricher@mitre.org>
                                            wrote:

                                               OK, I
                                                can see the wisdom in
                                                changing this term. 

                                                I picked "valid" because
                                                I wanted a simple
                                                "boolean" value that
                                                would require no
                                                additional parsing or
                                                string-matching on the
                                                client's behalf, and I'd
                                                like to stick with that.
                                                OAuth is built with the
                                                assumption that clients
                                                need to be able to
                                                recover from invalid
                                                tokens at any stage, so
                                                I think a simple yes/no
                                                is the right step here.

                                                That said, I think
                                                you're both right that
                                                "valid" seems to have
                                                caused a bit of
                                                confusion. I don't want
                                                to go with "revoked"
                                                because I'd rather have
                                                the "token is OK" be the
                                                positive boolean value.

                                                Would "valid_token" be
                                                more clear? Or do we
                                                need a different
                                                adjective all together?

                                                     -- Justin

                                                    On 02/11/2013
                                                      08:02 PM, Richard
                                                      Harrington wrote:

                                                      Have you
                                                        considered
                                                        "status" instead
                                                        of "valid"?  It
                                                        could have
                                                        values like
                                                        "active",
                                                        "expired", and
                                                        "revoked".

                                                      Is it
                                                        worthwhile
                                                        including the
                                                        status of the
                                                        client also?
                                                         For example, a
                                                        client
                                                        application
                                                        could be
                                                        disabled,
                                                        temporarily or
                                                        permanently, and
                                                        thus disabling
                                                        its access
                                                        tokens as well.

                                                        On Feb 11, 2013,
                                                        at 1:56 PM,
                                                        Prabath
                                                        Siriwardena <prabath@wso2.com>

                                                        wrote:

                                                        I guess
                                                          confusion is
                                                          with 'valid'
                                                          parameter is
                                                          in the
                                                          response..

                                                          I thought
                                                          this will be
                                                          helpful
                                                          to standardize the
                                                          communication
                                                          between
                                                          Resource
                                                          Server and the
                                                          Authorization
                                                          Server..

                                                          I would
                                                          suggest we
                                                          completely
                                                          remove "valid"
                                                          from the
                                                          response - or
                                                          define it much
                                                          clearly..

                                                          May be
                                                          can add
                                                          "revoked" with
                                                          a boolean
                                                          attribute..

                                                          Thanks
                                                          & regards,
                                                          -Prabath

                                                          On
                                                          Tue, Feb 12,
                                                          2013 at 3:19
                                                          AM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:

                                                          On
                                                          02/08/2013
                                                          12:51 AM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          Hi Justin,

                                                          I have
                                                          couple of
                                                          questions
                                                          related to
                                                          "valid"
                                                          parameter...

                                                          This
                                                          endpoint can
                                                          be invoked by
                                                          the Resource
                                                          Server in
                                                          runtime...

                                                          That's
                                                          correct.

                                                          In that
                                                          case what is
                                                          exactly meant
                                                          by the
                                                          "resource_id"
                                                          in request ?

                                                          The
                                                          resource_id
                                                          field is a
                                                          service-specific
                                                          string that
                                                          basically lets
                                                          the resource
                                                          server provide
                                                          some context
                                                          to the request
                                                          to the auth
                                                          server. There
                                                          have been some
                                                          other
                                                          suggestions
                                                          like client IP
                                                          address, but I
                                                          wanted to put
                                                          this one in
                                                          because it
                                                          seemed to be a
                                                          common theme.
                                                          The client is
                                                          trying to do
                                                          *something*
                                                          with the
                                                          token, after
                                                          all, and the
                                                          rights,
                                                          permissions,
                                                          and metadata
                                                          associated
                                                          with the token
                                                          could change
                                                          based on that.
                                                          Since the
                                                          Introspection
                                                          endpoint is
                                                          all about
                                                          getting that
                                                          metadata back
                                                          to the PR,
                                                          this seemed
                                                          like a good
                                                          idea.

                                                          IMO a
                                                          token to be
                                                          valid depends
                                                          on set of
                                                          criteria based
                                                          on it's type..

                                                          For a
                                                          Bearer token..

                                                          1. Token
                                                          should not be
                                                          expired
                                                          2. Token
                                                          should not be
                                                          revoked.
                                                          3. The
                                                          scope the
                                                          token issued
                                                          should match
                                                          with the scope
                                                          required for
                                                          the resource.

                                                          For a MAC
                                                          token...

                                                          1. Token
                                                          not expired
                                                          (mac id)
                                                          2. Token
                                                          should not be
                                                          revoked
                                                          3. The
                                                          scope the
                                                          token issued
                                                          should match
                                                          with the scope
                                                          required for
                                                          the resource.
                                                          4. HMAC
                                                          check should
                                                          be valid

                                                          There are
                                                          similar
                                                          conditions for
                                                          SAML bearer
                                                          too..

                                                          This isn't
                                                          really true.
                                                          The SAML
                                                          bearer token
                                                          is fully
                                                          self-contained
                                                          and doesn't
                                                          change based
                                                          on other
                                                          parameters in
                                                          the message,
                                                          unlike MAC.
                                                          Same with JWT.
                                                          When it hands
                                                          a SAML or JWT
                                                          token to the
                                                          AS, the PR has
                                                          given
                                                          *everything*
                                                          the server
                                                          needs to check
                                                          that token's
                                                          validity and
                                                          use. 

                                                          MAC signatures
                                                          change with
                                                          every message,
                                                          and they're
                                                          done across
                                                          several
                                                          components of
                                                          the HTTP
                                                          message.
                                                          Therefor, the
                                                          HMAC check for
                                                          MAC style
                                                          tokens will
                                                          still need to
                                                          be done by the
                                                          protected
                                                          resource.
                                                          Introspection
                                                          would help in
                                                          the case that
                                                          the signature
                                                          validated just
                                                          fine, but the
                                                          token might
                                                          have expired.
                                                          Or you need to
                                                          know what
                                                          scopes apply.
                                                          Introspection
                                                          isn't to fully
                                                          validate the
                                                          call to the
                                                          protected
                                                          resource -- if
                                                          that were the
                                                          case, the PR
                                                          would have to
                                                          send some kind
                                                          of
                                                          encapsulated
                                                          version of the
                                                          original
                                                          request.
                                                          Otherwise, the
                                                          AS won't have
                                                          all of the
                                                          information it
                                                          needs to check
                                                          the MAC.

                                                          I think what
                                                          you're
                                                          describing is
                                                          ultimately
                                                          *not* what the
                                                          introspection
                                                          endpoint is
                                                          intended to
                                                          do. If that's
                                                          unclear from
                                                          the document,
                                                          can you please
                                                          suggest text
                                                          that would
                                                          help clear the
                                                          use case up? I
                                                          wouldn't want
                                                          it to be
                                                          ambiguous.

                                                           -- Justin

                                                          Thanks
                                                          & regards,
                                                          -Prabath

                                                          On

                                                          Thu, Feb 7,
                                                          2013 at 10:30
                                                          PM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:

                                                          It validates
                                                          the token,
                                                          which would be
                                                          either the
                                                          token itself
                                                          in the case of
                                                          Bearer or the
                                                          token "id"
                                                          part of
                                                          something more
                                                          complex like
                                                          MAC. It
                                                          doesn't
                                                          directly
                                                          validate the
                                                          usage of the
                                                          token, that's
                                                          still up to
                                                          the PR to do
                                                          that.

                                                          I nearly added
                                                          a "token type"
                                                          field in this
                                                          draft, but
                                                          held back
                                                          because there
                                                          are several
                                                          kinds of
                                                          "token type"
                                                          that people
                                                          talk about in
                                                          OAuth. First,
                                                          there's
                                                          "Bearer" vs.
                                                          "MAC" vs.
                                                          "HOK", or what
                                                          have you. Then
                                                          within Bearer
                                                          you have "JWT"
                                                          or "SAML" or
                                                          "unstructured
                                                          blob". Then
                                                          you've also
                                                          got "access"
                                                          vs. "refresh"
                                                          and other
                                                          flavors of
                                                          token, like
                                                          the id_token
                                                          in OpenID
                                                          Connect. 

                                                          Thing is, the
                                                          server running
                                                          the
                                                          introspection
                                                          endpoint will
                                                          probably know
                                                          *all* of
                                                          these. But
                                                          should it tell
                                                          the client? If
                                                          so, which of
                                                          the three, and
                                                          what names
                                                          should the
                                                          fields be?

                                                           -- Justin

                                                          On
                                                          02/07/2013
                                                          11:26 AM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          Okay.. I was
                                                          thinking this
                                                          could be used
                                                          as a way to
                                                          validate the
                                                          token as well.
                                                          BTW even in
                                                          this case
                                                          shouldn't
                                                          communicate
                                                          the type of
                                                          token to AS?
                                                          For example in
                                                          the case of
                                                          SAML profile -
                                                          it could be
                                                          SAML token..

                                                          Thanks
                                                          & regards,
                                                          -Prabath

                                                          On

                                                          Thu, Feb 7,
                                                          2013 at 8:39
                                                          PM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:

                                                          "valid" might
                                                          not be the
                                                          best term, but
                                                          it's meant to
                                                          be a field
                                                          where the
                                                          server says
                                                          "yes this
                                                          token is still
                                                          good" or "no
                                                          this token
                                                          isn't good
                                                          anymore". We
                                                          could instead
                                                          do this with
                                                          HTTP codes or
                                                          something but
                                                          I went with a
                                                          pure JSON
                                                          response.

                                                           -- Justin

                                                          On
                                                          02/06/2013
                                                          10:47 PM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          Hi Justin,

                                                          I believe
                                                          this is
                                                          addressing one
                                                          of the key
                                                          missing part
                                                          in OAuth
                                                          2.0...

                                                          One
                                                          question - I
                                                          guess this was
                                                          discussed
                                                          already...

                                                          In the
                                                          spec - in the
                                                          introspection
                                                          response it
                                                          has the
                                                          attribute
                                                          "valid" - this
                                                          is basically
                                                          the validity
                                                          of the token
                                                          provided in
                                                          the request.

                                                          Validation criteria

                                                          depends on the
                                                          token and well
                                                          as token type
                                                          ( Bearer,
                                                          MAC..).

                                                          In the
                                                          spec it seems
                                                          like it's
                                                          coupled with
                                                          Bearer token
                                                          type... But I
                                                          guess, by
                                                          adding
                                                          "token_type"
                                                          to the request
                                                          we can remove
                                                          this
                                                          dependency.

                                                          WDYT..?

                                                          Thanks
                                                          & regards,
                                                          -Prabath 

                                                          On

                                                          Thu, Feb 7,
                                                          2013 at 12:54
                                                          AM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:

                                                          Updated
                                                          introspection
                                                          draft based on
                                                          recent
                                                          comments.
                                                          Changes
                                                          include:

                                                           - "scope"
                                                          return
                                                          parameter now
                                                          follows
                                                          RFC6749 format
                                                          instead of
                                                          JSON array

                                                           - "subject"
                                                          -> "sub",
                                                          and "audience"
                                                          -> "aud",
                                                          to be parallel
                                                          with JWT
                                                          claims

                                                           - clarified
                                                          what happens
                                                          if the
                                                          authentication
                                                          is bad

                                                           -- Justin

                                                          --------
                                                          Original
                                                          Message
                                                          --------

                                                          Subject: 
                                                          New
                                                          Version
                                                          Notification
                                                          for
                                                          draft-richer-oauth-introspection-02.txt

                                                          Date: 
                                                          Wed, 6 Feb
                                                          2013 11:24:20
                                                          -0800

                                                          From: 
                                                          <internet-drafts@ietf.org>

                                                          To: 
                                                          <jricher@mitre.org>

                                                          A new version of I-D, draft-richer-oauth-introspection-02.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 02
Title:		 OAuth Token Introspection
Creation date:	 2013-02-06
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.

The IETF Secretariat

_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

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

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94
                                                          71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                                        _______________________________________________

                                                          OAuth
                                                          mailing list

                                                          OAuth@ietf.org

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

                                          -- 

                                          Thanks & Regards,

                                          Prabath

                                          Mobile : +94 71 809
                                              6732 

                                            http://blog.facilelogin.com

                                            http://RampartFAQ.com

                                -- 

                                Thanks & Regards,

                                Prabath

                                Mobile : +94
                                    71 809 6732 

                                  http://blog.facilelogin.com

                                  http://RampartFAQ.com

                  -- 

                  Thanks & Regards,

                  Prabath

                  Mobile : +94 71 809
                      6732 

                    http://blog.facilelogin.com

                    http://RampartFAQ.com

        -- 

        Thanks & Regards,

        Prabath

        Mobile : +94 71 809 6732 

          http://blog.facilelogin.com

          http://RampartFAQ.com

--------------050907000800000603080505--

From prabath@wso2.com  Thu Feb 14 06:28:24 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B8B21F893D for ; Thu, 14 Feb 2013 06:28:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.882
X-Spam-Level: 
X-Spam-Status: No, score=-2.882 tagged_above=-999 required=5 tests=[AWL=0.094,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3m+XYV9o6y6p for ; Thu, 14 Feb 2013 06:28:22 -0800 (PST)
Received: from mail-ee0-f53.google.com (mail-ee0-f53.google.com [74.125.83.53]) by ietfa.amsl.com (Postfix) with ESMTP id EEFC721F892C for ; Thu, 14 Feb 2013 06:28:04 -0800 (PST)
Received: by mail-ee0-f53.google.com with SMTP id e53so1260177eek.26 for ; Thu, 14 Feb 2013 06:28:04 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=M0NEqoQzbqL4/EjV2TnRRKX3KH4FBllm6E/f0F6lUqU=; b=K1ghAkVvaSX7Rv+WmKs84YtRSUlfKZZZULHcNDvDKXYhpfk87QhesxFkoFgVVGqlE2 Ba4ETNrphDJfmpdqi0aZuZAMLx2g7RMm4Akp9hDrNUlkXxHkfOGyAHSUm8dsm/Bmaa9v iSGQEqqhBu5t+0RUSf3nlvQLrI3zogk/8GNyueTICl/98TUhWVmGy8RXNW7rdXz1rvib e3m4qscMc5qgZrged9sKTGVIhUXcrvY+QPPbasHbSkau1zXEoFWGmo1oByRW6G2I/ntf JWyK0cmI7BOdVusPsooXud+qcQ9lCZTF3FCYwIsLioKzeNh5cZtsFTHrDMxj8TuKsYhv wR4g==
MIME-Version: 1.0
X-Received: by 10.14.194.198 with SMTP id m46mr18423773een.8.1360852083737; Thu, 14 Feb 2013 06:28:03 -0800 (PST)
Received: by 10.223.37.77 with HTTP; Thu, 14 Feb 2013 06:28:03 -0800 (PST)
In-Reply-To: <511CF3EF.8040008@mitre.org>
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com> <5112AE0B.1080501@mitre.org>  <5113C3AA.1040701@mitre.org>  <5113DDB2.7060805@mitre.org>  <51196777.6000502@mitre.org>   <511A5062.5010108@mitre.org>   <511CEEAA.3030801@mitre.org>   <511CF3EF.8040008@mitre.org>
Date: Thu, 14 Feb 2013 19:58:03 +0530
Message-ID: 
From: Prabath Siriwardena 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=047d7b343a9e0b048704d5b0116e
X-Gm-Message-State: ALoCoQmDqfZDDT7wLLF49NsebDlhV8a/IAzh2duvK4sDtjVwXNOlw/pfO2mvEo6k0s/SQ3OgWrgD
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2013 14:28:24 -0000

--047d7b343a9e0b048704d5b0116e
Content-Type: text/plain; charset=ISO-8859-1

Okay. With out knowing the type of the token how can the AS validate the
token ? What is meant by the validity there?

Thanks & regards,
-Prabath

On Thu, Feb 14, 2013 at 7:55 PM, Justin Richer  wrote:

>  OK, I don't see the utility in that at all. What would it accomplish?
>
>  -- Justin
>
>
> On 02/14/2013 09:25 AM, Prabath Siriwardena wrote:
>
> To make it clear - my suggestion is to add token_type_hint to the
> introspection request. It can be from client to AS or from RS to AS.
>
>  Then AS can decide whether the provided token is valid or not and
> include "valid" attribute in the introspection response.
>
>  Thanks & regards,
> -Prabath
>
> On Thu, Feb 14, 2013 at 7:52 PM, Prabath Siriwardena wrote:
>
>> Both the client and the resource owner should be aware of the token type.
>>
>>  My argument is, if the authorization server to decide whether the token
>> is valid or not ( irrespective of who asked the question) - AS needs to
>> know the token type - because to validate a token AS should know the token
>> type.
>>
>>  The token type could be, bearer or MAC or any other token type.
>>
>>  Thanks & regards,
>> -Prabath
>>
>>
>> On Thu, Feb 14, 2013 at 7:33 PM, Justin Richer  wrote:
>>
>>>  What exactly are you suggesting be added to introspection? The
>>> "token_type_hint" is from the client to the server, but what you've asked
>>> for in terms of "token type" is from the server to the client. And there
>>> was never an answer to what exactly is meant by "token type" in this case,
>>> particularly because you seem to want to call out things like SAML and
>>> Bearer as separate types.
>>>
>>>  -- Justin
>>>
>>>
>>>
>>> On 02/14/2013 06:59 AM, Prabath Siriwardena wrote:
>>>
>>> I noticed that the latest Token Revocation draft [1] has introduced the
>>> parameter "token_type_hint". I would suggest the same here, as that would
>>> make what is meant by "valid" much clear..
>>>
>>>  [1]: http://tools.ietf.org/html/draft-ietf-oauth-revocation-05
>>>
>>>  Thanks & regards,
>>> -Prabath
>>>
>>> On Tue, Feb 12, 2013 at 9:35 PM, Prabath Siriwardena wrote:
>>>
>>>> Hi Justin,
>>>>
>>>>  I doubt whether valid_token would make a difference..?
>>>>
>>>>  My initial argument is what is the validation criteria..? Validation
>>>> criteria depends on the token_type..
>>>>
>>>>  If we are talking only about metadata - then I believe "revoked",
>>>> "expired" would be more meaningful..
>>>>
>>>>  Thanks & regards,
>>>> -Prabath
>>>>
>>>>
>>>>  On Tue, Feb 12, 2013 at 7:53 PM, Justin Richer wrote:
>>>>
>>>>>  OK, I can see the wisdom in changing this term.
>>>>>
>>>>> I picked "valid" because I wanted a simple "boolean" value that would
>>>>> require no additional parsing or string-matching on the client's behalf,
>>>>> and I'd like to stick with that. OAuth is built with the assumption that
>>>>> clients need to be able to recover from invalid tokens at any stage, so I
>>>>> think a simple yes/no is the right step here.
>>>>>
>>>>> That said, I think you're both right that "valid" seems to have caused
>>>>> a bit of confusion. I don't want to go with "revoked" because I'd rather
>>>>> have the "token is OK" be the positive boolean value.
>>>>>
>>>>> Would "valid_token" be more clear? Or do we need a different adjective
>>>>> all together?
>>>>>
>>>>>  -- Justin
>>>>>
>>>>>
>>>>> On 02/11/2013 08:02 PM, Richard Harrington wrote:
>>>>>
>>>>> Have you considered "status" instead of "valid"?  It could have values
>>>>> like "active", "expired", and "revoked".
>>>>>
>>>>>  Is it worthwhile including the status of the client also?  For
>>>>> example, a client application could be disabled, temporarily or
>>>>> permanently, and thus disabling its access tokens as well.
>>>>>
>>>>>
>>>>> On Feb 11, 2013, at 1:56 PM, Prabath Siriwardena 
>>>>> wrote:
>>>>>
>>>>>  I guess confusion is with 'valid' parameter is in the response..
>>>>>
>>>>>  I thought this will be helpful to standardize the communication
>>>>> between Resource Server and the Authorization Server..
>>>>>
>>>>>  I would suggest we completely remove "valid" from the response - or
>>>>> define it much clearly..
>>>>>
>>>>>  May be can add "revoked" with a boolean attribute..
>>>>>
>>>>>  Thanks & regards,
>>>>> -Prabath
>>>>>
>>>>> On Tue, Feb 12, 2013 at 3:19 AM, Justin Richer wrote:
>>>>>
>>>>>>
>>>>>> On 02/08/2013 12:51 AM, Prabath Siriwardena wrote:
>>>>>>
>>>>>> Hi Justin,
>>>>>>
>>>>>>  I have couple of questions related to "valid" parameter...
>>>>>>
>>>>>>  This endpoint can be invoked by the Resource Server in runtime...
>>>>>>
>>>>>>
>>>>>> That's correct.
>>>>>>
>>>>>>
>>>>>>
>>>>>>  In that case what is exactly meant by the "resource_id" in request ?
>>>>>>
>>>>>>
>>>>>>  The resource_id field is a service-specific string that basically
>>>>>> lets the resource server provide some context to the request to the auth
>>>>>> server. There have been some other suggestions like client IP address, but
>>>>>> I wanted to put this one in because it seemed to be a common theme. The
>>>>>> client is trying to do *something* with the token, after all, and the
>>>>>> rights, permissions, and metadata associated with the token could change
>>>>>> based on that. Since the Introspection endpoint is all about getting that
>>>>>> metadata back to the PR, this seemed like a good idea.
>>>>>>
>>>>>>
>>>>>>
>>>>>>  IMO a token to be valid depends on set of criteria based on it's
>>>>>> type..
>>>>>>
>>>>>>  For a Bearer token..
>>>>>>
>>>>>>  1. Token should not be expired
>>>>>> 2. Token should not be revoked.
>>>>>> 3. The scope the token issued should match with the scope required
>>>>>> for the resource.
>>>>>>
>>>>>>  For a MAC token...
>>>>>>
>>>>>>  1. Token not expired (mac id)
>>>>>> 2. Token should not be revoked
>>>>>> 3. The scope the token issued should match with the scope required
>>>>>> for the resource.
>>>>>> 4. HMAC check should be valid
>>>>>>
>>>>>>  There are similar conditions for SAML bearer too..
>>>>>>
>>>>>>
>>>>>>  This isn't really true. The SAML bearer token is fully
>>>>>> self-contained and doesn't change based on other parameters in the message,
>>>>>> unlike MAC. Same with JWT. When it hands a SAML or JWT token to the AS, the
>>>>>> PR has given *everything* the server needs to check that token's validity
>>>>>> and use.
>>>>>>
>>>>>> MAC signatures change with every message, and they're done across
>>>>>> several components of the HTTP message. Therefor, the HMAC check for MAC
>>>>>> style tokens will still need to be done by the protected resource.
>>>>>> Introspection would help in the case that the signature validated just
>>>>>> fine, but the token might have expired. Or you need to know what scopes
>>>>>> apply. Introspection isn't to fully validate the call to the protected
>>>>>> resource -- if that were the case, the PR would have to send some kind of
>>>>>> encapsulated version of the original request. Otherwise, the AS won't have
>>>>>> all of the information it needs to check the MAC.
>>>>>>
>>>>>>
>>>>>> I think what you're describing is ultimately *not* what the
>>>>>> introspection endpoint is intended to do. If that's unclear from the
>>>>>> document, can you please suggest text that would help clear the use case
>>>>>> up? I wouldn't want it to be ambiguous.
>>>>>>
>>>>>>  -- Justin
>>>>>>
>>>>>>
>>>>>>
>>>>>>  Thanks & regards,
>>>>>> -Prabath
>>>>>>
>>>>>>
>>>>>> On Thu, Feb 7, 2013 at 10:30 PM, Justin Richer wrote:
>>>>>>
>>>>>>>  It validates the token, which would be either the token itself in
>>>>>>> the case of Bearer or the token "id" part of something more complex like
>>>>>>> MAC. It doesn't directly validate the usage of the token, that's still up
>>>>>>> to the PR to do that.
>>>>>>>
>>>>>>> I nearly added a "token type" field in this draft, but held back
>>>>>>> because there are several kinds of "token type" that people talk about in
>>>>>>> OAuth. First, there's "Bearer" vs. "MAC" vs. "HOK", or what have you. Then
>>>>>>> within Bearer you have "JWT" or "SAML" or "unstructured blob". Then you've
>>>>>>> also got "access" vs. "refresh" and other flavors of token, like the
>>>>>>> id_token in OpenID Connect.
>>>>>>>
>>>>>>> Thing is, the server running the introspection endpoint will
>>>>>>> probably know *all* of these. But should it tell the client? If so, which
>>>>>>> of the three, and what names should the fields be?
>>>>>>>
>>>>>>>  -- Justin
>>>>>>>
>>>>>>>
>>>>>>> On 02/07/2013 11:26 AM, Prabath Siriwardena wrote:
>>>>>>>
>>>>>>> Okay.. I was thinking this could be used as a way to validate the
>>>>>>> token as well. BTW even in this case shouldn't communicate the type of
>>>>>>> token to AS? For example in the case of SAML profile - it could be SAML
>>>>>>> token..
>>>>>>>
>>>>>>>  Thanks & regards,
>>>>>>> -Prabath
>>>>>>>
>>>>>>> On Thu, Feb 7, 2013 at 8:39 PM, Justin Richer wrote:
>>>>>>>
>>>>>>>>  "valid" might not be the best term, but it's meant to be a field
>>>>>>>> where the server says "yes this token is still good" or "no this token
>>>>>>>> isn't good anymore". We could instead do this with HTTP codes or something
>>>>>>>> but I went with a pure JSON response.
>>>>>>>>
>>>>>>>>  -- Justin
>>>>>>>>
>>>>>>>>
>>>>>>>> On 02/06/2013 10:47 PM, Prabath Siriwardena wrote:
>>>>>>>>
>>>>>>>> Hi Justin,
>>>>>>>>
>>>>>>>>  I believe this is addressing one of the key missing part in OAuth
>>>>>>>> 2.0...
>>>>>>>>
>>>>>>>>  One question - I guess this was discussed already...
>>>>>>>>
>>>>>>>>  In the spec - in the introspection response it has the attribute
>>>>>>>> "valid" - this is basically the validity of the token provided in the
>>>>>>>> request.
>>>>>>>>
>>>>>>>>  Validation criteria depends on the token and well as token type (
>>>>>>>> Bearer, MAC..).
>>>>>>>>
>>>>>>>>  In the spec it seems like it's coupled with Bearer token type...
>>>>>>>> But I guess, by adding "token_type" to the request we can remove this
>>>>>>>> dependency.
>>>>>>>>
>>>>>>>>  WDYT..?
>>>>>>>>
>>>>>>>>  Thanks & regards,
>>>>>>>> -Prabath
>>>>>>>>
>>>>>>>> On Thu, Feb 7, 2013 at 12:54 AM, Justin Richer wrote:
>>>>>>>>
>>>>>>>>>  Updated introspection draft based on recent comments. Changes
>>>>>>>>> include:
>>>>>>>>>
>>>>>>>>>  - "scope" return parameter now follows RFC6749 format instead of
>>>>>>>>> JSON array
>>>>>>>>>  - "subject" -> "sub", and "audience" -> "aud", to be parallel
>>>>>>>>> with JWT claims
>>>>>>>>>  - clarified what happens if the authentication is bad
>>>>>>>>>
>>>>>>>>>  -- Justin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -------- Original Message --------  Subject: New Version
>>>>>>>>> Notification for draft-richer-oauth-introspection-02.txt  Date: Wed,
>>>>>>>>> 6 Feb 2013 11:24:20 -0800  From:   To:
>>>>>>>>>  
>>>>>>>>>
>>>>>>>>> A new version of I-D, draft-richer-oauth-introspection-02.txt
>>>>>>>>> has been successfully submitted by Justin Richer and posted to the
>>>>>>>>> IETF repository.
>>>>>>>>>
>>>>>>>>> Filename:	 draft-richer-oauth-introspection
>>>>>>>>> Revision:	 02
>>>>>>>>> Title:		 OAuth Token Introspection
>>>>>>>>> Creation date:	 2013-02-06
>>>>>>>>> WG ID:		 Individual Submission
>>>>>>>>> Number of pages: 6
>>>>>>>>> URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
>>>>>>>>> Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
>>>>>>>>> Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-02
>>>>>>>>> Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02
>>>>>>>>>
>>>>>>>>> Abstract:
>>>>>>>>>    This specification defines a method for a client or protected
>>>>>>>>>    resource to query an OAuth authorization server to determine meta-
>>>>>>>>>    information about an OAuth token.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The IETF Secretariat
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> OAuth mailing list
>>>>>>>>> OAuth@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>  --
>>>>>>>> Thanks & Regards,
>>>>>>>> Prabath
>>>>>>>>
>>>>>>>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>>>>>>>
>>>>>>>> http://blog.facilelogin.com
>>>>>>>> http://RampartFAQ.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  --
>>>>>>> Thanks & Regards,
>>>>>>> Prabath
>>>>>>>
>>>>>>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>>>>>>
>>>>>>> http://blog.facilelogin.com
>>>>>>> http://RampartFAQ.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>  --
>>>>>> Thanks & Regards,
>>>>>> Prabath
>>>>>>
>>>>>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>>>>>
>>>>>> http://blog.facilelogin.com
>>>>>> http://RampartFAQ.com
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>  --
>>>>> Thanks & Regards,
>>>>> Prabath
>>>>>
>>>>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>>>>
>>>>> http://blog.facilelogin.com
>>>>> http://RampartFAQ.com
>>>>>
>>>>>  _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>  --
>>>> Thanks & Regards,
>>>> Prabath
>>>>
>>>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>>>
>>>> http://blog.facilelogin.com
>>>> http://RampartFAQ.com
>>>>
>>>
>>>
>>>
>>>  --
>>> Thanks & Regards,
>>> Prabath
>>>
>>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>>
>>> http://blog.facilelogin.com
>>> http://RampartFAQ.com
>>>
>>>
>>>
>>
>>
>>  --
>> Thanks & Regards,
>> Prabath
>>
>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>
>> http://blog.facilelogin.com
>> http://RampartFAQ.com
>>
>
>
>
>  --
> Thanks & Regards,
> Prabath
>
>  Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com
>
>
>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.com

--047d7b343a9e0b048704d5b0116e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Okay. With out knowing the type of the token how can the AS validate the to=
ken ? What is meant by the validity there?
Thanks & =
regards,
-Prabath

On Thu, Feb 1=
4, 2013 at 7:55 PM, Justin Richer <jricher@mitre.org> wrote:=

 =20
   =20
 =20

    OK, I don't see the utility in that at all. What would it
    accomplish?

    =A0-- Justin

    On 02/14/2013 09:25 AM, Prabath
      Siriwardena wrote:

     =20
      To make it clear - my suggestion is to add token_type_hint to the
      introspection request. It can be from client to AS or from RS to
      AS.

      Then AS can decide whether the provided token is valid or not
        and include "valid" attribute in the introspection respon=
se.

      Thanks & regards,
      -Prabath

        On Thu, Feb 14, 2013 at 7:52 PM,
          Prabath Siriwardena <prabath@wso2.com> wrote:

          Both the
            client and the resource owner should be aware of the token
            type.

            My argument is, if the authorization server to decide
              whether the token is valid or not ( irrespective of who
              asked the question) - AS needs to know the token type -
              because to validate a token AS should know the token type.

            The token type could be, bearer or MAC or any other
              token type.

            Thanks & regards,
            -Prabath

                  On Thu, Feb 14, 2013 at 7:33
                    PM, Justin Richer <jricher@mitre.org>
                    wrote:

                       What
                        exactly are you suggesting be added to
                        introspection? The "token_type_hint" is f=
rom the
                        client to the server, but what you've asked for
                        in terms of "token type" is from the serv=
er to
                        the client. And there was never an answer to
                        what exactly is meant by "token type" in =
this
                        case, particularly because you seem to want to
                        call out things like SAML and Bearer as separate
                        types. 

                            =A0-- Justin

                            On 02/14/2013 06:59 AM, Prabath
                              Siriwardena wrote:

                             I noticed that the
                              latest Token Revocation draft [1] has
                              introduced the parameter
                              "token_type_hint". I would suggest =
the
                              same here, as that would make what is
                              meant by "valid" much clear..

                              [1]:=A0http=
://tools.ietf.org/html/draft-ietf-oauth-revocation-05

                              Thanks & regards,
                              -Prabath

                                On Tue, Feb 12,
                                  2013 at 9:35 PM, Prabath Siriwardena <pra=
bath@wso2.com>
                                  wrote:

                                  Hi Justi=
n,

                                    I doubt whether valid_token
                                      would make a difference..?

                                    My initial argument is what is
                                      the validation criteria..?
                                      Validation criteria depends on the
                                      token_type..

                                    If we are talking only about
                                      metadata - then I believe
                                      "revoked", "expired&qu=
ot; would be more
                                      meaningful..

                                    Thanks & regards,
                                    -Prabath

                                           On
                                            Tue, Feb 12, 2013 at 7:53
                                            PM, Justin Richer <jricher@mit=
re.org>
                                            wrote:

                                               OK, I
                                                can see the wisdom in
                                                changing this term. 

                                                I picked "valid" =
because
                                                I wanted a simple
                                                "boolean" value t=
hat
                                                would require no
                                                additional parsing or
                                                string-matching on the
                                                client's behalf, and I&=
#39;d
                                                like to stick with that.
                                                OAuth is built with the
                                                assumption that clients
                                                need to be able to
                                                recover from invalid
                                                tokens at any stage, so
                                                I think a simple yes/no
                                                is the right step here.

                                                That said, I think
                                                you're both right that
                                                "valid" seems to =
have
                                                caused a bit of
                                                confusion. I don't want
                                                to go with "revoked&qu=
ot;
                                                because I'd rather have
                                                the "token is OK"=
 be the
                                                positive boolean value.

                                                Would "valid_token&quo=
t; be
                                                more clear? Or do we
                                                need a different
                                                adjective all together?

                                                    =A0-- Justin

                                                    On 02/11/2013
                                                      08:02 PM, Richard
                                                      Harrington wrote:

                                                      Have you
                                                        considered
                                                        "status" =
instead
                                                        of "valid"=
;? =A0It
                                                        could have
                                                        values like
                                                        "active",
                                                        "expired"=
, and
                                                        "revoked"=
.

                                                      Is it
                                                        worthwhile
                                                        including the
                                                        status of the
                                                        client also?
                                                        =A0For example, a
                                                        client
                                                        application
                                                        could be
                                                        disabled,
                                                        temporarily or
                                                        permanently, and
                                                        thus disabling
                                                        its access
                                                        tokens as well.

                                                        On Feb 11, 2013,
                                                        at 1:56 PM,
                                                        Prabath
                                                        Siriwardena <prabath@wso2.com>

                                                        wrote:

                                                        I guess
                                                          confusion is
                                                          with 'valid&#=
39;
                                                          parameter is
                                                          in the
                                                          response..

                                                          I thought
                                                          this will be
                                                          helpful
                                                          to=A0standardize=
=A0the
                                                          communication
                                                          between
                                                          Resource
                                                          Server and the
                                                          Authorization
                                                          Server..

                                                          I would
                                                          suggest we
                                                          completely
                                                          remove "vali=
d"
                                                          from the
                                                          response - or
                                                          define it much
                                                          clearly..

                                                          May be
                                                          can add
                                                          "revoked&quo=
t; with
                                                          a boolean
                                                          attribute..

                                                          Thanks
                                                          & regards,
                                                          -Prabath

                                                          On
                                                          Tue, Feb 12,
                                                          2013 at 3:19
                                                          AM, Justin
                                                          Richer <jricher=
@mitre.org>
                                                          wrote:

                                                          On
                                                          02/08/2013
                                                          12:51 AM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          Hi=A0Justin,

                                                          I have
                                                          couple of
                                                          questions
                                                          related to
                                                          "valid"
                                                          parameter...

                                                          This
                                                          endpoint can
                                                          be invoked by
                                                          the Resource
                                                          Server in
                                                          runtime...

                                                          That's
                                                          correct.

                                                          In that
                                                          case what is
                                                          exactly meant
                                                          by the
                                                          "resource_id=
"
                                                          in request ?

                                                          The
                                                          resource_id
                                                          field is a
                                                          service-specific
                                                          string that
                                                          basically lets
                                                          the resource
                                                          server provide
                                                          some context
                                                          to the request
                                                          to the auth
                                                          server. There
                                                          have been some
                                                          other
                                                          suggestions
                                                          like client IP
                                                          address, but I
                                                          wanted to put
                                                          this one in
                                                          because it
                                                          seemed to be a
                                                          common theme.
                                                          The client is
                                                          trying to do
                                                          *something*
                                                          with the
                                                          token, after
                                                          all, and the
                                                          rights,
                                                          permissions,
                                                          and metadata
                                                          associated
                                                          with the token
                                                          could change
                                                          based on that.
                                                          Since the
                                                          Introspection
                                                          endpoint is
                                                          all about
                                                          getting that
                                                          metadata back
                                                          to the PR,
                                                          this seemed
                                                          like a good
                                                          idea.

                                                          IMO a
                                                          token to be
                                                          valid depends
                                                          on set of
                                                          criteria based
                                                          on it's type.=
.

                                                          For a
                                                          Bearer token..

                                                          1. Token
                                                          should not be
                                                          expired
                                                          2. Token
                                                          should not be
                                                          revoked.
                                                          3. The
                                                          scope the
                                                          token issued
                                                          should match
                                                          with the scope
                                                          required for
                                                          the resource.

                                                          For a MAC
                                                          token...

                                                          1. Token
                                                          not expired
                                                          (mac id)
                                                          2. Token
                                                          should not be
                                                          revoked
                                                          3. The
                                                          scope the
                                                          token issued
                                                          should match
                                                          with the scope
                                                          required for
                                                          the resource.
                                                          4. HMAC
                                                          check should
                                                          be valid

                                                          There are
                                                          similar
                                                          conditions for
                                                          SAML bearer
                                                          too..

                                                          This isn't
                                                          really true.
                                                          The SAML
                                                          bearer token
                                                          is fully
                                                          self-contained
                                                          and doesn't
                                                          change based
                                                          on other
                                                          parameters in
                                                          the message,
                                                          unlike MAC.
                                                          Same with JWT.
                                                          When it hands
                                                          a SAML or JWT
                                                          token to the
                                                          AS, the PR has
                                                          given
                                                          *everything*
                                                          the server
                                                          needs to check
                                                          that token's
                                                          validity and
                                                          use. 

                                                          MAC signatures
                                                          change with
                                                          every message,
                                                          and they're
                                                          done across
                                                          several
                                                          components of
                                                          the HTTP
                                                          message.
                                                          Therefor, the
                                                          HMAC check for
                                                          MAC style
                                                          tokens will
                                                          still need to
                                                          be done by the
                                                          protected
                                                          resource.
                                                          Introspection
                                                          would help in
                                                          the case that
                                                          the signature
                                                          validated just
                                                          fine, but the
                                                          token might
                                                          have expired.
                                                          Or you need to
                                                          know what
                                                          scopes apply.
                                                          Introspection
                                                          isn't to full=
y
                                                          validate the
                                                          call to the
                                                          protected
                                                          resource -- if
                                                          that were the
                                                          case, the PR
                                                          would have to
                                                          send some kind
                                                          of
                                                          encapsulated
                                                          version of the
                                                          original
                                                          request.
                                                          Otherwise, the
                                                          AS won't have
                                                          all of the
                                                          information it
                                                          needs to check
                                                          the MAC.

                                                          I think what
                                                          you're
                                                          describing is
                                                          ultimately
                                                          *not* what the
                                                          introspection
                                                          endpoint is
                                                          intended to
                                                          do. If that's
                                                          unclear from
                                                          the document,
                                                          can you please
                                                          suggest text
                                                          that would
                                                          help clear the
                                                          use case up? I
                                                          wouldn't want
                                                          it to be
                                                          ambiguous.<=
font color=3D"#888888">

                                                          =A0-- Justin

                                                          Thanks
                                                          & regards,
                                                          -Prabath

                                                          On

                                                          Thu, Feb 7,
                                                          2013 at 10:30
                                                          PM, Justin
                                                          Richer <jricher=
@mitre.org>
                                                          wrote:

                                                          It validates
                                                          the token,
                                                          which would be
                                                          either the
                                                          token itself
                                                          in the case of
                                                          Bearer or the
                                                          token "id&qu=
ot;
                                                          part of
                                                          something more
                                                          complex like
                                                          MAC. It
                                                          doesn't
                                                          directly
                                                          validate the
                                                          usage of the
                                                          token, that's
                                                          still up to
                                                          the PR to do
                                                          that.

                                                          I nearly added
                                                          a "token typ=
e"
                                                          field in this
                                                          draft, but
                                                          held back
                                                          because there
                                                          are several
                                                          kinds of
                                                          "token type&=
quot;
                                                          that people
                                                          talk about in
                                                          OAuth. First,
                                                          there's
                                                          "Bearer"=
; vs.
                                                          "MAC" v=
s.
                                                          "HOK", =
or what
                                                          have you. Then
                                                          within Bearer
                                                          you have "JW=
T"
                                                          or "SAML&quo=
t; or
                                                          "unstructure=
d
                                                          blob". Then
                                                          you've also
                                                          got "access&=
quot;
                                                          vs. "refresh=
"
                                                          and other
                                                          flavors of
                                                          token, like
                                                          the id_token
                                                          in OpenID
                                                          Connect. 

                                                          Thing is, the
                                                          server running
                                                          the
                                                          introspection
                                                          endpoint will
                                                          probably know
                                                          *all* of
                                                          these. But
                                                          should it tell
                                                          the client? If
                                                          so, which of
                                                          the three, and
                                                          what names
                                                          should the
                                                          fields be?<=
font color=3D"#888888">

                                                          =A0-- Justin

                                                          On
                                                          02/07/2013
                                                          11:26 AM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          Okay.. I was
                                                          thinking this
                                                          could be used
                                                          as a way to
                                                          validate the
                                                          token as well.
                                                          BTW even in
                                                          this case
                                                          shouldn't
                                                          communicate
                                                          the type of
                                                          token to AS?
                                                          For example in
                                                          the case of
                                                          SAML profile -
                                                          it could be
                                                          SAML token..

                                                          Thanks
                                                          & regards,
                                                          -Prabath

                                                          On

                                                          Thu, Feb 7,
                                                          2013 at 8:39
                                                          PM, Justin
                                                          Richer <jricher=
@mitre.org>
                                                          wrote:

                                                          "valid"=
 might
                                                          not be the
                                                          best term, but
                                                          it's meant to
                                                          be a field
                                                          where the
                                                          server says
                                                          "yes this
                                                          token is still
                                                          good" or &qu=
ot;no
                                                          this token
                                                          isn't good
                                                          anymore". We
                                                          could instead
                                                          do this with
                                                          HTTP codes or
                                                          something but
                                                          I went with a
                                                          pure JSON
                                                          response.

                                                          =A0-- Justin

                                                          On
                                                          02/06/2013
                                                          10:47 PM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          Hi Justin,

                                                          I believe
                                                          this is
                                                          addressing one
                                                          of the key
                                                          missing part
                                                          in OAuth
                                                          2.0...

                                                          One
                                                          question - I
                                                          guess this was
                                                          discussed
                                                          already...

                                                          In the
                                                          spec - in the
                                                          introspection
                                                          response it
                                                          has the
                                                          attribute
                                                          "valid"=
 - this
                                                          is basically
                                                          the validity
                                                          of the token
                                                          provided in
                                                          the request.

                                                          Validation=
=A0criteria

                                                          depends on the
                                                          token and well
                                                          as token type
                                                          ( Bearer,
                                                          MAC..).

                                                          In the
                                                          spec it seems
                                                          like it's
                                                          coupled with
                                                          Bearer token
                                                          type... But I
                                                          guess, by
                                                          adding
                                                          "token_type&=
quot;
                                                          to the request
                                                          we can remove
                                                          this
                                                          dependency.

                                                          WDYT..?

                                                          Thanks
                                                          & regards,
                                                          -Prabath=A0<=
/div>

                                                          On

                                                          Thu, Feb 7,
                                                          2013 at 12:54
                                                          AM, Justin
                                                          Richer <jricher=
@mitre.org>
                                                          wrote:

                                                          Updated
                                                          introspection
                                                          draft based on
                                                          recent
                                                          comments.
                                                          Changes
                                                          include:

                                                          =A0- "scope&=
quot;
                                                          return
                                                          parameter now
                                                          follows
                                                          RFC6749 format
                                                          instead of
                                                          JSON array

                                                          =A0- "subjec=
t"
                                                          -> "sub&q=
uot;,
                                                          and "audienc=
e"
                                                          -> "aud&q=
uot;,
                                                          to be parallel
                                                          with JWT
                                                          claims

                                                          =A0- clarified
                                                          what happens
                                                          if the
                                                          authentication
                                                          is bad

                                                          =A0-- Justin

                                                          --------
                                                          Original
                                                          Message
                                                          --------

                                                          Subject: 
                                                          New
                                                          Version
                                                          Notification
                                                          for
                                                          draft-richer-oaut=
h-introspection-02.txt

                                                          Date: 
                                                          Wed, 6 Feb
                                                          2013 11:24:20
                                                          -0800

                                                          From: 
                                                          <internet-drafts@ietf.o=
rg>

                                                          To: 
                                                          <jricher@mitre.org>

                                                          A new versio=
n of I-D, draft-richer-oauth-introspection-02.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 02
Title:		 OAuth Token Introspection
Creation date:	 2013-02-06
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/interne=
t-drafts/draft-richer-oauth-introspection-02.txt
Status:          http://datatracker.ietf.org/doc/draft-=
richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-=
oauth-introspection-02
Diff:            http://www.ietf.org/rfcdiff?url2=
=3Ddraft-richer-oauth-introspection-02

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.

                                                                           =
      =20

The IETF Secretariat

_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

                                                          https://www.ietf.o=
rg/mailman/listinfo/oauth

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732=
=A0

                                                          http://blog.facilelogin.com
                                                          http://RampartFAQ.com

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732=
=A0

                                                          http://blog.facilelogin.com
                                                          http://RampartFAQ.com

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732=
=A0

                                                          http://blog.facilelogin.com
                                                          http://RampartFAQ.com

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94
                                                          71 809 6732=
=A0

                                                          http://blog.facilelogin.com
                                                          http://RampartFAQ.com

                                                        ________=
_______________________________________

                                                          OAuth
                                                          mailing list

                                                          OAuth@ietf.org

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

                                          -- 

                                          Thanks & Regards,

                                          Prabath

                                          Mobile : +94 71 809
                                              6732=A0

                                            http://blog.facilelogin.com

                                            http://RampartFAQ.com

                                -- 

                                Thanks & Regards,

                                Prabath

                                Mobile : +94
                                    71 809 6732=A0

                                  http://blog.facilelogin.com

                                  http://RampartFAQ.com

                  -- 

                  Thanks & Regards,

                  Prabath

                  Mobile : +94 71 809
                      6732=A0

                    http://blog.facilelogin.com

                    htt=
p://RampartFAQ.com

        -- 

        Thanks & Regards,

        Prabath

        Mobile : +94 71 809 6732=A0

          http://=
blog.facilelogin.com

          http://Rampar=
tFAQ.com

-- 
Thanks &=
 Regards,
Prabath
Mobile : +94 71 809 6732=A0

=
http://blog.facil=
elogin.com

http://RampartFAQ.com

--047d7b343a9e0b048704d5b0116e--

From jricher@mitre.org  Thu Feb 14 06:29:49 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9383921F8682 for ; Thu, 14 Feb 2013 06:29:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.57
X-Spam-Level: 
X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.028,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmR+gI+oEL0C for ; Thu, 14 Feb 2013 06:29:47 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1148521F8691 for ; Thu, 14 Feb 2013 06:29:46 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 917A45310DC7; Thu, 14 Feb 2013 09:29:45 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7D20E5310DC5; Thu, 14 Feb 2013 09:29:45 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 14 Feb 2013 09:29:45 -0500
Message-ID: <511CF4AB.5010700@mitre.org>
Date: Thu, 14 Feb 2013 09:28:59 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Prabath Siriwardena 
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com> <5112AE0B.1080501@mitre.org>  <5113C3AA.1040701@mitre.org>  <5113DDB2.7060805@mitre.org>  <51196777.6000502@mitre.org>   <511A5062.5010108@mitre.org>   <511CEEAA.3030801@mitre.org>   <511CF3EF.8040008@mitre.org> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090306090907080103010008"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2013 14:29:49 -0000

--------------090306090907080103010008
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Because it will be the one that issued the token in the first place.

Validity means "token was issued from here, it hasn't been revoked, it 
hasn't expired".

  -- Justin

On 02/14/2013 09:28 AM, Prabath Siriwardena wrote:
> Okay. With out knowing the type of the token how can the AS validate 
> the token ? What is meant by the validity there?
>
> Thanks & regards,
> -Prabath
>
> On Thu, Feb 14, 2013 at 7:55 PM, Justin Richer  > wrote:
>
>     OK, I don't see the utility in that at all. What would it accomplish?
>
>      -- Justin
>
>
>     On 02/14/2013 09:25 AM, Prabath Siriwardena wrote:
>>     To make it clear - my suggestion is to add token_type_hint to the
>>     introspection request. It can be from client to AS or from RS to AS.
>>
>>     Then AS can decide whether the provided token is valid or not and
>>     include "valid" attribute in the introspection response.
>>
>>     Thanks & regards,
>>     -Prabath
>>
>>     On Thu, Feb 14, 2013 at 7:52 PM, Prabath Siriwardena
>>     > wrote:
>>
>>         Both the client and the resource owner should be aware of the
>>         token type.
>>
>>         My argument is, if the authorization server to decide whether
>>         the token is valid or not ( irrespective of who asked the
>>         question) - AS needs to know the token type - because to
>>         validate a token AS should know the token type.
>>
>>         The token type could be, bearer or MAC or any other token type.
>>
>>         Thanks & regards,
>>         -Prabath
>>
>>
>>         On Thu, Feb 14, 2013 at 7:33 PM, Justin Richer
>>         > wrote:
>>
>>             What exactly are you suggesting be added to
>>             introspection? The "token_type_hint" is from the client
>>             to the server, but what you've asked for in terms of
>>             "token type" is from the server to the client. And there
>>             was never an answer to what exactly is meant by "token
>>             type" in this case, particularly because you seem to want
>>             to call out things like SAML and Bearer as separate types.
>>
>>              -- Justin
>>
>>
>>
>>             On 02/14/2013 06:59 AM, Prabath Siriwardena wrote:
>>>             I noticed that the latest Token Revocation draft [1] has
>>>             introduced the parameter "token_type_hint". I would
>>>             suggest the same here, as that would make what is meant
>>>             by "valid" much clear..
>>>
>>>             [1]:
>>>             http://tools.ietf.org/html/draft-ietf-oauth-revocation-05
>>>
>>>             Thanks & regards,
>>>             -Prabath
>>>
>>>             On Tue, Feb 12, 2013 at 9:35 PM, Prabath Siriwardena
>>>             > wrote:
>>>
>>>                 Hi Justin,
>>>
>>>                 I doubt whether valid_token would make a difference..?
>>>
>>>                 My initial argument is what is the validation
>>>                 criteria..? Validation criteria depends on the
>>>                 token_type..
>>>
>>>                 If we are talking only about metadata - then I
>>>                 believe "revoked", "expired" would be more meaningful..
>>>
>>>                 Thanks & regards,
>>>                 -Prabath
>>>
>>>
>>>                 On Tue, Feb 12, 2013 at 7:53 PM, Justin Richer
>>>                 > wrote:
>>>
>>>                     OK, I can see the wisdom in changing this term.
>>>
>>>                     I picked "valid" because I wanted a simple
>>>                     "boolean" value that would require no additional
>>>                     parsing or string-matching on the client's
>>>                     behalf, and I'd like to stick with that. OAuth
>>>                     is built with the assumption that clients need
>>>                     to be able to recover from invalid tokens at any
>>>                     stage, so I think a simple yes/no is the right
>>>                     step here.
>>>
>>>                     That said, I think you're both right that
>>>                     "valid" seems to have caused a bit of confusion.
>>>                     I don't want to go with "revoked" because I'd
>>>                     rather have the "token is OK" be the positive
>>>                     boolean value.
>>>
>>>                     Would "valid_token" be more clear? Or do we need
>>>                     a different adjective all together?
>>>
>>>                      -- Justin
>>>
>>>
>>>                     On 02/11/2013 08:02 PM, Richard Harrington wrote:
>>>>                     Have you considered "status" instead of
>>>>                     "valid"?  It could have values like "active",
>>>>                     "expired", and "revoked".
>>>>
>>>>                     Is it worthwhile including the status of the
>>>>                     client also?  For example, a client application
>>>>                     could be disabled, temporarily or permanently,
>>>>                     and thus disabling its access tokens as well.
>>>>
>>>>
>>>>                     On Feb 11, 2013, at 1:56 PM, Prabath
>>>>                     Siriwardena >>>                     > wrote:
>>>>
>>>>>                     I guess confusion is with 'valid' parameter is
>>>>>                     in the response..
>>>>>
>>>>>                     I thought this will be helpful
>>>>>                     to standardize the communication between
>>>>>                     Resource Server and the Authorization Server..
>>>>>
>>>>>                     I would suggest we completely remove "valid"
>>>>>                     from the response - or define it much clearly..
>>>>>
>>>>>                     May be can add "revoked" with a boolean
>>>>>                     attribute..
>>>>>
>>>>>                     Thanks & regards,
>>>>>                     -Prabath
>>>>>
>>>>>                     On Tue, Feb 12, 2013 at 3:19 AM, Justin Richer
>>>>>                     >
>>>>>                     wrote:
>>>>>
>>>>>
>>>>>                         On 02/08/2013 12:51 AM, Prabath
>>>>>                         Siriwardena wrote:
>>>>>>                         Hi Justin,
>>>>>>
>>>>>>                         I have couple of questions related to
>>>>>>                         "valid" parameter...
>>>>>>
>>>>>>                         This endpoint can be invoked by the
>>>>>>                         Resource Server in runtime...
>>>>>
>>>>>                         That's correct.
>>>>>
>>>>>
>>>>>>
>>>>>>                         In that case what is exactly meant by the
>>>>>>                         "resource_id" in request ?
>>>>>
>>>>>                         The resource_id field is a
>>>>>                         service-specific string that basically
>>>>>                         lets the resource server provide some
>>>>>                         context to the request to the auth server.
>>>>>                         There have been some other suggestions
>>>>>                         like client IP address, but I wanted to
>>>>>                         put this one in because it seemed to be a
>>>>>                         common theme. The client is trying to do
>>>>>                         *something* with the token, after all, and
>>>>>                         the rights, permissions, and metadata
>>>>>                         associated with the token could change
>>>>>                         based on that. Since the Introspection
>>>>>                         endpoint is all about getting that
>>>>>                         metadata back to the PR, this seemed like
>>>>>                         a good idea.
>>>>>
>>>>>
>>>>>>
>>>>>>                         IMO a token to be valid depends on set of
>>>>>>                         criteria based on it's type..
>>>>>>
>>>>>>                         For a Bearer token..
>>>>>>
>>>>>>                         1. Token should not be expired
>>>>>>                         2. Token should not be revoked.
>>>>>>                         3. The scope the token issued should
>>>>>>                         match with the scope required for the
>>>>>>                         resource.
>>>>>>
>>>>>>                         For a MAC token...
>>>>>>
>>>>>>                         1. Token not expired (mac id)
>>>>>>                         2. Token should not be revoked
>>>>>>                         3. The scope the token issued should
>>>>>>                         match with the scope required for the
>>>>>>                         resource.
>>>>>>                         4. HMAC check should be valid
>>>>>>
>>>>>>                         There are similar conditions for SAML
>>>>>>                         bearer too..
>>>>>
>>>>>                         This isn't really true. The SAML bearer
>>>>>                         token is fully self-contained and doesn't
>>>>>                         change based on other parameters in the
>>>>>                         message, unlike MAC. Same with JWT. When
>>>>>                         it hands a SAML or JWT token to the AS,
>>>>>                         the PR has given *everything* the server
>>>>>                         needs to check that token's validity and use.
>>>>>
>>>>>                         MAC signatures change with every message,
>>>>>                         and they're done across several components
>>>>>                         of the HTTP message. Therefor, the HMAC
>>>>>                         check for MAC style tokens will still need
>>>>>                         to be done by the protected resource.
>>>>>                         Introspection would help in the case that
>>>>>                         the signature validated just fine, but the
>>>>>                         token might have expired. Or you need to
>>>>>                         know what scopes apply. Introspection
>>>>>                         isn't to fully validate the call to the
>>>>>                         protected resource -- if that were the
>>>>>                         case, the PR would have to send some kind
>>>>>                         of encapsulated version of the original
>>>>>                         request. Otherwise, the AS won't have all
>>>>>                         of the information it needs to check the MAC.
>>>>>
>>>>>
>>>>>                         I think what you're describing is
>>>>>                         ultimately *not* what the introspection
>>>>>                         endpoint is intended to do. If that's
>>>>>                         unclear from the document, can you please
>>>>>                         suggest text that would help clear the use
>>>>>                         case up? I wouldn't want it to be ambiguous.
>>>>>
>>>>>                          -- Justin
>>>>>
>>>>>
>>>>>>
>>>>>>                         Thanks & regards,
>>>>>>                         -Prabath
>>>>>>
>>>>>>
>>>>>>                         On Thu, Feb 7, 2013 at 10:30 PM, Justin
>>>>>>                         Richer >>>>>                         > wrote:
>>>>>>
>>>>>>                             It validates the token, which would
>>>>>>                             be either the token itself in the
>>>>>>                             case of Bearer or the token "id" part
>>>>>>                             of something more complex like MAC.
>>>>>>                             It doesn't directly validate the
>>>>>>                             usage of the token, that's still up
>>>>>>                             to the PR to do that.
>>>>>>
>>>>>>                             I nearly added a "token type" field
>>>>>>                             in this draft, but held back because
>>>>>>                             there are several kinds of "token
>>>>>>                             type" that people talk about in
>>>>>>                             OAuth. First, there's "Bearer" vs.
>>>>>>                             "MAC" vs. "HOK", or what have you.
>>>>>>                             Then within Bearer you have "JWT" or
>>>>>>                             "SAML" or "unstructured blob". Then
>>>>>>                             you've also got "access" vs.
>>>>>>                             "refresh" and other flavors of token,
>>>>>>                             like the id_token in OpenID Connect.
>>>>>>
>>>>>>                             Thing is, the server running the
>>>>>>                             introspection endpoint will probably
>>>>>>                             know *all* of these. But should it
>>>>>>                             tell the client? If so, which of the
>>>>>>                             three, and what names should the
>>>>>>                             fields be?
>>>>>>
>>>>>>                              -- Justin
>>>>>>
>>>>>>
>>>>>>                             On 02/07/2013 11:26 AM, Prabath
>>>>>>                             Siriwardena wrote:
>>>>>>>                             Okay.. I was thinking this could be
>>>>>>>                             used as a way to validate the token
>>>>>>>                             as well. BTW even in this case
>>>>>>>                             shouldn't communicate the type of
>>>>>>>                             token to AS? For example in the case
>>>>>>>                             of SAML profile - it could be SAML
>>>>>>>                             token..
>>>>>>>
>>>>>>>                             Thanks & regards,
>>>>>>>                             -Prabath
>>>>>>>
>>>>>>>                             On Thu, Feb 7, 2013 at 8:39 PM,
>>>>>>>                             Justin Richer >>>>>>                             > wrote:
>>>>>>>
>>>>>>>                                 "valid" might not be the best
>>>>>>>                                 term, but it's meant to be a
>>>>>>>                                 field where the server says "yes
>>>>>>>                                 this token is still good" or "no
>>>>>>>                                 this token isn't good anymore".
>>>>>>>                                 We could instead do this with
>>>>>>>                                 HTTP codes or something but I
>>>>>>>                                 went with a pure JSON response.
>>>>>>>
>>>>>>>                                  -- Justin
>>>>>>>
>>>>>>>
>>>>>>>                                 On 02/06/2013 10:47 PM, Prabath
>>>>>>>                                 Siriwardena wrote:
>>>>>>>>                                 Hi Justin,
>>>>>>>>
>>>>>>>>                                 I believe this is addressing
>>>>>>>>                                 one of the key missing part in
>>>>>>>>                                 OAuth 2.0...
>>>>>>>>
>>>>>>>>                                 One question - I guess this was
>>>>>>>>                                 discussed already...
>>>>>>>>
>>>>>>>>                                 In the spec - in the
>>>>>>>>                                 introspection response it has
>>>>>>>>                                 the attribute "valid" - this is
>>>>>>>>                                 basically the validity of the
>>>>>>>>                                 token provided in the request.
>>>>>>>>
>>>>>>>>                                 Validation criteria depends on
>>>>>>>>                                 the token and well as token
>>>>>>>>                                 type ( Bearer, MAC..).
>>>>>>>>
>>>>>>>>                                 In the spec it seems like it's
>>>>>>>>                                 coupled with Bearer token
>>>>>>>>                                 type... But I guess, by adding
>>>>>>>>                                 "token_type" to the request we
>>>>>>>>                                 can remove this dependency.
>>>>>>>>
>>>>>>>>                                 WDYT..?
>>>>>>>>
>>>>>>>>                                 Thanks & regards,
>>>>>>>>                                 -Prabath
>>>>>>>>
>>>>>>>>                                 On Thu, Feb 7, 2013 at 12:54
>>>>>>>>                                 AM, Justin Richer
>>>>>>>>                                 >>>>>>>                                 > wrote:
>>>>>>>>
>>>>>>>>                                     Updated introspection draft
>>>>>>>>                                     based on recent comments.
>>>>>>>>                                     Changes include:
>>>>>>>>
>>>>>>>>                                      - "scope" return parameter
>>>>>>>>                                     now follows RFC6749 format
>>>>>>>>                                     instead of JSON array
>>>>>>>>                                      - "subject" -> "sub", and
>>>>>>>>                                     "audience" -> "aud", to be
>>>>>>>>                                     parallel with JWT claims
>>>>>>>>                                      - clarified what happens
>>>>>>>>                                     if the authentication is bad
>>>>>>>>
>>>>>>>>                                      -- Justin
>>>>>>>>
>>>>>>>>
>>>>>>>>                                     -------- Original Message
>>>>>>>>                                     --------
>>>>>>>>                                     Subject: 	New Version
>>>>>>>>                                     Notification for
>>>>>>>>                                     draft-richer-oauth-introspection-02.txt
>>>>>>>>
>>>>>>>>                                     Date: 	Wed, 6 Feb 2013
>>>>>>>>                                     11:24:20 -0800
>>>>>>>>                                     From:
>>>>>>>>                                     
>>>>>>>>                                     
>>>>>>>>
>>>>>>>>                                     To: 	
>>>>>>>>                                     
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                                     A new version of I-D, draft-richer-oauth-introspection-02.txt
>>>>>>>>                                     has been successfully submitted by Justin Richer and posted to the
>>>>>>>>                                     IETF repository.
>>>>>>>>
>>>>>>>>                                     Filename:	 draft-richer-oauth-introspection
>>>>>>>>                                     Revision:	 02
>>>>>>>>                                     Title:		 OAuth Token Introspection
>>>>>>>>                                     Creation date:	 2013-02-06
>>>>>>>>                                     WG ID:		 Individual Submission
>>>>>>>>                                     Number of pages: 6
>>>>>>>>                                     URL:http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
>>>>>>>>                                     Status:http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
>>>>>>>>                                     Htmlized:http://tools.ietf.org/html/draft-richer-oauth-introspection-02
>>>>>>>>                                     Diff:http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02
>>>>>>>>
>>>>>>>>                                     Abstract:
>>>>>>>>                                         This specification defines a method for a client or protected
>>>>>>>>                                         resource to query an OAuth authorization server to determine meta-
>>>>>>>>                                         information about an OAuth token.
>>>>>>>>
>>>>>>>>
>>>>>>>>                                                                                                                        
>>>>>>>>
>>>>>>>>
>>>>>>>>                                     The IETF Secretariat
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                                     _______________________________________________
>>>>>>>>                                     OAuth mailing list
>>>>>>>>                                     OAuth@ietf.org
>>>>>>>>                                     
>>>>>>>>                                     https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                                 -- 
>>>>>>>>                                 Thanks & Regards,
>>>>>>>>                                 Prabath
>>>>>>>>
>>>>>>>>                                 Mobile : +94 71 809 6732
>>>>>>>>                                 
>>>>>>>>
>>>>>>>>                                 http://blog.facilelogin.com
>>>>>>>>                                 http://RampartFAQ.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                             -- 
>>>>>>>                             Thanks & Regards,
>>>>>>>                             Prabath
>>>>>>>
>>>>>>>                             Mobile : +94 71 809 6732
>>>>>>>                             
>>>>>>>
>>>>>>>                             http://blog.facilelogin.com
>>>>>>>                             http://RampartFAQ.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>                         -- 
>>>>>>                         Thanks & Regards,
>>>>>>                         Prabath
>>>>>>
>>>>>>                         Mobile : +94 71 809 6732
>>>>>>                         
>>>>>>
>>>>>>                         http://blog.facilelogin.com
>>>>>>                         http://RampartFAQ.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>                     -- 
>>>>>                     Thanks & Regards,
>>>>>                     Prabath
>>>>>
>>>>>                     Mobile : +94 71 809 6732
>>>>>                     
>>>>>
>>>>>                     http://blog.facilelogin.com
>>>>>                     http://RampartFAQ.com
>>>>>                     _______________________________________________
>>>>>                     OAuth mailing list
>>>>>                     OAuth@ietf.org 
>>>>>                     https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>>
>>>                 -- 
>>>                 Thanks & Regards,
>>>                 Prabath
>>>
>>>                 Mobile : +94 71 809 6732 
>>>
>>>                 http://blog.facilelogin.com
>>>                 http://RampartFAQ.com
>>>
>>>
>>>
>>>
>>>             -- 
>>>             Thanks & Regards,
>>>             Prabath
>>>
>>>             Mobile : +94 71 809 6732 
>>>
>>>             http://blog.facilelogin.com
>>>             http://RampartFAQ.com
>>
>>
>>
>>
>>         -- 
>>         Thanks & Regards,
>>         Prabath
>>
>>         Mobile : +94 71 809 6732 
>>
>>         http://blog.facilelogin.com
>>         http://RampartFAQ.com
>>
>>
>>
>>
>>     -- 
>>     Thanks & Regards,
>>     Prabath
>>
>>     Mobile : +94 71 809 6732 
>>
>>     http://blog.facilelogin.com
>>     http://RampartFAQ.com
>
>
>
>
> -- 
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com

--------------090306090907080103010008
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

    Because it will be the one that issued the token in the first place.

    Validity means "token was issued from here, it hasn't been revoked,
    it hasn't expired". 

     -- Justin

    On 02/14/2013 09:28 AM, Prabath
      Siriwardena wrote:

      Okay. With out knowing the type of the token how can the AS
      validate the token ? What is meant by the validity there?

      Thanks & regards,
      -Prabath

        On Thu, Feb 14, 2013 at 7:55 PM, Justin
          Richer <jricher@mitre.org>
          wrote:

             OK, I don't see the
              utility in that at all. What would it accomplish?

                   -- Justin

                  On 02/14/2013 09:25 AM, Prabath Siriwardena
                    wrote:

                   To make it clear - my
                    suggestion is to add token_type_hint to the
                    introspection request. It can be from client to AS
                    or from RS to AS.

                    Then AS can decide whether the provided token
                      is valid or not and include "valid" attribute in
                      the introspection response.

                    Thanks & regards,
                    -Prabath

                      On Thu, Feb 14, 2013 at
                        7:52 PM, Prabath Siriwardena <prabath@wso2.com>
                        wrote:

                        Both the client and
                          the resource owner should be aware of the
                          token type.

                          My argument is, if the authorization
                            server to decide whether the token is valid
                            or not ( irrespective of who asked the
                            question) - AS needs to know the token type
                            - because to validate a token AS should know
                            the token type.

                          The token type could be, bearer or MAC or
                            any other token type.

                          Thanks & regards,
                          -Prabath

                                On Thu, Feb 14,
                                  2013 at 7:33 PM, Justin Richer <jricher@mitre.org>
                                  wrote:

                                     What exactly are
                                      you suggesting be added to
                                      introspection? The
                                      "token_type_hint" is from the
                                      client to the server, but what
                                      you've asked for in terms of
                                      "token type" is from the server to
                                      the client. And there was never an
                                      answer to what exactly is meant by
                                      "token type" in this case,
                                      particularly because you seem to
                                      want to call out things like SAML
                                      and Bearer as separate types. 

                                           -- Justin

                                          On 02/14/2013 06:59 AM,
                                            Prabath Siriwardena wrote:

                                           I
                                            noticed that the latest
                                            Token Revocation draft [1]
                                            has introduced the parameter
                                            "token_type_hint". I would
                                            suggest the same here, as
                                            that would make what is
                                            meant by "valid" much
                                            clear..

                                            [1]: http://tools.ietf.org/html/draft-ietf-oauth-revocation-05

                                            Thanks & regards,
                                            -Prabath

                                              On
                                                Tue, Feb 12, 2013 at
                                                9:35 PM, Prabath
                                                Siriwardena <prabath@wso2.com>
                                                wrote:

                                                Hi
                                                  Justin,

                                                  I doubt whether
                                                    valid_token would
                                                    make a difference..?

                                                  My initial
                                                    argument is what is
                                                    the validation
                                                    criteria..?
                                                    Validation criteria
                                                    depends on the
                                                    token_type..

                                                  If we are talking
                                                    only about metadata
                                                    - then I believe
                                                    "revoked", "expired"
                                                    would be more
                                                    meaningful..

                                                  Thanks &
                                                    regards,
                                                  -Prabath

                                                          On Tue, Feb
                                                          12, 2013 at
                                                          7:53 PM,
                                                          Justin Richer
                                                          <jricher@mitre.org>
                                                          wrote:

                                                          OK, I can see
                                                          the wisdom in
                                                          changing this
                                                          term. 

                                                          I picked
                                                          "valid"
                                                          because I
                                                          wanted a
                                                          simple
                                                          "boolean"
                                                          value that
                                                          would require
                                                          no additional
                                                          parsing or
                                                          string-matching
                                                          on the
                                                          client's
                                                          behalf, and
                                                          I'd like to
                                                          stick with
                                                          that. OAuth is
                                                          built with the
                                                          assumption
                                                          that clients
                                                          need to be
                                                          able to
                                                          recover from
                                                          invalid tokens
                                                          at any stage,
                                                          so I think a
                                                          simple yes/no
                                                          is the right
                                                          step here. 

                                                          That said, I
                                                          think you're
                                                          both right
                                                          that "valid"
                                                          seems to have
                                                          caused a bit
                                                          of confusion.
                                                          I don't want
                                                          to go with
                                                          "revoked"
                                                          because I'd
                                                          rather have
                                                          the "token is
                                                          OK" be the
                                                          positive
                                                          boolean value.

                                                          Would
                                                          "valid_token"
                                                          be more clear?
                                                          Or do we need
                                                          a different
                                                          adjective all
                                                          together?

                                                           -- Justin

                                                          On
                                                          02/11/2013
                                                          08:02 PM,
                                                          Richard
                                                          Harrington
                                                          wrote:

                                                          Have you
                                                          considered
                                                          "status"
                                                          instead of
                                                          "valid"?  It
                                                          could have
                                                          values like
                                                          "active",
                                                          "expired", and
                                                          "revoked".

                                                          Is it
                                                          worthwhile
                                                          including the
                                                          status of the
                                                          client also?
                                                           For example,
                                                          a client
                                                          application
                                                          could be
                                                          disabled,
                                                          temporarily or
                                                          permanently,
                                                          and thus
                                                          disabling its
                                                          access tokens
                                                          as well.

                                                          On Feb 11,
                                                          2013, at 1:56
                                                          PM, Prabath
                                                          Siriwardena
                                                          <prabath@wso2.com>
                                                          wrote:

                                                          I guess
                                                          confusion is
                                                          with 'valid'
                                                          parameter is
                                                          in the
                                                          response..

                                                          I thought
                                                          this will be
                                                          helpful
                                                          to standardize the
                                                          communication
                                                          between
                                                          Resource
                                                          Server and the
                                                          Authorization
                                                          Server..

                                                          I would
                                                          suggest we
                                                          completely
                                                          remove "valid"
                                                          from the
                                                          response - or
                                                          define it much
                                                          clearly..

                                                          May be
                                                          can add
                                                          "revoked" with
                                                          a boolean
                                                          attribute..

                                                          Thanks
                                                          & regards,
                                                          -Prabath

                                                          On

                                                          Tue, Feb 12,
                                                          2013 at 3:19
                                                          AM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:

                                                          On
                                                          02/08/2013
                                                          12:51 AM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          Hi Justin,

                                                          I have
                                                          couple of
                                                          questions
                                                          related to
                                                          "valid"
                                                          parameter...

                                                          This
                                                          endpoint can
                                                          be invoked by
                                                          the Resource
                                                          Server in
                                                          runtime...

                                                          That's
                                                          correct.

                                                          In that
                                                          case what is
                                                          exactly meant
                                                          by the
                                                          "resource_id"
                                                          in request ?

                                                          The
                                                          resource_id
                                                          field is a
                                                          service-specific
                                                          string that
                                                          basically lets
                                                          the resource
                                                          server provide
                                                          some context
                                                          to the request
                                                          to the auth
                                                          server. There
                                                          have been some
                                                          other
                                                          suggestions
                                                          like client IP
                                                          address, but I
                                                          wanted to put
                                                          this one in
                                                          because it
                                                          seemed to be a
                                                          common theme.
                                                          The client is
                                                          trying to do
                                                          *something*
                                                          with the
                                                          token, after
                                                          all, and the
                                                          rights,
                                                          permissions,
                                                          and metadata
                                                          associated
                                                          with the token
                                                          could change
                                                          based on that.
                                                          Since the
                                                          Introspection
                                                          endpoint is
                                                          all about
                                                          getting that
                                                          metadata back
                                                          to the PR,
                                                          this seemed
                                                          like a good
                                                          idea.

                                                          IMO a
                                                          token to be
                                                          valid depends
                                                          on set of
                                                          criteria based
                                                          on it's type..

                                                          For a
                                                          Bearer token..

                                                          1. Token
                                                          should not be
                                                          expired
                                                          2. Token
                                                          should not be
                                                          revoked.
                                                          3. The
                                                          scope the
                                                          token issued
                                                          should match
                                                          with the scope
                                                          required for
                                                          the resource.

                                                          For a MAC
                                                          token...

                                                          1. Token
                                                          not expired
                                                          (mac id)
                                                          2. Token
                                                          should not be
                                                          revoked
                                                          3. The
                                                          scope the
                                                          token issued
                                                          should match
                                                          with the scope
                                                          required for
                                                          the resource.
                                                          4. HMAC
                                                          check should
                                                          be valid

                                                          There are
                                                          similar
                                                          conditions for
                                                          SAML bearer
                                                          too..

                                                          This isn't
                                                          really true.
                                                          The SAML
                                                          bearer token
                                                          is fully
                                                          self-contained
                                                          and doesn't
                                                          change based
                                                          on other
                                                          parameters in
                                                          the message,
                                                          unlike MAC.
                                                          Same with JWT.
                                                          When it hands
                                                          a SAML or JWT
                                                          token to the
                                                          AS, the PR has
                                                          given
                                                          *everything*
                                                          the server
                                                          needs to check
                                                          that token's
                                                          validity and
                                                          use. 

                                                          MAC signatures
                                                          change with
                                                          every message,
                                                          and they're
                                                          done across
                                                          several
                                                          components of
                                                          the HTTP
                                                          message.
                                                          Therefor, the
                                                          HMAC check for
                                                          MAC style
                                                          tokens will
                                                          still need to
                                                          be done by the
                                                          protected
                                                          resource.
                                                          Introspection
                                                          would help in
                                                          the case that
                                                          the signature
                                                          validated just
                                                          fine, but the
                                                          token might
                                                          have expired.
                                                          Or you need to
                                                          know what
                                                          scopes apply.
                                                          Introspection
                                                          isn't to fully
                                                          validate the
                                                          call to the
                                                          protected
                                                          resource -- if
                                                          that were the
                                                          case, the PR
                                                          would have to
                                                          send some kind
                                                          of
                                                          encapsulated
                                                          version of the
                                                          original
                                                          request.
                                                          Otherwise, the
                                                          AS won't have
                                                          all of the
                                                          information it
                                                          needs to check
                                                          the MAC.

                                                          I think what
                                                          you're
                                                          describing is
                                                          ultimately
                                                          *not* what the
                                                          introspection
                                                          endpoint is
                                                          intended to
                                                          do. If that's
                                                          unclear from
                                                          the document,
                                                          can you please
                                                          suggest text
                                                          that would
                                                          help clear the
                                                          use case up? I
                                                          wouldn't want
                                                          it to be
                                                          ambiguous.

                                                           -- Justin

                                                          Thanks
                                                          & regards,
                                                          -Prabath

                                                          On

                                                          Thu, Feb 7,
                                                          2013 at 10:30
                                                          PM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:

                                                          It validates
                                                          the token,
                                                          which would be
                                                          either the
                                                          token itself
                                                          in the case of
                                                          Bearer or the
                                                          token "id"
                                                          part of
                                                          something more
                                                          complex like
                                                          MAC. It
                                                          doesn't
                                                          directly
                                                          validate the
                                                          usage of the
                                                          token, that's
                                                          still up to
                                                          the PR to do
                                                          that.

                                                          I nearly added
                                                          a "token type"
                                                          field in this
                                                          draft, but
                                                          held back
                                                          because there
                                                          are several
                                                          kinds of
                                                          "token type"
                                                          that people
                                                          talk about in
                                                          OAuth. First,
                                                          there's
                                                          "Bearer" vs.
                                                          "MAC" vs.
                                                          "HOK", or what
                                                          have you. Then
                                                          within Bearer
                                                          you have "JWT"
                                                          or "SAML" or
                                                          "unstructured
                                                          blob". Then
                                                          you've also
                                                          got "access"
                                                          vs. "refresh"
                                                          and other
                                                          flavors of
                                                          token, like
                                                          the id_token
                                                          in OpenID
                                                          Connect. 

                                                          Thing is, the
                                                          server running
                                                          the
                                                          introspection
                                                          endpoint will
                                                          probably know
                                                          *all* of
                                                          these. But
                                                          should it tell
                                                          the client? If
                                                          so, which of
                                                          the three, and
                                                          what names
                                                          should the
                                                          fields be?

                                                           -- Justin

                                                          On
                                                          02/07/2013
                                                          11:26 AM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          Okay.. I was
                                                          thinking this
                                                          could be used
                                                          as a way to
                                                          validate the
                                                          token as well.
                                                          BTW even in
                                                          this case
                                                          shouldn't
                                                          communicate
                                                          the type of
                                                          token to AS?
                                                          For example in
                                                          the case of
                                                          SAML profile -
                                                          it could be
                                                          SAML token..

                                                          Thanks
                                                          & regards,
                                                          -Prabath

                                                          On

                                                          Thu, Feb 7,
                                                          2013 at 8:39
                                                          PM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:

                                                          "valid" might
                                                          not be the
                                                          best term, but
                                                          it's meant to
                                                          be a field
                                                          where the
                                                          server says
                                                          "yes this
                                                          token is still
                                                          good" or "no
                                                          this token
                                                          isn't good
                                                          anymore". We
                                                          could instead
                                                          do this with
                                                          HTTP codes or
                                                          something but
                                                          I went with a
                                                          pure JSON
                                                          response.

                                                           -- Justin

                                                          On
                                                          02/06/2013
                                                          10:47 PM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          Hi Justin,

                                                          I believe
                                                          this is
                                                          addressing one
                                                          of the key
                                                          missing part
                                                          in OAuth
                                                          2.0...

                                                          One
                                                          question - I
                                                          guess this was
                                                          discussed
                                                          already...

                                                          In the
                                                          spec - in the
                                                          introspection
                                                          response it
                                                          has the
                                                          attribute
                                                          "valid" - this
                                                          is basically
                                                          the validity
                                                          of the token
                                                          provided in
                                                          the request.

                                                          Validation criteria

                                                          depends on the
                                                          token and well
                                                          as token type
                                                          ( Bearer,
                                                          MAC..).

                                                          In the
                                                          spec it seems
                                                          like it's
                                                          coupled with
                                                          Bearer token
                                                          type... But I
                                                          guess, by
                                                          adding
                                                          "token_type"
                                                          to the request
                                                          we can remove
                                                          this
                                                          dependency.

                                                          WDYT..?

                                                          Thanks
                                                          & regards,
                                                          -Prabath 

                                                          On

                                                          Thu, Feb 7,
                                                          2013 at 12:54
                                                          AM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:

                                                          Updated
                                                          introspection
                                                          draft based on
                                                          recent
                                                          comments.
                                                          Changes
                                                          include:

                                                           - "scope"
                                                          return
                                                          parameter now
                                                          follows
                                                          RFC6749 format
                                                          instead of
                                                          JSON array

                                                           - "subject"
                                                          -> "sub",
                                                          and "audience"
                                                          -> "aud",
                                                          to be parallel
                                                          with JWT
                                                          claims

                                                           - clarified
                                                          what happens
                                                          if the
                                                          authentication
                                                          is bad

                                                           -- Justin

                                                          --------
                                                          Original
                                                          Message
                                                          --------

                                                          Subject: 
                                                          New
                                                          Version
                                                          Notification
                                                          for
                                                          draft-richer-oauth-introspection-02.txt

                                                          Date: 
                                                          Wed, 6 Feb
                                                          2013 11:24:20
                                                          -0800

                                                          From: 
                                                          <internet-drafts@ietf.org>

                                                          To: 
                                                          <jricher@mitre.org>

                                                          A new version of I-D, draft-richer-oauth-introspection-02.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 02
Title:		 OAuth Token Introspection
Creation date:	 2013-02-06
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.

The IETF Secretariat

_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

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

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                                          _______________________________________________

                                                          OAuth
                                                          mailing list

                                                          OAuth@ietf.org

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

                                                        -- 

                                                        Thanks &
                                                        Regards,

                                                        Prabath

                                                        Mobile : +94 71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                              -- 

                                              Thanks & Regards,

                                              Prabath

                                              Mobile : +94

                                                  71 809 6732 

                                                http://blog.facilelogin.com

                                                http://RampartFAQ.com

                                -- 

                                Thanks & Regards,

                                Prabath

                                Mobile : +94
                                    71 809 6732 

                                  http://blog.facilelogin.com

                                  http://RampartFAQ.com

                      -- 

                      Thanks & Regards,

                      Prabath

                      Mobile : +94 71
                          809 6732 

                        http://blog.facilelogin.com

                        http://RampartFAQ.com

        -- 

        Thanks & Regards,

        Prabath

        Mobile : +94 71 809 6732 

          http://blog.facilelogin.com

          http://RampartFAQ.com

--------------090306090907080103010008--

From ve7jtb@ve7jtb.com  Thu Feb 14 06:35:32 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B61A21F8806 for ; Thu, 14 Feb 2013 06:35:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.388
X-Spam-Level: 
X-Spam-Status: No, score=-3.388 tagged_above=-999 required=5 tests=[AWL=0.211,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-ymjLj7UUN7 for ; Thu, 14 Feb 2013 06:35:31 -0800 (PST)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4032721F871F for ; Thu, 14 Feb 2013 06:35:31 -0800 (PST)
Received: by mail-qa0-f51.google.com with SMTP id cr7so1070927qab.10 for ; Thu, 14 Feb 2013 06:35:30 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=/vuqJQIbDMQYS9H7Pf26NQpkWSqKkoE7ALL9OEj94mE=; b=ScbexGbljiyjAlxZi+GPZttwHC2JDMBrtckCoDFwdJlbS02BycRvAqOC/GFJAV5CTB VqyEO0CsqyIXyvAuatxesNoHxDuXcw2gVOtAAgtYrqnr3CUdr1J6aFXSgZdeEYVrcuzw t2iPTOWGaJy7FuLJ4EeVzz7XqzXuxS/feLhphCsnUAYpi9LyqHX6z1GLqhf6NXTLpwM8 cTz1daSKRARiR47brYtLL0ytkbz3VNgCyZh8m72MdMGYrjuIPVxWZsTbj/JiHBT6OwIu K8jCiID5xAcCo2OEFE3t6O2O+UlJL20MXUwJrP2eG2xvsfsN/iDLHh5xZYdFm4SRRgv1 g+nw==
X-Received: by 10.224.33.140 with SMTP id h12mr682388qad.73.1360852530651; Thu, 14 Feb 2013 06:35:30 -0800 (PST)
Received: from [192.168.1.213] (190-20-16-126.baf.movistar.cl. [190.20.16.126]) by mx.google.com with ESMTPS id o5sm18495545qao.12.2013.02.14.06.35.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Feb 2013 06:35:29 -0800 (PST)
Content-Type: text/plain; charset=iso-2022-jp
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <511CF2C9.9040604@mitre.org>
Date: Thu, 14 Feb 2013 11:35:16 -0300
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <51195F36.6040705@mitre.org> <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com> <511BAA8B.8030309@mitre.org>  <-4554688250617930935@unknownmsgid>   <4687F290-4855-49DE-892F-F9694BB211D4@ve7jtb.com> <511CF2C9.9040604@mitre.org>
To: Justin Richer 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQlOdioMRTLvfP/d4Xjf7OPRnEBEHgpR6Ces/pyYVcmQagnU7IrVomCN7CZUYBP8jOCWpqdA
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2013 14:35:32 -0000

On 2013-02-14, at 11:20 AM, Justin Richer  wrote:

>=20
> On 02/14/2013 09:05 AM, John Bradley wrote:
>> I agree with Tim that is the behaviour I would  expect to see with =
DELETE though I have a rd time seeing a server ever honouring it.
>>=20
>> I guess that we need to clarify what happens with PUT and claims the =
server has defaults for, perhaps some that are not changeable by the =
client.  =20
>>=20
>> Is not including a claim in a PUT the same as not including it in =
registration, and it is set to the default. =20
>> If you want to set a claim to null then you must explicitly include =
the claim with null as the value. That is the previous logic we had for =
replace as the client wasn't getting back all the config in the response =
and couldn't know about defaults it wasn't setting.
>>=20
>> Perhaps PUT causes unsent claims to be interpreted as if they are =
sent with a null value (I think that is a likely to cause tears =
personally).
>>=20
>> In ether case the client is not deleted and can still be recovered =
and the client_id and associated permissions are still active.
>=20
> What I had in mind from this conversation is something like this:
>=20
> When sending an update, a client MUST send all metadata fields =
returned
> from the server in its initial registration or previous read or update
> call, including its client_id. A server MAY replace any missing or
> invalid fields with default values, or it MAY return an error as
> described in the Error Response section. A server MUST return all
> provisioned fields in its response. A server MUST NOT change the
> client_id field. A server MAY change the client_secret and/or
> refresh_access_token fields.

Yes that covers it.
>=20
>>=20
>> DELETE to be used correctly is I think going to delete the client_id =
and all associated tokens and cause a ripple effect in removing grants =
associated with that client_id. =20
>=20
> This is how I would interpret it as well. It's de-provisioning the
> client, not resetting it.

That is what I would expect I don't know if it is a good idea, and adds =
to the size of the spec.   Having a not supported response is better =
but, I don't have a good feeling about it yet.

>=20
> -- Justin
>=20
>>=20
>> It is a big difference and understanding what a AS is supposed to do =
to delete a client still seems a touch vague to me.   I understand the =
http verb but there is more to it than that if we want interoperability.
>>=20
>> John
>>=20
>> On 2013-02-14, at 12:31 AM, Nat Sakimura  wrote:
>>=20
>>> I thought your concern about DELETE was whether the client should be
>>> allowed to erase the registration data.
>>> I thought PUT with an empty values would achieve a similar effect.
>>> Or did you mean that with PUT, the server default kicks in and
>>> parameters are set to the defaults?
>>> If that is the case, they are quite different, I agree.
>>>=20
>>> On the effect of DELETE, +1 to Tim's comment.
>>>=20
>>> Nat
>>>=20
>>> 2013/2/14 John Bradley :
>>>> DELETE is removing the record not resetting it to defaults.  They =
are quite diffrent.
>>>>=20
>>>> I want to agree on what the expected behaviour of DELETE is.   I =
think we have agreement on PUT and POST.
>>>>=20
>>>> The general not in that a client can DELETE it's record is a =
implication I don't like.  I think that is for the server to decide and =
if it is not actually deleting it then DELETE is the wrong verb to use.
>>>>=20
>>>> John B.
>>>>=20
>>>> On 2013-02-13, at 3:31 PM, Nat Sakimura  wrote:
>>>>=20
>>>>> Generally speaking, mapping PUT to replace and POST to change is =
an
>>>>> acceptable practice so I am fine with it.
>>>>>=20
>>>>> Now, what I still do not understand is why you think it is fine to =
do
>>>>> PUT or POST and not DELETE. Doing PUT with empty content is almost =
the
>>>>> same as DELETE. Could you explain?
>>>>>=20
>>>>> =3Dnat via iPhone
>>>>>=20
>>>>> Feb 14, 2013 0:10=1B$B!"=1B(BJohn Bradley  =
=1B$B$N%a%C%;!<%8=1B(B:
>>>>>=20
>>>>>> I am not violently opposed to PUT as a option that completely =
replaces the resource setting all unsent claims back to the defaults.
>>>>>>=20
>>>>>> I don't have a good feeling about DELETE,  I think we still need =
more discussion on what it means, what privileges it takes to invoke it =
etc.
>>>>>> It could be a bad thing if we get wrong or is not implemented =
consistently.
>>>>>>=20
>>>>>> Personally I don't think a client should ever be able to DELETE =
it's record.
>>>>>>=20
>>>>>> I think marking a client_id as pending provisioning, suspended,  =
revoked etc is better and that can be done with a claim in the update =
endpoint.
>>>>>>=20
>>>>>> It should only be the server that deletes a record after =
satisfying it's audit requirements.
>>>>>>=20
>>>>>> John B.
>>>>>>=20
>>>>>> On 2013-02-13, at 12:00 PM, Justin Richer  =
wrote:
>>>>>>=20
>>>>>>> Would it be reasonable to mark the PUT and DELETE methods as =
optional for the server to implement, but with defined semantics if they =
do? I want to keep GET and POST(create) as mandatory, as I think that's =
the minimal set of functionality required.
>>>>>>>=20
>>>>>>> -- Justin
>>>>>>>=20
>>>>>>> On 02/11/2013 08:51 PM, John Bradley wrote:
>>>>>>>> I would always include the client_id on update.
>>>>>>>>=20
>>>>>>>> I think it is also us full to have other tokens used at the =
update endpoint.  I can see the master token used to update all the =
clients it has registered as part of API management.
>>>>>>>> Relying on the registration_access_token is probably a design =
that will cause trouble down the road.
>>>>>>>>=20
>>>>>>>> I think GET and POST are relatively clear.   I don't know about =
expelling PUT to developers.  I think POST with a client_id to a =
(separate discussion) update_uri works without restricting it to PUT.
>>>>>>>>=20
>>>>>>>> I think DELETE needs to be better understood.   I think a =
status that can be set for client lifecycle is better than letting a =
client delete a entry.
>>>>>>>> In some cases there will be more than one instance of a client =
and letting them know they have been turned off for a reason is better =
than making there registration disappear.
>>>>>>>> So for the moment I would levee out DELETE.
>>>>>>>>=20
>>>>>>>> John B.
>>>>>>>>=20
>>>>>>>> On 2013-02-11, at 6:14 PM, Justin Richer  =
wrote:
>>>>>>>>=20
>>>>>>>>> Draft -05 of OAuth Dynamic Client Registration [1] defines =
several operations that the client can take on its behalf as part of the =
registration process. These boil down to the basic CRUD operations that =
you find in many APIs: Create, Read, Update, Delete. Draft -00 defined =
only the "Create" operation, draft -01 through -04 added the "Update" =
operation, switched using the "operation=3D" parameter.
>>>>>>>>>=20
>>>>>>>>> Following several suggestions to do so on the list, the -05 =
draft defines these operations in terms of a RESTful API for the client. =
Namely:
>>>>>>>>>=20
>>>>>>>>> - HTTP POST to registration endpoint =3D> Create (register) a =
new client
>>>>>>>>> - HTTP PUT to update endpoint (with registration_access_token) =
=3D> Update the registered information for this client
>>>>>>>>> - HTTP GET to update endpoint (with registration_access_token) =
=3D> read the registered information for this client
>>>>>>>>> - HTTP DELETE to update endpoint (with =
registration_access_token) =3D> Delete (unregister/de-provision) this =
client
>>>>>>>>>=20
>>>>>>>>> The two main issues at stake here are: the addition of the =
READ and DELETE methods, and the use of HTTP verbs following a RESTful =
design philosophy.
>>>>>>>>>=20
>>>>>>>>> Pro:
>>>>>>>>> - RESTful APIs (with HTTP verbs to differentiate =
functionality) are the norm today
>>>>>>>>> - Full lifecycle management is common and is going to be =
expected by many users of this protocol in the wild
>>>>>>>>>=20
>>>>>>>>> Cons:
>>>>>>>>> - Update semantics are still under debate (full replace? =
patch?)
>>>>>>>>> - Somewhat increased complexity on the server to support all =
operations
>>>>>>>>> - Client has to understand all HTTP verbs for full access =
(though plain registration is just POST)
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Alternatives include using an operational switch parameter =
(like the old drafts), defining separate endpoints for every action, or =
doing all operations on a single endpoint using verbs to switch.
>>>>>>>>>=20
>>>>>>>>> -- Justin
>>>>>>>>>=20
>>>>>>>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>=20
>>>=20
>>> --=20
>>> Nat Sakimura (=3Dnat)
>>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/
>>> @_nat_en
>=20

From prabath@wso2.com  Thu Feb 14 06:37:30 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C7D21F884B for ; Thu, 14 Feb 2013 06:37:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.624
X-Spam-Level: 
X-Spam-Status: No, score=-2.624 tagged_above=-999 required=5 tests=[AWL=0.352,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0MWGFpXiLbI for ; Thu, 14 Feb 2013 06:37:24 -0800 (PST)
Received: from mail-ea0-f180.google.com (mail-ea0-f180.google.com [209.85.215.180]) by ietfa.amsl.com (Postfix) with ESMTP id 47CD421F8836 for ; Thu, 14 Feb 2013 06:37:23 -0800 (PST)
Received: by mail-ea0-f180.google.com with SMTP id c1so934407eaa.11 for ; Thu, 14 Feb 2013 06:37:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=xM3ZuXORS1QjpZBCf70tcYndrBB9gaLAN70RAGhXDQY=; b=GVMlxywTM5pt+x93+J1bImIfUxi8qelWabWG/1IS4ANxtxyDRbu+OYkHnc2nu4cHkE mHvZm845xLG5gmS3w6GPav/F7wS5mRJ21e90ML6zffCEevtSRHCngThGl5bS+xzdPhp4 KX1/tDzsXQHbhcalScLjk+hKc7CvC8QKxsVzhkbfdYUyfWkhiaECrjKiF2rXIcNUCRD7 idEnovnMYwyhvL9kU+zDQIT6AYGdY2w0IWPr7Xy1N7PaJ/n28w6o6YdUZHIZMPywBR2F vDMxn57N+9zAs7+niwEE89KRvprnMmpOXu6DNxXVbw6w+XrPcgfM21Y9C40W/PLL9pvy hozA==
MIME-Version: 1.0
X-Received: by 10.14.210.8 with SMTP id t8mr20493307eeo.35.1360852641981; Thu, 14 Feb 2013 06:37:21 -0800 (PST)
Received: by 10.223.37.77 with HTTP; Thu, 14 Feb 2013 06:37:21 -0800 (PST)
In-Reply-To: <511CF4AB.5010700@mitre.org>
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com> <5112AE0B.1080501@mitre.org>  <5113C3AA.1040701@mitre.org>  <5113DDB2.7060805@mitre.org>  <51196777.6000502@mitre.org>   <511A5062.5010108@mitre.org>   <511CEEAA.3030801@mitre.org>   <511CF3EF.8040008@mitre.org>  <511CF4AB.5010700@mitre.org>
Date: Thu, 14 Feb 2013 20:07:21 +0530
Message-ID: 
From: Prabath Siriwardena 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=047d7b603fe251265604d5b032c0
X-Gm-Message-State: ALoCoQmWhXVQOxykBBNRRyejKyFmt2dl5H6Z7jdvA5RoYYke+eaAfPM5kdbaCCI0k2uoBDwzlk15
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2013 14:37:30 -0000

--047d7b603fe251265604d5b032c0
Content-Type: text/plain; charset=ISO-8859-1

The definition of valid is bit ambiguous in the draft...

Okay.. If that is the definition... and if we beak that in to parts...

"it hasn't expired" : In the response it self we have parameter for
issued_at and and expires_at - so whether the token is not expired or not
can even be derived at the requestor's end.

"token was issued from here" : For this IMO we need to send an error code.
Requestor has picked the wrong AS.

The remaining is  "revoked".. That is why I proposed earlier - we better
have an attribute "revoked" - instead of "valid" in the response..

WDYT...?

Thanks & regards,
-Prabath

On Thu, Feb 14, 2013 at 7:58 PM, Justin Richer  wrote:

>  Because it will be the one that issued the token in the first place.
>
> Validity means "token was issued from here, it hasn't been revoked, it
> hasn't expired".
>
>  -- Justin
>
>
> On 02/14/2013 09:28 AM, Prabath Siriwardena wrote:
>
> Okay. With out knowing the type of the token how can the AS validate the
> token ? What is meant by the validity there?
>
>  Thanks & regards,
> -Prabath
>
> On Thu, Feb 14, 2013 at 7:55 PM, Justin Richer  wrote:
>
>>  OK, I don't see the utility in that at all. What would it accomplish?
>>
>>  -- Justin
>>
>>
>> On 02/14/2013 09:25 AM, Prabath Siriwardena wrote:
>>
>> To make it clear - my suggestion is to add token_type_hint to the
>> introspection request. It can be from client to AS or from RS to AS.
>>
>>  Then AS can decide whether the provided token is valid or not and
>> include "valid" attribute in the introspection response.
>>
>>  Thanks & regards,
>> -Prabath
>>
>> On Thu, Feb 14, 2013 at 7:52 PM, Prabath Siriwardena wrote:
>>
>>> Both the client and the resource owner should be aware of the token
>>> type.
>>>
>>>  My argument is, if the authorization server to decide whether the
>>> token is valid or not ( irrespective of who asked the question) - AS needs
>>> to know the token type - because to validate a token AS should know the
>>> token type.
>>>
>>>  The token type could be, bearer or MAC or any other token type.
>>>
>>>  Thanks & regards,
>>> -Prabath
>>>
>>>
>>> On Thu, Feb 14, 2013 at 7:33 PM, Justin Richer wrote:
>>>
>>>>  What exactly are you suggesting be added to introspection? The
>>>> "token_type_hint" is from the client to the server, but what you've asked
>>>> for in terms of "token type" is from the server to the client. And there
>>>> was never an answer to what exactly is meant by "token type" in this case,
>>>> particularly because you seem to want to call out things like SAML and
>>>> Bearer as separate types.
>>>>
>>>>  -- Justin
>>>>
>>>>
>>>>
>>>> On 02/14/2013 06:59 AM, Prabath Siriwardena wrote:
>>>>
>>>> I noticed that the latest Token Revocation draft [1] has introduced the
>>>> parameter "token_type_hint". I would suggest the same here, as that would
>>>> make what is meant by "valid" much clear..
>>>>
>>>>  [1]: http://tools.ietf.org/html/draft-ietf-oauth-revocation-05
>>>>
>>>>  Thanks & regards,
>>>> -Prabath
>>>>
>>>> On Tue, Feb 12, 2013 at 9:35 PM, Prabath Siriwardena wrote:
>>>>
>>>>> Hi Justin,
>>>>>
>>>>>  I doubt whether valid_token would make a difference..?
>>>>>
>>>>>  My initial argument is what is the validation criteria..? Validation
>>>>> criteria depends on the token_type..
>>>>>
>>>>>  If we are talking only about metadata - then I believe "revoked",
>>>>> "expired" would be more meaningful..
>>>>>
>>>>>  Thanks & regards,
>>>>> -Prabath
>>>>>
>>>>>
>>>>>  On Tue, Feb 12, 2013 at 7:53 PM, Justin Richer wrote:
>>>>>
>>>>>>  OK, I can see the wisdom in changing this term.
>>>>>>
>>>>>> I picked "valid" because I wanted a simple "boolean" value that would
>>>>>> require no additional parsing or string-matching on the client's behalf,
>>>>>> and I'd like to stick with that. OAuth is built with the assumption that
>>>>>> clients need to be able to recover from invalid tokens at any stage, so I
>>>>>> think a simple yes/no is the right step here.
>>>>>>
>>>>>> That said, I think you're both right that "valid" seems to have
>>>>>> caused a bit of confusion. I don't want to go with "revoked" because I'd
>>>>>> rather have the "token is OK" be the positive boolean value.
>>>>>>
>>>>>> Would "valid_token" be more clear? Or do we need a different
>>>>>> adjective all together?
>>>>>>
>>>>>>  -- Justin
>>>>>>
>>>>>>
>>>>>> On 02/11/2013 08:02 PM, Richard Harrington wrote:
>>>>>>
>>>>>> Have you considered "status" instead of "valid"?  It could have
>>>>>> values like "active", "expired", and "revoked".
>>>>>>
>>>>>>  Is it worthwhile including the status of the client also?  For
>>>>>> example, a client application could be disabled, temporarily or
>>>>>> permanently, and thus disabling its access tokens as well.
>>>>>>
>>>>>>
>>>>>> On Feb 11, 2013, at 1:56 PM, Prabath Siriwardena 
>>>>>> wrote:
>>>>>>
>>>>>>  I guess confusion is with 'valid' parameter is in the response..
>>>>>>
>>>>>>  I thought this will be helpful to standardize the communication
>>>>>> between Resource Server and the Authorization Server..
>>>>>>
>>>>>>  I would suggest we completely remove "valid" from the response - or
>>>>>> define it much clearly..
>>>>>>
>>>>>>  May be can add "revoked" with a boolean attribute..
>>>>>>
>>>>>>  Thanks & regards,
>>>>>> -Prabath
>>>>>>
>>>>>> On Tue, Feb 12, 2013 at 3:19 AM, Justin Richer wrote:
>>>>>>
>>>>>>>
>>>>>>> On 02/08/2013 12:51 AM, Prabath Siriwardena wrote:
>>>>>>>
>>>>>>> Hi Justin,
>>>>>>>
>>>>>>>  I have couple of questions related to "valid" parameter...
>>>>>>>
>>>>>>>  This endpoint can be invoked by the Resource Server in runtime...
>>>>>>>
>>>>>>>
>>>>>>> That's correct.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  In that case what is exactly meant by the "resource_id" in request
>>>>>>> ?
>>>>>>>
>>>>>>>
>>>>>>>  The resource_id field is a service-specific string that basically
>>>>>>> lets the resource server provide some context to the request to the auth
>>>>>>> server. There have been some other suggestions like client IP address, but
>>>>>>> I wanted to put this one in because it seemed to be a common theme. The
>>>>>>> client is trying to do *something* with the token, after all, and the
>>>>>>> rights, permissions, and metadata associated with the token could change
>>>>>>> based on that. Since the Introspection endpoint is all about getting that
>>>>>>> metadata back to the PR, this seemed like a good idea.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  IMO a token to be valid depends on set of criteria based on it's
>>>>>>> type..
>>>>>>>
>>>>>>>  For a Bearer token..
>>>>>>>
>>>>>>>  1. Token should not be expired
>>>>>>> 2. Token should not be revoked.
>>>>>>> 3. The scope the token issued should match with the scope required
>>>>>>> for the resource.
>>>>>>>
>>>>>>>  For a MAC token...
>>>>>>>
>>>>>>>  1. Token not expired (mac id)
>>>>>>> 2. Token should not be revoked
>>>>>>> 3. The scope the token issued should match with the scope required
>>>>>>> for the resource.
>>>>>>> 4. HMAC check should be valid
>>>>>>>
>>>>>>>  There are similar conditions for SAML bearer too..
>>>>>>>
>>>>>>>
>>>>>>>  This isn't really true. The SAML bearer token is fully
>>>>>>> self-contained and doesn't change based on other parameters in the message,
>>>>>>> unlike MAC. Same with JWT. When it hands a SAML or JWT token to the AS, the
>>>>>>> PR has given *everything* the server needs to check that token's validity
>>>>>>> and use.
>>>>>>>
>>>>>>> MAC signatures change with every message, and they're done across
>>>>>>> several components of the HTTP message. Therefor, the HMAC check for MAC
>>>>>>> style tokens will still need to be done by the protected resource.
>>>>>>> Introspection would help in the case that the signature validated just
>>>>>>> fine, but the token might have expired. Or you need to know what scopes
>>>>>>> apply. Introspection isn't to fully validate the call to the protected
>>>>>>> resource -- if that were the case, the PR would have to send some kind of
>>>>>>> encapsulated version of the original request. Otherwise, the AS won't have
>>>>>>> all of the information it needs to check the MAC.
>>>>>>>
>>>>>>>
>>>>>>> I think what you're describing is ultimately *not* what the
>>>>>>> introspection endpoint is intended to do. If that's unclear from the
>>>>>>> document, can you please suggest text that would help clear the use case
>>>>>>> up? I wouldn't want it to be ambiguous.
>>>>>>>
>>>>>>>  -- Justin
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  Thanks & regards,
>>>>>>> -Prabath
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Feb 7, 2013 at 10:30 PM, Justin Richer wrote:
>>>>>>>
>>>>>>>>  It validates the token, which would be either the token itself in
>>>>>>>> the case of Bearer or the token "id" part of something more complex like
>>>>>>>> MAC. It doesn't directly validate the usage of the token, that's still up
>>>>>>>> to the PR to do that.
>>>>>>>>
>>>>>>>> I nearly added a "token type" field in this draft, but held back
>>>>>>>> because there are several kinds of "token type" that people talk about in
>>>>>>>> OAuth. First, there's "Bearer" vs. "MAC" vs. "HOK", or what have you. Then
>>>>>>>> within Bearer you have "JWT" or "SAML" or "unstructured blob". Then you've
>>>>>>>> also got "access" vs. "refresh" and other flavors of token, like the
>>>>>>>> id_token in OpenID Connect.
>>>>>>>>
>>>>>>>> Thing is, the server running the introspection endpoint will
>>>>>>>> probably know *all* of these. But should it tell the client? If so, which
>>>>>>>> of the three, and what names should the fields be?
>>>>>>>>
>>>>>>>>  -- Justin
>>>>>>>>
>>>>>>>>
>>>>>>>> On 02/07/2013 11:26 AM, Prabath Siriwardena wrote:
>>>>>>>>
>>>>>>>> Okay.. I was thinking this could be used as a way to validate the
>>>>>>>> token as well. BTW even in this case shouldn't communicate the type of
>>>>>>>> token to AS? For example in the case of SAML profile - it could be SAML
>>>>>>>> token..
>>>>>>>>
>>>>>>>>  Thanks & regards,
>>>>>>>> -Prabath
>>>>>>>>
>>>>>>>> On Thu, Feb 7, 2013 at 8:39 PM, Justin Richer wrote:
>>>>>>>>
>>>>>>>>>  "valid" might not be the best term, but it's meant to be a field
>>>>>>>>> where the server says "yes this token is still good" or "no this token
>>>>>>>>> isn't good anymore". We could instead do this with HTTP codes or something
>>>>>>>>> but I went with a pure JSON response.
>>>>>>>>>
>>>>>>>>>  -- Justin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 02/06/2013 10:47 PM, Prabath Siriwardena wrote:
>>>>>>>>>
>>>>>>>>> Hi Justin,
>>>>>>>>>
>>>>>>>>>  I believe this is addressing one of the key missing part in
>>>>>>>>> OAuth 2.0...
>>>>>>>>>
>>>>>>>>>  One question - I guess this was discussed already...
>>>>>>>>>
>>>>>>>>>  In the spec - in the introspection response it has the attribute
>>>>>>>>> "valid" - this is basically the validity of the token provided in the
>>>>>>>>> request.
>>>>>>>>>
>>>>>>>>>  Validation criteria depends on the token and well as token type
>>>>>>>>> ( Bearer, MAC..).
>>>>>>>>>
>>>>>>>>>  In the spec it seems like it's coupled with Bearer token type...
>>>>>>>>> But I guess, by adding "token_type" to the request we can remove this
>>>>>>>>> dependency.
>>>>>>>>>
>>>>>>>>>  WDYT..?
>>>>>>>>>
>>>>>>>>>  Thanks & regards,
>>>>>>>>> -Prabath
>>>>>>>>>
>>>>>>>>> On Thu, Feb 7, 2013 at 12:54 AM, Justin Richer wrote:
>>>>>>>>>
>>>>>>>>>>  Updated introspection draft based on recent comments. Changes
>>>>>>>>>> include:
>>>>>>>>>>
>>>>>>>>>>  - "scope" return parameter now follows RFC6749 format instead of
>>>>>>>>>> JSON array
>>>>>>>>>>  - "subject" -> "sub", and "audience" -> "aud", to be parallel
>>>>>>>>>> with JWT claims
>>>>>>>>>>  - clarified what happens if the authentication is bad
>>>>>>>>>>
>>>>>>>>>>  -- Justin
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -------- Original Message --------  Subject: New Version
>>>>>>>>>> Notification for draft-richer-oauth-introspection-02.txt  Date: Wed,
>>>>>>>>>> 6 Feb 2013 11:24:20 -0800  From:   To:
>>>>>>>>>>  
>>>>>>>>>>
>>>>>>>>>> A new version of I-D, draft-richer-oauth-introspection-02.txt
>>>>>>>>>> has been successfully submitted by Justin Richer and posted to the
>>>>>>>>>> IETF repository.
>>>>>>>>>>
>>>>>>>>>> Filename:	 draft-richer-oauth-introspection
>>>>>>>>>> Revision:	 02
>>>>>>>>>> Title:		 OAuth Token Introspection
>>>>>>>>>> Creation date:	 2013-02-06
>>>>>>>>>> WG ID:		 Individual Submission
>>>>>>>>>> Number of pages: 6
>>>>>>>>>> URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
>>>>>>>>>> Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
>>>>>>>>>> Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-02
>>>>>>>>>> Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02
>>>>>>>>>>
>>>>>>>>>> Abstract:
>>>>>>>>>>    This specification defines a method for a client or protected
>>>>>>>>>>    resource to query an OAuth authorization server to determine meta-
>>>>>>>>>>    information about an OAuth token.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The IETF Secretariat
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> OAuth mailing list
>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  --
>>>>>>>>> Thanks & Regards,
>>>>>>>>> Prabath
>>>>>>>>>
>>>>>>>>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>>>>>>>>
>>>>>>>>> http://blog.facilelogin.com
>>>>>>>>> http://RampartFAQ.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>  --
>>>>>>>> Thanks & Regards,
>>>>>>>> Prabath
>>>>>>>>
>>>>>>>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>>>>>>>
>>>>>>>> http://blog.facilelogin.com
>>>>>>>> http://RampartFAQ.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  --
>>>>>>> Thanks & Regards,
>>>>>>> Prabath
>>>>>>>
>>>>>>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>>>>>>
>>>>>>> http://blog.facilelogin.com
>>>>>>> http://RampartFAQ.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>  --
>>>>>> Thanks & Regards,
>>>>>> Prabath
>>>>>>
>>>>>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>>>>>
>>>>>> http://blog.facilelogin.com
>>>>>> http://RampartFAQ.com
>>>>>>
>>>>>>  _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>  --
>>>>> Thanks & Regards,
>>>>> Prabath
>>>>>
>>>>>  Mobile : +94 71 809 6732
>>>>>
>>>>> http://blog.facilelogin.com
>>>>> http://RampartFAQ.com
>>>>>
>>>>
>>>>
>>>>
>>>>  --
>>>> Thanks & Regards,
>>>> Prabath
>>>>
>>>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>>>
>>>> http://blog.facilelogin.com
>>>> http://RampartFAQ.com
>>>>
>>>>
>>>>
>>>
>>>
>>>  --
>>> Thanks & Regards,
>>> Prabath
>>>
>>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>>
>>> http://blog.facilelogin.com
>>> http://RampartFAQ.com
>>>
>>
>>
>>
>>  --
>> Thanks & Regards,
>> Prabath
>>
>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>
>> http://blog.facilelogin.com
>> http://RampartFAQ.com
>>
>>
>>
>
>
>  --
> Thanks & Regards,
> Prabath
>
>  Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com
>
>
>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.com

--047d7b603fe251265604d5b032c0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The definition of valid is bit ambiguous=A0in the draft...
<=
br>
Okay.. If that is the definition... and if we beak that in to=
 parts...

"it hasn't expired" : In t=
he response it self we have parameter for issued_at and and expires_at - so=
 whether the token is not expired or not can even be derived at the request=
or's end.

"token was issued from here" : For this IMO w=
e need to send an error code. Requestor has picked the wrong AS.
=

The remaining is =A0"revoked".. That is why I prop=
osed=A0earlier=A0- we better have an attribute "revoked" - instea=
d of "valid" in the response..

WDYT...?

Thanks & regards,=
-Prabath

On Thu, Feb 14, 2013 at 7:58 PM, Justin Richer <jricher@mitre.org>=
 wrote:

 =20
   =20
 =20

    Because it will be the one that issued the token in the first place.

    Validity means "token was issued from here, it hasn't been rev=
oked,
    it hasn't expired". 

    =A0-- Justin

    On 02/14/2013 09:28 AM, Prabath
      Siriwardena wrote:

     =20
      Okay. With out knowing the type of the token how can the AS
      validate the token ? What is meant by the validity there?

      Thanks & regards,
      -Prabath

        On Thu, Feb 14, 2013 at 7:55 PM, Justin
          Richer <jricher@mitre.org>
          wrote:

             OK, I don't see =
the
              utility in that at all. What would it accomplish?

                  =A0-- Justin

                  On 02/14/2013 09:25 AM, Prabath Siriwardena
                    wrote:

                   To make it clear - my
                    suggestion is to add token_type_hint to the
                    introspection request. It can be from client to AS
                    or from RS to AS.

                    Then AS can decide whether the provided token
                      is valid or not and include "valid" attribu=
te in
                      the introspection response.

                    Thanks & regards,
                    -Prabath

                      On Thu, Feb 14, 2013 at
                        7:52 PM, Prabath Siriwardena <=
prabath@wso2.com&=
gt;
                        wrote:

                        Both the client and
                          the resource owner should be aware of the
                          token type.

                          My argument is, if the authorization
                            server to decide whether the token is valid
                            or not ( irrespective of who asked the
                            question) - AS needs to know the token type
                            - because to validate a token AS should know
                            the token type.

                          The token type could be, bearer or MAC or
                            any other token type.

                          Thanks & regards,
                          -Prabath

                                On Thu, Feb 14,
                                  2013 at 7:33 PM, Justin Richer <jricher=
@mitre.org>
                                  wrote:

                                     What exactly are
                                      you suggesting be added to
                                      introspection? The
                                      "token_type_hint" is from t=
he
                                      client to the server, but what
                                      you've asked for in terms of
                                      "token type" is from the se=
rver to
                                      the client. And there was never an
                                      answer to what exactly is meant by
                                      "token type" in this case,
                                      particularly because you seem to
                                      want to call out things like SAML
                                      and Bearer as separate types. 

                                          =A0-- Justin

                                          On 02/14/2013 06:59 AM,
                                            Prabath Siriwardena wrote:

                                           I
                                            noticed that the latest
                                            Token Revocation draft [1]
                                            has introduced the parameter
                                            "token_type_hint". I =
would
                                            suggest the same here, as
                                            that would make what is
                                            meant by "valid" much
                                            clear..

                                            [1]:=A0http://tools.ietf.org/html/draft-ietf-oauth-revocation-05

                                            Thanks & regards,
                                            -Prabath

                                              On
                                                Tue, Feb 12, 2013 at
                                                9:35 PM, Prabath
                                                Siriwardena <prabath@wso2.c=
om>
                                                wrote:

                                                Hi
                                                  Justin,

                                                  I doubt whether
                                                    valid_token would
                                                    make a difference..?

                                                  My initial
                                                    argument is what is
                                                    the validation
                                                    criteria..?
                                                    Validation criteria
                                                    depends on the
                                                    token_type..

                                                  If we are talking
                                                    only about metadata
                                                    - then I believe
                                                    "revoked", &q=
uot;expired"
                                                    would be more
                                                    meaningful..

                                                  Thanks &
                                                    regards,
                                                  -Prabath

                                                          On Tue, Feb
                                                          12, 2013 at
                                                          7:53 PM,
                                                          Justin Richer
                                                          <jricher@mitre.o=
rg>
                                                          wrote:

                                                          OK, I can see
                                                          the wisdom in
                                                          changing this
                                                          term. 

                                                          I picked
                                                          "valid"
                                                          because I
                                                          wanted a
                                                          simple
                                                          "boolean&quo=
t;
                                                          value that
                                                          would require
                                                          no additional
                                                          parsing or
                                                          string-matching
                                                          on the
                                                          client's
                                                          behalf, and
                                                          I'd like to
                                                          stick with
                                                          that. OAuth is
                                                          built with the
                                                          assumption
                                                          that clients
                                                          need to be
                                                          able to
                                                          recover from
                                                          invalid tokens
                                                          at any stage,
                                                          so I think a
                                                          simple yes/no
                                                          is the right
                                                          step here. 

                                                          That said, I
                                                          think you're
                                                          both right
                                                          that "valid&=
quot;
                                                          seems to have
                                                          caused a bit
                                                          of confusion.
                                                          I don't want
                                                          to go with
                                                          "revoked&quo=
t;
                                                          because I'd
                                                          rather have
                                                          the "token i=
s
                                                          OK" be the
                                                          positive
                                                          boolean value.

                                                          Would
                                                          "valid_token=
"
                                                          be more clear?
                                                          Or do we need
                                                          a different
                                                          adjective all
                                                          together?

                                                          =A0-- Justin

                                                          On
                                                          02/11/2013
                                                          08:02 PM,
                                                          Richard
                                                          Harrington
                                                          wrote:

                                                          Have you
                                                          considered
                                                          "status"=
;
                                                          instead of
                                                          "valid"=
? =A0It
                                                          could have
                                                          values like
                                                          "active"=
;,
                                                          "expired&quo=
t;, and
                                                          "revoked&quo=
t;.

                                                          Is it
                                                          worthwhile
                                                          including the
                                                          status of the
                                                          client also?
                                                          =A0For example,
                                                          a client
                                                          application
                                                          could be
                                                          disabled,
                                                          temporarily or
                                                          permanently,
                                                          and thus
                                                          disabling its
                                                          access tokens
                                                          as well.

                                                          On Feb 11,
                                                          2013, at 1:56
                                                          PM, Prabath
                                                          Siriwardena
                                                          <prabath@wso2.com>
                                                          wrote:

                                                          I guess
                                                          confusion is
                                                          with 'valid&#=
39;
                                                          parameter is
                                                          in the
                                                          response..

                                                          I thought
                                                          this will be
                                                          helpful
                                                          to=A0standardize=
=A0the
                                                          communication
                                                          between
                                                          Resource
                                                          Server and the
                                                          Authorization
                                                          Server..

                                                          I would
                                                          suggest we
                                                          completely
                                                          remove "vali=
d"
                                                          from the
                                                          response - or
                                                          define it much
                                                          clearly..

                                                          May be
                                                          can add
                                                          "revoked&quo=
t; with
                                                          a boolean
                                                          attribute..

                                                          Thanks
                                                          & regards,
                                                          -Prabath

                                                          On

                                                          Tue, Feb 12,
                                                          2013 at 3:19
                                                          AM, Justin
                                                          Richer <jricher=
@mitre.org>
                                                          wrote:

                                                          On
                                                          02/08/2013
                                                          12:51 AM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          Hi=A0Justin,

                                                          I have
                                                          couple of
                                                          questions
                                                          related to
                                                          "valid"
                                                          parameter...

                                                          This
                                                          endpoint can
                                                          be invoked by
                                                          the Resource
                                                          Server in
                                                          runtime...

                                                          That's
                                                          correct.

                                                          In that
                                                          case what is
                                                          exactly meant
                                                          by the
                                                          "resource_id=
"
                                                          in request ?

                                                          The
                                                          resource_id
                                                          field is a
                                                          service-specific
                                                          string that
                                                          basically lets
                                                          the resource
                                                          server provide
                                                          some context
                                                          to the request
                                                          to the auth
                                                          server. There
                                                          have been some
                                                          other
                                                          suggestions
                                                          like client IP
                                                          address, but I
                                                          wanted to put
                                                          this one in
                                                          because it
                                                          seemed to be a
                                                          common theme.
                                                          The client is
                                                          trying to do
                                                          *something*
                                                          with the
                                                          token, after
                                                          all, and the
                                                          rights,
                                                          permissions,
                                                          and metadata
                                                          associated
                                                          with the token
                                                          could change
                                                          based on that.
                                                          Since the
                                                          Introspection
                                                          endpoint is
                                                          all about
                                                          getting that
                                                          metadata back
                                                          to the PR,
                                                          this seemed
                                                          like a good
                                                          idea.

                                                          IMO a
                                                          token to be
                                                          valid depends
                                                          on set of
                                                          criteria based
                                                          on it's type.=
.

                                                          For a
                                                          Bearer token..

                                                          1. Token
                                                          should not be
                                                          expired
                                                          2. Token
                                                          should not be
                                                          revoked.
                                                          3. The
                                                          scope the
                                                          token issued
                                                          should match
                                                          with the scope
                                                          required for
                                                          the resource.

                                                          For a MAC
                                                          token...

                                                          1. Token
                                                          not expired
                                                          (mac id)
                                                          2. Token
                                                          should not be
                                                          revoked
                                                          3. The
                                                          scope the
                                                          token issued
                                                          should match
                                                          with the scope
                                                          required for
                                                          the resource.
                                                          4. HMAC
                                                          check should
                                                          be valid

                                                          There are
                                                          similar
                                                          conditions for
                                                          SAML bearer
                                                          too..

                                                          This isn't
                                                          really true.
                                                          The SAML
                                                          bearer token
                                                          is fully
                                                          self-contained
                                                          and doesn't
                                                          change based
                                                          on other
                                                          parameters in
                                                          the message,
                                                          unlike MAC.
                                                          Same with JWT.
                                                          When it hands
                                                          a SAML or JWT
                                                          token to the
                                                          AS, the PR has
                                                          given
                                                          *everything*
                                                          the server
                                                          needs to check
                                                          that token's
                                                          validity and
                                                          use. 

                                                          MAC signatures
                                                          change with
                                                          every message,
                                                          and they're
                                                          done across
                                                          several
                                                          components of
                                                          the HTTP
                                                          message.
                                                          Therefor, the
                                                          HMAC check for
                                                          MAC style
                                                          tokens will
                                                          still need to
                                                          be done by the
                                                          protected
                                                          resource.
                                                          Introspection
                                                          would help in
                                                          the case that
                                                          the signature
                                                          validated just
                                                          fine, but the
                                                          token might
                                                          have expired.
                                                          Or you need to
                                                          know what
                                                          scopes apply.
                                                          Introspection
                                                          isn't to full=
y
                                                          validate the
                                                          call to the
                                                          protected
                                                          resource -- if
                                                          that were the
                                                          case, the PR
                                                          would have to
                                                          send some kind
                                                          of
                                                          encapsulated
                                                          version of the
                                                          original
                                                          request.
                                                          Otherwise, the
                                                          AS won't have
                                                          all of the
                                                          information it
                                                          needs to check
                                                          the MAC.

                                                          I think what
                                                          you're
                                                          describing is
                                                          ultimately
                                                          *not* what the
                                                          introspection
                                                          endpoint is
                                                          intended to
                                                          do. If that's
                                                          unclear from
                                                          the document,
                                                          can you please
                                                          suggest text
                                                          that would
                                                          help clear the
                                                          use case up? I
                                                          wouldn't want
                                                          it to be
                                                          ambiguous.<=
font color=3D"#888888">

                                                          =A0-- Justin

                                                          Thanks
                                                          & regards,
                                                          -Prabath

                                                          On

                                                          Thu, Feb 7,
                                                          2013 at 10:30
                                                          PM, Justin
                                                          Richer <jricher=
@mitre.org>
                                                          wrote:

                                                          It validates
                                                          the token,
                                                          which would be
                                                          either the
                                                          token itself
                                                          in the case of
                                                          Bearer or the
                                                          token "id&qu=
ot;
                                                          part of
                                                          something more
                                                          complex like
                                                          MAC. It
                                                          doesn't
                                                          directly
                                                          validate the
                                                          usage of the
                                                          token, that's
                                                          still up to
                                                          the PR to do
                                                          that.

                                                          I nearly added
                                                          a "token typ=
e"
                                                          field in this
                                                          draft, but
                                                          held back
                                                          because there
                                                          are several
                                                          kinds of
                                                          "token type&=
quot;
                                                          that people
                                                          talk about in
                                                          OAuth. First,
                                                          there's
                                                          "Bearer"=
; vs.
                                                          "MAC" v=
s.
                                                          "HOK", =
or what
                                                          have you. Then
                                                          within Bearer
                                                          you have "JW=
T"
                                                          or "SAML&quo=
t; or
                                                          "unstructure=
d
                                                          blob". Then
                                                          you've also
                                                          got "access&=
quot;
                                                          vs. "refresh=
"
                                                          and other
                                                          flavors of
                                                          token, like
                                                          the id_token
                                                          in OpenID
                                                          Connect. 

                                                          Thing is, the
                                                          server running
                                                          the
                                                          introspection
                                                          endpoint will
                                                          probably know
                                                          *all* of
                                                          these. But
                                                          should it tell
                                                          the client? If
                                                          so, which of
                                                          the three, and
                                                          what names
                                                          should the
                                                          fields be?<=
font color=3D"#888888">

                                                          =A0-- Justin

                                                          On
                                                          02/07/2013
                                                          11:26 AM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          Okay.. I was
                                                          thinking this
                                                          could be used
                                                          as a way to
                                                          validate the
                                                          token as well.
                                                          BTW even in
                                                          this case
                                                          shouldn't
                                                          communicate
                                                          the type of
                                                          token to AS?
                                                          For example in
                                                          the case of
                                                          SAML profile -
                                                          it could be
                                                          SAML token..

                                                          Thanks
                                                          & regards,
                                                          -Prabath

                                                          On

                                                          Thu, Feb 7,
                                                          2013 at 8:39
                                                          PM, Justin
                                                          Richer <jricher=
@mitre.org>
                                                          wrote:

                                                          "valid"=
 might
                                                          not be the
                                                          best term, but
                                                          it's meant to
                                                          be a field
                                                          where the
                                                          server says
                                                          "yes this
                                                          token is still
                                                          good" or &qu=
ot;no
                                                          this token
                                                          isn't good
                                                          anymore". We
                                                          could instead
                                                          do this with
                                                          HTTP codes or
                                                          something but
                                                          I went with a
                                                          pure JSON
                                                          response.

                                                          =A0-- Justin

                                                          On
                                                          02/06/2013
                                                          10:47 PM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          Hi Justin,

                                                          I believe
                                                          this is
                                                          addressing one
                                                          of the key
                                                          missing part
                                                          in OAuth
                                                          2.0...

                                                          One
                                                          question - I
                                                          guess this was
                                                          discussed
                                                          already...

                                                          In the
                                                          spec - in the
                                                          introspection
                                                          response it
                                                          has the
                                                          attribute
                                                          "valid"=
 - this
                                                          is basically
                                                          the validity
                                                          of the token
                                                          provided in
                                                          the request.

                                                          Validation=
=A0criteria

                                                          depends on the
                                                          token and well
                                                          as token type
                                                          ( Bearer,
                                                          MAC..).

                                                          In the
                                                          spec it seems
                                                          like it's
                                                          coupled with
                                                          Bearer token
                                                          type... But I
                                                          guess, by
                                                          adding
                                                          "token_type&=
quot;
                                                          to the request
                                                          we can remove
                                                          this
                                                          dependency.

                                                          WDYT..?

                                                          Thanks
                                                          & regards,
                                                          -Prabath=A0<=
/div>

                                                          On

                                                          Thu, Feb 7,
                                                          2013 at 12:54
                                                          AM, Justin
                                                          Richer <jricher=
@mitre.org>
                                                          wrote:

                                                          Updated
                                                          introspection
                                                          draft based on
                                                          recent
                                                          comments.
                                                          Changes
                                                          include:

                                                          =A0- "scope&=
quot;
                                                          return
                                                          parameter now
                                                          follows
                                                          RFC6749 format
                                                          instead of
                                                          JSON array

                                                          =A0- "subjec=
t"
                                                          -> "sub&q=
uot;,
                                                          and "audienc=
e"
                                                          -> "aud&q=
uot;,
                                                          to be parallel
                                                          with JWT
                                                          claims

                                                          =A0- clarified
                                                          what happens
                                                          if the
                                                          authentication
                                                          is bad

                                                          =A0-- Justin

                                                          --------
                                                          Original
                                                          Message
                                                          --------

                                                          Subject: 
                                                          New
                                                          Version
                                                          Notification
                                                          for
                                                          draft-richer-oaut=
h-introspection-02.txt

                                                          Date: 
                                                          Wed, 6 Feb
                                                          2013 11:24:20
                                                          -0800

                                                          From: 
                                                          <internet-drafts@ietf.o=
rg>

                                                          To: 
                                                          <jricher@mitre.org>

                                                          A new versio=
n of I-D, draft-richer-oauth-introspection-02.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 02
Title:		 OAuth Token Introspection
Creation date:	 2013-02-06
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/interne=
t-drafts/draft-richer-oauth-introspection-02.txt
Status:          http://datatracker.ietf.org/doc/draft-=
richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-=
oauth-introspection-02
Diff:            http://www.ietf.org/rfcdiff?url2=
=3Ddraft-richer-oauth-introspection-02

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.

                                                                           =
      =20

The IETF Secretariat

_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

                                                          https://www.ietf.o=
rg/mailman/listinfo/oauth

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732=
=A0

                                                          http://blog.facilelogin.com
                                                          http://RampartFAQ.com

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732=
=A0

                                                          http://blog.facilelogin.com
                                                          http://RampartFAQ.com

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732=
=A0

                                                          http://blog.facilelogin.com
                                                          http://RampartFAQ.com

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732=
=A0

                                                          http://blog.facilelogin.com
                                                          http://RampartFAQ.com

                                                          ______=
_________________________________________

                                                          OAuth
                                                          mailing list

                                                          OAuth@ietf.org

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

                                                        -- 

                                                        Thanks &
                                                        Regards,

                                                        Prabath

                                                        Mobile : +94 71 809 6732=A0

                                                          http://blog.facilelogin.com
                                                          http://RampartFAQ.com

                                              -- 

                                              Thanks & Regards,

                                              Prabath

                                              Mobile : +94

                                                  71 809 6732=A0

                                                http://blog.facilelogin.com

                                                http://RampartFAQ.com

                                -- 

                                Thanks & Regards,

                                Prabath

                                Mobile : +94
                                    71 809 6732=A0

                                  http://blog.facilelogin.com

                                  http://RampartFAQ.com

                      -- 

                      Thanks & Regards,

                      Prabath

                      Mobile : +94 71
                          809 6732=A0

                        http://blog.facilelogin.com

                        http://RampartFAQ.com

        -- 

        Thanks & Regards,

        Prabath

        Mobile : +94 71 809 6732=A0

          http://=
blog.facilelogin.com

          http://Rampar=
tFAQ.com

-- 
Thanks &=
 Regards,
Prabath
Mobile : +94 71 809 6732=A0

=
http://blog.facil=
elogin.com

http://RampartFAQ.com

--047d7b603fe251265604d5b032c0--

From jricher@mitre.org  Thu Feb 14 06:47:18 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C915D21F8499 for ; Thu, 14 Feb 2013 06:47:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.57
X-Spam-Level: 
X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.028,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwXFoWXq1JiO for ; Thu, 14 Feb 2013 06:47:16 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6BA21F8461 for ; Thu, 14 Feb 2013 06:47:15 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 258081F2CB5; Thu, 14 Feb 2013 09:47:15 -0500 (EST)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id D1D4C1F2CAA; Thu, 14 Feb 2013 09:47:14 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 14 Feb 2013 09:47:14 -0500
Message-ID: <511CF8C5.70301@mitre.org>
Date: Thu, 14 Feb 2013 09:46:29 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Prabath Siriwardena 
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com> <5113C3AA.1040701@mitre.org>  <5113DDB2.7060805@mitre.org>  <51196777.6000502@mitre.org>   <511A5062.5010108@mitre.org>   <511CEEAA.3030801@mitre.org>   <511CF3EF.8040008@mitre.org>  <511CF4AB.5010700@mitre.org> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050307080309090507000504"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2013 14:47:18 -0000

--------------050307080309090507000504
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

On 02/14/2013 09:37 AM, Prabath Siriwardena wrote:
> The definition of valid is bit ambiguous in the draft...
>
> Okay.. If that is the definition... and if we beak that in to parts...
>
> "it hasn't expired" : In the response it self we have parameter for 
> issued_at and and expires_at - so whether the token is not expired or 
> not can even be derived at the requestor's end.

If the token isn't good anymore, it doesn't matter when it was issued or 
when it was expired, just that it has.

>
> "token was issued from here" : For this IMO we need to send an error 
> code. Requestor has picked the wrong AS.
We don't know if it came from another AS or if someone's just making 
things up. Either way it's not a good token.

>
> The remaining is  "revoked".. That is why I proposed earlier - we 
> better have an attribute "revoked" - instead of "valid" in the response..

The end result of all three is the same: either the token is good, or it 
isn't. I think it's much simpler and more useful to leave it at that.

  -- Justin

>
> WDYT...?
>
> Thanks & regards,
> -Prabath
>
>
> On Thu, Feb 14, 2013 at 7:58 PM, Justin Richer  > wrote:
>
>     Because it will be the one that issued the token in the first place.
>
>     Validity means "token was issued from here, it hasn't been
>     revoked, it hasn't expired".
>
>      -- Justin
>
>
>     On 02/14/2013 09:28 AM, Prabath Siriwardena wrote:
>>     Okay. With out knowing the type of the token how can the AS
>>     validate the token ? What is meant by the validity there?
>>
>>     Thanks & regards,
>>     -Prabath
>>
>>     On Thu, Feb 14, 2013 at 7:55 PM, Justin Richer >     > wrote:
>>
>>         OK, I don't see the utility in that at all. What would it
>>         accomplish?
>>
>>          -- Justin
>>
>>
>>         On 02/14/2013 09:25 AM, Prabath Siriwardena wrote:
>>>         To make it clear - my suggestion is to add token_type_hint
>>>         to the introspection request. It can be from client to AS or
>>>         from RS to AS.
>>>
>>>         Then AS can decide whether the provided token is valid or
>>>         not and include "valid" attribute in the introspection response.
>>>
>>>         Thanks & regards,
>>>         -Prabath
>>>
>>>         On Thu, Feb 14, 2013 at 7:52 PM, Prabath Siriwardena
>>>         > wrote:
>>>
>>>             Both the client and the resource owner should be aware
>>>             of the token type.
>>>
>>>             My argument is, if the authorization server to decide
>>>             whether the token is valid or not ( irrespective of who
>>>             asked the question) - AS needs to know the token type -
>>>             because to validate a token AS should know the token type.
>>>
>>>             The token type could be, bearer or MAC or any other
>>>             token type.
>>>
>>>             Thanks & regards,
>>>             -Prabath
>>>
>>>
>>>             On Thu, Feb 14, 2013 at 7:33 PM, Justin Richer
>>>             > wrote:
>>>
>>>                 What exactly are you suggesting be added to
>>>                 introspection? The "token_type_hint" is from the
>>>                 client to the server, but what you've asked for in
>>>                 terms of "token type" is from the server to the
>>>                 client. And there was never an answer to what
>>>                 exactly is meant by "token type" in this case,
>>>                 particularly because you seem to want to call out
>>>                 things like SAML and Bearer as separate types.
>>>
>>>                  -- Justin
>>>
>>>
>>>
>>>                 On 02/14/2013 06:59 AM, Prabath Siriwardena wrote:
>>>>                 I noticed that the latest Token Revocation draft
>>>>                 [1] has introduced the parameter "token_type_hint".
>>>>                 I would suggest the same here, as that would make
>>>>                 what is meant by "valid" much clear..
>>>>
>>>>                 [1]:
>>>>                 http://tools.ietf.org/html/draft-ietf-oauth-revocation-05
>>>>
>>>>                 Thanks & regards,
>>>>                 -Prabath
>>>>
>>>>                 On Tue, Feb 12, 2013 at 9:35 PM, Prabath
>>>>                 Siriwardena >>>                 > wrote:
>>>>
>>>>                     Hi Justin,
>>>>
>>>>                     I doubt whether valid_token would make a
>>>>                     difference..?
>>>>
>>>>                     My initial argument is what is the validation
>>>>                     criteria..? Validation criteria depends on the
>>>>                     token_type..
>>>>
>>>>                     If we are talking only about metadata - then I
>>>>                     believe "revoked", "expired" would be more
>>>>                     meaningful..
>>>>
>>>>                     Thanks & regards,
>>>>                     -Prabath
>>>>
>>>>
>>>>                     On Tue, Feb 12, 2013 at 7:53 PM, Justin Richer
>>>>                     >
>>>>                     wrote:
>>>>
>>>>                         OK, I can see the wisdom in changing this
>>>>                         term.
>>>>
>>>>                         I picked "valid" because I wanted a simple
>>>>                         "boolean" value that would require no
>>>>                         additional parsing or string-matching on
>>>>                         the client's behalf, and I'd like to stick
>>>>                         with that. OAuth is built with the
>>>>                         assumption that clients need to be able to
>>>>                         recover from invalid tokens at any stage,
>>>>                         so I think a simple yes/no is the right
>>>>                         step here.
>>>>
>>>>                         That said, I think you're both right that
>>>>                         "valid" seems to have caused a bit of
>>>>                         confusion. I don't want to go with
>>>>                         "revoked" because I'd rather have the
>>>>                         "token is OK" be the positive boolean value.
>>>>
>>>>                         Would "valid_token" be more clear? Or do we
>>>>                         need a different adjective all together?
>>>>
>>>>                          -- Justin
>>>>
>>>>
>>>>                         On 02/11/2013 08:02 PM, Richard Harrington
>>>>                         wrote:
>>>>>                         Have you considered "status" instead of
>>>>>                         "valid"?  It could have values like
>>>>>                         "active", "expired", and "revoked".
>>>>>
>>>>>                         Is it worthwhile including the status of
>>>>>                         the client also?  For example, a client
>>>>>                         application could be disabled, temporarily
>>>>>                         or permanently, and thus disabling its
>>>>>                         access tokens as well.
>>>>>
>>>>>
>>>>>                         On Feb 11, 2013, at 1:56 PM, Prabath
>>>>>                         Siriwardena >>>>                         > wrote:
>>>>>
>>>>>>                         I guess confusion is with 'valid'
>>>>>>                         parameter is in the response..
>>>>>>
>>>>>>                         I thought this will be helpful
>>>>>>                         to standardize the communication between
>>>>>>                         Resource Server and the Authorization
>>>>>>                         Server..
>>>>>>
>>>>>>                         I would suggest we completely remove
>>>>>>                         "valid" from the response - or define it
>>>>>>                         much clearly..
>>>>>>
>>>>>>                         May be can add "revoked" with a boolean
>>>>>>                         attribute..
>>>>>>
>>>>>>                         Thanks & regards,
>>>>>>                         -Prabath
>>>>>>
>>>>>>                         On Tue, Feb 12, 2013 at 3:19 AM, Justin
>>>>>>                         Richer >>>>>                         > wrote:
>>>>>>
>>>>>>
>>>>>>                             On 02/08/2013 12:51 AM, Prabath
>>>>>>                             Siriwardena wrote:
>>>>>>>                             Hi Justin,
>>>>>>>
>>>>>>>                             I have couple of questions related
>>>>>>>                             to "valid" parameter...
>>>>>>>
>>>>>>>                             This endpoint can be invoked by the
>>>>>>>                             Resource Server in runtime...
>>>>>>
>>>>>>                             That's correct.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>                             In that case what is exactly meant
>>>>>>>                             by the "resource_id" in request ?
>>>>>>
>>>>>>                             The resource_id field is a
>>>>>>                             service-specific string that
>>>>>>                             basically lets the resource server
>>>>>>                             provide some context to the request
>>>>>>                             to the auth server. There have been
>>>>>>                             some other suggestions like client IP
>>>>>>                             address, but I wanted to put this one
>>>>>>                             in because it seemed to be a common
>>>>>>                             theme. The client is trying to do
>>>>>>                             *something* with the token, after
>>>>>>                             all, and the rights, permissions, and
>>>>>>                             metadata associated with the token
>>>>>>                             could change based on that. Since the
>>>>>>                             Introspection endpoint is all about
>>>>>>                             getting that metadata back to the PR,
>>>>>>                             this seemed like a good idea.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>                             IMO a token to be valid depends on
>>>>>>>                             set of criteria based on it's type..
>>>>>>>
>>>>>>>                             For a Bearer token..
>>>>>>>
>>>>>>>                             1. Token should not be expired
>>>>>>>                             2. Token should not be revoked.
>>>>>>>                             3. The scope the token issued should
>>>>>>>                             match with the scope required for
>>>>>>>                             the resource.
>>>>>>>
>>>>>>>                             For a MAC token...
>>>>>>>
>>>>>>>                             1. Token not expired (mac id)
>>>>>>>                             2. Token should not be revoked
>>>>>>>                             3. The scope the token issued should
>>>>>>>                             match with the scope required for
>>>>>>>                             the resource.
>>>>>>>                             4. HMAC check should be valid
>>>>>>>
>>>>>>>                             There are similar conditions for
>>>>>>>                             SAML bearer too..
>>>>>>
>>>>>>                             This isn't really true. The SAML
>>>>>>                             bearer token is fully self-contained
>>>>>>                             and doesn't change based on other
>>>>>>                             parameters in the message, unlike
>>>>>>                             MAC. Same with JWT. When it hands a
>>>>>>                             SAML or JWT token to the AS, the PR
>>>>>>                             has given *everything* the server
>>>>>>                             needs to check that token's validity
>>>>>>                             and use.
>>>>>>
>>>>>>                             MAC signatures change with every
>>>>>>                             message, and they're done across
>>>>>>                             several components of the HTTP
>>>>>>                             message. Therefor, the HMAC check for
>>>>>>                             MAC style tokens will still need to
>>>>>>                             be done by the protected resource.
>>>>>>                             Introspection would help in the case
>>>>>>                             that the signature validated just
>>>>>>                             fine, but the token might have
>>>>>>                             expired. Or you need to know what
>>>>>>                             scopes apply. Introspection isn't to
>>>>>>                             fully validate the call to the
>>>>>>                             protected resource -- if that were
>>>>>>                             the case, the PR would have to send
>>>>>>                             some kind of encapsulated version of
>>>>>>                             the original request. Otherwise, the
>>>>>>                             AS won't have all of the information
>>>>>>                             it needs to check the MAC.
>>>>>>
>>>>>>
>>>>>>                             I think what you're describing is
>>>>>>                             ultimately *not* what the
>>>>>>                             introspection endpoint is intended to
>>>>>>                             do. If that's unclear from the
>>>>>>                             document, can you please suggest text
>>>>>>                             that would help clear the use case
>>>>>>                             up? I wouldn't want it to be ambiguous.
>>>>>>
>>>>>>                              -- Justin
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>                             Thanks & regards,
>>>>>>>                             -Prabath
>>>>>>>
>>>>>>>
>>>>>>>                             On Thu, Feb 7, 2013 at 10:30 PM,
>>>>>>>                             Justin Richer >>>>>>                             > wrote:
>>>>>>>
>>>>>>>                                 It validates the token, which
>>>>>>>                                 would be either the token itself
>>>>>>>                                 in the case of Bearer or the
>>>>>>>                                 token "id" part of something
>>>>>>>                                 more complex like MAC. It
>>>>>>>                                 doesn't directly validate the
>>>>>>>                                 usage of the token, that's still
>>>>>>>                                 up to the PR to do that.
>>>>>>>
>>>>>>>                                 I nearly added a "token type"
>>>>>>>                                 field in this draft, but held
>>>>>>>                                 back because there are several
>>>>>>>                                 kinds of "token type" that
>>>>>>>                                 people talk about in OAuth.
>>>>>>>                                 First, there's "Bearer" vs.
>>>>>>>                                 "MAC" vs. "HOK", or what have
>>>>>>>                                 you. Then within Bearer you have
>>>>>>>                                 "JWT" or "SAML" or "unstructured
>>>>>>>                                 blob". Then you've also got
>>>>>>>                                 "access" vs. "refresh" and other
>>>>>>>                                 flavors of token, like the
>>>>>>>                                 id_token in OpenID Connect.
>>>>>>>
>>>>>>>                                 Thing is, the server running the
>>>>>>>                                 introspection endpoint will
>>>>>>>                                 probably know *all* of these.
>>>>>>>                                 But should it tell the client?
>>>>>>>                                 If so, which of the three, and
>>>>>>>                                 what names should the fields be?
>>>>>>>
>>>>>>>                                  -- Justin
>>>>>>>
>>>>>>>
>>>>>>>                                 On 02/07/2013 11:26 AM, Prabath
>>>>>>>                                 Siriwardena wrote:
>>>>>>>>                                 Okay.. I was thinking this
>>>>>>>>                                 could be used as a way to
>>>>>>>>                                 validate the token as well. BTW
>>>>>>>>                                 even in this case shouldn't
>>>>>>>>                                 communicate the type of token
>>>>>>>>                                 to AS? For example in the case
>>>>>>>>                                 of SAML profile - it could be
>>>>>>>>                                 SAML token..
>>>>>>>>
>>>>>>>>                                 Thanks & regards,
>>>>>>>>                                 -Prabath
>>>>>>>>
>>>>>>>>                                 On Thu, Feb 7, 2013 at 8:39 PM,
>>>>>>>>                                 Justin Richer
>>>>>>>>                                 >>>>>>>                                 > wrote:
>>>>>>>>
>>>>>>>>                                     "valid" might not be the
>>>>>>>>                                     best term, but it's meant
>>>>>>>>                                     to be a field where the
>>>>>>>>                                     server says "yes this token
>>>>>>>>                                     is still good" or "no this
>>>>>>>>                                     token isn't good anymore".
>>>>>>>>                                     We could instead do this
>>>>>>>>                                     with HTTP codes or
>>>>>>>>                                     something but I went with a
>>>>>>>>                                     pure JSON response.
>>>>>>>>
>>>>>>>>                                      -- Justin
>>>>>>>>
>>>>>>>>
>>>>>>>>                                     On 02/06/2013 10:47 PM,
>>>>>>>>                                     Prabath Siriwardena wrote:
>>>>>>>>>                                     Hi Justin,
>>>>>>>>>
>>>>>>>>>                                     I believe this is
>>>>>>>>>                                     addressing one of the key
>>>>>>>>>                                     missing part in OAuth 2.0...
>>>>>>>>>
>>>>>>>>>                                     One question - I guess
>>>>>>>>>                                     this was discussed already...
>>>>>>>>>
>>>>>>>>>                                     In the spec - in the
>>>>>>>>>                                     introspection response it
>>>>>>>>>                                     has the attribute "valid"
>>>>>>>>>                                     - this is basically the
>>>>>>>>>                                     validity of the token
>>>>>>>>>                                     provided in the request.
>>>>>>>>>
>>>>>>>>>                                     Validation criteria
>>>>>>>>>                                     depends on the token and
>>>>>>>>>                                     well as token type (
>>>>>>>>>                                     Bearer, MAC..).
>>>>>>>>>
>>>>>>>>>                                     In the spec it seems like
>>>>>>>>>                                     it's coupled with Bearer
>>>>>>>>>                                     token type... But I guess,
>>>>>>>>>                                     by adding "token_type" to
>>>>>>>>>                                     the request we can remove
>>>>>>>>>                                     this dependency.
>>>>>>>>>
>>>>>>>>>                                     WDYT..?
>>>>>>>>>
>>>>>>>>>                                     Thanks & regards,
>>>>>>>>>                                     -Prabath
>>>>>>>>>
>>>>>>>>>                                     On Thu, Feb 7, 2013 at
>>>>>>>>>                                     12:54 AM, Justin Richer
>>>>>>>>>                                     >>>>>>>>                                     > wrote:
>>>>>>>>>
>>>>>>>>>                                         Updated introspection
>>>>>>>>>                                         draft based on recent
>>>>>>>>>                                         comments. Changes include:
>>>>>>>>>
>>>>>>>>>                                          - "scope" return
>>>>>>>>>                                         parameter now follows
>>>>>>>>>                                         RFC6749 format instead
>>>>>>>>>                                         of JSON array
>>>>>>>>>                                          - "subject" -> "sub",
>>>>>>>>>                                         and "audience" ->
>>>>>>>>>                                         "aud", to be parallel
>>>>>>>>>                                         with JWT claims
>>>>>>>>>                                          - clarified what
>>>>>>>>>                                         happens if the
>>>>>>>>>                                         authentication is bad
>>>>>>>>>
>>>>>>>>>                                          -- Justin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                                         -------- Original
>>>>>>>>>                                         Message --------
>>>>>>>>>                                         Subject: 	New Version
>>>>>>>>>                                         Notification for
>>>>>>>>>                                         draft-richer-oauth-introspection-02.txt
>>>>>>>>>
>>>>>>>>>                                         Date: 	Wed, 6 Feb 2013
>>>>>>>>>                                         11:24:20 -0800
>>>>>>>>>                                         From:
>>>>>>>>>                                         
>>>>>>>>>                                         
>>>>>>>>>
>>>>>>>>>                                         To:
>>>>>>>>>                                         
>>>>>>>>>                                         
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                                         A new version of I-D, draft-richer-oauth-introspection-02.txt
>>>>>>>>>                                         has been successfully submitted by Justin Richer and posted to the
>>>>>>>>>                                         IETF repository.
>>>>>>>>>
>>>>>>>>>                                         Filename:	 draft-richer-oauth-introspection
>>>>>>>>>                                         Revision:	 02
>>>>>>>>>                                         Title:		 OAuth Token Introspection
>>>>>>>>>                                         Creation date:	 2013-02-06
>>>>>>>>>                                         WG ID:		 Individual Submission
>>>>>>>>>                                         Number of pages: 6
>>>>>>>>>                                         URL:http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
>>>>>>>>>                                         Status:http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
>>>>>>>>>                                         Htmlized:http://tools.ietf.org/html/draft-richer-oauth-introspection-02
>>>>>>>>>                                         Diff:http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02
>>>>>>>>>
>>>>>>>>>                                         Abstract:
>>>>>>>>>                                             This specification defines a method for a client or protected
>>>>>>>>>                                             resource to query an OAuth authorization server to determine meta-
>>>>>>>>>                                             information about an OAuth token.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                                                                                                                            
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                                         The IETF Secretariat
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                                         _______________________________________________
>>>>>>>>>                                         OAuth mailing list
>>>>>>>>>                                         OAuth@ietf.org
>>>>>>>>>                                         
>>>>>>>>>                                         https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                                     -- 
>>>>>>>>>                                     Thanks & Regards,
>>>>>>>>>                                     Prabath
>>>>>>>>>
>>>>>>>>>                                     Mobile : +94 71 809 6732
>>>>>>>>>                                     
>>>>>>>>>
>>>>>>>>>                                     http://blog.facilelogin.com
>>>>>>>>>                                     http://RampartFAQ.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                                 -- 
>>>>>>>>                                 Thanks & Regards,
>>>>>>>>                                 Prabath
>>>>>>>>
>>>>>>>>                                 Mobile : +94 71 809 6732
>>>>>>>>                                 
>>>>>>>>
>>>>>>>>                                 http://blog.facilelogin.com
>>>>>>>>                                 http://RampartFAQ.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                             -- 
>>>>>>>                             Thanks & Regards,
>>>>>>>                             Prabath
>>>>>>>
>>>>>>>                             Mobile : +94 71 809 6732
>>>>>>>                             
>>>>>>>
>>>>>>>                             http://blog.facilelogin.com
>>>>>>>                             http://RampartFAQ.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>                         -- 
>>>>>>                         Thanks & Regards,
>>>>>>                         Prabath
>>>>>>
>>>>>>                         Mobile : +94 71 809 6732
>>>>>>                         
>>>>>>
>>>>>>                         http://blog.facilelogin.com
>>>>>>                         http://RampartFAQ.com
>>>>>>                         _______________________________________________
>>>>>>                         OAuth mailing list
>>>>>>                         OAuth@ietf.org 
>>>>>>                         https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>>
>>>>                     -- 
>>>>                     Thanks & Regards,
>>>>                     Prabath
>>>>
>>>>                     Mobile : +94 71 809 6732
>>>>                     
>>>>
>>>>                     http://blog.facilelogin.com
>>>>                     http://RampartFAQ.com
>>>>
>>>>
>>>>
>>>>
>>>>                 -- 
>>>>                 Thanks & Regards,
>>>>                 Prabath
>>>>
>>>>                 Mobile : +94 71 809 6732 
>>>>
>>>>                 http://blog.facilelogin.com
>>>>                 http://RampartFAQ.com
>>>
>>>
>>>
>>>
>>>             -- 
>>>             Thanks & Regards,
>>>             Prabath
>>>
>>>             Mobile : +94 71 809 6732 
>>>
>>>             http://blog.facilelogin.com
>>>             http://RampartFAQ.com
>>>
>>>
>>>
>>>
>>>         -- 
>>>         Thanks & Regards,
>>>         Prabath
>>>
>>>         Mobile : +94 71 809 6732 
>>>
>>>         http://blog.facilelogin.com
>>>         http://RampartFAQ.com
>>
>>
>>
>>
>>     -- 
>>     Thanks & Regards,
>>     Prabath
>>
>>     Mobile : +94 71 809 6732 
>>
>>     http://blog.facilelogin.com
>>     http://RampartFAQ.com
>
>
>
>
> -- 
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com

--------------050307080309090507000504
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

    On 02/14/2013 09:37 AM, Prabath
      Siriwardena wrote:

      The definition of valid is bit ambiguous in the draft...

      Okay.. If that is the definition... and if we beak that in to
        parts...

      "it hasn't expired" : In the response it self we have
        parameter for issued_at and and expires_at - so whether the
        token is not expired or not can even be derived at the
        requestor's end.

    If the token isn't good anymore, it doesn't matter when it was
    issued or when it was expired, just that it has.

      "token was issued from here" : For this IMO we need to send
        an error code. Requestor has picked the wrong AS.

    We don't know if it came from another AS or if someone's just making
    things up. Either way it's not a good token.

      The remaining is  "revoked".. That is why I
        proposed earlier - we better have an attribute "revoked" -
        instead of "valid" in the response..

    The end result of all three is the same: either the token is good,
    or it isn't. I think it's much simpler and more useful to leave it
    at that.

     -- Justin

      WDYT...?

      Thanks & regards,
      -Prabath

        On Thu, Feb 14, 2013 at 7:58 PM, Justin
          Richer <jricher@mitre.org>
          wrote:

             Because it will be
              the one that issued the token in the first place. 

              Validity means "token was issued from here, it hasn't been
              revoked, it hasn't expired". 

                   -- Justin

                  On 02/14/2013 09:28 AM, Prabath Siriwardena
                    wrote:

                   Okay. With out knowing the
                    type of the token how can the AS validate the token
                    ? What is meant by the validity there?

                    Thanks & regards,
                    -Prabath

                      On Thu, Feb 14, 2013 at
                        7:55 PM, Justin Richer <jricher@mitre.org>
                        wrote:

                           OK, I
                            don't see the utility in that at all. What
                            would it accomplish?

                                 -- Justin

                                On 02/14/2013 09:25 AM, Prabath
                                  Siriwardena wrote:

                                 To make it
                                  clear - my suggestion is to add
                                  token_type_hint to the introspection
                                  request. It can be from client to AS
                                  or from RS to AS.

                                  Then AS can decide whether the
                                    provided token is valid or not and
                                    include "valid" attribute in the
                                    introspection response.

                                  Thanks & regards,
                                  -Prabath

                                    On Thu, Feb
                                      14, 2013 at 7:52 PM, Prabath
                                      Siriwardena <prabath@wso2.com>
                                      wrote:

                                      Both the
                                        client and the resource owner
                                        should be aware of the token
                                        type.

                                        My argument is, if the
                                          authorization server to decide
                                          whether the token is valid or
                                          not ( irrespective of who
                                          asked the question) - AS needs
                                          to know the token type -
                                          because to validate a token AS
                                          should know the token type.

                                        The token type could be,
                                          bearer or MAC or any other
                                          token type.

                                        Thanks & regards,
                                        -Prabath

                                              On
                                                Thu, Feb 14, 2013 at
                                                7:33 PM, Justin Richer <jricher@mitre.org>
                                                wrote:

                                                   What
                                                    exactly are you
                                                    suggesting be added
                                                    to introspection?
                                                    The
                                                    "token_type_hint" is
                                                    from the client to
                                                    the server, but what
                                                    you've asked for in
                                                    terms of "token
                                                    type" is from the
                                                    server to the
                                                    client. And there
                                                    was never an answer
                                                    to what exactly is
                                                    meant by "token
                                                    type" in this case,
                                                    particularly because
                                                    you seem to want to
                                                    call out things like
                                                    SAML and Bearer as
                                                    separate types. 

                                                         -- Justin

                                                        On
                                                          02/14/2013
                                                          06:59 AM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                         I
                                                          noticed that
                                                          the latest
                                                          Token
                                                          Revocation
                                                          draft [1] has
                                                          introduced the
                                                          parameter
                                                          "token_type_hint".
                                                          I would
                                                          suggest the
                                                          same here, as
                                                          that would
                                                          make what is
                                                          meant by
                                                          "valid" much
                                                          clear..

                                                          [1]: http://tools.ietf.org/html/draft-ietf-oauth-revocation-05

                                                          Thanks
                                                          & regards,
                                                          -Prabath

                                                          On

                                                          Tue, Feb 12,
                                                          2013 at 9:35
                                                          PM, Prabath
                                                          Siriwardena <prabath@wso2.com>
                                                          wrote:

                                                          Hi

                                                          Justin,

                                                          I doubt
                                                          whether
                                                          valid_token
                                                          would make a
                                                          difference..?

                                                          My
                                                          initial
                                                          argument is
                                                          what is the
                                                          validation
                                                          criteria..?
                                                          Validation
                                                          criteria
                                                          depends on the
                                                          token_type..

                                                          If we are
                                                          talking only
                                                          about metadata
                                                          - then I
                                                          believe
                                                          "revoked",
                                                          "expired"
                                                          would be more
                                                          meaningful..

                                                          Thanks
                                                          & regards,
                                                          -Prabath

                                                          On Tue, Feb
                                                          12, 2013 at
                                                          7:53 PM,
                                                          Justin Richer
                                                          <jricher@mitre.org>
                                                          wrote:

                                                          OK, I can see
                                                          the wisdom in
                                                          changing this
                                                          term. 

                                                          I picked
                                                          "valid"
                                                          because I
                                                          wanted a
                                                          simple
                                                          "boolean"
                                                          value that
                                                          would require
                                                          no additional
                                                          parsing or
                                                          string-matching
                                                          on the
                                                          client's
                                                          behalf, and
                                                          I'd like to
                                                          stick with
                                                          that. OAuth is
                                                          built with the
                                                          assumption
                                                          that clients
                                                          need to be
                                                          able to
                                                          recover from
                                                          invalid tokens
                                                          at any stage,
                                                          so I think a
                                                          simple yes/no
                                                          is the right
                                                          step here. 

                                                          That said, I
                                                          think you're
                                                          both right
                                                          that "valid"
                                                          seems to have
                                                          caused a bit
                                                          of confusion.
                                                          I don't want
                                                          to go with
                                                          "revoked"
                                                          because I'd
                                                          rather have
                                                          the "token is
                                                          OK" be the
                                                          positive
                                                          boolean value.

                                                          Would
                                                          "valid_token"
                                                          be more clear?
                                                          Or do we need
                                                          a different
                                                          adjective all
                                                          together?

                                                           -- Justin

                                                          On
                                                          02/11/2013
                                                          08:02 PM,
                                                          Richard
                                                          Harrington
                                                          wrote:

                                                          Have you
                                                          considered
                                                          "status"
                                                          instead of
                                                          "valid"?  It
                                                          could have
                                                          values like
                                                          "active",
                                                          "expired", and
                                                          "revoked".

                                                          Is it
                                                          worthwhile
                                                          including the
                                                          status of the
                                                          client also?
                                                           For example,
                                                          a client
                                                          application
                                                          could be
                                                          disabled,
                                                          temporarily or
                                                          permanently,
                                                          and thus
                                                          disabling its
                                                          access tokens
                                                          as well.

                                                          On Feb 11,
                                                          2013, at 1:56
                                                          PM, Prabath
                                                          Siriwardena
                                                          <prabath@wso2.com>
                                                          wrote:

                                                          I guess
                                                          confusion is
                                                          with 'valid'
                                                          parameter is
                                                          in the
                                                          response..

                                                          I thought
                                                          this will be
                                                          helpful
                                                          to standardize the
                                                          communication
                                                          between
                                                          Resource
                                                          Server and the
                                                          Authorization
                                                          Server..

                                                          I would
                                                          suggest we
                                                          completely
                                                          remove "valid"
                                                          from the
                                                          response - or
                                                          define it much
                                                          clearly..

                                                          May be
                                                          can add
                                                          "revoked" with
                                                          a boolean
                                                          attribute..

                                                          Thanks
                                                          & regards,
                                                          -Prabath

                                                          On

                                                          Tue, Feb 12,
                                                          2013 at 3:19
                                                          AM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:

                                                          On
                                                          02/08/2013
                                                          12:51 AM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          Hi Justin,

                                                          I have
                                                          couple of
                                                          questions
                                                          related to
                                                          "valid"
                                                          parameter...

                                                          This
                                                          endpoint can
                                                          be invoked by
                                                          the Resource
                                                          Server in
                                                          runtime...

                                                          That's
                                                          correct.

                                                          In that
                                                          case what is
                                                          exactly meant
                                                          by the
                                                          "resource_id"
                                                          in request ?

                                                          The
                                                          resource_id
                                                          field is a
                                                          service-specific
                                                          string that
                                                          basically lets
                                                          the resource
                                                          server provide
                                                          some context
                                                          to the request
                                                          to the auth
                                                          server. There
                                                          have been some
                                                          other
                                                          suggestions
                                                          like client IP
                                                          address, but I
                                                          wanted to put
                                                          this one in
                                                          because it
                                                          seemed to be a
                                                          common theme.
                                                          The client is
                                                          trying to do
                                                          *something*
                                                          with the
                                                          token, after
                                                          all, and the
                                                          rights,
                                                          permissions,
                                                          and metadata
                                                          associated
                                                          with the token
                                                          could change
                                                          based on that.
                                                          Since the
                                                          Introspection
                                                          endpoint is
                                                          all about
                                                          getting that
                                                          metadata back
                                                          to the PR,
                                                          this seemed
                                                          like a good
                                                          idea.

                                                          IMO a
                                                          token to be
                                                          valid depends
                                                          on set of
                                                          criteria based
                                                          on it's type..

                                                          For a
                                                          Bearer token..

                                                          1. Token
                                                          should not be
                                                          expired
                                                          2. Token
                                                          should not be
                                                          revoked.
                                                          3. The
                                                          scope the
                                                          token issued
                                                          should match
                                                          with the scope
                                                          required for
                                                          the resource.

                                                          For a MAC
                                                          token...

                                                          1. Token
                                                          not expired
                                                          (mac id)
                                                          2. Token
                                                          should not be
                                                          revoked
                                                          3. The
                                                          scope the
                                                          token issued
                                                          should match
                                                          with the scope
                                                          required for
                                                          the resource.
                                                          4. HMAC
                                                          check should
                                                          be valid

                                                          There are
                                                          similar
                                                          conditions for
                                                          SAML bearer
                                                          too..

                                                          This isn't
                                                          really true.
                                                          The SAML
                                                          bearer token
                                                          is fully
                                                          self-contained
                                                          and doesn't
                                                          change based
                                                          on other
                                                          parameters in
                                                          the message,
                                                          unlike MAC.
                                                          Same with JWT.
                                                          When it hands
                                                          a SAML or JWT
                                                          token to the
                                                          AS, the PR has
                                                          given
                                                          *everything*
                                                          the server
                                                          needs to check
                                                          that token's
                                                          validity and
                                                          use. 

                                                          MAC signatures
                                                          change with
                                                          every message,
                                                          and they're
                                                          done across
                                                          several
                                                          components of
                                                          the HTTP
                                                          message.
                                                          Therefor, the
                                                          HMAC check for
                                                          MAC style
                                                          tokens will
                                                          still need to
                                                          be done by the
                                                          protected
                                                          resource.
                                                          Introspection
                                                          would help in
                                                          the case that
                                                          the signature
                                                          validated just
                                                          fine, but the
                                                          token might
                                                          have expired.
                                                          Or you need to
                                                          know what
                                                          scopes apply.
                                                          Introspection
                                                          isn't to fully
                                                          validate the
                                                          call to the
                                                          protected
                                                          resource -- if
                                                          that were the
                                                          case, the PR
                                                          would have to
                                                          send some kind
                                                          of
                                                          encapsulated
                                                          version of the
                                                          original
                                                          request.
                                                          Otherwise, the
                                                          AS won't have
                                                          all of the
                                                          information it
                                                          needs to check
                                                          the MAC.

                                                          I think what
                                                          you're
                                                          describing is
                                                          ultimately
                                                          *not* what the
                                                          introspection
                                                          endpoint is
                                                          intended to
                                                          do. If that's
                                                          unclear from
                                                          the document,
                                                          can you please
                                                          suggest text
                                                          that would
                                                          help clear the
                                                          use case up? I
                                                          wouldn't want
                                                          it to be
                                                          ambiguous.

                                                           -- Justin

                                                          Thanks
                                                          & regards,
                                                          -Prabath

                                                          On

                                                          Thu, Feb 7,
                                                          2013 at 10:30
                                                          PM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:

                                                          It validates
                                                          the token,
                                                          which would be
                                                          either the
                                                          token itself
                                                          in the case of
                                                          Bearer or the
                                                          token "id"
                                                          part of
                                                          something more
                                                          complex like
                                                          MAC. It
                                                          doesn't
                                                          directly
                                                          validate the
                                                          usage of the
                                                          token, that's
                                                          still up to
                                                          the PR to do
                                                          that.

                                                          I nearly added
                                                          a "token type"
                                                          field in this
                                                          draft, but
                                                          held back
                                                          because there
                                                          are several
                                                          kinds of
                                                          "token type"
                                                          that people
                                                          talk about in
                                                          OAuth. First,
                                                          there's
                                                          "Bearer" vs.
                                                          "MAC" vs.
                                                          "HOK", or what
                                                          have you. Then
                                                          within Bearer
                                                          you have "JWT"
                                                          or "SAML" or
                                                          "unstructured
                                                          blob". Then
                                                          you've also
                                                          got "access"
                                                          vs. "refresh"
                                                          and other
                                                          flavors of
                                                          token, like
                                                          the id_token
                                                          in OpenID
                                                          Connect. 

                                                          Thing is, the
                                                          server running
                                                          the
                                                          introspection
                                                          endpoint will
                                                          probably know
                                                          *all* of
                                                          these. But
                                                          should it tell
                                                          the client? If
                                                          so, which of
                                                          the three, and
                                                          what names
                                                          should the
                                                          fields be?

                                                           -- Justin

                                                          On
                                                          02/07/2013
                                                          11:26 AM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          Okay.. I was
                                                          thinking this
                                                          could be used
                                                          as a way to
                                                          validate the
                                                          token as well.
                                                          BTW even in
                                                          this case
                                                          shouldn't
                                                          communicate
                                                          the type of
                                                          token to AS?
                                                          For example in
                                                          the case of
                                                          SAML profile -
                                                          it could be
                                                          SAML token..

                                                          Thanks
                                                          & regards,
                                                          -Prabath

                                                          On

                                                          Thu, Feb 7,
                                                          2013 at 8:39
                                                          PM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:

                                                          "valid" might
                                                          not be the
                                                          best term, but
                                                          it's meant to
                                                          be a field
                                                          where the
                                                          server says
                                                          "yes this
                                                          token is still
                                                          good" or "no
                                                          this token
                                                          isn't good
                                                          anymore". We
                                                          could instead
                                                          do this with
                                                          HTTP codes or
                                                          something but
                                                          I went with a
                                                          pure JSON
                                                          response.

                                                           -- Justin

                                                          On
                                                          02/06/2013
                                                          10:47 PM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          Hi Justin,

                                                          I believe
                                                          this is
                                                          addressing one
                                                          of the key
                                                          missing part
                                                          in OAuth
                                                          2.0...

                                                          One
                                                          question - I
                                                          guess this was
                                                          discussed
                                                          already...

                                                          In the
                                                          spec - in the
                                                          introspection
                                                          response it
                                                          has the
                                                          attribute
                                                          "valid" - this
                                                          is basically
                                                          the validity
                                                          of the token
                                                          provided in
                                                          the request.

                                                          Validation criteria

                                                          depends on the
                                                          token and well
                                                          as token type
                                                          ( Bearer,
                                                          MAC..).

                                                          In the
                                                          spec it seems
                                                          like it's
                                                          coupled with
                                                          Bearer token
                                                          type... But I
                                                          guess, by
                                                          adding
                                                          "token_type"
                                                          to the request
                                                          we can remove
                                                          this
                                                          dependency.

                                                          WDYT..?

                                                          Thanks
                                                          & regards,
                                                          -Prabath 

                                                          On

                                                          Thu, Feb 7,
                                                          2013 at 12:54
                                                          AM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:

                                                          Updated
                                                          introspection
                                                          draft based on
                                                          recent
                                                          comments.
                                                          Changes
                                                          include:

                                                           - "scope"
                                                          return
                                                          parameter now
                                                          follows
                                                          RFC6749 format
                                                          instead of
                                                          JSON array

                                                           - "subject"
                                                          -> "sub",
                                                          and "audience"
                                                          -> "aud",
                                                          to be parallel
                                                          with JWT
                                                          claims

                                                           - clarified
                                                          what happens
                                                          if the
                                                          authentication
                                                          is bad

                                                           -- Justin

                                                          --------
                                                          Original
                                                          Message
                                                          --------

                                                          Subject: 
                                                          New
                                                          Version
                                                          Notification
                                                          for
                                                          draft-richer-oauth-introspection-02.txt

                                                          Date: 
                                                          Wed, 6 Feb
                                                          2013 11:24:20
                                                          -0800

                                                          From: 
                                                          <internet-drafts@ietf.org>

                                                          To: 
                                                          <jricher@mitre.org>

                                                          A new version of I-D, draft-richer-oauth-introspection-02.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 02
Title:		 OAuth Token Introspection
Creation date:	 2013-02-06
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.

The IETF Secretariat

_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

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

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                                          _______________________________________________

                                                          OAuth
                                                          mailing list

                                                          OAuth@ietf.org

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

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94
                                                          71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                              -- 

                                              Thanks & Regards,

                                              Prabath

                                              Mobile : +94

                                                  71 809 6732 

                                                http://blog.facilelogin.com

                                                http://RampartFAQ.com

                                    -- 

                                    Thanks & Regards,

                                    Prabath

                                    Mobile : +94 71 809 6732 

                                      http://blog.facilelogin.com

                                      http://RampartFAQ.com

                      -- 

                      Thanks & Regards,

                      Prabath

                      Mobile : +94 71
                          809 6732 

                        http://blog.facilelogin.com

                        http://RampartFAQ.com

        -- 

        Thanks & Regards,

        Prabath

        Mobile : +94 71 809 6732 

          http://blog.facilelogin.com

          http://RampartFAQ.com

--------------050307080309090507000504--

From prabath@wso2.com  Thu Feb 14 07:57:23 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B7121F8802 for ; Thu, 14 Feb 2013 07:57:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.889
X-Spam-Level: 
X-Spam-Status: No, score=-2.889 tagged_above=-999 required=5 tests=[AWL=0.088,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXWVyfBfFgRz for ; Thu, 14 Feb 2013 07:57:20 -0800 (PST)
Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by ietfa.amsl.com (Postfix) with ESMTP id 073C621F8561 for ; Thu, 14 Feb 2013 07:57:19 -0800 (PST)
Received: by mail-ee0-f52.google.com with SMTP id b15so1304743eek.25 for ; Thu, 14 Feb 2013 07:57:19 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=wxfe81zS4yudK7Je/SdlRhMJVHkYUUdzp1n2fxNjl8Q=; b=kvZcUnlQsWDYvseRpqaBZWFVPVdGgi55T32z9Z6W0sCWTDZKf5O31QPtTCJ6RYaj82 pqvSbnrNSQbiETyWYpxAEFPUuZHXgk4jaFV8RhHeh+LJEDNh1YsLjsIGhYn7pPT8k0SM 08RwDJ19iZfTd57etXy3lQJOU2htlNF4x72K4j/SX3A2CCqEBwZp7QcO2VFG3wk52l2x jWcwlQCikglntVXB5/hy/edLwvHFCoLzhrNgpvFlyHiQ3VYDCFfwFDlakfHKRDN0ctYF VMMW8D1qdr/nrjpG1zr4aN+B2YlFAbA6TplEgv6dPHgO/nNemwaVHUBIodPVLp6eK4Ej ZJ2A==
MIME-Version: 1.0
X-Received: by 10.14.215.193 with SMTP id e41mr20568623eep.32.1360857439003; Thu, 14 Feb 2013 07:57:19 -0800 (PST)
Received: by 10.223.37.77 with HTTP; Thu, 14 Feb 2013 07:57:18 -0800 (PST)
In-Reply-To: <511CF8C5.70301@mitre.org>
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com> <5113C3AA.1040701@mitre.org>  <5113DDB2.7060805@mitre.org>  <51196777.6000502@mitre.org>   <511A5062.5010108@mitre.org>   <511CEEAA.3030801@mitre.org>   <511CF3EF.8040008@mitre.org>  <511CF4AB.5010700@mitre.org>  <511CF8C5.70301@mitre.org>
Date: Thu, 14 Feb 2013 21:27:18 +0530
Message-ID: 
From: Prabath Siriwardena 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=e89a8f647ac33de3d904d5b1501f
X-Gm-Message-State: ALoCoQlIyfIMfyjun037PXg2MMp7NTmKGzBdjV3lc5bSqxbyu+8AVa4YZ2bWnQuR9cQb45WCe061
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2013 15:57:23 -0000

--e89a8f647ac33de3d904d5b1501f
Content-Type: text/plain; charset=ISO-8859-1

Not quite convinced :-) Valid has a meaning attached to that..

In case we are going ahead with this please define it clearly in the draft
- with the one you shared in this thread.

Thanks & regards,
-Prabath

On Thu, Feb 14, 2013 at 8:16 PM, Justin Richer  wrote:

>
> On 02/14/2013 09:37 AM, Prabath Siriwardena wrote:
>
> The definition of valid is bit ambiguous in the draft...
>
>  Okay.. If that is the definition... and if we beak that in to parts...
>
>  "it hasn't expired" : In the response it self we have parameter for
> issued_at and and expires_at - so whether the token is not expired or not
> can even be derived at the requestor's end.
>
>
> If the token isn't good anymore, it doesn't matter when it was issued or
> when it was expired, just that it has.
>
>
>
>  "token was issued from here" : For this IMO we need to send an error
> code. Requestor has picked the wrong AS.
>
> We don't know if it came from another AS or if someone's just making
> things up. Either way it's not a good token.
>
>
>
>  The remaining is  "revoked".. That is why I proposed earlier - we better
> have an attribute "revoked" - instead of "valid" in the response..
>
>
> The end result of all three is the same: either the token is good, or it
> isn't. I think it's much simpler and more useful to leave it at that.
>
>  -- Justin
>
>
>
>  WDYT...?
>
>  Thanks & regards,
> -Prabath
>
>
> On Thu, Feb 14, 2013 at 7:58 PM, Justin Richer  wrote:
>
>>  Because it will be the one that issued the token in the first place.
>>
>> Validity means "token was issued from here, it hasn't been revoked, it
>> hasn't expired".
>>
>>  -- Justin
>>
>>
>> On 02/14/2013 09:28 AM, Prabath Siriwardena wrote:
>>
>> Okay. With out knowing the type of the token how can the AS validate the
>> token ? What is meant by the validity there?
>>
>>  Thanks & regards,
>> -Prabath
>>
>> On Thu, Feb 14, 2013 at 7:55 PM, Justin Richer  wrote:
>>
>>>  OK, I don't see the utility in that at all. What would it accomplish?
>>>
>>>  -- Justin
>>>
>>>
>>> On 02/14/2013 09:25 AM, Prabath Siriwardena wrote:
>>>
>>> To make it clear - my suggestion is to add token_type_hint to the
>>> introspection request. It can be from client to AS or from RS to AS.
>>>
>>>  Then AS can decide whether the provided token is valid or not and
>>> include "valid" attribute in the introspection response.
>>>
>>>  Thanks & regards,
>>> -Prabath
>>>
>>> On Thu, Feb 14, 2013 at 7:52 PM, Prabath Siriwardena wrote:
>>>
>>>> Both the client and the resource owner should be aware of the token
>>>> type.
>>>>
>>>>  My argument is, if the authorization server to decide whether the
>>>> token is valid or not ( irrespective of who asked the question) - AS needs
>>>> to know the token type - because to validate a token AS should know the
>>>> token type.
>>>>
>>>>  The token type could be, bearer or MAC or any other token type.
>>>>
>>>>  Thanks & regards,
>>>> -Prabath
>>>>
>>>>
>>>> On Thu, Feb 14, 2013 at 7:33 PM, Justin Richer wrote:
>>>>
>>>>>  What exactly are you suggesting be added to introspection? The
>>>>> "token_type_hint" is from the client to the server, but what you've asked
>>>>> for in terms of "token type" is from the server to the client. And there
>>>>> was never an answer to what exactly is meant by "token type" in this case,
>>>>> particularly because you seem to want to call out things like SAML and
>>>>> Bearer as separate types.
>>>>>
>>>>>  -- Justin
>>>>>
>>>>>
>>>>>
>>>>> On 02/14/2013 06:59 AM, Prabath Siriwardena wrote:
>>>>>
>>>>> I noticed that the latest Token Revocation draft [1] has introduced
>>>>> the parameter "token_type_hint". I would suggest the same here, as that
>>>>> would make what is meant by "valid" much clear..
>>>>>
>>>>>  [1]: http://tools.ietf.org/html/draft-ietf-oauth-revocation-05
>>>>>
>>>>>  Thanks & regards,
>>>>> -Prabath
>>>>>
>>>>> On Tue, Feb 12, 2013 at 9:35 PM, Prabath Siriwardena >>>> > wrote:
>>>>>
>>>>>> Hi Justin,
>>>>>>
>>>>>>  I doubt whether valid_token would make a difference..?
>>>>>>
>>>>>>  My initial argument is what is the validation criteria..?
>>>>>> Validation criteria depends on the token_type..
>>>>>>
>>>>>>  If we are talking only about metadata - then I believe "revoked",
>>>>>> "expired" would be more meaningful..
>>>>>>
>>>>>>  Thanks & regards,
>>>>>> -Prabath
>>>>>>
>>>>>>
>>>>>>  On Tue, Feb 12, 2013 at 7:53 PM, Justin Richer wrote:
>>>>>>
>>>>>>>  OK, I can see the wisdom in changing this term.
>>>>>>>
>>>>>>> I picked "valid" because I wanted a simple "boolean" value that
>>>>>>> would require no additional parsing or string-matching on the client's
>>>>>>> behalf, and I'd like to stick with that. OAuth is built with the assumption
>>>>>>> that clients need to be able to recover from invalid tokens at any stage,
>>>>>>> so I think a simple yes/no is the right step here.
>>>>>>>
>>>>>>> That said, I think you're both right that "valid" seems to have
>>>>>>> caused a bit of confusion. I don't want to go with "revoked" because I'd
>>>>>>> rather have the "token is OK" be the positive boolean value.
>>>>>>>
>>>>>>> Would "valid_token" be more clear? Or do we need a different
>>>>>>> adjective all together?
>>>>>>>
>>>>>>>  -- Justin
>>>>>>>
>>>>>>>
>>>>>>> On 02/11/2013 08:02 PM, Richard Harrington wrote:
>>>>>>>
>>>>>>> Have you considered "status" instead of "valid"?  It could have
>>>>>>> values like "active", "expired", and "revoked".
>>>>>>>
>>>>>>>  Is it worthwhile including the status of the client also?  For
>>>>>>> example, a client application could be disabled, temporarily or
>>>>>>> permanently, and thus disabling its access tokens as well.
>>>>>>>
>>>>>>>
>>>>>>> On Feb 11, 2013, at 1:56 PM, Prabath Siriwardena 
>>>>>>> wrote:
>>>>>>>
>>>>>>>  I guess confusion is with 'valid' parameter is in the response..
>>>>>>>
>>>>>>>  I thought this will be helpful to standardize the communication
>>>>>>> between Resource Server and the Authorization Server..
>>>>>>>
>>>>>>>  I would suggest we completely remove "valid" from the response -
>>>>>>> or define it much clearly..
>>>>>>>
>>>>>>>  May be can add "revoked" with a boolean attribute..
>>>>>>>
>>>>>>>  Thanks & regards,
>>>>>>> -Prabath
>>>>>>>
>>>>>>> On Tue, Feb 12, 2013 at 3:19 AM, Justin Richer wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> On 02/08/2013 12:51 AM, Prabath Siriwardena wrote:
>>>>>>>>
>>>>>>>> Hi Justin,
>>>>>>>>
>>>>>>>>  I have couple of questions related to "valid" parameter...
>>>>>>>>
>>>>>>>>  This endpoint can be invoked by the Resource Server in runtime...
>>>>>>>>
>>>>>>>>
>>>>>>>> That's correct.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>  In that case what is exactly meant by the "resource_id" in
>>>>>>>> request ?
>>>>>>>>
>>>>>>>>
>>>>>>>>  The resource_id field is a service-specific string that basically
>>>>>>>> lets the resource server provide some context to the request to the auth
>>>>>>>> server. There have been some other suggestions like client IP address, but
>>>>>>>> I wanted to put this one in because it seemed to be a common theme. The
>>>>>>>> client is trying to do *something* with the token, after all, and the
>>>>>>>> rights, permissions, and metadata associated with the token could change
>>>>>>>> based on that. Since the Introspection endpoint is all about getting that
>>>>>>>> metadata back to the PR, this seemed like a good idea.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>  IMO a token to be valid depends on set of criteria based on it's
>>>>>>>> type..
>>>>>>>>
>>>>>>>>  For a Bearer token..
>>>>>>>>
>>>>>>>>  1. Token should not be expired
>>>>>>>> 2. Token should not be revoked.
>>>>>>>> 3. The scope the token issued should match with the scope required
>>>>>>>> for the resource.
>>>>>>>>
>>>>>>>>  For a MAC token...
>>>>>>>>
>>>>>>>>  1. Token not expired (mac id)
>>>>>>>> 2. Token should not be revoked
>>>>>>>> 3. The scope the token issued should match with the scope required
>>>>>>>> for the resource.
>>>>>>>> 4. HMAC check should be valid
>>>>>>>>
>>>>>>>>  There are similar conditions for SAML bearer too..
>>>>>>>>
>>>>>>>>
>>>>>>>>  This isn't really true. The SAML bearer token is fully
>>>>>>>> self-contained and doesn't change based on other parameters in the message,
>>>>>>>> unlike MAC. Same with JWT. When it hands a SAML or JWT token to the AS, the
>>>>>>>> PR has given *everything* the server needs to check that token's validity
>>>>>>>> and use.
>>>>>>>>
>>>>>>>> MAC signatures change with every message, and they're done across
>>>>>>>> several components of the HTTP message. Therefor, the HMAC check for MAC
>>>>>>>> style tokens will still need to be done by the protected resource.
>>>>>>>> Introspection would help in the case that the signature validated just
>>>>>>>> fine, but the token might have expired. Or you need to know what scopes
>>>>>>>> apply. Introspection isn't to fully validate the call to the protected
>>>>>>>> resource -- if that were the case, the PR would have to send some kind of
>>>>>>>> encapsulated version of the original request. Otherwise, the AS won't have
>>>>>>>> all of the information it needs to check the MAC.
>>>>>>>>
>>>>>>>>
>>>>>>>> I think what you're describing is ultimately *not* what the
>>>>>>>> introspection endpoint is intended to do. If that's unclear from the
>>>>>>>> document, can you please suggest text that would help clear the use case
>>>>>>>> up? I wouldn't want it to be ambiguous.
>>>>>>>>
>>>>>>>>  -- Justin
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>  Thanks & regards,
>>>>>>>> -Prabath
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Feb 7, 2013 at 10:30 PM, Justin Richer wrote:
>>>>>>>>
>>>>>>>>>  It validates the token, which would be either the token itself in
>>>>>>>>> the case of Bearer or the token "id" part of something more complex like
>>>>>>>>> MAC. It doesn't directly validate the usage of the token, that's still up
>>>>>>>>> to the PR to do that.
>>>>>>>>>
>>>>>>>>> I nearly added a "token type" field in this draft, but held back
>>>>>>>>> because there are several kinds of "token type" that people talk about in
>>>>>>>>> OAuth. First, there's "Bearer" vs. "MAC" vs. "HOK", or what have you. Then
>>>>>>>>> within Bearer you have "JWT" or "SAML" or "unstructured blob". Then you've
>>>>>>>>> also got "access" vs. "refresh" and other flavors of token, like the
>>>>>>>>> id_token in OpenID Connect.
>>>>>>>>>
>>>>>>>>> Thing is, the server running the introspection endpoint will
>>>>>>>>> probably know *all* of these. But should it tell the client? If so, which
>>>>>>>>> of the three, and what names should the fields be?
>>>>>>>>>
>>>>>>>>>  -- Justin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 02/07/2013 11:26 AM, Prabath Siriwardena wrote:
>>>>>>>>>
>>>>>>>>> Okay.. I was thinking this could be used as a way to validate the
>>>>>>>>> token as well. BTW even in this case shouldn't communicate the type of
>>>>>>>>> token to AS? For example in the case of SAML profile - it could be SAML
>>>>>>>>> token..
>>>>>>>>>
>>>>>>>>>  Thanks & regards,
>>>>>>>>> -Prabath
>>>>>>>>>
>>>>>>>>> On Thu, Feb 7, 2013 at 8:39 PM, Justin Richer wrote:
>>>>>>>>>
>>>>>>>>>>  "valid" might not be the best term, but it's meant to be a field
>>>>>>>>>> where the server says "yes this token is still good" or "no this token
>>>>>>>>>> isn't good anymore". We could instead do this with HTTP codes or something
>>>>>>>>>> but I went with a pure JSON response.
>>>>>>>>>>
>>>>>>>>>>  -- Justin
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 02/06/2013 10:47 PM, Prabath Siriwardena wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Justin,
>>>>>>>>>>
>>>>>>>>>>  I believe this is addressing one of the key missing part in
>>>>>>>>>> OAuth 2.0...
>>>>>>>>>>
>>>>>>>>>>  One question - I guess this was discussed already...
>>>>>>>>>>
>>>>>>>>>>  In the spec - in the introspection response it has the
>>>>>>>>>> attribute "valid" - this is basically the validity of the token provided in
>>>>>>>>>> the request.
>>>>>>>>>>
>>>>>>>>>>  Validation criteria depends on the token and well as token type
>>>>>>>>>> ( Bearer, MAC..).
>>>>>>>>>>
>>>>>>>>>>  In the spec it seems like it's coupled with Bearer token
>>>>>>>>>> type... But I guess, by adding "token_type" to the request we can remove
>>>>>>>>>> this dependency.
>>>>>>>>>>
>>>>>>>>>>  WDYT..?
>>>>>>>>>>
>>>>>>>>>>  Thanks & regards,
>>>>>>>>>> -Prabath
>>>>>>>>>>
>>>>>>>>>> On Thu, Feb 7, 2013 at 12:54 AM, Justin Richer >>>>>>>>> > wrote:
>>>>>>>>>>
>>>>>>>>>>>  Updated introspection draft based on recent comments. Changes
>>>>>>>>>>> include:
>>>>>>>>>>>
>>>>>>>>>>>  - "scope" return parameter now follows RFC6749 format instead
>>>>>>>>>>> of JSON array
>>>>>>>>>>>  - "subject" -> "sub", and "audience" -> "aud", to be parallel
>>>>>>>>>>> with JWT claims
>>>>>>>>>>>  - clarified what happens if the authentication is bad
>>>>>>>>>>>
>>>>>>>>>>>  -- Justin
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -------- Original Message --------  Subject: New Version
>>>>>>>>>>> Notification for draft-richer-oauth-introspection-02.txt  Date: Wed,
>>>>>>>>>>> 6 Feb 2013 11:24:20 -0800  From:   To:
>>>>>>>>>>>  
>>>>>>>>>>>
>>>>>>>>>>> A new version of I-D, draft-richer-oauth-introspection-02.txt
>>>>>>>>>>> has been successfully submitted by Justin Richer and posted to the
>>>>>>>>>>> IETF repository.
>>>>>>>>>>>
>>>>>>>>>>> Filename:	 draft-richer-oauth-introspection
>>>>>>>>>>> Revision:	 02
>>>>>>>>>>> Title:		 OAuth Token Introspection
>>>>>>>>>>> Creation date:	 2013-02-06
>>>>>>>>>>> WG ID:		 Individual Submission
>>>>>>>>>>> Number of pages: 6
>>>>>>>>>>> URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
>>>>>>>>>>> Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
>>>>>>>>>>> Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-02
>>>>>>>>>>> Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02
>>>>>>>>>>>
>>>>>>>>>>> Abstract:
>>>>>>>>>>>    This specification defines a method for a client or protected
>>>>>>>>>>>    resource to query an OAuth authorization server to determine meta-
>>>>>>>>>>>    information about an OAuth token.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The IETF Secretariat
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  --
>>>>>>>>>> Thanks & Regards,
>>>>>>>>>> Prabath
>>>>>>>>>>
>>>>>>>>>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>>>>>>>>>
>>>>>>>>>> http://blog.facilelogin.com
>>>>>>>>>> http://RampartFAQ.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  --
>>>>>>>>> Thanks & Regards,
>>>>>>>>> Prabath
>>>>>>>>>
>>>>>>>>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>>>>>>>>
>>>>>>>>> http://blog.facilelogin.com
>>>>>>>>> http://RampartFAQ.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>  --
>>>>>>>> Thanks & Regards,
>>>>>>>> Prabath
>>>>>>>>
>>>>>>>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>>>>>>>
>>>>>>>> http://blog.facilelogin.com
>>>>>>>> http://RampartFAQ.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  --
>>>>>>> Thanks & Regards,
>>>>>>> Prabath
>>>>>>>
>>>>>>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>>>>>>
>>>>>>> http://blog.facilelogin.com
>>>>>>> http://RampartFAQ.com
>>>>>>>
>>>>>>>  _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>  --
>>>>>> Thanks & Regards,
>>>>>> Prabath
>>>>>>
>>>>>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>>>>>
>>>>>> http://blog.facilelogin.com
>>>>>> http://RampartFAQ.com
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>  --
>>>>> Thanks & Regards,
>>>>> Prabath
>>>>>
>>>>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>>>>
>>>>> http://blog.facilelogin.com
>>>>> http://RampartFAQ.com
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>  --
>>>> Thanks & Regards,
>>>> Prabath
>>>>
>>>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>>>
>>>> http://blog.facilelogin.com
>>>> http://RampartFAQ.com
>>>>
>>>
>>>
>>>
>>>  --
>>> Thanks & Regards,
>>> Prabath
>>>
>>>  Mobile : +94 71 809 6732
>>>
>>> http://blog.facilelogin.com
>>> http://RampartFAQ.com
>>>
>>>
>>>
>>
>>
>>  --
>> Thanks & Regards,
>> Prabath
>>
>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>
>> http://blog.facilelogin.com
>> http://RampartFAQ.com
>>
>>
>>
>
>
>  --
> Thanks & Regards,
> Prabath
>
>  Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com
>
>
>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.com

--e89a8f647ac33de3d904d5b1501f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Not quite convinced :-) Valid has a meaning attached to that..
In case we are going ahead with this please define it clearly in the=
 draft - with the one you shared in this thread.

Thanks & regards,
-Prabath

=
On Thu, Feb 14, 2013 at 8:16 PM, Justin Richer <jricher@mitre.org><=
/span> wrote:

 =20
   =20
 =20

    On 02/14/2013 09:37 AM, Prabath
      Siriwardena wrote:

     =20
      The definition of valid is bit ambiguous=A0in the draft...

      Okay.. If that is the definition... and if we beak that in to
        parts...

      "it hasn't expired" : In the response it self we h=
ave
        parameter for issued_at and and expires_at - so whether the
        token is not expired or not can even be derived at the
        requestor's end.

    If the token isn't good anymore, it doesn't matter when it was
    issued or when it was expired, just that it has.

      "token was issued from here" : For this IMO we need to=
 send
        an error code. Requestor has picked the wrong AS.

    We don't know if it came from another AS or if someone's just m=
aking
    things up. Either way it's not a good token.

      The remaining is =A0"revoked".. That is why I
        proposed=A0earlier=A0- we better have an attribute "revoked&qu=
ot; -
        instead of "valid" in the response..

    The end result of all three is the same: either the token is good,
    or it isn't. I think it's much simpler and more useful to leave=
 it
    at that.

    =A0-- Justin

      WDYT...?

      Thanks & regards,
      -Prabath

        On Thu, Feb 14, 2013 at 7:58 PM, Justin
          Richer <jricher@mitre.org>
          wrote:

             Because it will be
              the one that issued the token in the first place. 

              Validity means "token was issued from here, it hasn'=
t been
              revoked, it hasn't expired". 

                  =A0-- Justin

                  On 02/14/2013 09:28 AM, Prabath Siriwardena
                    wrote:

                   Okay. With out knowing the
                    type of the token how can the AS validate the token
                    ? What is meant by the validity there?

                    Thanks & regards,
                    -Prabath

                      On Thu, Feb 14, 2013 at
                        7:55 PM, Justin Richer <jricher@mitre.org><=
/span>
                        wrote:

                           OK, I
                            don't see the utility in that at all. What
                            would it accomplish?

                                =A0-- Justin

                                On 02/14/2013 09:25 AM, Prabath
                                  Siriwardena wrote:

                                 To make it
                                  clear - my suggestion is to add
                                  token_type_hint to the introspection
                                  request. It can be from client to AS
                                  or from RS to AS.

                                  Then AS can decide whether the
                                    provided token is valid or not and
                                    include "valid" attribute in =
the
                                    introspection response.

                                  Thanks & regards,
                                  -Prabath

                                    On Thu, Feb
                                      14, 2013 at 7:52 PM, Prabath
                                      Siriwardena <prabath@wso2.com>=

                                      wrote:

                                      Both t=
he
                                        client and the resource owner
                                        should be aware of the token
                                        type.

                                        My argument is, if the
                                          authorization server to decide
                                          whether the token is valid or
                                          not ( irrespective of who
                                          asked the question) - AS needs
                                          to know the token type -
                                          because to validate a token AS
                                          should know the token type.

                                        The token type could be,
                                          bearer or MAC or any other
                                          token type.

                                        Thanks & regards,
                                        -Prabath

                                              On
                                                Thu, Feb 14, 2013 at
                                                7:33 PM, Justin Richer <jr=
icher@mitre.org>
                                                wrote:

                                                   What
                                                    exactly are you
                                                    suggesting be added
                                                    to introspection?
                                                    The
                                                    "token_type_hint&q=
uot; is
                                                    from the client to
                                                    the server, but what
                                                    you've asked for in
                                                    terms of "token
                                                    type" is from the
                                                    server to the
                                                    client. And there
                                                    was never an answer
                                                    to what exactly is
                                                    meant by "token
                                                    type" in this case=
,
                                                    particularly because
                                                    you seem to want to
                                                    call out things like
                                                    SAML and Bearer as
                                                    separate types. 

                                                        =A0-- Justin=

                                                        On
                                                          02/14/2013
                                                          06:59 AM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                         I
                                                          noticed that
                                                          the latest
                                                          Token
                                                          Revocation
                                                          draft [1] has
                                                          introduced the
                                                          parameter
                                                          "token_type_=
hint".
                                                          I would
                                                          suggest the
                                                          same here, as
                                                          that would
                                                          make what is
                                                          meant by
                                                          "valid"=
 much
                                                          clear..

                                                          [1]:=A0http://tools.ietf.org/html/draft-ietf-oauth-revocat=
ion-05

                                                          Thanks
                                                          & regards,
                                                          -Prabath

                                                          On

                                                          Tue, Feb 12,
                                                          2013 at 9:35
                                                          PM, Prabath
                                                          Siriwardena <prab=
ath@wso2.com>
                                                          wrote:

                                                          Hi

                                                          Justin,

                                                          I doubt
                                                          whether
                                                          valid_token
                                                          would make a
                                                          difference..?

                                                          My
                                                          initial
                                                          argument is
                                                          what is the
                                                          validation
                                                          criteria..?
                                                          Validation
                                                          criteria
                                                          depends on the
                                                          token_type..

                                                          If we are
                                                          talking only
                                                          about metadata
                                                          - then I
                                                          believe
                                                          "revoked&quo=
t;,
                                                          "expired&quo=
t;
                                                          would be more
                                                          meaningful..

                                                          Thanks
                                                          & regards,
                                                          -Prabath

                                                          On Tue, Feb
                                                          12, 2013 at
                                                          7:53 PM,
                                                          Justin Richer
                                                          <jricher@mitre.o=
rg>
                                                          wrote:

                                                          OK, I can see
                                                          the wisdom in
                                                          changing this
                                                          term. 

                                                          I picked
                                                          "valid"
                                                          because I
                                                          wanted a
                                                          simple
                                                          "boolean&quo=
t;
                                                          value that
                                                          would require
                                                          no additional
                                                          parsing or
                                                          string-matching
                                                          on the
                                                          client's
                                                          behalf, and
                                                          I'd like to
                                                          stick with
                                                          that. OAuth is
                                                          built with the
                                                          assumption
                                                          that clients
                                                          need to be
                                                          able to
                                                          recover from
                                                          invalid tokens
                                                          at any stage,
                                                          so I think a
                                                          simple yes/no
                                                          is the right
                                                          step here. 

                                                          That said, I
                                                          think you're
                                                          both right
                                                          that "valid&=
quot;
                                                          seems to have
                                                          caused a bit
                                                          of confusion.
                                                          I don't want
                                                          to go with
                                                          "revoked&quo=
t;
                                                          because I'd
                                                          rather have
                                                          the "token i=
s
                                                          OK" be the
                                                          positive
                                                          boolean value.

                                                          Would
                                                          "valid_token=
"
                                                          be more clear?
                                                          Or do we need
                                                          a different
                                                          adjective all
                                                          together?

                                                          =A0-- Justin

                                                          On
                                                          02/11/2013
                                                          08:02 PM,
                                                          Richard
                                                          Harrington
                                                          wrote:

                                                          Have you
                                                          considered
                                                          "status"=
;
                                                          instead of
                                                          "valid"=
? =A0It
                                                          could have
                                                          values like
                                                          "active"=
;,
                                                          "expired&quo=
t;, and
                                                          "revoked&quo=
t;.

                                                          Is it
                                                          worthwhile
                                                          including the
                                                          status of the
                                                          client also?
                                                          =A0For example,
                                                          a client
                                                          application
                                                          could be
                                                          disabled,
                                                          temporarily or
                                                          permanently,
                                                          and thus
                                                          disabling its
                                                          access tokens
                                                          as well.

                                                          On Feb 11,
                                                          2013, at 1:56
                                                          PM, Prabath
                                                          Siriwardena
                                                          <prabath@wso2.com>
                                                          wrote:

                                                          I guess
                                                          confusion is
                                                          with 'valid&#=
39;
                                                          parameter is
                                                          in the
                                                          response..

                                                          I thought
                                                          this will be
                                                          helpful
                                                          to=A0standardize=
=A0the
                                                          communication
                                                          between
                                                          Resource
                                                          Server and the
                                                          Authorization
                                                          Server..

                                                          I would
                                                          suggest we
                                                          completely
                                                          remove "vali=
d"
                                                          from the
                                                          response - or
                                                          define it much
                                                          clearly..

                                                          May be
                                                          can add
                                                          "revoked&quo=
t; with
                                                          a boolean
                                                          attribute..

                                                          Thanks
                                                          & regards,
                                                          -Prabath

                                                          On

                                                          Tue, Feb 12,
                                                          2013 at 3:19
                                                          AM, Justin
                                                          Richer <jricher=
@mitre.org>
                                                          wrote:

                                                          On
                                                          02/08/2013
                                                          12:51 AM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          Hi=A0Justin,

                                                          I have
                                                          couple of
                                                          questions
                                                          related to
                                                          "valid"
                                                          parameter...

                                                          This
                                                          endpoint can
                                                          be invoked by
                                                          the Resource
                                                          Server in
                                                          runtime...

                                                          That's
                                                          correct.

                                                          In that
                                                          case what is
                                                          exactly meant
                                                          by the
                                                          "resource_id=
"
                                                          in request ?

                                                          The
                                                          resource_id
                                                          field is a
                                                          service-specific
                                                          string that
                                                          basically lets
                                                          the resource
                                                          server provide
                                                          some context
                                                          to the request
                                                          to the auth
                                                          server. There
                                                          have been some
                                                          other
                                                          suggestions
                                                          like client IP
                                                          address, but I
                                                          wanted to put
                                                          this one in
                                                          because it
                                                          seemed to be a
                                                          common theme.
                                                          The client is
                                                          trying to do
                                                          *something*
                                                          with the
                                                          token, after
                                                          all, and the
                                                          rights,
                                                          permissions,
                                                          and metadata
                                                          associated
                                                          with the token
                                                          could change
                                                          based on that.
                                                          Since the
                                                          Introspection
                                                          endpoint is
                                                          all about
                                                          getting that
                                                          metadata back
                                                          to the PR,
                                                          this seemed
                                                          like a good
                                                          idea.

                                                          IMO a
                                                          token to be
                                                          valid depends
                                                          on set of
                                                          criteria based
                                                          on it's type.=
.

                                                          For a
                                                          Bearer token..

                                                          1. Token
                                                          should not be
                                                          expired
                                                          2. Token
                                                          should not be
                                                          revoked.
                                                          3. The
                                                          scope the
                                                          token issued
                                                          should match
                                                          with the scope
                                                          required for
                                                          the resource.

                                                          For a MAC
                                                          token...

                                                          1. Token
                                                          not expired
                                                          (mac id)
                                                          2. Token
                                                          should not be
                                                          revoked
                                                          3. The
                                                          scope the
                                                          token issued
                                                          should match
                                                          with the scope
                                                          required for
                                                          the resource.
                                                          4. HMAC
                                                          check should
                                                          be valid

                                                          There are
                                                          similar
                                                          conditions for
                                                          SAML bearer
                                                          too..

                                                          This isn't
                                                          really true.
                                                          The SAML
                                                          bearer token
                                                          is fully
                                                          self-contained
                                                          and doesn't
                                                          change based
                                                          on other
                                                          parameters in
                                                          the message,
                                                          unlike MAC.
                                                          Same with JWT.
                                                          When it hands
                                                          a SAML or JWT
                                                          token to the
                                                          AS, the PR has
                                                          given
                                                          *everything*
                                                          the server
                                                          needs to check
                                                          that token's
                                                          validity and
                                                          use. 

                                                          MAC signatures
                                                          change with
                                                          every message,
                                                          and they're
                                                          done across
                                                          several
                                                          components of
                                                          the HTTP
                                                          message.
                                                          Therefor, the
                                                          HMAC check for
                                                          MAC style
                                                          tokens will
                                                          still need to
                                                          be done by the
                                                          protected
                                                          resource.
                                                          Introspection
                                                          would help in
                                                          the case that
                                                          the signature
                                                          validated just
                                                          fine, but the
                                                          token might
                                                          have expired.
                                                          Or you need to
                                                          know what
                                                          scopes apply.
                                                          Introspection
                                                          isn't to full=
y
                                                          validate the
                                                          call to the
                                                          protected
                                                          resource -- if
                                                          that were the
                                                          case, the PR
                                                          would have to
                                                          send some kind
                                                          of
                                                          encapsulated
                                                          version of the
                                                          original
                                                          request.
                                                          Otherwise, the
                                                          AS won't have
                                                          all of the
                                                          information it
                                                          needs to check
                                                          the MAC.

                                                          I think what
                                                          you're
                                                          describing is
                                                          ultimately
                                                          *not* what the
                                                          introspection
                                                          endpoint is
                                                          intended to
                                                          do. If that's
                                                          unclear from
                                                          the document,
                                                          can you please
                                                          suggest text
                                                          that would
                                                          help clear the
                                                          use case up? I
                                                          wouldn't want
                                                          it to be
                                                          ambiguous.<=
font color=3D"#888888">

                                                          =A0-- Justin

                                                          Thanks
                                                          & regards,
                                                          -Prabath

                                                          On

                                                          Thu, Feb 7,
                                                          2013 at 10:30
                                                          PM, Justin
                                                          Richer <jricher=
@mitre.org>
                                                          wrote:

                                                          It validates
                                                          the token,
                                                          which would be
                                                          either the
                                                          token itself
                                                          in the case of
                                                          Bearer or the
                                                          token "id&qu=
ot;
                                                          part of
                                                          something more
                                                          complex like
                                                          MAC. It
                                                          doesn't
                                                          directly
                                                          validate the
                                                          usage of the
                                                          token, that's
                                                          still up to
                                                          the PR to do
                                                          that.

                                                          I nearly added
                                                          a "token typ=
e"
                                                          field in this
                                                          draft, but
                                                          held back
                                                          because there
                                                          are several
                                                          kinds of
                                                          "token type&=
quot;
                                                          that people
                                                          talk about in
                                                          OAuth. First,
                                                          there's
                                                          "Bearer"=
; vs.
                                                          "MAC" v=
s.
                                                          "HOK", =
or what
                                                          have you. Then
                                                          within Bearer
                                                          you have "JW=
T"
                                                          or "SAML&quo=
t; or
                                                          "unstructure=
d
                                                          blob". Then
                                                          you've also
                                                          got "access&=
quot;
                                                          vs. "refresh=
"
                                                          and other
                                                          flavors of
                                                          token, like
                                                          the id_token
                                                          in OpenID
                                                          Connect. 

                                                          Thing is, the
                                                          server running
                                                          the
                                                          introspection
                                                          endpoint will
                                                          probably know
                                                          *all* of
                                                          these. But
                                                          should it tell
                                                          the client? If
                                                          so, which of
                                                          the three, and
                                                          what names
                                                          should the
                                                          fields be?<=
font color=3D"#888888">

                                                          =A0-- Justin

                                                          On
                                                          02/07/2013
                                                          11:26 AM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          Okay.. I was
                                                          thinking this
                                                          could be used
                                                          as a way to
                                                          validate the
                                                          token as well.
                                                          BTW even in
                                                          this case
                                                          shouldn't
                                                          communicate
                                                          the type of
                                                          token to AS?
                                                          For example in
                                                          the case of
                                                          SAML profile -
                                                          it could be
                                                          SAML token..

                                                          Thanks
                                                          & regards,
                                                          -Prabath

                                                          On

                                                          Thu, Feb 7,
                                                          2013 at 8:39
                                                          PM, Justin
                                                          Richer <jricher=
@mitre.org>
                                                          wrote:

                                                          "valid"=
 might
                                                          not be the
                                                          best term, but
                                                          it's meant to
                                                          be a field
                                                          where the
                                                          server says
                                                          "yes this
                                                          token is still
                                                          good" or &qu=
ot;no
                                                          this token
                                                          isn't good
                                                          anymore". We
                                                          could instead
                                                          do this with
                                                          HTTP codes or
                                                          something but
                                                          I went with a
                                                          pure JSON
                                                          response.

                                                          =A0-- Justin

                                                          On
                                                          02/06/2013
                                                          10:47 PM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          Hi Justin,

                                                          I believe
                                                          this is
                                                          addressing one
                                                          of the key
                                                          missing part
                                                          in OAuth
                                                          2.0...

                                                          One
                                                          question - I
                                                          guess this was
                                                          discussed
                                                          already...

                                                          In the
                                                          spec - in the
                                                          introspection
                                                          response it
                                                          has the
                                                          attribute
                                                          "valid"=
 - this
                                                          is basically
                                                          the validity
                                                          of the token
                                                          provided in
                                                          the request.

                                                          Validation=
=A0criteria

                                                          depends on the
                                                          token and well
                                                          as token type
                                                          ( Bearer,
                                                          MAC..).

                                                          In the
                                                          spec it seems
                                                          like it's
                                                          coupled with
                                                          Bearer token
                                                          type... But I
                                                          guess, by
                                                          adding
                                                          "token_type&=
quot;
                                                          to the request
                                                          we can remove
                                                          this
                                                          dependency.

                                                          WDYT..?

                                                          Thanks
                                                          & regards,
                                                          -Prabath=A0<=
/div>

                                                          On

                                                          Thu, Feb 7,
                                                          2013 at 12:54
                                                          AM, Justin
                                                          Richer <jricher=
@mitre.org>
                                                          wrote:

                                                          Updated
                                                          introspection
                                                          draft based on
                                                          recent
                                                          comments.
                                                          Changes
                                                          include:

                                                          =A0- "scope&=
quot;
                                                          return
                                                          parameter now
                                                          follows
                                                          RFC6749 format
                                                          instead of
                                                          JSON array

                                                          =A0- "subjec=
t"
                                                          -> "sub&q=
uot;,
                                                          and "audienc=
e"
                                                          -> "aud&q=
uot;,
                                                          to be parallel
                                                          with JWT
                                                          claims

                                                          =A0- clarified
                                                          what happens
                                                          if the
                                                          authentication
                                                          is bad

                                                          =A0-- Justin

                                                          --------
                                                          Original
                                                          Message
                                                          --------

                                                          Subject: 
                                                          New
                                                          Version
                                                          Notification
                                                          for
                                                          draft-richer-oaut=
h-introspection-02.txt

                                                          Date: 
                                                          Wed, 6 Feb
                                                          2013 11:24:20
                                                          -0800

                                                          From: 
                                                          <internet-drafts@ietf.o=
rg>

                                                          To: 
                                                          <jricher@mitre.org>

                                                          A new versio=
n of I-D, draft-richer-oauth-introspection-02.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 02
Title:		 OAuth Token Introspection
Creation date:	 2013-02-06
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/interne=
t-drafts/draft-richer-oauth-introspection-02.txt
Status:          http://datatracker.ietf.org/doc/draft-=
richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-=
oauth-introspection-02
Diff:            http://www.ietf.org/rfcdiff?url2=
=3Ddraft-richer-oauth-introspection-02

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.

                                                                           =
      =20

The IETF Secretariat

_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

                                                          https://www.ietf.o=
rg/mailman/listinfo/oauth

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732=
=A0

                                                          http://blog.facilelogin.com
                                                          http://RampartFAQ.com

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732=
=A0

                                                          http://blog.facilelogin.com
                                                          http://RampartFAQ.com

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732=
=A0

                                                          http://blog.facilelogin.com
                                                          http://RampartFAQ.com

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732=
=A0

                                                          http://blog.facilelogin.com
                                                          http://RampartFAQ.com

                                                          ______=
_________________________________________

                                                          OAuth
                                                          mailing list

                                                          OAuth@ietf.org

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

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94
                                                          71 809 6732=
=A0

                                                          http://blog.facilelogin.com
                                                          http://RampartFAQ.com

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732=
=A0

                                                          http://blog.facilelogin.com
                                                          http://RampartFAQ.com

                                              -- 

                                              Thanks & Regards,

                                              Prabath

                                              Mobile : +94

                                                  71 809 6732=A0

                                                http://blog.facilelogin.com

                                                http://RampartFAQ.com

                                    -- 

                                    Thanks & Regards,

                                    Prabath

                                    Mobile : +94 71 809 6732=
=A0

                                      http://blog.facilelogin.com

                                      http://RampartFAQ.com

                      -- 

                      Thanks & Regards,

                      Prabath

                      Mobile : +94 71
                          809 6732=A0

                        http://blog.facilelogin.com

                        http://RampartFAQ.com

        -- 

        Thanks & Regards,

        Prabath

        Mobile : +94 71 809 6732=A0

          http://=
blog.facilelogin.com

          http://Rampar=
tFAQ.com

-- 
Thanks &=
 Regards,
Prabath
Mobile : +94 71 809 6732=A0

=
http://blog.facil=
elogin.com

http://RampartFAQ.com

--e89a8f647ac33de3d904d5b1501f--

From jricher@mitre.org  Thu Feb 14 08:16:53 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E8321F8861 for ; Thu, 14 Feb 2013 08:16:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.57
X-Spam-Level: 
X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.028,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbN4p385sBYC for ; Thu, 14 Feb 2013 08:16:50 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 10F9121F886A for ; Thu, 14 Feb 2013 08:16:50 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8DB8F1F2CEE; Thu, 14 Feb 2013 11:16:49 -0500 (EST)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 6FCBD1F07F7; Thu, 14 Feb 2013 11:16:49 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 14 Feb 2013 11:16:48 -0500
Message-ID: <511D0DC3.7000607@mitre.org>
Date: Thu, 14 Feb 2013 11:16:03 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Prabath Siriwardena 
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com> <5113DDB2.7060805@mitre.org>  <51196777.6000502@mitre.org>   <511A5062.5010108@mitre.org>   <511CEEAA.3030801@mitre.org>   <511CF3EF.8040008@mitre.org>  <511CF4AB.5010700@mitre.org>  <511CF8C5.70301@mitre.org> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000109060609020608000502"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2013 16:16:53 -0000

--------------000109060609020608000502
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

That much I can at least do. I'd be happy with another term if there was 
a good one we could drop in its place without changing the intended 
semantics.

  -- Justin

On 02/14/2013 10:57 AM, Prabath Siriwardena wrote:
> Not quite convinced :-) Valid has a meaning attached to that..
>
> In case we are going ahead with this please define it clearly in the 
> draft - with the one you shared in this thread.
>
> Thanks & regards,
> -Prabath
>
> On Thu, Feb 14, 2013 at 8:16 PM, Justin Richer  > wrote:
>
>
>     On 02/14/2013 09:37 AM, Prabath Siriwardena wrote:
>>     The definition of valid is bit ambiguous in the draft...
>>
>>     Okay.. If that is the definition... and if we beak that in to
>>     parts...
>>
>>     "it hasn't expired" : In the response it self we have parameter
>>     for issued_at and and expires_at - so whether the token is not
>>     expired or not can even be derived at the requestor's end.
>
>     If the token isn't good anymore, it doesn't matter when it was
>     issued or when it was expired, just that it has.
>
>
>>
>>     "token was issued from here" : For this IMO we need to send an
>>     error code. Requestor has picked the wrong AS.
>     We don't know if it came from another AS or if someone's just
>     making things up. Either way it's not a good token.
>
>
>>
>>     The remaining is  "revoked".. That is why I proposed earlier - we
>>     better have an attribute "revoked" - instead of "valid" in the
>>     response..
>
>     The end result of all three is the same: either the token is good,
>     or it isn't. I think it's much simpler and more useful to leave it
>     at that.
>
>      -- Justin
>
>
>>
>>     WDYT...?
>>
>>     Thanks & regards,
>>     -Prabath
>>
>>
>>     On Thu, Feb 14, 2013 at 7:58 PM, Justin Richer >     > wrote:
>>
>>         Because it will be the one that issued the token in the first
>>         place.
>>
>>         Validity means "token was issued from here, it hasn't been
>>         revoked, it hasn't expired".
>>
>>          -- Justin
>>
>>
>>         On 02/14/2013 09:28 AM, Prabath Siriwardena wrote:
>>>         Okay. With out knowing the type of the token how can the AS
>>>         validate the token ? What is meant by the validity there?
>>>
>>>         Thanks & regards,
>>>         -Prabath
>>>
>>>         On Thu, Feb 14, 2013 at 7:55 PM, Justin Richer
>>>         > wrote:
>>>
>>>             OK, I don't see the utility in that at all. What would
>>>             it accomplish?
>>>
>>>              -- Justin
>>>
>>>
>>>             On 02/14/2013 09:25 AM, Prabath Siriwardena wrote:
>>>>             To make it clear - my suggestion is to add
>>>>             token_type_hint to the introspection request. It can be
>>>>             from client to AS or from RS to AS.
>>>>
>>>>             Then AS can decide whether the provided token is valid
>>>>             or not and include "valid" attribute in the
>>>>             introspection response.
>>>>
>>>>             Thanks & regards,
>>>>             -Prabath
>>>>
>>>>             On Thu, Feb 14, 2013 at 7:52 PM, Prabath Siriwardena
>>>>             > wrote:
>>>>
>>>>                 Both the client and the resource owner should be
>>>>                 aware of the token type.
>>>>
>>>>                 My argument is, if the authorization server to
>>>>                 decide whether the token is valid or not (
>>>>                 irrespective of who asked the question) - AS needs
>>>>                 to know the token type - because to validate a
>>>>                 token AS should know the token type.
>>>>
>>>>                 The token type could be, bearer or MAC or any other
>>>>                 token type.
>>>>
>>>>                 Thanks & regards,
>>>>                 -Prabath
>>>>
>>>>
>>>>                 On Thu, Feb 14, 2013 at 7:33 PM, Justin Richer
>>>>                 > wrote:
>>>>
>>>>                     What exactly are you suggesting be added to
>>>>                     introspection? The "token_type_hint" is from
>>>>                     the client to the server, but what you've asked
>>>>                     for in terms of "token type" is from the server
>>>>                     to the client. And there was never an answer to
>>>>                     what exactly is meant by "token type" in this
>>>>                     case, particularly because you seem to want to
>>>>                     call out things like SAML and Bearer as
>>>>                     separate types.
>>>>
>>>>                      -- Justin
>>>>
>>>>
>>>>
>>>>                     On 02/14/2013 06:59 AM, Prabath Siriwardena wrote:
>>>>>                     I noticed that the latest Token Revocation
>>>>>                     draft [1] has introduced the parameter
>>>>>                     "token_type_hint". I would suggest the same
>>>>>                     here, as that would make what is meant by
>>>>>                     "valid" much clear..
>>>>>
>>>>>                     [1]:
>>>>>                     http://tools.ietf.org/html/draft-ietf-oauth-revocation-05
>>>>>
>>>>>                     Thanks & regards,
>>>>>                     -Prabath
>>>>>
>>>>>                     On Tue, Feb 12, 2013 at 9:35 PM, Prabath
>>>>>                     Siriwardena >>>>                     > wrote:
>>>>>
>>>>>                         Hi Justin,
>>>>>
>>>>>                         I doubt whether valid_token would make a
>>>>>                         difference..?
>>>>>
>>>>>                         My initial argument is what is the
>>>>>                         validation criteria..? Validation criteria
>>>>>                         depends on the token_type..
>>>>>
>>>>>                         If we are talking only about metadata -
>>>>>                         then I believe "revoked", "expired" would
>>>>>                         be more meaningful..
>>>>>
>>>>>                         Thanks & regards,
>>>>>                         -Prabath
>>>>>
>>>>>
>>>>>                         On Tue, Feb 12, 2013 at 7:53 PM, Justin
>>>>>                         Richer >>>>                         > wrote:
>>>>>
>>>>>                             OK, I can see the wisdom in changing
>>>>>                             this term.
>>>>>
>>>>>                             I picked "valid" because I wanted a
>>>>>                             simple "boolean" value that would
>>>>>                             require no additional parsing or
>>>>>                             string-matching on the client's
>>>>>                             behalf, and I'd like to stick with
>>>>>                             that. OAuth is built with the
>>>>>                             assumption that clients need to be
>>>>>                             able to recover from invalid tokens at
>>>>>                             any stage, so I think a simple yes/no
>>>>>                             is the right step here.
>>>>>
>>>>>                             That said, I think you're both right
>>>>>                             that "valid" seems to have caused a
>>>>>                             bit of confusion. I don't want to go
>>>>>                             with "revoked" because I'd rather have
>>>>>                             the "token is OK" be the positive
>>>>>                             boolean value.
>>>>>
>>>>>                             Would "valid_token" be more clear? Or
>>>>>                             do we need a different adjective all
>>>>>                             together?
>>>>>
>>>>>                              -- Justin
>>>>>
>>>>>
>>>>>                             On 02/11/2013 08:02 PM, Richard
>>>>>                             Harrington wrote:
>>>>>>                             Have you considered "status" instead
>>>>>>                             of "valid"?  It could have values
>>>>>>                             like "active", "expired", and "revoked".
>>>>>>
>>>>>>                             Is it worthwhile including the status
>>>>>>                             of the client also?  For example, a
>>>>>>                             client application could be disabled,
>>>>>>                             temporarily or permanently, and thus
>>>>>>                             disabling its access tokens as well.
>>>>>>
>>>>>>
>>>>>>                             On Feb 11, 2013, at 1:56 PM, Prabath
>>>>>>                             Siriwardena >>>>>                             > wrote:
>>>>>>
>>>>>>>                             I guess confusion is with 'valid'
>>>>>>>                             parameter is in the response..
>>>>>>>
>>>>>>>                             I thought this will be helpful
>>>>>>>                             to standardize the communication
>>>>>>>                             between Resource Server and the
>>>>>>>                             Authorization Server..
>>>>>>>
>>>>>>>                             I would suggest we completely remove
>>>>>>>                             "valid" from the response - or
>>>>>>>                             define it much clearly..
>>>>>>>
>>>>>>>                             May be can add "revoked" with a
>>>>>>>                             boolean attribute..
>>>>>>>
>>>>>>>                             Thanks & regards,
>>>>>>>                             -Prabath
>>>>>>>
>>>>>>>                             On Tue, Feb 12, 2013 at 3:19 AM,
>>>>>>>                             Justin Richer >>>>>>                             > wrote:
>>>>>>>
>>>>>>>
>>>>>>>                                 On 02/08/2013 12:51 AM, Prabath
>>>>>>>                                 Siriwardena wrote:
>>>>>>>>                                 Hi Justin,
>>>>>>>>
>>>>>>>>                                 I have couple of questions
>>>>>>>>                                 related to "valid" parameter...
>>>>>>>>
>>>>>>>>                                 This endpoint can be invoked by
>>>>>>>>                                 the Resource Server in runtime...
>>>>>>>
>>>>>>>                                 That's correct.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>                                 In that case what is exactly
>>>>>>>>                                 meant by the "resource_id" in
>>>>>>>>                                 request ?
>>>>>>>
>>>>>>>                                 The resource_id field is a
>>>>>>>                                 service-specific string that
>>>>>>>                                 basically lets the resource
>>>>>>>                                 server provide some context to
>>>>>>>                                 the request to the auth server.
>>>>>>>                                 There have been some other
>>>>>>>                                 suggestions like client IP
>>>>>>>                                 address, but I wanted to put
>>>>>>>                                 this one in because it seemed to
>>>>>>>                                 be a common theme. The client is
>>>>>>>                                 trying to do *something* with
>>>>>>>                                 the token, after all, and the
>>>>>>>                                 rights, permissions, and
>>>>>>>                                 metadata associated with the
>>>>>>>                                 token could change based on
>>>>>>>                                 that. Since the Introspection
>>>>>>>                                 endpoint is all about getting
>>>>>>>                                 that metadata back to the PR,
>>>>>>>                                 this seemed like a good idea.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>                                 IMO a token to be valid depends
>>>>>>>>                                 on set of criteria based on
>>>>>>>>                                 it's type..
>>>>>>>>
>>>>>>>>                                 For a Bearer token..
>>>>>>>>
>>>>>>>>                                 1. Token should not be expired
>>>>>>>>                                 2. Token should not be revoked.
>>>>>>>>                                 3. The scope the token issued
>>>>>>>>                                 should match with the scope
>>>>>>>>                                 required for the resource.
>>>>>>>>
>>>>>>>>                                 For a MAC token...
>>>>>>>>
>>>>>>>>                                 1. Token not expired (mac id)
>>>>>>>>                                 2. Token should not be revoked
>>>>>>>>                                 3. The scope the token issued
>>>>>>>>                                 should match with the scope
>>>>>>>>                                 required for the resource.
>>>>>>>>                                 4. HMAC check should be valid
>>>>>>>>
>>>>>>>>                                 There are similar conditions
>>>>>>>>                                 for SAML bearer too..
>>>>>>>
>>>>>>>                                 This isn't really true. The SAML
>>>>>>>                                 bearer token is fully
>>>>>>>                                 self-contained and doesn't
>>>>>>>                                 change based on other parameters
>>>>>>>                                 in the message, unlike MAC. Same
>>>>>>>                                 with JWT. When it hands a SAML
>>>>>>>                                 or JWT token to the AS, the PR
>>>>>>>                                 has given *everything* the
>>>>>>>                                 server needs to check that
>>>>>>>                                 token's validity and use.
>>>>>>>
>>>>>>>                                 MAC signatures change with every
>>>>>>>                                 message, and they're done across
>>>>>>>                                 several components of the HTTP
>>>>>>>                                 message. Therefor, the HMAC
>>>>>>>                                 check for MAC style tokens will
>>>>>>>                                 still need to be done by the
>>>>>>>                                 protected resource.
>>>>>>>                                 Introspection would help in the
>>>>>>>                                 case that the signature
>>>>>>>                                 validated just fine, but the
>>>>>>>                                 token might have expired. Or you
>>>>>>>                                 need to know what scopes apply.
>>>>>>>                                 Introspection isn't to fully
>>>>>>>                                 validate the call to the
>>>>>>>                                 protected resource -- if that
>>>>>>>                                 were the case, the PR would have
>>>>>>>                                 to send some kind of
>>>>>>>                                 encapsulated version of the
>>>>>>>                                 original request. Otherwise, the
>>>>>>>                                 AS won't have all of the
>>>>>>>                                 information it needs to check
>>>>>>>                                 the MAC.
>>>>>>>
>>>>>>>
>>>>>>>                                 I think what you're describing
>>>>>>>                                 is ultimately *not* what the
>>>>>>>                                 introspection endpoint is
>>>>>>>                                 intended to do. If that's
>>>>>>>                                 unclear from the document, can
>>>>>>>                                 you please suggest text that
>>>>>>>                                 would help clear the use case
>>>>>>>                                 up? I wouldn't want it to be
>>>>>>>                                 ambiguous.
>>>>>>>
>>>>>>>                                  -- Justin
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>                                 Thanks & regards,
>>>>>>>>                                 -Prabath
>>>>>>>>
>>>>>>>>
>>>>>>>>                                 On Thu, Feb 7, 2013 at 10:30
>>>>>>>>                                 PM, Justin Richer
>>>>>>>>                                 >>>>>>>                                 > wrote:
>>>>>>>>
>>>>>>>>                                     It validates the token,
>>>>>>>>                                     which would be either the
>>>>>>>>                                     token itself in the case of
>>>>>>>>                                     Bearer or the token "id"
>>>>>>>>                                     part of something more
>>>>>>>>                                     complex like MAC. It
>>>>>>>>                                     doesn't directly validate
>>>>>>>>                                     the usage of the token,
>>>>>>>>                                     that's still up to the PR
>>>>>>>>                                     to do that.
>>>>>>>>
>>>>>>>>                                     I nearly added a "token
>>>>>>>>                                     type" field in this draft,
>>>>>>>>                                     but held back because there
>>>>>>>>                                     are several kinds of "token
>>>>>>>>                                     type" that people talk
>>>>>>>>                                     about in OAuth. First,
>>>>>>>>                                     there's "Bearer" vs. "MAC"
>>>>>>>>                                     vs. "HOK", or what have
>>>>>>>>                                     you. Then within Bearer you
>>>>>>>>                                     have "JWT" or "SAML" or
>>>>>>>>                                     "unstructured blob". Then
>>>>>>>>                                     you've also got "access"
>>>>>>>>                                     vs. "refresh" and other
>>>>>>>>                                     flavors of token, like the
>>>>>>>>                                     id_token in OpenID Connect.
>>>>>>>>
>>>>>>>>                                     Thing is, the server
>>>>>>>>                                     running the introspection
>>>>>>>>                                     endpoint will probably know
>>>>>>>>                                     *all* of these. But should
>>>>>>>>                                     it tell the client? If so,
>>>>>>>>                                     which of the three, and
>>>>>>>>                                     what names should the
>>>>>>>>                                     fields be?
>>>>>>>>
>>>>>>>>                                      -- Justin
>>>>>>>>
>>>>>>>>
>>>>>>>>                                     On 02/07/2013 11:26 AM,
>>>>>>>>                                     Prabath Siriwardena wrote:
>>>>>>>>>                                     Okay.. I was thinking this
>>>>>>>>>                                     could be used as a way to
>>>>>>>>>                                     validate the token as
>>>>>>>>>                                     well. BTW even in this
>>>>>>>>>                                     case shouldn't communicate
>>>>>>>>>                                     the type of token to AS?
>>>>>>>>>                                     For example in the case of
>>>>>>>>>                                     SAML profile - it could be
>>>>>>>>>                                     SAML token..
>>>>>>>>>
>>>>>>>>>                                     Thanks & regards,
>>>>>>>>>                                     -Prabath
>>>>>>>>>
>>>>>>>>>                                     On Thu, Feb 7, 2013 at
>>>>>>>>>                                     8:39 PM, Justin Richer
>>>>>>>>>                                     >>>>>>>>                                     > wrote:
>>>>>>>>>
>>>>>>>>>                                         "valid" might not be
>>>>>>>>>                                         the best term, but
>>>>>>>>>                                         it's meant to be a
>>>>>>>>>                                         field where the server
>>>>>>>>>                                         says "yes this token
>>>>>>>>>                                         is still good" or "no
>>>>>>>>>                                         this token isn't good
>>>>>>>>>                                         anymore". We could
>>>>>>>>>                                         instead do this with
>>>>>>>>>                                         HTTP codes or
>>>>>>>>>                                         something but I went
>>>>>>>>>                                         with a pure JSON response.
>>>>>>>>>
>>>>>>>>>                                          -- Justin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                                         On 02/06/2013 10:47
>>>>>>>>>                                         PM, Prabath
>>>>>>>>>                                         Siriwardena wrote:
>>>>>>>>>>                                         Hi Justin,
>>>>>>>>>>
>>>>>>>>>>                                         I believe this is
>>>>>>>>>>                                         addressing one of the
>>>>>>>>>>                                         key missing part in
>>>>>>>>>>                                         OAuth 2.0...
>>>>>>>>>>
>>>>>>>>>>                                         One question - I
>>>>>>>>>>                                         guess this was
>>>>>>>>>>                                         discussed already...
>>>>>>>>>>
>>>>>>>>>>                                         In the spec - in the
>>>>>>>>>>                                         introspection
>>>>>>>>>>                                         response it has the
>>>>>>>>>>                                         attribute "valid" -
>>>>>>>>>>                                         this is basically the
>>>>>>>>>>                                         validity of the token
>>>>>>>>>>                                         provided in the request.
>>>>>>>>>>
>>>>>>>>>>                                         Validation criteria
>>>>>>>>>>                                         depends on the token
>>>>>>>>>>                                         and well as token
>>>>>>>>>>                                         type ( Bearer, MAC..).
>>>>>>>>>>
>>>>>>>>>>                                         In the spec it seems
>>>>>>>>>>                                         like it's coupled
>>>>>>>>>>                                         with Bearer token
>>>>>>>>>>                                         type... But I guess,
>>>>>>>>>>                                         by adding
>>>>>>>>>>                                         "token_type" to the
>>>>>>>>>>                                         request we can remove
>>>>>>>>>>                                         this dependency.
>>>>>>>>>>
>>>>>>>>>>                                         WDYT..?
>>>>>>>>>>
>>>>>>>>>>                                         Thanks & regards,
>>>>>>>>>>                                         -Prabath
>>>>>>>>>>
>>>>>>>>>>                                         On Thu, Feb 7, 2013
>>>>>>>>>>                                         at 12:54 AM, Justin
>>>>>>>>>>                                         Richer
>>>>>>>>>>                                         >>>>>>>>>                                         >
>>>>>>>>>>                                         wrote:
>>>>>>>>>>
>>>>>>>>>>                                             Updated
>>>>>>>>>>                                             introspection
>>>>>>>>>>                                             draft based on
>>>>>>>>>>                                             recent comments.
>>>>>>>>>>                                             Changes include:
>>>>>>>>>>
>>>>>>>>>>                                              - "scope" return
>>>>>>>>>>                                             parameter now
>>>>>>>>>>                                             follows RFC6749
>>>>>>>>>>                                             format instead of
>>>>>>>>>>                                             JSON array
>>>>>>>>>>                                              - "subject" ->
>>>>>>>>>>                                             "sub", and
>>>>>>>>>>                                             "audience" ->
>>>>>>>>>>                                             "aud", to be
>>>>>>>>>>                                             parallel with JWT
>>>>>>>>>>                                             claims
>>>>>>>>>>                                              - clarified what
>>>>>>>>>>                                             happens if the
>>>>>>>>>>                                             authentication is bad
>>>>>>>>>>
>>>>>>>>>>                                              -- Justin
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                                             -------- Original
>>>>>>>>>>                                             Message --------
>>>>>>>>>>                                             Subject: 	New
>>>>>>>>>>                                             Version
>>>>>>>>>>                                             Notification for
>>>>>>>>>>                                             draft-richer-oauth-introspection-02.txt
>>>>>>>>>>
>>>>>>>>>>                                             Date: 	Wed, 6 Feb
>>>>>>>>>>                                             2013 11:24:20 -0800
>>>>>>>>>>                                             From:
>>>>>>>>>>                                             
>>>>>>>>>>                                             
>>>>>>>>>>
>>>>>>>>>>                                             To:
>>>>>>>>>>                                             
>>>>>>>>>>                                             
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                                             A new version of I-D, draft-richer-oauth-introspection-02.txt
>>>>>>>>>>                                             has been successfully submitted by Justin Richer and posted to the
>>>>>>>>>>                                             IETF repository.
>>>>>>>>>>
>>>>>>>>>>                                             Filename:	 draft-richer-oauth-introspection
>>>>>>>>>>                                             Revision:	 02
>>>>>>>>>>                                             Title:		 OAuth Token Introspection
>>>>>>>>>>                                             Creation date:	 2013-02-06
>>>>>>>>>>                                             WG ID:		 Individual Submission
>>>>>>>>>>                                             Number of pages: 6
>>>>>>>>>>                                             URL:http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
>>>>>>>>>>                                             Status:http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
>>>>>>>>>>                                             Htmlized:http://tools.ietf.org/html/draft-richer-oauth-introspection-02
>>>>>>>>>>                                             Diff:http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02
>>>>>>>>>>
>>>>>>>>>>                                             Abstract:
>>>>>>>>>>                                                 This specification defines a method for a client or protected
>>>>>>>>>>                                                 resource to query an OAuth authorization server to determine meta-
>>>>>>>>>>                                                 information about an OAuth token.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                                                                                                                                
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                                             The IETF Secretariat
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                                             _______________________________________________
>>>>>>>>>>                                             OAuth mailing list
>>>>>>>>>>                                             OAuth@ietf.org
>>>>>>>>>>                                             
>>>>>>>>>>                                             https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                                         -- 
>>>>>>>>>>                                         Thanks & Regards,
>>>>>>>>>>                                         Prabath
>>>>>>>>>>
>>>>>>>>>>                                         Mobile : +94 71 809
>>>>>>>>>>                                         6732
>>>>>>>>>>                                         
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                                         http://blog.facilelogin.com
>>>>>>>>>>                                         http://RampartFAQ.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                                     -- 
>>>>>>>>>                                     Thanks & Regards,
>>>>>>>>>                                     Prabath
>>>>>>>>>
>>>>>>>>>                                     Mobile : +94 71 809 6732
>>>>>>>>>                                     
>>>>>>>>>
>>>>>>>>>                                     http://blog.facilelogin.com
>>>>>>>>>                                     http://RampartFAQ.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                                 -- 
>>>>>>>>                                 Thanks & Regards,
>>>>>>>>                                 Prabath
>>>>>>>>
>>>>>>>>                                 Mobile : +94 71 809 6732
>>>>>>>>                                 
>>>>>>>>
>>>>>>>>                                 http://blog.facilelogin.com
>>>>>>>>                                 http://RampartFAQ.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                             -- 
>>>>>>>                             Thanks & Regards,
>>>>>>>                             Prabath
>>>>>>>
>>>>>>>                             Mobile : +94 71 809 6732
>>>>>>>                             
>>>>>>>
>>>>>>>                             http://blog.facilelogin.com
>>>>>>>                             http://RampartFAQ.com
>>>>>>>                             _______________________________________________
>>>>>>>                             OAuth mailing list
>>>>>>>                             OAuth@ietf.org 
>>>>>>>                             https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>                         -- 
>>>>>                         Thanks & Regards,
>>>>>                         Prabath
>>>>>
>>>>>                         Mobile : +94 71 809 6732
>>>>>                         
>>>>>
>>>>>                         http://blog.facilelogin.com
>>>>>                         http://RampartFAQ.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>                     -- 
>>>>>                     Thanks & Regards,
>>>>>                     Prabath
>>>>>
>>>>>                     Mobile : +94 71 809 6732
>>>>>                     
>>>>>
>>>>>                     http://blog.facilelogin.com
>>>>>                     http://RampartFAQ.com
>>>>
>>>>
>>>>
>>>>
>>>>                 -- 
>>>>                 Thanks & Regards,
>>>>                 Prabath
>>>>
>>>>                 Mobile : +94 71 809 6732 
>>>>
>>>>                 http://blog.facilelogin.com
>>>>                 http://RampartFAQ.com
>>>>
>>>>
>>>>
>>>>
>>>>             -- 
>>>>             Thanks & Regards,
>>>>             Prabath
>>>>
>>>>             Mobile : +94 71 809 6732 
>>>>
>>>>             http://blog.facilelogin.com
>>>>             http://RampartFAQ.com
>>>
>>>
>>>
>>>
>>>         -- 
>>>         Thanks & Regards,
>>>         Prabath
>>>
>>>         Mobile : +94 71 809 6732 
>>>
>>>         http://blog.facilelogin.com
>>>         http://RampartFAQ.com
>>
>>
>>
>>
>>     -- 
>>     Thanks & Regards,
>>     Prabath
>>
>>     Mobile : +94 71 809 6732 
>>
>>     http://blog.facilelogin.com
>>     http://RampartFAQ.com
>
>
>
>
> -- 
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com

--------------000109060609020608000502
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

    That much I can at least do. I'd be happy with another term if there
    was a good one we could drop in its place without changing the
    intended semantics.

     -- Justin

    On 02/14/2013 10:57 AM, Prabath
      Siriwardena wrote:

      Not quite convinced :-) Valid has a meaning attached to that..

      In case we are going ahead with this please define it clearly
        in the draft - with the one you shared in this thread.

        Thanks & regards,
      -Prabath

        On Thu, Feb 14, 2013 at 8:16 PM, Justin
          Richer <jricher@mitre.org>
          wrote:

                On 02/14/2013 09:37 AM, Prabath Siriwardena wrote:

                  The definition of valid is bit ambiguous in the
                    draft...

                  Okay.. If that is the definition... and if we
                    beak that in to parts...

                  "it hasn't expired" : In the response it self we
                    have parameter for issued_at and and expires_at - so
                    whether the token is not expired or not can even be
                    derived at the requestor's end.

              If the token isn't good anymore, it doesn't matter when it
              was issued or when it was expired, just that it has.

                  "token was issued from here" : For this IMO we
                    need to send an error code. Requestor has picked the
                    wrong AS.

              We don't know if it came from another AS or if someone's
              just making things up. Either way it's not a good token.

                  The remaining is  "revoked".. That is why I
                    proposed earlier - we better have an attribute
                    "revoked" - instead of "valid" in the response..

              The end result of all three is the same: either the token
              is good, or it isn't. I think it's much simpler and more
              useful to leave it at that.

                   -- Justin

                    WDYT...?

                    Thanks & regards,
                    -Prabath

                      On Thu, Feb 14, 2013 at
                        7:58 PM, Justin Richer <jricher@mitre.org>
                        wrote:

                           Because
                            it will be the one that issued the token in
                            the first place. 

                            Validity means "token was issued from here,
                            it hasn't been revoked, it hasn't expired".

                                 -- Justin

                                On 02/14/2013 09:28 AM, Prabath
                                  Siriwardena wrote:

                                 Okay. With out
                                  knowing the type of the token how can
                                  the AS validate the token ? What is
                                  meant by the validity there?

                                  Thanks & regards,
                                  -Prabath

                                    On Thu, Feb
                                      14, 2013 at 7:55 PM, Justin Richer
                                      <jricher@mitre.org>
                                      wrote:

                                         OK, I don't
                                          see the utility in that at
                                          all. What would it accomplish?

                                               -- Justin

                                              On 02/14/2013 09:25
                                                AM, Prabath Siriwardena
                                                wrote:

                                                To make it clear - my
                                                suggestion is to add
                                                token_type_hint to the
                                                introspection request.
                                                It can be from client to
                                                AS or from RS to AS.

                                                Then AS can decide
                                                  whether the provided
                                                  token is valid or not
                                                  and include "valid"
                                                  attribute in the
                                                  introspection
                                                  response.

                                                Thanks &
                                                  regards,
                                                -Prabath

                                                  On
                                                    Thu, Feb 14, 2013 at
                                                    7:52 PM, Prabath
                                                    Siriwardena <prabath@wso2.com>
                                                    wrote:

                                                    Both
                                                      the client and the
                                                      resource owner
                                                      should be aware of
                                                      the token type.

                                                      My argument
                                                        is, if the
                                                        authorization
                                                        server to decide
                                                        whether the
                                                        token is valid
                                                        or not (
                                                        irrespective of
                                                        who asked the
                                                        question) - AS
                                                        needs to know
                                                        the token type -
                                                        because to
                                                        validate a token
                                                        AS should know
                                                        the token type.

                                                      The token
                                                        type could be,
                                                        bearer or MAC or
                                                        any other token
                                                        type.

                                                      Thanks &
                                                        regards,
                                                      -Prabath

                                                          On

                                                          Thu, Feb 14,
                                                          2013 at 7:33
                                                          PM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:

                                                          What exactly
                                                          are you
                                                          suggesting be
                                                          added to
                                                          introspection?
                                                          The
                                                          "token_type_hint"
                                                          is from the
                                                          client to the
                                                          server, but
                                                          what you've
                                                          asked for in
                                                          terms of
                                                          "token type"
                                                          is from the
                                                          server to the
                                                          client. And
                                                          there was
                                                          never an
                                                          answer to what
                                                          exactly is
                                                          meant by
                                                          "token type"
                                                          in this case,
                                                          particularly
                                                          because you
                                                          seem to want
                                                          to call out
                                                          things like
                                                          SAML and
                                                          Bearer as
                                                          separate
                                                          types. 

                                                           -- Justin

                                                          On
                                                          02/14/2013
                                                          06:59 AM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                           I
                                                          noticed that
                                                          the latest
                                                          Token
                                                          Revocation
                                                          draft [1] has
                                                          introduced the
                                                          parameter
                                                          "token_type_hint".
                                                          I would
                                                          suggest the
                                                          same here, as
                                                          that would
                                                          make what is
                                                          meant by
                                                          "valid" much
                                                          clear..

                                                          [1]: http://tools.ietf.org/html/draft-ietf-oauth-revocation-05

                                                          Thanks
                                                          & regards,
                                                          -Prabath

                                                          On

                                                          Tue, Feb 12,
                                                          2013 at 9:35
                                                          PM, Prabath
                                                          Siriwardena <prabath@wso2.com>
                                                          wrote:

                                                          Hi

                                                          Justin,

                                                          I doubt
                                                          whether
                                                          valid_token
                                                          would make a
                                                          difference..?

                                                          My
                                                          initial
                                                          argument is
                                                          what is the
                                                          validation
                                                          criteria..?
                                                          Validation
                                                          criteria
                                                          depends on the
                                                          token_type..

                                                          If we are
                                                          talking only
                                                          about metadata
                                                          - then I
                                                          believe
                                                          "revoked",
                                                          "expired"
                                                          would be more
                                                          meaningful..

                                                          Thanks
                                                          & regards,
                                                          -Prabath

                                                          On Tue, Feb
                                                          12, 2013 at
                                                          7:53 PM,
                                                          Justin Richer
                                                          <jricher@mitre.org>
                                                          wrote:

                                                          OK, I can see
                                                          the wisdom in
                                                          changing this
                                                          term. 

                                                          I picked
                                                          "valid"
                                                          because I
                                                          wanted a
                                                          simple
                                                          "boolean"
                                                          value that
                                                          would require
                                                          no additional
                                                          parsing or
                                                          string-matching
                                                          on the
                                                          client's
                                                          behalf, and
                                                          I'd like to
                                                          stick with
                                                          that. OAuth is
                                                          built with the
                                                          assumption
                                                          that clients
                                                          need to be
                                                          able to
                                                          recover from
                                                          invalid tokens
                                                          at any stage,
                                                          so I think a
                                                          simple yes/no
                                                          is the right
                                                          step here. 

                                                          That said, I
                                                          think you're
                                                          both right
                                                          that "valid"
                                                          seems to have
                                                          caused a bit
                                                          of confusion.
                                                          I don't want
                                                          to go with
                                                          "revoked"
                                                          because I'd
                                                          rather have
                                                          the "token is
                                                          OK" be the
                                                          positive
                                                          boolean value.

                                                          Would
                                                          "valid_token"
                                                          be more clear?
                                                          Or do we need
                                                          a different
                                                          adjective all
                                                          together?

                                                           -- Justin

                                                          On
                                                          02/11/2013
                                                          08:02 PM,
                                                          Richard
                                                          Harrington
                                                          wrote:

                                                          Have you
                                                          considered
                                                          "status"
                                                          instead of
                                                          "valid"?  It
                                                          could have
                                                          values like
                                                          "active",
                                                          "expired", and
                                                          "revoked".

                                                          Is it
                                                          worthwhile
                                                          including the
                                                          status of the
                                                          client also?
                                                           For example,
                                                          a client
                                                          application
                                                          could be
                                                          disabled,
                                                          temporarily or
                                                          permanently,
                                                          and thus
                                                          disabling its
                                                          access tokens
                                                          as well.

                                                          On Feb 11,
                                                          2013, at 1:56
                                                          PM, Prabath
                                                          Siriwardena
                                                          <prabath@wso2.com>
                                                          wrote:

                                                          I guess
                                                          confusion is
                                                          with 'valid'
                                                          parameter is
                                                          in the
                                                          response..

                                                          I thought
                                                          this will be
                                                          helpful
                                                          to standardize the
                                                          communication
                                                          between
                                                          Resource
                                                          Server and the
                                                          Authorization
                                                          Server..

                                                          I would
                                                          suggest we
                                                          completely
                                                          remove "valid"
                                                          from the
                                                          response - or
                                                          define it much
                                                          clearly..

                                                          May be
                                                          can add
                                                          "revoked" with
                                                          a boolean
                                                          attribute..

                                                          Thanks
                                                          & regards,
                                                          -Prabath

                                                          On

                                                          Tue, Feb 12,
                                                          2013 at 3:19
                                                          AM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:

                                                          On
                                                          02/08/2013
                                                          12:51 AM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          Hi Justin,

                                                          I have
                                                          couple of
                                                          questions
                                                          related to
                                                          "valid"
                                                          parameter...

                                                          This
                                                          endpoint can
                                                          be invoked by
                                                          the Resource
                                                          Server in
                                                          runtime...

                                                          That's
                                                          correct.

                                                          In that
                                                          case what is
                                                          exactly meant
                                                          by the
                                                          "resource_id"
                                                          in request ?

                                                          The
                                                          resource_id
                                                          field is a
                                                          service-specific
                                                          string that
                                                          basically lets
                                                          the resource
                                                          server provide
                                                          some context
                                                          to the request
                                                          to the auth
                                                          server. There
                                                          have been some
                                                          other
                                                          suggestions
                                                          like client IP
                                                          address, but I
                                                          wanted to put
                                                          this one in
                                                          because it
                                                          seemed to be a
                                                          common theme.
                                                          The client is
                                                          trying to do
                                                          *something*
                                                          with the
                                                          token, after
                                                          all, and the
                                                          rights,
                                                          permissions,
                                                          and metadata
                                                          associated
                                                          with the token
                                                          could change
                                                          based on that.
                                                          Since the
                                                          Introspection
                                                          endpoint is
                                                          all about
                                                          getting that
                                                          metadata back
                                                          to the PR,
                                                          this seemed
                                                          like a good
                                                          idea.

                                                          IMO a
                                                          token to be
                                                          valid depends
                                                          on set of
                                                          criteria based
                                                          on it's type..

                                                          For a
                                                          Bearer token..

                                                          1. Token
                                                          should not be
                                                          expired
                                                          2. Token
                                                          should not be
                                                          revoked.
                                                          3. The
                                                          scope the
                                                          token issued
                                                          should match
                                                          with the scope
                                                          required for
                                                          the resource.

                                                          For a MAC
                                                          token...

                                                          1. Token
                                                          not expired
                                                          (mac id)
                                                          2. Token
                                                          should not be
                                                          revoked
                                                          3. The
                                                          scope the
                                                          token issued
                                                          should match
                                                          with the scope
                                                          required for
                                                          the resource.
                                                          4. HMAC
                                                          check should
                                                          be valid

                                                          There are
                                                          similar
                                                          conditions for
                                                          SAML bearer
                                                          too..

                                                          This isn't
                                                          really true.
                                                          The SAML
                                                          bearer token
                                                          is fully
                                                          self-contained
                                                          and doesn't
                                                          change based
                                                          on other
                                                          parameters in
                                                          the message,
                                                          unlike MAC.
                                                          Same with JWT.
                                                          When it hands
                                                          a SAML or JWT
                                                          token to the
                                                          AS, the PR has
                                                          given
                                                          *everything*
                                                          the server
                                                          needs to check
                                                          that token's
                                                          validity and
                                                          use. 

                                                          MAC signatures
                                                          change with
                                                          every message,
                                                          and they're
                                                          done across
                                                          several
                                                          components of
                                                          the HTTP
                                                          message.
                                                          Therefor, the
                                                          HMAC check for
                                                          MAC style
                                                          tokens will
                                                          still need to
                                                          be done by the
                                                          protected
                                                          resource.
                                                          Introspection
                                                          would help in
                                                          the case that
                                                          the signature
                                                          validated just
                                                          fine, but the
                                                          token might
                                                          have expired.
                                                          Or you need to
                                                          know what
                                                          scopes apply.
                                                          Introspection
                                                          isn't to fully
                                                          validate the
                                                          call to the
                                                          protected
                                                          resource -- if
                                                          that were the
                                                          case, the PR
                                                          would have to
                                                          send some kind
                                                          of
                                                          encapsulated
                                                          version of the
                                                          original
                                                          request.
                                                          Otherwise, the
                                                          AS won't have
                                                          all of the
                                                          information it
                                                          needs to check
                                                          the MAC.

                                                          I think what
                                                          you're
                                                          describing is
                                                          ultimately
                                                          *not* what the
                                                          introspection
                                                          endpoint is
                                                          intended to
                                                          do. If that's
                                                          unclear from
                                                          the document,
                                                          can you please
                                                          suggest text
                                                          that would
                                                          help clear the
                                                          use case up? I
                                                          wouldn't want
                                                          it to be
                                                          ambiguous.

                                                           -- Justin

                                                          Thanks
                                                          & regards,
                                                          -Prabath

                                                          On

                                                          Thu, Feb 7,
                                                          2013 at 10:30
                                                          PM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:

                                                          It validates
                                                          the token,
                                                          which would be
                                                          either the
                                                          token itself
                                                          in the case of
                                                          Bearer or the
                                                          token "id"
                                                          part of
                                                          something more
                                                          complex like
                                                          MAC. It
                                                          doesn't
                                                          directly
                                                          validate the
                                                          usage of the
                                                          token, that's
                                                          still up to
                                                          the PR to do
                                                          that.

                                                          I nearly added
                                                          a "token type"
                                                          field in this
                                                          draft, but
                                                          held back
                                                          because there
                                                          are several
                                                          kinds of
                                                          "token type"
                                                          that people
                                                          talk about in
                                                          OAuth. First,
                                                          there's
                                                          "Bearer" vs.
                                                          "MAC" vs.
                                                          "HOK", or what
                                                          have you. Then
                                                          within Bearer
                                                          you have "JWT"
                                                          or "SAML" or
                                                          "unstructured
                                                          blob". Then
                                                          you've also
                                                          got "access"
                                                          vs. "refresh"
                                                          and other
                                                          flavors of
                                                          token, like
                                                          the id_token
                                                          in OpenID
                                                          Connect. 

                                                          Thing is, the
                                                          server running
                                                          the
                                                          introspection
                                                          endpoint will
                                                          probably know
                                                          *all* of
                                                          these. But
                                                          should it tell
                                                          the client? If
                                                          so, which of
                                                          the three, and
                                                          what names
                                                          should the
                                                          fields be?

                                                           -- Justin

                                                          On
                                                          02/07/2013
                                                          11:26 AM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          Okay.. I was
                                                          thinking this
                                                          could be used
                                                          as a way to
                                                          validate the
                                                          token as well.
                                                          BTW even in
                                                          this case
                                                          shouldn't
                                                          communicate
                                                          the type of
                                                          token to AS?
                                                          For example in
                                                          the case of
                                                          SAML profile -
                                                          it could be
                                                          SAML token..

                                                          Thanks
                                                          & regards,
                                                          -Prabath

                                                          On

                                                          Thu, Feb 7,
                                                          2013 at 8:39
                                                          PM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:

                                                          "valid" might
                                                          not be the
                                                          best term, but
                                                          it's meant to
                                                          be a field
                                                          where the
                                                          server says
                                                          "yes this
                                                          token is still
                                                          good" or "no
                                                          this token
                                                          isn't good
                                                          anymore". We
                                                          could instead
                                                          do this with
                                                          HTTP codes or
                                                          something but
                                                          I went with a
                                                          pure JSON
                                                          response.

                                                           -- Justin

                                                          On
                                                          02/06/2013
                                                          10:47 PM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          Hi Justin,

                                                          I believe
                                                          this is
                                                          addressing one
                                                          of the key
                                                          missing part
                                                          in OAuth
                                                          2.0...

                                                          One
                                                          question - I
                                                          guess this was
                                                          discussed
                                                          already...

                                                          In the
                                                          spec - in the
                                                          introspection
                                                          response it
                                                          has the
                                                          attribute
                                                          "valid" - this
                                                          is basically
                                                          the validity
                                                          of the token
                                                          provided in
                                                          the request.

                                                          Validation criteria

                                                          depends on the
                                                          token and well
                                                          as token type
                                                          ( Bearer,
                                                          MAC..).

                                                          In the
                                                          spec it seems
                                                          like it's
                                                          coupled with
                                                          Bearer token
                                                          type... But I
                                                          guess, by
                                                          adding
                                                          "token_type"
                                                          to the request
                                                          we can remove
                                                          this
                                                          dependency.

                                                          WDYT..?

                                                          Thanks
                                                          & regards,
                                                          -Prabath 

                                                          On

                                                          Thu, Feb 7,
                                                          2013 at 12:54
                                                          AM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:

                                                          Updated
                                                          introspection
                                                          draft based on
                                                          recent
                                                          comments.
                                                          Changes
                                                          include:

                                                           - "scope"
                                                          return
                                                          parameter now
                                                          follows
                                                          RFC6749 format
                                                          instead of
                                                          JSON array

                                                           - "subject"
                                                          -> "sub",
                                                          and "audience"
                                                          -> "aud",
                                                          to be parallel
                                                          with JWT
                                                          claims

                                                           - clarified
                                                          what happens
                                                          if the
                                                          authentication
                                                          is bad

                                                           -- Justin

                                                          --------
                                                          Original
                                                          Message
                                                          --------

                                                          Subject: 
                                                          New
                                                          Version
                                                          Notification
                                                          for
                                                          draft-richer-oauth-introspection-02.txt

                                                          Date: 
                                                          Wed, 6 Feb
                                                          2013 11:24:20
                                                          -0800

                                                          From: 
                                                          <internet-drafts@ietf.org>

                                                          To: 
                                                          <jricher@mitre.org>

                                                          A new version of I-D, draft-richer-oauth-introspection-02.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 02
Title:		 OAuth Token Introspection
Creation date:	 2013-02-06
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.

The IETF Secretariat

_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

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

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                                          _______________________________________________

                                                          OAuth
                                                          mailing list

                                                          OAuth@ietf.org

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

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                                          -- 

                                                          Thanks &
                                                          Regards,

                                                          Prabath

                                                          Mobile :
                                                          +94

                                                          71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                                  -- 

                                                  Thanks & Regards,

                                                  Prabath

                                                  Mobile : +94
                                                      71 809 6732 

                                                    http://blog.facilelogin.com

                                                    http://RampartFAQ.com

                                    -- 

                                    Thanks & Regards,

                                    Prabath

                                    Mobile : +94 71 809 6732 

                                      http://blog.facilelogin.com

                                      http://RampartFAQ.com

                      -- 

                      Thanks & Regards,

                      Prabath

                      Mobile : +94 71
                          809 6732 

                        http://blog.facilelogin.com

                        http://RampartFAQ.com

        -- 

        Thanks & Regards,

        Prabath

        Mobile : +94 71 809 6732 

          http://blog.facilelogin.com

          http://RampartFAQ.com

--------------000109060609020608000502--

From prateek.mishra@oracle.com  Thu Feb 14 10:59:49 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A64F21F8570 for ; Thu, 14 Feb 2013 10:59:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NcKqXmpUedME for ; Thu, 14 Feb 2013 10:59:48 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id C593021F856F for ; Thu, 14 Feb 2013 10:59:48 -0800 (PST)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1EIxjci007790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Feb 2013 18:59:46 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1EIxjnP001453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Feb 2013 18:59:45 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1EIxhhR008969; Thu, 14 Feb 2013 12:59:44 -0600
Received: from [10.152.53.230] (/10.152.53.230) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 14 Feb 2013 10:59:43 -0800
Message-ID: <511D341F.6080405@oracle.com>
Date: Thu, 14 Feb 2013 13:59:43 -0500
From: Prateek Mishra 
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Hannes Tschofenig 
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net> <511BBBAC.9060502@oracle.com> <0DF3F088-7F15-4C0F-85C4-35DE80CB01E0@gmx.net>
In-Reply-To: <0DF3F088-7F15-4C0F-85C4-35DE80CB01E0@gmx.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2013 18:59:49 -0000

Regarding the question of AS to RS communication, I think capturing it 
is a reasonable task but not one essential to this activity.

So my view would be to exclude it from consideration in this groups 
activity. We have many use-cases where support for confirmation that goes
beyond the currently supported bearer model would be valuable. In these 
cases, the AS and RS belong to the same administrative domain.

- prateek
> Hi Prateek,
>
>
> thanks for your questions.
>
>
> On Feb 13, 2013, at 6:13 PM, Prateek Mishra wrote:
>
>> Hannes,
>>
>> 1) Its not clear to me that we need  to specify exchanges between the AS and the RS as part of this work. The core specification leaves this
>> unspecified. There could be many different ways that the AS and RS collaborate to validate signatures in messages received from the client.
> It depends what the group wants to accomplish. So far, I thought that the goal was to offer the ability to provide a sufficient description in our specifications so that the authorization server and the resource server can be provided by different vendors and that they still interoperate.
>
> The group may have changed their mind in the meanwhile.
>
> What is your view?
>

From prateek.mishra@oracle.com  Thu Feb 14 11:21:15 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC7921F8681 for ; Thu, 14 Feb 2013 11:21:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mDx9t1NLm50 for ; Thu, 14 Feb 2013 11:21:05 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id D64C121F8610 for ; Thu, 14 Feb 2013 11:21:04 -0800 (PST)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1EJL1tL008043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Feb 2013 19:21:02 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1EJL0rO013391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Feb 2013 19:21:01 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1EJL0HV021389; Thu, 14 Feb 2013 13:21:00 -0600
Received: from [10.152.53.230] (/10.152.53.230) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 14 Feb 2013 11:21:00 -0800
Message-ID: <511D3919.4090906@oracle.com>
Date: Thu, 14 Feb 2013 14:20:57 -0500
From: Prateek Mishra 
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Justin Richer 
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net> <511BBBAC.9060502@oracle.com> <0DF3F088-7F15-4C0F-85C4-35DE80CB01E0@gmx.net> <511CEDFB.6010908@mitre.org>
In-Reply-To: <511CEDFB.6010908@mitre.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2013 19:21:17 -0000

Justin - my comment was scoped to *key distribution* - not to the 
general use of public clients.

I was wondering how one can distribute keys or have key agreement 
between an AS and a client, if there is no existing trust relationship 
between them. Maybe there is some
clever crypto way of achieving this, but I personally dont understand 
how this might happen.

- prateek

>
>>> 2) Regarding (symmetric) key distribution, dont we need some kind of 
>>> existing trust relationship between the client and AS to make this 
>>> possible? I guess it
>>> would be enough to require use of a "confidential" client, that 
>>> would make it possible for the two parties to agree on a session key 
>>> at the point where an access token
>>> is  issued by the AS.
>> That's a very good question. I have not formed an option about this 
>> issue yet particularly given the recent capability to dynamically 
>> register clients.
>
> I don't think that signing tokens should require confidential clients. 
> This was one of the implementation issues with OAuth 1, as it required 
> a "consumer_secret" at all times. This led to Google telling people to 
> use "anonymous" as the "consumer_secret" for what were effectively 
> public clients. Even with dynamic registration, there's still a place 
> for public clients, in my opinion.
>

From jricher@mitre.org  Thu Feb 14 11:25:26 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B2321F88CC for ; Thu, 14 Feb 2013 11:25:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.571
X-Spam-Level: 
X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.028,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Lo3Yg-Qm8TQ for ; Thu, 14 Feb 2013 11:25:20 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id ACF6A21F86AD for ; Thu, 14 Feb 2013 11:25:17 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1E37E1F05EF; Thu, 14 Feb 2013 14:25:17 -0500 (EST)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id EDF0B1F0254; Thu, 14 Feb 2013 14:25:16 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 14 Feb 2013 14:25:16 -0500
Message-ID: <511D39EF.8010403@mitre.org>
Date: Thu, 14 Feb 2013 14:24:31 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Prateek Mishra 
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net> <511BBBAC.9060502@oracle.com> <0DF3F088-7F15-4C0F-85C4-35DE80CB01E0@gmx.net> <511CEDFB.6010908@mitre.org> <511D3919.4090906@oracle.com>
In-Reply-To: <511D3919.4090906@oracle.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.58]
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2013 19:25:26 -0000

Prateek,

My point was that a public client could very easily and safely be issued 
a secret in the form of an OAuth token. This includes any type of 
signing key that the MAC/etc token would want to use. What public 
client's can't have are configuration-time keys, like a client_secret. 
It's important to not conflate the two.

  -- Justin

On 02/14/2013 02:20 PM, Prateek Mishra wrote:
> Justin - my comment was scoped to *key distribution* - not to the 
> general use of public clients.
>
> I was wondering how one can distribute keys or have key agreement 
> between an AS and a client, if there is no existing trust relationship 
> between them. Maybe there is some
> clever crypto way of achieving this, but I personally dont understand 
> how this might happen.
>
> - prateek
>
>>
>>>> 2) Regarding (symmetric) key distribution, dont we need some kind 
>>>> of existing trust relationship between the client and AS to make 
>>>> this possible? I guess it
>>>> would be enough to require use of a "confidential" client, that 
>>>> would make it possible for the two parties to agree on a session 
>>>> key at the point where an access token
>>>> is  issued by the AS.
>>> That's a very good question. I have not formed an option about this 
>>> issue yet particularly given the recent capability to dynamically 
>>> register clients.
>>
>> I don't think that signing tokens should require confidential 
>> clients. This was one of the implementation issues with OAuth 1, as 
>> it required a "consumer_secret" at all times. This led to Google 
>> telling people to use "anonymous" as the "consumer_secret" for what 
>> were effectively public clients. Even with dynamic registration, 
>> there's still a place for public clients, in my opinion.
>>
>

From donald.coffin@reminetworks.com  Thu Feb 14 13:21:46 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A57621F8878 for ; Thu, 14 Feb 2013 13:21:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.41
X-Spam-Level: 
X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[AWL=0.855,  BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j90nmsSmi9AN for ; Thu, 14 Feb 2013 13:21:16 -0800 (PST)
Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id ECAD921F85AC for ; Thu, 14 Feb 2013 13:21:12 -0800 (PST)
Received: (qmail 29308 invoked by uid 0); 14 Feb 2013 21:20:47 -0000
Received: from unknown (HELO host125.hostmonster.com) (74.220.207.125) by cpoproxy2.bluehost.com with SMTP; 14 Feb 2013 21:20:47 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default;  h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=yGlhsnnKV/15sJn8CxuxK6xLXUjs7127pCXEk7s1WD8=;  b=NubQ+B31JmzYiHowWyhIV5jvNEezZVUUe3P6xeuSnzmBgJaFGXpqtMb5LReiO+3QtKTyM3lwcNes0spUGR6qFiFjasd6VgtGopel8UVuRCaBx8hknKAtA9Q2x9LUGqlq;
Received: from [68.4.207.246] (port=4202 helo=HPPavilionElite) by host125.hostmonster.com with esmtpa (Exim 4.80) (envelope-from ) id 1U66EZ-0001TR-5O; Thu, 14 Feb 2013 14:20:47 -0700
From: "Donald F Coffin" 
To: "'Justin Richer'" , "'Prabath Siriwardena'" 
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com>	<5113DDB2.7060805@mitre.org>		<51196777.6000502@mitre.org>			<511A5062.5010108@mitre.org>			<511CEEAA.3030801@mitre.org>			<511CF3EF.8040008@mitre.org>		<511CF4AB.5010700@mitre.org>		<511CF8C5.70301@mitre.org>	 <511D0DC3.7000607@mitre.org>
In-Reply-To: <511D0DC3.7000607@mitre.org>
Date: Thu, 14 Feb 2013 13:19:08 -0800
Message-ID: <00ef01ce0af8$ed591ad0$c80b5070$@reminetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F0_01CE0AB5.DF3D54E0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKDOKkKu6yMl3x1pM1nhfntlxrFNAIjEZUMAE2AgncDUno3igJSz0GQAgVlQCcCxP9CmwE/IqWjAg3xqC8BYatj8wLMSpeZAquJYigCgHFF8QFxkfy7AgxfqA8B+ueWagJI6UCwAQ9iy3QCP8zfgpXqvpnw
Content-Language: en-us
X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.4.207.246 authed with donald.coffin@reminetworks.com}
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for	draft-richer-oauth-introspection-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2013 21:21:46 -0000

This is a multipart message in MIME format.

------=_NextPart_000_00F0_01CE0AB5.DF3D54E0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Does the term "Active" help clarify the meaning but still confirm to your
intention, Justin?

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

Phone:      (949) 636-8571

Email:        
donald.coffin@reminetworks.com

From: Justin Richer [mailto:jricher@mitre.org] 
Sent: Thursday, February 14, 2013 8:16 AM
To: Prabath Siriwardena
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for
draft-richer-oauth-introspection-02.txt

That much I can at least do. I'd be happy with another term if there was a
good one we could drop in its place without changing the intended semantics.

 -- Justin

On 02/14/2013 10:57 AM, Prabath Siriwardena wrote:

Not quite convinced :-) Valid has a meaning attached to that.. 

In case we are going ahead with this please define it clearly in the draft -
with the one you shared in this thread.

Thanks & regards,

-Prabath

On Thu, Feb 14, 2013 at 8:16 PM, Justin Richer  wrote:

On 02/14/2013 09:37 AM, Prabath Siriwardena wrote:

The definition of valid is bit ambiguous in the draft...

Okay.. If that is the definition... and if we beak that in to parts...

"it hasn't expired" : In the response it self we have parameter for
issued_at and and expires_at - so whether the token is not expired or not
can even be derived at the requestor's end.

If the token isn't good anymore, it doesn't matter when it was issued or
when it was expired, just that it has. 

"token was issued from here" : For this IMO we need to send an error code.
Requestor has picked the wrong AS.

We don't know if it came from another AS or if someone's just making things
up. Either way it's not a good token. 

The remaining is  "revoked".. That is why I proposed earlier - we better
have an attribute "revoked" - instead of "valid" in the response..

The end result of all three is the same: either the token is good, or it
isn't. I think it's much simpler and more useful to leave it at that.

 -- Justin 

WDYT...?

Thanks & regards,

-Prabath

On Thu, Feb 14, 2013 at 7:58 PM, Justin Richer  wrote:

Because it will be the one that issued the token in the first place. 

Validity means "token was issued from here, it hasn't been revoked, it
hasn't expired". 

 -- Justin 

On 02/14/2013 09:28 AM, Prabath Siriwardena wrote:

Okay. With out knowing the type of the token how can the AS validate the
token ? What is meant by the validity there? 

Thanks & regards,

-Prabath

On Thu, Feb 14, 2013 at 7:55 PM, Justin Richer  wrote:

OK, I don't see the utility in that at all. What would it accomplish?

 -- Justin 

On 02/14/2013 09:25 AM, Prabath Siriwardena wrote:

To make it clear - my suggestion is to add token_type_hint to the
introspection request. It can be from client to AS or from RS to AS. 

Then AS can decide whether the provided token is valid or not and include
"valid" attribute in the introspection response.

Thanks & regards,

-Prabath

On Thu, Feb 14, 2013 at 7:52 PM, Prabath Siriwardena 
wrote:

Both the client and the resource owner should be aware of the token type. 

My argument is, if the authorization server to decide whether the token is
valid or not ( irrespective of who asked the question) - AS needs to know
the token type - because to validate a token AS should know the token type.

The token type could be, bearer or MAC or any other token type.

Thanks & regards,

-Prabath 

On Thu, Feb 14, 2013 at 7:33 PM, Justin Richer  wrote:

What exactly are you suggesting be added to introspection? The
"token_type_hint" is from the client to the server, but what you've asked
for in terms of "token type" is from the server to the client. And there was
never an answer to what exactly is meant by "token type" in this case,
particularly because you seem to want to call out things like SAML and
Bearer as separate types. 

 -- Justin 

On 02/14/2013 06:59 AM, Prabath Siriwardena wrote:

I noticed that the latest Token Revocation draft [1] has introduced the
parameter "token_type_hint". I would suggest the same here, as that would
make what is meant by "valid" much clear.. 

[1]:  
http://tools.ietf.org/html/draft-ietf-oauth-revocation-05

Thanks & regards,

-Prabath

On Tue, Feb 12, 2013 at 9:35 PM, Prabath Siriwardena 
wrote:

Hi Justin, 

I doubt whether valid_token would make a difference..?

My initial argument is what is the validation criteria..? Validation
criteria depends on the token_type..

If we are talking only about metadata - then I believe "revoked", "expired"
would be more meaningful..

Thanks & regards,

-Prabath 

On Tue, Feb 12, 2013 at 7:53 PM, Justin Richer  wrote:

OK, I can see the wisdom in changing this term. 

I picked "valid" because I wanted a simple "boolean" value that would
require no additional parsing or string-matching on the client's behalf, and
I'd like to stick with that. OAuth is built with the assumption that clients
need to be able to recover from invalid tokens at any stage, so I think a
simple yes/no is the right step here. 

That said, I think you're both right that "valid" seems to have caused a bit
of confusion. I don't want to go with "revoked" because I'd rather have the
"token is OK" be the positive boolean value. 

Would "valid_token" be more clear? Or do we need a different adjective all
together?

 -- Justin 

On 02/11/2013 08:02 PM, Richard Harrington wrote:

Have you considered "status" instead of "valid"?  It could have values like
"active", "expired", and "revoked".

Is it worthwhile including the status of the client also?  For example, a
client application could be disabled, temporarily or permanently, and thus
disabling its access tokens as well.

On Feb 11, 2013, at 1:56 PM, Prabath Siriwardena  wrote:

I guess confusion is with 'valid' parameter is in the response.. 

I thought this will be helpful to standardize the communication between
Resource Server and the Authorization Server..

I would suggest we completely remove "valid" from the response - or define
it much clearly..

May be can add "revoked" with a boolean attribute..

Thanks & regards,

-Prabath

On Tue, Feb 12, 2013 at 3:19 AM, Justin Richer  wrote:

On 02/08/2013 12:51 AM, Prabath Siriwardena wrote:

Hi Justin, 

I have couple of questions related to "valid" parameter...

This endpoint can be invoked by the Resource Server in runtime...

That's correct. 

In that case what is exactly meant by the "resource_id" in request ?

The resource_id field is a service-specific string that basically lets the
resource server provide some context to the request to the auth server.
There have been some other suggestions like client IP address, but I wanted
to put this one in because it seemed to be a common theme. The client is
trying to do *something* with the token, after all, and the rights,
permissions, and metadata associated with the token could change based on
that. Since the Introspection endpoint is all about getting that metadata
back to the PR, this seemed like a good idea. 

IMO a token to be valid depends on set of criteria based on it's type..

For a Bearer token..

1. Token should not be expired

2. Token should not be revoked.

3. The scope the token issued should match with the scope required for the
resource.

For a MAC token...

1. Token not expired (mac id)

2. Token should not be revoked

3. The scope the token issued should match with the scope required for the
resource.

4. HMAC check should be valid

There are similar conditions for SAML bearer too..

This isn't really true. The SAML bearer token is fully self-contained and
doesn't change based on other parameters in the message, unlike MAC. Same
with JWT. When it hands a SAML or JWT token to the AS, the PR has given
*everything* the server needs to check that token's validity and use. 

MAC signatures change with every message, and they're done across several
components of the HTTP message. Therefor, the HMAC check for MAC style
tokens will still need to be done by the protected resource. Introspection
would help in the case that the signature validated just fine, but the token
might have expired. Or you need to know what scopes apply. Introspection
isn't to fully validate the call to the protected resource -- if that were
the case, the PR would have to send some kind of encapsulated version of the
original request. Otherwise, the AS won't have all of the information it
needs to check the MAC.

I think what you're describing is ultimately *not* what the introspection
endpoint is intended to do. If that's unclear from the document, can you
please suggest text that would help clear the use case up? I wouldn't want
it to be ambiguous.

 -- Justin 

Thanks & regards,

-Prabath

On Thu, Feb 7, 2013 at 10:30 PM, Justin Richer  wrote:

It validates the token, which would be either the token itself in the case
of Bearer or the token "id" part of something more complex like MAC. It
doesn't directly validate the usage of the token, that's still up to the PR
to do that.

I nearly added a "token type" field in this draft, but held back because
there are several kinds of "token type" that people talk about in OAuth.
First, there's "Bearer" vs. "MAC" vs. "HOK", or what have you. Then within
Bearer you have "JWT" or "SAML" or "unstructured blob". Then you've also got
"access" vs. "refresh" and other flavors of token, like the id_token in
OpenID Connect. 

Thing is, the server running the introspection endpoint will probably know
*all* of these. But should it tell the client? If so, which of the three,
and what names should the fields be?

 -- Justin 

On 02/07/2013 11:26 AM, Prabath Siriwardena wrote:

Okay.. I was thinking this could be used as a way to validate the token as
well. BTW even in this case shouldn't communicate the type of token to AS?
For example in the case of SAML profile - it could be SAML token.. 

Thanks & regards,

-Prabath

On Thu, Feb 7, 2013 at 8:39 PM, Justin Richer  wrote:

"valid" might not be the best term, but it's meant to be a field where the
server says "yes this token is still good" or "no this token isn't good
anymore". We could instead do this with HTTP codes or something but I went
with a pure JSON response.

 -- Justin 

On 02/06/2013 10:47 PM, Prabath Siriwardena wrote:

Hi Justin, 

I believe this is addressing one of the key missing part in OAuth 2.0...

One question - I guess this was discussed already...

In the spec - in the introspection response it has the attribute "valid" -
this is basically the validity of the token provided in the request.

Validation criteria depends on the token and well as token type ( Bearer,
MAC..).

In the spec it seems like it's coupled with Bearer token type... But I
guess, by adding "token_type" to the request we can remove this dependency.

WDYT..?

Thanks & regards,

-Prabath 

On Thu, Feb 7, 2013 at 12:54 AM, Justin Richer  wrote:

Updated introspection draft based on recent comments. Changes include:

 - "scope" return parameter now follows RFC6749 format instead of JSON array
 - "subject" -> "sub", and "audience" -> "aud", to be parallel with JWT
claims
 - clarified what happens if the authentication is bad

 -- Justin

-------- Original Message -------- 

Subject: 

New Version Notification for draft-richer-oauth-introspection-02.txt

Date: 

Wed, 6 Feb 2013 11:24:20 -0800

From: 

To: 

A new version of I-D, draft-richer-oauth-introspection-02.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:       draft-richer-oauth-introspection
Revision:       02
Title:             OAuth Token Introspection
Creation date:       2013-02-06
WG ID:             Individual Submission
Number of pages: 6
URL:
http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
Status:
http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:
http://tools.ietf.org/html/draft-richer-oauth-introspection-02
Diff:
http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.

The IETF Secretariat

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

-- 
Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732   

http://blog.facilelogin.com
http://RampartFAQ.com

-- 
Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732   

http://blog.facilelogin.com
http://RampartFAQ.com

-- 
Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732   

http://blog.facilelogin.com
http://RampartFAQ.com

-- 
Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732   

http://blog.facilelogin.com
http://RampartFAQ.com

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

-- 
Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732   

http://blog.facilelogin.com
http://RampartFAQ.com

-- 
Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732   

http://blog.facilelogin.com
http://RampartFAQ.com

-- 
Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732   

http://blog.facilelogin.com
http://RampartFAQ.com

-- 
Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732   

http://blog.facilelogin.com
http://RampartFAQ.com

-- 
Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732   

http://blog.facilelogin.com
http://RampartFAQ.com

-- 
Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732   

http://blog.facilelogin.com
http://RampartFAQ.com

-- 
Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

------=_NextPart_000_00F0_01CE0AB5.DF3D54E0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Does the term =
“Active” help clarify the meaning but still confirm to your =
intention, Justin?

Best =
regards,
Don
Donald F. =
Coffin
Founder/CTO=
 =
REMI =
Networks
22751 El =
Prado Suite 6216
Rancho =
Santa Margarita, CA  92688-3836
 =
Phone: =
;     (949) 636-8571
Email: =
;      donald.coffin@reminetworks.com=

From: Justin Richer [mailto:jricher@mitre.org] 
Sent: =
Thursday, February 14, 2013 8:16 AM
To: Prabath =
Siriwardena
Cc: oauth@ietf.org
Subject: Re: =
[OAUTH-WG] Fwd: New Version Notification for =
draft-richer-oauth-introspection-02.txt=

That much I can at least do. I'd be happy =
with another term if there was a good one we could drop in its place =
without changing the intended semantics.

 -- =
Justin
On 02/14/2013 10:57 AM, =
Prabath Siriwardena wrote:
Not =
quite convinced :-) Valid has a meaning attached to that.. =

In case we are going ahead with this please define it =
clearly in the draft - with the one you shared in this =
thread.

Thanks & regards,
-Prabath
On Thu, Feb 14, 2013 at 8:16 PM, Justin Richer <jricher@mitre.org> =
wrote:

On =
02/14/2013 09:37 AM, Prabath Siriwardena =
wrote:
The definition of valid is bit ambiguous in the =
draft...

Okay.. If that is the definition... and if we beak =
that in to parts...

"it hasn't expired" : In the response it =
self we have parameter for issued_at and and expires_at - so whether the =
token is not expired or not can even be derived at the requestor's =
end.

If the =
token isn't good anymore, it doesn't matter when it was issued or when =
it was expired, just that it has. 

"token was issued from here" : For this IMO =
we need to send an error code. Requestor has picked the wrong =
AS.
We don't know if it =
came from another AS or if someone's just making things up. Either way =
it's not a good token. 

The remaining is  "revoked".. That is =
why I proposed earlier - we better have an attribute =
"revoked" - instead of "valid" in the =
response..

The =
end result of all three is the same: either the token is good, or it =
isn't. I think it's much simpler and more useful to leave it at =
that.

 -- =
Justin 

WDYT...?

Thanks & regards,
-Prabath

On Thu, =
Feb 14, 2013 at 7:58 PM, Justin Richer <jricher@mitre.org> wrote:
Because it will be the one that issued the token in =
the first place. 

Validity means "token was issued from =
here, it hasn't been revoked, it hasn't expired". 

 -- Justin =

On 02/14/2013 09:28 AM, Prabath Siriwardena =
wrote:
Okay. With out knowing the type of the token how can =
the AS validate the token ? What is meant by the validity there? =

Thanks & regards,
-Prabath
On Thu, Feb 14, 2013 at 7:55 PM, Justin Richer <jricher@mitre.org> wrote:
OK, I don't see the utility in that at all. What would =
it accomplish?

 -- =
Justin 

On 02/14/2013 09:25 AM, Prabath Siriwardena =
wrote:
To =
make it clear - my suggestion is to add token_type_hint to the =
introspection request. It can be from client to AS or from RS to AS. =

Then AS can decide whether the provided token is valid =
or not and include "valid" attribute in the introspection =
response.

Thanks & regards,
-Prabath
On Thu, Feb 14, 2013 at 7:52 PM, Prabath Siriwardena =
<prabath@wso2.com> wrote:
Both the client and the resource owner should be aware =
of the token type. 

My argument is, if the authorization server to decide =
whether the token is valid or not ( irrespective of who asked the =
question) - AS needs to know the token type - because to validate a =
token AS should know the token type.

The token type could be, bearer or MAC or any other =
token type.

Thanks & regards,
-Prabath 

On Thu, Feb 14, 2013 at 7:33 PM, Justin Richer <jricher@mitre.org> wrote:
What exactly are you suggesting be added to =
introspection? The "token_type_hint" is from the client to the =
server, but what you've asked for in terms of "token type" is =
from the server to the client. And there was never an answer to what =
exactly is meant by "token type" in this case, particularly =
because you seem to want to call out things like SAML and Bearer as =
separate types. 

 -- =
Justin 

On 02/14/2013 06:59 AM, Prabath Siriwardena =
wrote:
I =
noticed that the latest Token Revocation draft [1] has introduced the =
parameter "token_type_hint". I would suggest the same here, as =
that would make what is meant by "valid" much clear.. =

[1]: =
http://tools.ietf.org/html/draft-ietf-oauth-revocation-05=

Thanks & regards,
-Prabath
On Tue, Feb 12, 2013 at 9:35 PM, Prabath Siriwardena =
<prabath@wso2.com> wrote:
Hi Justin, 

I =
doubt whether valid_token would make a =
difference..?

My initial argument is what is the validation =
criteria..? Validation criteria depends on the =
token_type..

If we are talking only about metadata - then I believe =
"revoked", "expired" would be more =
meaningful..

Thanks & regards,
-Prabath 

On Tue, Feb 12, 2013 at 7:53 PM, Justin Richer <jricher@mitre.org> wrote:
OK, I can see the wisdom in changing this term. =

I picked "valid" because I wanted a simple =
"boolean" value that would require no additional parsing or =
string-matching on the client's behalf, and I'd like to stick with that. =
OAuth is built with the assumption that clients need to be able to =
recover from invalid tokens at any stage, so I think a simple yes/no is =
the right step here. 

That said, I think you're both right that =
"valid" seems to have caused a bit of confusion. I don't want =
to go with "revoked" because I'd rather have the "token =
is OK" be the positive boolean value. 

Would =
"valid_token" be more clear? Or do we need a different =
adjective all together?

 -- =
Justin 

On 02/11/2013 08:02 PM, Richard Harrington =
wrote:
Have you considered "status" instead of =
"valid"?  It could have values like "active", =
"expired", and =
"revoked".

Is it worthwhile including the status of the client =
also?  For example, a client application could be disabled, =
temporarily or permanently, and thus disabling its access tokens as =
well.

On Feb 11, 2013, at 1:56 PM, Prabath =
Siriwardena <prabath@wso2.com> =
wrote:
I guess confusion is with 'valid' parameter is in the =
response.. 

I =
thought this will be helpful to standardize the communication =
between Resource Server and the Authorization =
Server..

I =
would suggest we completely remove "valid" from the response - =
or define it much clearly..

May be can add "revoked" with a boolean =
attribute..

Thanks & regards,
-Prabath
On Tue, Feb 12, 2013 at 3:19 AM, Justin Richer <jricher@mitre.org> =
wrote:

On =
02/08/2013 12:51 AM, Prabath Siriwardena =
wrote:
Hi Justin, 

I have couple of questions related to =
"valid" parameter...

This endpoint can be invoked by the Resource Server in =
runtime...

That's correct. 

In that case what is exactly meant by the =
"resource_id" in request ?

The =
resource_id field is a service-specific string that basically lets the =
resource server provide some context to the request to the auth server. =
There have been some other suggestions like client IP address, but I =
wanted to put this one in because it seemed to be a common theme. The =
client is trying to do *something* with the token, after all, and the =
rights, permissions, and metadata associated with the token could change =
based on that. Since the Introspection endpoint is all about getting =
that metadata back to the PR, this seemed like a good idea. =

IMO a token to be valid depends on set of criteria =
based on it's type..

For a Bearer token..

1. Token should not be =
expired
2. Token should =
not be revoked.
3. The =
scope the token issued should match with the scope required for the =
resource.

For a MAC token...

1. Token not expired (mac =
id)
2. Token should not be =
revoked
3. The scope the =
token issued should match with the scope required for the =
resource.
4. HMAC check =
should be valid

There =
are similar conditions for SAML bearer too..

This =
isn't really true. The SAML bearer token is fully self-contained and =
doesn't change based on other parameters in the message, unlike MAC. =
Same with JWT. When it hands a SAML or JWT token to the AS, the PR has =
given *everything* the server needs to check that token's validity and =
use. 

MAC signatures change with every message, and they're done =
across several components of the HTTP message. Therefor, the HMAC check =
for MAC style tokens will still need to be done by the protected =
resource. Introspection would help in the case that the signature =
validated just fine, but the token might have expired. Or you need to =
know what scopes apply. Introspection isn't to fully validate the call =
to the protected resource -- if that were the case, the PR would have to =
send some kind of encapsulated version of the original request. =
Otherwise, the AS won't have all of the information it needs to check =
the MAC.

I think what you're describing is ultimately *not* =
what the introspection endpoint is intended to do. If that's unclear =
from the document, can you please suggest text that would help clear the =
use case up? I wouldn't want it to be ambiguous.

 -- Justin =

Thanks & regards,
-Prabath

On Thu, =
Feb 7, 2013 at 10:30 PM, Justin Richer <jricher@mitre.org> wrote:
It validates the token, which would be either the =
token itself in the case of Bearer or the token "id" part of =
something more complex like MAC. It doesn't directly validate the usage =
of the token, that's still up to the PR to do that.

I nearly =
added a "token type" field in this draft, but held back =
because there are several kinds of "token type" that people =
talk about in OAuth. First, there's "Bearer" vs. =
"MAC" vs. "HOK", or what have you. Then within =
Bearer you have "JWT" or "SAML" or =
"unstructured blob". Then you've also got "access" =
vs. "refresh" and other flavors of token, like the id_token in =
OpenID Connect. 

Thing is, the server running the introspection =
endpoint will probably know *all* of these. But should it tell the =
client? If so, which of the three, and what names should the fields =
be?

 -- Justin =

On 02/07/2013 11:26 AM, Prabath Siriwardena =
wrote:
Okay.. I was thinking this could be used as a way to =
validate the token as well. BTW even in this case shouldn't communicate =
the type of token to AS? For example in the case of SAML profile - it =
could be SAML token.. 

Thanks & regards,
-Prabath
On Thu, Feb 7, 2013 at 8:39 PM, Justin Richer <jricher@mitre.org> wrote:
"valid" might not be the best term, but it's =
meant to be a field where the server says "yes this token is still =
good" or "no this token isn't good anymore". We could =
instead do this with HTTP codes or something but I went with a pure JSON =
response.

 -- Justin =

On 02/06/2013 10:47 PM, Prabath Siriwardena =
wrote:
Hi =
Justin, 

I =
believe this is addressing one of the key missing part in OAuth =
2.0...

One question - I guess this was discussed =
already...

In the spec - in the introspection response it has the =
attribute "valid" - this is basically the validity of the =
token provided in the request.

Validation criteria depends on the token and well =
as token type ( Bearer, MAC..).

In the spec it seems like it's coupled with Bearer =
token type... But I guess, by adding "token_type" to the =
request we can remove this dependency.

WDYT..?

Thanks & regards,
-Prabath 

On Thu, =
Feb 7, 2013 at 12:54 AM, Justin Richer <jricher@mitre.org> wrote:
Updated introspection draft based on recent comments. =
Changes include:

 - "scope" return parameter now =
follows RFC6749 format instead of JSON array
 - =
"subject" -> "sub", and "audience" =
-> "aud", to be parallel with JWT claims
 - =
clarified what happens if the authentication is bad

 -- =
Justin

-------- Original =
Message -------- <=
/table> 
A new version =
of I-D, draft-richer-oauth-introspection-02.txt
has =
been successfully submitted by Justin Richer and posted to =
the
IETF =
repository.

Filename:&nb=
sp;      =
draft-richer-oauth-introspection
Revision: &nbs=
p;     =
02
Title:      =
       OAuth Token =
Introspection
Creation =
date:       2013-02-06
WG =
ID:             =
Individual Submission
Number of pages: =
6
URL:       &nbs=
p;     http://www.ietf.org/internet-drafts/draft-richer-oauth-=
introspection-02.txt
Status:   &n=
bsp;      http://datatracker.ietf.org/doc/draft-richer-oauth-intr=
ospection
Htmlized:     =
;   http://tools.ietf.org/html/draft-richer-oauth-introspec=
tion-02
Diff:      =
;      http://www.ietf.org/rfcdiff?url2=3Ddraft-richer-oauth-i=
ntrospection-02

Abst=
ract:
   This specification defines a =
method for a client or protected
   =
resource to query an OAuth authorization server to determine =
meta-
   information about an OAuth =
token.

 =
          &n=
bsp;           &nb=
sp;           &nbs=
p;            =
;            =
            &=
nbsp;          =

 =
The IETF Secretariat

______________________________________=
_________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

-- =

Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

-- =

Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

-- =

Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

-- =

Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com
_______________________________________________
OAut=
h mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

-- =

Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

-- =

Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

-- =

Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

-- =

Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

-- =

Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

-- =

Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

-- =

Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com

------=_NextPart_000_00F0_01CE0AB5.DF3D54E0--

From jricher@mitre.org  Thu Feb 14 13:24:33 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA60321F88B5 for ; Thu, 14 Feb 2013 13:24:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.571
X-Spam-Level: 
X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.027,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdiLRyKmtCOn for ; Thu, 14 Feb 2013 13:24:14 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3AF21F85AC for ; Thu, 14 Feb 2013 13:24:04 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 13946150118; Thu, 14 Feb 2013 16:24:04 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id E039E15011C; Thu, 14 Feb 2013 16:24:03 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 14 Feb 2013 16:24:03 -0500
Message-ID: <511D55C5.4080503@mitre.org>
Date: Thu, 14 Feb 2013 16:23:17 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Donald F Coffin 
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com>		<51196777.6000502@mitre.org>			<511A5062.5010108@mitre.org>			<511CEEAA.3030801@mitre.org>			<511CF3EF.8040008@mitre.org>		<511CF4AB.5010700@mitre.org>		<511CF8C5.70301@mitre.org>	 <511D0DC3.7000607@mitre.org> <00ef01ce0af8$ed591ad0$c80b5070$@reminetworks.com>
In-Reply-To: <00ef01ce0af8$ed591ad0$c80b5070$@reminetworks.com>
Content-Type: multipart/alternative; boundary="------------040709040705020505060806"
X-Originating-IP: [129.83.31.58]
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for	draft-richer-oauth-introspection-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2013 21:24:33 -0000

--------------040709040705020505060806
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

That could work for me. Anyone else?

  -- Justin

On 02/14/2013 04:19 PM, Donald F Coffin wrote:
>
> Does the term "Active" help clarify the meaning but still confirm to 
> your intention, Justin?
>
> Best regards,
>
> Don
>
> Donald F. Coffin
>
> Founder/CTO
>
> REMI Networks
>
> 22751 El Prado Suite 6216
>
> Rancho Santa Margarita, CA  92688-3836
>
> Phone: (949) 636-8571
>
> Email: donald.coffin@reminetworks.com 
> 
>
> *From:*Justin Richer [mailto:jricher@mitre.org]
> *Sent:* Thursday, February 14, 2013 8:16 AM
> *To:* Prabath Siriwardena
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Fwd: New Version Notification for 
> draft-richer-oauth-introspection-02.txt
>
> That much I can at least do. I'd be happy with another term if there 
> was a good one we could drop in its place without changing the 
> intended semantics.
>
>  -- Justin
>
> On 02/14/2013 10:57 AM, Prabath Siriwardena wrote:
>
>     Not quite convinced :-) Valid has a meaning attached to that..
>
>     In case we are going ahead with this please define it clearly in
>     the draft - with the one you shared in this thread.
>
>     Thanks & regards,
>
>     -Prabath
>
>     On Thu, Feb 14, 2013 at 8:16 PM, Justin Richer      > wrote:
>
>     On 02/14/2013 09:37 AM, Prabath Siriwardena wrote:
>
>         The definition of valid is bit ambiguous in the draft...
>
>         Okay.. If that is the definition... and if we beak that in to
>         parts...
>
>         "it hasn't expired" : In the response it self we have
>         parameter for issued_at and and expires_at - so whether the
>         token is not expired or not can even be derived at the
>         requestor's end.
>
>     If the token isn't good anymore, it doesn't matter when it was
>     issued or when it was expired, just that it has.
>
>
>
>
>     "token was issued from here" : For this IMO we need to send an
>     error code. Requestor has picked the wrong AS.
>
>     We don't know if it came from another AS or if someone's just
>     making things up. Either way it's not a good token.
>
>
>
>
>     The remaining is  "revoked".. That is why I proposed earlier - we
>     better have an attribute "revoked" - instead of "valid" in the
>     response..
>
>     The end result of all three is the same: either the token is good,
>     or it isn't. I think it's much simpler and more useful to leave it
>     at that.
>
>      -- Justin
>
>
>
>
>     WDYT...?
>
>     Thanks & regards,
>
>     -Prabath
>
>     On Thu, Feb 14, 2013 at 7:58 PM, Justin Richer      > wrote:
>
>     Because it will be the one that issued the token in the first place.
>
>     Validity means "token was issued from here, it hasn't been
>     revoked, it hasn't expired".
>
>      -- Justin
>
>     On 02/14/2013 09:28 AM, Prabath Siriwardena wrote:
>
>         Okay. With out knowing the type of the token how can the AS
>         validate the token ? What is meant by the validity there?
>
>         Thanks & regards,
>
>         -Prabath
>
>         On Thu, Feb 14, 2013 at 7:55 PM, Justin Richer
>         > wrote:
>
>         OK, I don't see the utility in that at all. What would it
>         accomplish?
>
>          -- Justin
>
>         On 02/14/2013 09:25 AM, Prabath Siriwardena wrote:
>
>             To make it clear - my suggestion is to add token_type_hint
>             to the introspection request. It can be from client to AS
>             or from RS to AS.
>
>             Then AS can decide whether the provided token is valid or
>             not and include "valid" attribute in the introspection
>             response.
>
>             Thanks & regards,
>
>             -Prabath
>
>             On Thu, Feb 14, 2013 at 7:52 PM, Prabath Siriwardena
>             > wrote:
>
>             Both the client and the resource owner should be aware of
>             the token type.
>
>             My argument is, if the authorization server to decide
>             whether the token is valid or not ( irrespective of who
>             asked the question) - AS needs to know the token type -
>             because to validate a token AS should know the token type.
>
>             The token type could be, bearer or MAC or any other token
>             type.
>
>             Thanks & regards,
>
>             -Prabath
>
>             On Thu, Feb 14, 2013 at 7:33 PM, Justin Richer
>             > wrote:
>
>             What exactly are you suggesting be added to introspection?
>             The "token_type_hint" is from the client to the server,
>             but what you've asked for in terms of "token type" is from
>             the server to the client. And there was never an answer to
>             what exactly is meant by "token type" in this case,
>             particularly because you seem to want to call out things
>             like SAML and Bearer as separate types.
>
>              -- Justin
>
>
>
>             On 02/14/2013 06:59 AM, Prabath Siriwardena wrote:
>
>                 I noticed that the latest Token Revocation draft [1]
>                 has introduced the parameter "token_type_hint". I
>                 would suggest the same here, as that would make what
>                 is meant by "valid" much clear..
>
>                 [1]:
>                 http://tools.ietf.org/html/draft-ietf-oauth-revocation-05
>
>                 Thanks & regards,
>
>                 -Prabath
>
>                 On Tue, Feb 12, 2013 at 9:35 PM, Prabath Siriwardena
>                 > wrote:
>
>                 Hi Justin,
>
>                 I doubt whether valid_token would make a difference..?
>
>                 My initial argument is what is the validation
>                 criteria..? Validation criteria depends on the
>                 token_type..
>
>                 If we are talking only about metadata - then I believe
>                 "revoked", "expired" would be more meaningful..
>
>                 Thanks & regards,
>
>                 -Prabath
>
>                 On Tue, Feb 12, 2013 at 7:53 PM, Justin Richer
>                 > wrote:
>
>                 OK, I can see the wisdom in changing this term.
>
>                 I picked "valid" because I wanted a simple "boolean"
>                 value that would require no additional parsing or
>                 string-matching on the client's behalf, and I'd like
>                 to stick with that. OAuth is built with the assumption
>                 that clients need to be able to recover from invalid
>                 tokens at any stage, so I think a simple yes/no is the
>                 right step here.
>
>                 That said, I think you're both right that "valid"
>                 seems to have caused a bit of confusion. I don't want
>                 to go with "revoked" because I'd rather have the
>                 "token is OK" be the positive boolean value.
>
>                 Would "valid_token" be more clear? Or do we need a
>                 different adjective all together?
>
>                  -- Justin
>
>                 On 02/11/2013 08:02 PM, Richard Harrington wrote:
>
>                     Have you considered "status" instead of "valid"?
>                      It could have values like "active", "expired",
>                     and "revoked".
>
>                     Is it worthwhile including the status of the
>                     client also?  For example, a client application
>                     could be disabled, temporarily or permanently, and
>                     thus disabling its access tokens as well.
>
>
>                     On Feb 11, 2013, at 1:56 PM, Prabath Siriwardena
>                     > wrote:
>
>                         I guess confusion is with 'valid' parameter is
>                         in the response..
>
>                         I thought this will be helpful
>                         to standardize the communication between
>                         Resource Server and the Authorization Server..
>
>                         I would suggest we completely remove "valid"
>                         from the response - or define it much clearly..
>
>                         May be can add "revoked" with a boolean
>                         attribute..
>
>                         Thanks & regards,
>
>                         -Prabath
>
>                         On Tue, Feb 12, 2013 at 3:19 AM, Justin Richer
>                         >
>                         wrote:
>
>                         On 02/08/2013 12:51 AM, Prabath Siriwardena wrote:
>
>                             Hi Justin,
>
>                             I have couple of questions related to
>                             "valid" parameter...
>
>                             This endpoint can be invoked by the
>                             Resource Server in runtime...
>
>
>                         That's correct.
>
>
>
>
>                         In that case what is exactly meant by the
>                         "resource_id" in request ?
>
>                         The resource_id field is a service-specific
>                         string that basically lets the resource server
>                         provide some context to the request to the
>                         auth server. There have been some other
>                         suggestions like client IP address, but I
>                         wanted to put this one in because it seemed to
>                         be a common theme. The client is trying to do
>                         *something* with the token, after all, and the
>                         rights, permissions, and metadata associated
>                         with the token could change based on that.
>                         Since the Introspection endpoint is all about
>                         getting that metadata back to the PR, this
>                         seemed like a good idea.
>
>
>
>
>                         IMO a token to be valid depends on set of
>                         criteria based on it's type..
>
>                         For a Bearer token..
>
>                         1. Token should not be expired
>
>                         2. Token should not be revoked.
>
>                         3. The scope the token issued should match
>                         with the scope required for the resource.
>
>                         For a MAC token...
>
>                         1. Token not expired (mac id)
>
>                         2. Token should not be revoked
>
>                         3. The scope the token issued should match
>                         with the scope required for the resource.
>
>                         4. HMAC check should be valid
>
>                         There are similar conditions for SAML bearer too..
>
>                         This isn't really true. The SAML bearer token
>                         is fully self-contained and doesn't change
>                         based on other parameters in the message,
>                         unlike MAC. Same with JWT. When it hands a
>                         SAML or JWT token to the AS, the PR has given
>                         *everything* the server needs to check that
>                         token's validity and use.
>
>                         MAC signatures change with every message, and
>                         they're done across several components of the
>                         HTTP message. Therefor, the HMAC check for MAC
>                         style tokens will still need to be done by the
>                         protected resource. Introspection would help
>                         in the case that the signature validated just
>                         fine, but the token might have expired. Or you
>                         need to know what scopes apply. Introspection
>                         isn't to fully validate the call to the
>                         protected resource -- if that were the case,
>                         the PR would have to send some kind of
>                         encapsulated version of the original request.
>                         Otherwise, the AS won't have all of the
>                         information it needs to check the MAC.
>
>
>                         I think what you're describing is ultimately
>                         *not* what the introspection endpoint is
>                         intended to do. If that's unclear from the
>                         document, can you please suggest text that
>                         would help clear the use case up? I wouldn't
>                         want it to be ambiguous.
>
>                          -- Justin
>
>
>
>
>                         Thanks & regards,
>
>                         -Prabath
>
>                         On Thu, Feb 7, 2013 at 10:30 PM, Justin Richer
>                         >
>                         wrote:
>
>                         It validates the token, which would be either
>                         the token itself in the case of Bearer or the
>                         token "id" part of something more complex like
>                         MAC. It doesn't directly validate the usage of
>                         the token, that's still up to the PR to do that.
>
>                         I nearly added a "token type" field in this
>                         draft, but held back because there are several
>                         kinds of "token type" that people talk about
>                         in OAuth. First, there's "Bearer" vs. "MAC"
>                         vs. "HOK", or what have you. Then within
>                         Bearer you have "JWT" or "SAML" or
>                         "unstructured blob". Then you've also got
>                         "access" vs. "refresh" and other flavors of
>                         token, like the id_token in OpenID Connect.
>
>                         Thing is, the server running the introspection
>                         endpoint will probably know *all* of these.
>                         But should it tell the client? If so, which of
>                         the three, and what names should the fields be?
>
>                          -- Justin
>
>                         On 02/07/2013 11:26 AM, Prabath Siriwardena wrote:
>
>                             Okay.. I was thinking this could be used
>                             as a way to validate the token as well.
>                             BTW even in this case shouldn't
>                             communicate the type of token to AS? For
>                             example in the case of SAML profile - it
>                             could be SAML token..
>
>                             Thanks & regards,
>
>                             -Prabath
>
>                             On Thu, Feb 7, 2013 at 8:39 PM, Justin
>                             Richer                              > wrote:
>
>                             "valid" might not be the best term, but
>                             it's meant to be a field where the server
>                             says "yes this token is still good" or "no
>                             this token isn't good anymore". We could
>                             instead do this with HTTP codes or
>                             something but I went with a pure JSON
>                             response.
>
>                              -- Justin
>
>                             On 02/06/2013 10:47 PM, Prabath
>                             Siriwardena wrote:
>
>                                 Hi Justin,
>
>                                 I believe this is addressing one of
>                                 the key missing part in OAuth 2.0...
>
>                                 One question - I guess this was
>                                 discussed already...
>
>                                 In the spec - in the introspection
>                                 response it has the attribute "valid"
>                                 - this is basically the validity of
>                                 the token provided in the request.
>
>                                 Validation criteria depends on the
>                                 token and well as token type ( Bearer,
>                                 MAC..).
>
>                                 In the spec it seems like it's coupled
>                                 with Bearer token type... But I guess,
>                                 by adding "token_type" to the request
>                                 we can remove this dependency.
>
>                                 WDYT..?
>
>                                 Thanks & regards,
>
>                                 -Prabath
>
>                                 On Thu, Feb 7, 2013 at 12:54 AM,
>                                 Justin Richer                                  > wrote:
>
>                                 Updated introspection draft based on
>                                 recent comments. Changes include:
>
>                                  - "scope" return parameter now
>                                 follows RFC6749 format instead of JSON
>                                 array
>                                  - "subject" -> "sub", and "audience"
>                                 -> "aud", to be parallel with JWT claims
>                                  - clarified what happens if the
>                                 authentication is bad
>
>                                  -- Justin
>
>
>
>                                 -------- Original Message --------
>
>                                 *Subject: *
>
>                                 	
>
>                                 New Version Notification for
>                                 draft-richer-oauth-introspection-02.txt
>
>                                 *Date: *
>
>                                 	
>
>                                 Wed, 6 Feb 2013 11:24:20 -0800
>
>                                 *From: *
>
>                                 	
>
>                                 
>                                 
>
>                                 *To: *
>
>                                 	
>
>                                 
>                                 
>
>                                 A new version of I-D, draft-richer-oauth-introspection-02.txt
>
>                                 has been successfully submitted by Justin Richer and posted to the
>
>                                 IETF repository.
>
>                                   
>
>                                 Filename:       draft-richer-oauth-introspection
>
>                                 Revision:       02
>
>                                 Title:             OAuth Token Introspection
>
>                                 Creation date:       2013-02-06
>
>                                 WG ID:             Individual Submission
>
>                                 Number of pages: 6
>
>                                 URL:http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
>
>                                 Status:http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
>
>                                 Htmlized:http://tools.ietf.org/html/draft-richer-oauth-introspection-02
>
>                                 Diff:http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02
>
>                                   
>
>                                 Abstract:
>
>                                     This specification defines a method for a client or protected
>
>                                     resource to query an OAuth authorization server to determine meta-
>
>                                     information about an OAuth token.
>
>                                   
>
>                                   
>
>                                                                                                                    
>
>                                   
>
>                                   
>
>                                 The IETF Secretariat
>
>                                   
>
>
>                                 _______________________________________________
>                                 OAuth mailing list
>                                 OAuth@ietf.org 
>                                 https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>                                 -- 
>                                 Thanks & Regards,
>                                 Prabath
>
>                                 Mobile : +94 71 809 6732
>                                 
>
>                                 http://blog.facilelogin.com
>                                 http://RampartFAQ.com
>
>
>
>                             -- 
>                             Thanks & Regards,
>                             Prabath
>
>                             Mobile : +94 71 809 6732
>                             
>
>                             http://blog.facilelogin.com
>                             http://RampartFAQ.com
>
>
>
>                         -- 
>                         Thanks & Regards,
>                         Prabath
>
>                         Mobile : +94 71 809 6732
>                         
>
>                         http://blog.facilelogin.com
>                         http://RampartFAQ.com
>
>
>
>                         -- 
>                         Thanks & Regards,
>                         Prabath
>
>                         Mobile : +94 71 809 6732
>                         
>
>                         http://blog.facilelogin.com
>                         http://RampartFAQ.com
>
>                         _______________________________________________
>                         OAuth mailing list
>                         OAuth@ietf.org 
>                         https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>                 -- 
>                 Thanks & Regards,
>                 Prabath
>
>                 Mobile : +94 71 809 6732 
>
>                 http://blog.facilelogin.com
>                 http://RampartFAQ.com
>
>
>
>                 -- 
>                 Thanks & Regards,
>                 Prabath
>
>                 Mobile : +94 71 809 6732 
>
>                 http://blog.facilelogin.com
>                 http://RampartFAQ.com
>
>
>
>             -- 
>             Thanks & Regards,
>             Prabath
>
>             Mobile : +94 71 809 6732 
>
>             http://blog.facilelogin.com
>             http://RampartFAQ.com
>
>
>
>             -- 
>             Thanks & Regards,
>             Prabath
>
>             Mobile : +94 71 809 6732 
>
>             http://blog.facilelogin.com
>             http://RampartFAQ.com
>
>
>
>         -- 
>         Thanks & Regards,
>         Prabath
>
>         Mobile : +94 71 809 6732 
>
>         http://blog.facilelogin.com
>         http://RampartFAQ.com
>
>
>
>     -- 
>     Thanks & Regards,
>     Prabath
>
>     Mobile : +94 71 809 6732 
>
>     http://blog.facilelogin.com
>     http://RampartFAQ.com
>
>
>
>     -- 
>     Thanks & Regards,
>     Prabath
>
>     Mobile : +94 71 809 6732
>
>     http://blog.facilelogin.com
>     http://RampartFAQ.com
>

--------------040709040705020505060806
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

    That could work for me. Anyone else?

     -- Justin

    On 02/14/2013 04:19 PM, Donald F Coffin
      wrote:

        Does
            the term “Active” help clarify the meaning but still confirm
            to your intention, Justin?

          Best
              regards,
          Don
          Donald
              F. Coffin
          Founder/CTO

          REMI
              Networks
          22751
              El Prado Suite 6216
          Rancho
              Santa Margarita, CA  92688-3836

          Phone:     
              (949) 636-8571
          Email:      
              donald.coffin@reminetworks.com

            From:
                Justin Richer [mailto:jricher@mitre.org] 

                Sent: Thursday, February 14, 2013 8:16 AM

                To: Prabath Siriwardena

                Cc: oauth@ietf.org

                Subject: Re: [OAUTH-WG] Fwd: New Version
                Notification for draft-richer-oauth-introspection-02.txt

        That much I
          can at least do. I'd be happy with another term if there was a
          good one we could drop in its place without changing the
          intended semantics.

           -- Justin

          On 02/14/2013 10:57 AM, Prabath
            Siriwardena wrote:

          Not quite convinced :-) Valid has a
            meaning attached to that.. 

            In case we are going ahead with this
              please define it clearly in the draft - with the one you
              shared in this thread.

            Thanks & regards,

            -Prabath

              On Thu, Feb 14, 2013 at 8:16 PM,
                Justin Richer <jricher@mitre.org>
                wrote:

                    On 02/14/2013 09:37 AM, Prabath
                      Siriwardena wrote:

                      The definition of valid is
                        bit ambiguous in the draft...

                      Okay.. If that is the
                        definition... and if we beak that in to parts...

                      "it hasn't expired" : In the
                        response it self we have parameter for issued_at
                        and and expires_at - so whether the token is not
                        expired or not can even be derived at the
                        requestor's end.

                If the token isn't good anymore, it
                  doesn't matter when it was issued or when it was
                  expired, just that it has. 

                    "token was issued from here" :
                      For this IMO we need to send an error code.
                      Requestor has picked the wrong AS.

                We don't know if it came from
                  another AS or if someone's just making things up.
                  Either way it's not a good token. 

                    The remaining is  "revoked"..
                      That is why I proposed earlier - we better have an
                      attribute "revoked" - instead of "valid" in the
                      response..

                The end result of all three is the
                  same: either the token is good, or it isn't. I think
                  it's much simpler and more useful to leave it at that.

                     -- Justin 

                      WDYT...?

                      Thanks & regards,

                      -Prabath

                        On Thu, Feb 14, 2013 at
                          7:58 PM, Justin Richer <jricher@mitre.org>
                          wrote:

                          Because it will be the
                            one that issued the token in the first
                            place. 

                            Validity means "token was issued from here,
                            it hasn't been revoked, it hasn't expired".

                               -- Justin 

                                On 02/14/2013 09:28
                                  AM, Prabath Siriwardena wrote:

                                Okay. With out
                                  knowing the type of the token how can
                                  the AS validate the token ? What is
                                  meant by the validity there? 

                                  Thanks &
                                    regards,

                                  -Prabath

                                    On Thu, Feb 14,
                                      2013 at 7:55 PM, Justin Richer
                                      <jricher@mitre.org>
                                      wrote:

                                      OK, I don't
                                        see the utility in that at all.
                                        What would it accomplish?

                                           -- Justin 

                                            On
                                              02/14/2013 09:25 AM,
                                              Prabath Siriwardena wrote:

                                            To make
                                              it clear - my suggestion
                                              is to add token_type_hint
                                              to the introspection
                                              request. It can be from
                                              client to AS or from RS to
                                              AS. 

                                              Then
                                                AS can decide whether
                                                the provided token is
                                                valid or not and include
                                                "valid" attribute in the
                                                introspection response.

                                              Thanks
                                                & regards,

                                              -Prabath

                                                On
                                                  Thu, Feb 14, 2013 at
                                                  7:52 PM, Prabath
                                                  Siriwardena <prabath@wso2.com>
                                                  wrote:
                                                Both
                                                  the client and the
                                                  resource owner should
                                                  be aware of the token
                                                  type. 

                                                  My
                                                    argument is, if the
                                                    authorization server
                                                    to decide whether
                                                    the token is valid
                                                    or not (
                                                    irrespective of who
                                                    asked the question)
                                                    - AS needs to know
                                                    the token type -
                                                    because to validate
                                                    a token AS should
                                                    know the token type.

                                                  The
                                                    token type could be,
                                                    bearer or MAC or any
                                                    other token type.

                                                  Thanks
                                                    & regards,

                                                  -Prabath

                                                        On
                                                          Thu, Feb 14,
                                                          2013 at 7:33
                                                          PM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:

                                                          What
                                                          exactly are
                                                          you suggesting
                                                          be added to
                                                          introspection?
                                                          The
                                                          "token_type_hint"
                                                          is from the
                                                          client to the
                                                          server, but
                                                          what you've
                                                          asked for in
                                                          terms of
                                                          "token type"
                                                          is from the
                                                          server to the
                                                          client. And
                                                          there was
                                                          never an
                                                          answer to what
                                                          exactly is
                                                          meant by
                                                          "token type"
                                                          in this case,
                                                          particularly
                                                          because you
                                                          seem to want
                                                          to call out
                                                          things like
                                                          SAML and
                                                          Bearer as
                                                          separate
                                                          types. 

                                                           -- Justin

                                                          On
                                                          02/14/2013
                                                          06:59 AM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          I
                                                          noticed that
                                                          the latest
                                                          Token
                                                          Revocation
                                                          draft [1] has
                                                          introduced the
                                                          parameter
                                                          "token_type_hint".
                                                          I would
                                                          suggest the
                                                          same here, as
                                                          that would
                                                          make what is
                                                          meant by
                                                          "valid" much
                                                          clear.. 

                                                          [1]: http://tools.ietf.org/html/draft-ietf-oauth-revocation-05

                                                          Thanks
                                                          & regards,

                                                          -Prabath

                                                          On
                                                          Tue, Feb 12,
                                                          2013 at 9:35
                                                          PM, Prabath
                                                          Siriwardena
                                                          <prabath@wso2.com>
                                                          wrote:
                                                          Hi
                                                          Justin, 

                                                          I
                                                          doubt whether
                                                          valid_token
                                                          would make a
                                                          difference..?

                                                          My
                                                          initial
                                                          argument is
                                                          what is the
                                                          validation
                                                          criteria..?
                                                          Validation
                                                          criteria
                                                          depends on the
                                                          token_type..

                                                          If
                                                          we are talking
                                                          only about
                                                          metadata -
                                                          then I believe
                                                          "revoked",
                                                          "expired"
                                                          would be more
                                                          meaningful..

                                                          Thanks
                                                          & regards,

                                                          -Prabath

                                                          On
                                                          Tue, Feb 12,
                                                          2013 at 7:53
                                                          PM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:

                                                          OK,
                                                          I can see the
                                                          wisdom in
                                                          changing this
                                                          term. 

                                                          I picked
                                                          "valid"
                                                          because I
                                                          wanted a
                                                          simple
                                                          "boolean"
                                                          value that
                                                          would require
                                                          no additional
                                                          parsing or
                                                          string-matching
                                                          on the
                                                          client's
                                                          behalf, and
                                                          I'd like to
                                                          stick with
                                                          that. OAuth is
                                                          built with the
                                                          assumption
                                                          that clients
                                                          need to be
                                                          able to
                                                          recover from
                                                          invalid tokens
                                                          at any stage,
                                                          so I think a
                                                          simple yes/no
                                                          is the right
                                                          step here. 

                                                          That said, I
                                                          think you're
                                                          both right
                                                          that "valid"
                                                          seems to have
                                                          caused a bit
                                                          of confusion.
                                                          I don't want
                                                          to go with
                                                          "revoked"
                                                          because I'd
                                                          rather have
                                                          the "token is
                                                          OK" be the
                                                          positive
                                                          boolean value.

                                                          Would
                                                          "valid_token"
                                                          be more clear?
                                                          Or do we need
                                                          a different
                                                          adjective all
                                                          together?

                                                           -- Justin

                                                          On
                                                          02/11/2013
                                                          08:02 PM,
                                                          Richard
                                                          Harrington
                                                          wrote:

                                                          Have
                                                          you considered
                                                          "status"
                                                          instead of
                                                          "valid"?  It
                                                          could have
                                                          values like
                                                          "active",
                                                          "expired", and
                                                          "revoked".

                                                          Is
                                                          it worthwhile
                                                          including the
                                                          status of the
                                                          client also?
                                                           For example,
                                                          a client
                                                          application
                                                          could be
                                                          disabled,
                                                          temporarily or
                                                          permanently,
                                                          and thus
                                                          disabling its
                                                          access tokens
                                                          as well.

                                                          On Feb 11,
                                                          2013, at 1:56
                                                          PM, Prabath
                                                          Siriwardena
                                                          <prabath@wso2.com>
                                                          wrote:

                                                          I
                                                          guess
                                                          confusion is
                                                          with 'valid'
                                                          parameter is
                                                          in the
                                                          response.. 

                                                          I
                                                          thought this
                                                          will be
                                                          helpful
                                                          to standardize the
                                                          communication
                                                          between
                                                          Resource
                                                          Server and the
                                                          Authorization
                                                          Server..

                                                          I
                                                          would suggest
                                                          we completely
                                                          remove "valid"
                                                          from the
                                                          response - or
                                                          define it much
                                                          clearly..

                                                          May
                                                          be can add
                                                          "revoked" with
                                                          a boolean
                                                          attribute..

                                                          Thanks
                                                          & regards,

                                                          -Prabath

                                                          On
                                                          Tue, Feb 12,
                                                          2013 at 3:19
                                                          AM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:

                                                          On
                                                          02/08/2013
                                                          12:51 AM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          Hi Justin,

                                                          I
                                                          have couple of
                                                          questions
                                                          related to
                                                          "valid"
                                                          parameter...

                                                          This
                                                          endpoint can
                                                          be invoked by
                                                          the Resource
                                                          Server in
                                                          runtime...

                                                          That's
                                                          correct. 

                                                          In
                                                          that case what
                                                          is exactly
                                                          meant by the
                                                          "resource_id"
                                                          in request ?

                                                          The
                                                          resource_id
                                                          field is a
                                                          service-specific
                                                          string that
                                                          basically lets
                                                          the resource
                                                          server provide
                                                          some context
                                                          to the request
                                                          to the auth
                                                          server. There
                                                          have been some
                                                          other
                                                          suggestions
                                                          like client IP
                                                          address, but I
                                                          wanted to put
                                                          this one in
                                                          because it
                                                          seemed to be a
                                                          common theme.
                                                          The client is
                                                          trying to do
                                                          *something*
                                                          with the
                                                          token, after
                                                          all, and the
                                                          rights,
                                                          permissions,
                                                          and metadata
                                                          associated
                                                          with the token
                                                          could change
                                                          based on that.
                                                          Since the
                                                          Introspection
                                                          endpoint is
                                                          all about
                                                          getting that
                                                          metadata back
                                                          to the PR,
                                                          this seemed
                                                          like a good
                                                          idea. 

                                                          IMO
                                                          a token to be
                                                          valid depends
                                                          on set of
                                                          criteria based
                                                          on it's type..

                                                          For
                                                          a Bearer
                                                          token..

                                                          1.
                                                          Token should
                                                          not be expired

                                                          2.
                                                          Token should
                                                          not be
                                                          revoked.

                                                          3.
                                                          The scope the
                                                          token issued
                                                          should match
                                                          with the scope
                                                          required for
                                                          the resource.

                                                          For
                                                          a MAC token...

                                                          1.
                                                          Token not
                                                          expired (mac
                                                          id)

                                                          2.
                                                          Token should
                                                          not be revoked

                                                          3.
                                                          The scope the
                                                          token issued
                                                          should match
                                                          with the scope
                                                          required for
                                                          the resource.

                                                          4.
                                                          HMAC check
                                                          should be
                                                          valid

                                                          There
                                                          are similar
                                                          conditions for
                                                          SAML bearer
                                                          too..

                                                          This
                                                          isn't really
                                                          true. The SAML
                                                          bearer token
                                                          is fully
                                                          self-contained
                                                          and doesn't
                                                          change based
                                                          on other
                                                          parameters in
                                                          the message,
                                                          unlike MAC.
                                                          Same with JWT.
                                                          When it hands
                                                          a SAML or JWT
                                                          token to the
                                                          AS, the PR has
                                                          given
                                                          *everything*
                                                          the server
                                                          needs to check
                                                          that token's
                                                          validity and
                                                          use. 

                                                          MAC signatures
                                                          change with
                                                          every message,
                                                          and they're
                                                          done across
                                                          several
                                                          components of
                                                          the HTTP
                                                          message.
                                                          Therefor, the
                                                          HMAC check for
                                                          MAC style
                                                          tokens will
                                                          still need to
                                                          be done by the
                                                          protected
                                                          resource.
                                                          Introspection
                                                          would help in
                                                          the case that
                                                          the signature
                                                          validated just
                                                          fine, but the
                                                          token might
                                                          have expired.
                                                          Or you need to
                                                          know what
                                                          scopes apply.
                                                          Introspection
                                                          isn't to fully
                                                          validate the
                                                          call to the
                                                          protected
                                                          resource -- if
                                                          that were the
                                                          case, the PR
                                                          would have to
                                                          send some kind
                                                          of
                                                          encapsulated
                                                          version of the
                                                          original
                                                          request.
                                                          Otherwise, the
                                                          AS won't have
                                                          all of the
                                                          information it
                                                          needs to check
                                                          the MAC.

                                                          I think what
                                                          you're
                                                          describing is
                                                          ultimately
                                                          *not* what the
                                                          introspection
                                                          endpoint is
                                                          intended to
                                                          do. If that's
                                                          unclear from
                                                          the document,
                                                          can you please
                                                          suggest text
                                                          that would
                                                          help clear the
                                                          use case up? I
                                                          wouldn't want
                                                          it to be
                                                          ambiguous.

                                                           -- Justin

                                                          Thanks
                                                          & regards,

                                                          -Prabath

                                                          On
                                                          Thu, Feb 7,
                                                          2013 at 10:30
                                                          PM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:

                                                          It
                                                          validates the
                                                          token, which
                                                          would be
                                                          either the
                                                          token itself
                                                          in the case of
                                                          Bearer or the
                                                          token "id"
                                                          part of
                                                          something more
                                                          complex like
                                                          MAC. It
                                                          doesn't
                                                          directly
                                                          validate the
                                                          usage of the
                                                          token, that's
                                                          still up to
                                                          the PR to do
                                                          that.

                                                          I nearly added
                                                          a "token type"
                                                          field in this
                                                          draft, but
                                                          held back
                                                          because there
                                                          are several
                                                          kinds of
                                                          "token type"
                                                          that people
                                                          talk about in
                                                          OAuth. First,
                                                          there's
                                                          "Bearer" vs.
                                                          "MAC" vs.
                                                          "HOK", or what
                                                          have you. Then
                                                          within Bearer
                                                          you have "JWT"
                                                          or "SAML" or
                                                          "unstructured
                                                          blob". Then
                                                          you've also
                                                          got "access"
                                                          vs. "refresh"
                                                          and other
                                                          flavors of
                                                          token, like
                                                          the id_token
                                                          in OpenID
                                                          Connect. 

                                                          Thing is, the
                                                          server running
                                                          the
                                                          introspection
                                                          endpoint will
                                                          probably know
                                                          *all* of
                                                          these. But
                                                          should it tell
                                                          the client? If
                                                          so, which of
                                                          the three, and
                                                          what names
                                                          should the
                                                          fields be?

                                                           -- Justin

                                                          On
                                                          02/07/2013
                                                          11:26 AM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          Okay..
                                                          I was thinking
                                                          this could be
                                                          used as a way
                                                          to validate
                                                          the token as
                                                          well. BTW even
                                                          in this case
                                                          shouldn't
                                                          communicate
                                                          the type of
                                                          token to AS?
                                                          For example in
                                                          the case of
                                                          SAML profile -
                                                          it could be
                                                          SAML token.. 

                                                          Thanks
                                                          & regards,

                                                          -Prabath

                                                          On
                                                          Thu, Feb 7,
                                                          2013 at 8:39
                                                          PM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:

                                                          "valid"
                                                          might not be
                                                          the best term,
                                                          but it's meant
                                                          to be a field
                                                          where the
                                                          server says
                                                          "yes this
                                                          token is still
                                                          good" or "no
                                                          this token
                                                          isn't good
                                                          anymore". We
                                                          could instead
                                                          do this with
                                                          HTTP codes or
                                                          something but
                                                          I went with a
                                                          pure JSON
                                                          response.

                                                           -- Justin

                                                          On
                                                          02/06/2013
                                                          10:47 PM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:

                                                          Hi
                                                          Justin, 

                                                          I
                                                          believe this
                                                          is addressing
                                                          one of the key
                                                          missing part
                                                          in OAuth
                                                          2.0...

                                                          One
                                                          question - I
                                                          guess this was
                                                          discussed
                                                          already...

                                                          In
                                                          the spec - in
                                                          the
                                                          introspection
                                                          response it
                                                          has the
                                                          attribute
                                                          "valid" - this
                                                          is basically
                                                          the validity
                                                          of the token
                                                          provided in
                                                          the request.

                                                          Validation criteria
                                                          depends on the
                                                          token and well
                                                          as token type
                                                          ( Bearer,
                                                          MAC..).

                                                          In
                                                          the spec it
                                                          seems like
                                                          it's coupled
                                                          with Bearer
                                                          token type...
                                                          But I guess,
                                                          by adding
                                                          "token_type"
                                                          to the request
                                                          we can remove
                                                          this
                                                          dependency.

                                                          WDYT..?

                                                          Thanks
                                                          & regards,

                                                          -Prabath 

                                                          On
                                                          Thu, Feb 7,
                                                          2013 at 12:54
                                                          AM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:

                                                          Updated
                                                          introspection
                                                          draft based on
                                                          recent
                                                          comments.
                                                          Changes
                                                          include:

                                                           - "scope"
                                                          return
                                                          parameter now
                                                          follows
                                                          RFC6749 format
                                                          instead of
                                                          JSON array

                                                           - "subject"
                                                          -> "sub",
                                                          and "audience"
                                                          -> "aud",
                                                          to be parallel
                                                          with JWT
                                                          claims

                                                           - clarified
                                                          what happens
                                                          if the
                                                          authentication
                                                          is bad

                                                           -- Justin

                                                          --------
                                                          Original
                                                          Message
                                                          -------- 
                                                          Subject: New Version =
Notification for =
draft-richer-oauth-introspection-02.txt
Date: =
Wed, 6 Feb 2013 11:24:20 =
-0800
From: <internet-drafts@ietf.org>
To: =
<jricher@mitre.org>

                                                          Subject: 

                                                          New
                                                          Version
                                                          Notification
                                                          for
                                                          draft-richer-oauth-introspection-02.txt

                                                          Date: 

                                                          Wed,
                                                          6 Feb 2013
                                                          11:24:20 -0800

                                                          From: 

                                                          <internet-drafts@ietf.org>

                                                          To: 

                                                          <jricher@mitre.org>

                                                          A new version of I-D, draft-richer-oauth-introspection-02.txt
                                                          has been successfully submitted by Justin Richer and posted to the
                                                          IETF repository.

                                                          Filename:       draft-richer-oauth-introspection
                                                          Revision:       02
                                                          Title:             OAuth Token Introspection
                                                          Creation date:       2013-02-06
                                                          WG ID:             Individual Submission
                                                          Number of pages: 6
                                                          URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt
                                                          Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
                                                          Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-02
                                                          Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02

                                                          Abstract:
                                                             This specification defines a method for a client or protected
                                                             resource to query an OAuth authorization server to determine meta-
                                                             information about an OAuth token.

                                                          The IETF Secretariat

_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

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

                                                          --

                                                          Thanks &
                                                          Regards,

                                                          Prabath 

                                                          Mobile
                                                          : +94 71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                                          --

                                                          Thanks &
                                                          Regards,

                                                          Prabath 

                                                          Mobile
                                                          : +94 71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                                          --

                                                          Thanks &
                                                          Regards,

                                                          Prabath 

                                                          Mobile
                                                          : +94 71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                                          --

                                                          Thanks &
                                                          Regards,

                                                          Prabath 

                                                          Mobile
                                                          : +94 71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                                          _______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

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

                                                          --

                                                          Thanks &
                                                          Regards,

                                                          Prabath 

                                                          Mobile
                                                          : +94 71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                                          --

                                                          Thanks &
                                                          Regards,

                                                          Prabath 

                                                          Mobile
                                                          : +94 71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                                      --

                                                        Thanks &
                                                        Regards,

                                                        Prabath 

                                                        Mobile
                                                          : +94 71 809 6732 

                                                          http://blog.facilelogin.com

                                                          http://RampartFAQ.com

                                              -- 

                                                Thanks & Regards,

                                                Prabath 

                                                Mobile
                                                  : +94 71 809 6732 

                                                  http://blog.facilelogin.com

                                                  http://RampartFAQ.com

                                  -- 

                                    Thanks & Regards,

                                    Prabath 

                                    Mobile : +94 71 809 6732 

                                      http://blog.facilelogin.com

                                      http://RampartFAQ.com

                      -- 

                        Thanks & Regards,

                        Prabath 

                        Mobile : +94 71 809 6732 

                          http://blog.facilelogin.com

                          http://RampartFAQ.com

            -- 

              Thanks & Regards,

              Prabath 

              Mobile : +94 71 809 6732 

                http://blog.facilelogin.com

                http://RampartFAQ.com

--------------040709040705020505060806--

From prabath@wso2.com  Thu Feb 14 13:33:31 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B17421F866F for ; Thu, 14 Feb 2013 13:33:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.894
X-Spam-Level: 
X-Spam-Status: No, score=-2.894 tagged_above=-999 required=5 tests=[AWL=0.082,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNFhYpg6vdnZ for ; Thu, 14 Feb 2013 13:33:28 -0800 (PST)
Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by ietfa.amsl.com (Postfix) with ESMTP id 259D321F8654 for ; Thu, 14 Feb 2013 13:33:26 -0800 (PST)
Received: by mail-ee0-f52.google.com with SMTP id b15so1356358eek.39 for ; Thu, 14 Feb 2013 13:33:26 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=r+ERsgxzTu8h9lsFxhRiO2sQgTbpymDNz5J0gvwiOWg=; b=cYRjO6iDxIwS9kBLzKpAk+TnMy1pL3CObGrJYFaTSt5JjyABSOAM191tE7GFOLG8KB +/WFJmO8AaVFQ+Lpl8KZ7gCdsfcbByroSytSFjfO5GnaBJr5ViC6FIXJIs100lP3dL5T L3kHEkHXow7XBRpjlWf8Wf5t2HbCAwxkstKFKBAMORUNuo/HPEFMDBZ2OgrITgAIIv/O 4myn0GpnTw+WaG44i2blTZOQg5Obq4MInfunWTdPPnplKHad1aMK2AGjX5w2qU/n+CSz GtBzwOFKvoeif3HQ1731GCo31JVmEJYpKMsziJfqjT4YYA/bUtFV/en/ITk8GxZwHNMx IxAA==
MIME-Version: 1.0
X-Received: by 10.14.194.198 with SMTP id m46mr699345een.8.1360877594287; Thu, 14 Feb 2013 13:33:14 -0800 (PST)
Received: by 10.223.37.77 with HTTP; Thu, 14 Feb 2013 13:33:13 -0800 (PST)
In-Reply-To: <511D55C5.4080503@mitre.org>
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com>  <51196777.6000502@mitre.org>   <511A5062.5010108@mitre.org>   <511CEEAA.3030801@mitre.org>   <511CF3EF.8040008@mitre.org>  <511CF4AB.5010700@mitre.org>  <511CF8C5.70301@mitre.org>  <511D0DC3.7000607@mitre.org> <00ef01ce0af8$ed591ad0$c80b5070$@reminetworks.com> <511D55C5.4080503@mitre.org>
Date: Fri, 15 Feb 2013 03:03:13 +0530
Message-ID: 
From: Prabath Siriwardena 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=047d7b343a9e971d2f04d5b601ea
X-Gm-Message-State: ALoCoQlEH4AvdBHEhQ2DtkpkfKbul6y9IEvoaaErrxdyHJVyfDelG4jD3tVJeDPmMU6vB+8TVddn
Cc: Donald F Coffin , oauth@ietf.org
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2013 21:33:31 -0000

--047d7b343a9e971d2f04d5b601ea
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

+1 for active.

Thanks & regards,
-Prabath

On Fri, Feb 15, 2013 at 2:53 AM, Justin Richer  wrote:

>  That could work for me. Anyone else?
>
>  -- Justin
>
> On 02/14/2013 04:19 PM, Donald F Coffin wrote:
>
>  Does the term =93Active=94 help clarify the meaning but still confirm to
> your intention, Justin?****
>
> ** **
>
> Best regards,****
>
> Don****
>
> Donald F. Coffin****
>
> Founder/CTO****
>
> ** **
>
> REMI Networks****
>
> 22751 El Prado Suite 6216****
>
> Rancho Santa Margarita, CA  92688-3836****
>
> ** **
>
> Phone:      (949) 636-8571****
>
> Email:       donald.coffin@reminetworks.com****
>
> ** **
>
> *From:* Justin Richer [mailto:jricher@mitre.org ]
> *Sent:* Thursday, February 14, 2013 8:16 AM
> *To:* Prabath Siriwardena
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Fwd: New Version Notification for
> draft-richer-oauth-introspection-02.txt****
>
> ** **
>
> That much I can at least do. I'd be happy with another term if there was =
a
> good one we could drop in its place without changing the intended semanti=
cs.
>
>  -- Justin****
>
> On 02/14/2013 10:57 AM, Prabath Siriwardena wrote:****
>
> Not quite convinced :-) Valid has a meaning attached to that.. ****
>
> ** **
>
> In case we are going ahead with this please define it clearly in the draf=
t
> - with the one you shared in this thread.****
>
> ** **
>
> Thanks & regards,****
>
> -Prabath****
>
> On Thu, Feb 14, 2013 at 8:16 PM, Justin Richer  wrote:=
*
> ***
>
> ** **
>
> On 02/14/2013 09:37 AM, Prabath Siriwardena wrote:****
>
>  The definition of valid is bit ambiguous in the draft...****
>
> ** **
>
> Okay.. If that is the definition... and if we beak that in to parts...***=
*
>
> ** **
>
> "it hasn't expired" : In the response it self we have parameter for
> issued_at and and expires_at - so whether the token is not expired or not
> can even be derived at the requestor's end.****
>
> ** **
>
> If the token isn't good anymore, it doesn't matter when it was issued or
> when it was expired, just that it has. ****
>
>
>
>
> ****
>
> ** **
>
> "token was issued from here" : For this IMO we need to send an error code=
.
> Requestor has picked the wrong AS.****
>
> We don't know if it came from another AS or if someone's just making
> things up. Either way it's not a good token. ****
>
>
>
>
> ****
>
> ** **
>
> The remaining is  "revoked".. That is why I proposed earlier - we better
> have an attribute "revoked" - instead of "valid" in the response..****
>
> ** **
>
> The end result of all three is the same: either the token is good, or it
> isn't. I think it's much simpler and more useful to leave it at that.
>
>  -- Justin ****
>
>
>
>
> ****
>
> ** **
>
> WDYT...?****
>
> ** **
>
> Thanks & regards,****
>
> -Prabath****
>
> ** **
>
> ** **
>
> On Thu, Feb 14, 2013 at 7:58 PM, Justin Richer  wrote:=
*
> ***
>
> Because it will be the one that issued the token in the first place.
>
> Validity means "token was issued from here, it hasn't been revoked, it
> hasn't expired".
>
>  -- Justin ****
>
> ** **
>
> On 02/14/2013 09:28 AM, Prabath Siriwardena wrote:****
>
> Okay. With out knowing the type of the token how can the AS validate the
> token ? What is meant by the validity there? ****
>
> ** **
>
> Thanks & regards,****
>
> -Prabath****
>
> On Thu, Feb 14, 2013 at 7:55 PM, Justin Richer  wrote:=
*
> ***
>
> OK, I don't see the utility in that at all. What would it accomplish?
>
>  -- Justin ****
>
> ** **
>
> On 02/14/2013 09:25 AM, Prabath Siriwardena wrote:****
>
> To make it clear - my suggestion is to add token_type_hint to the
> introspection request. It can be from client to AS or from RS to AS. ****
>
> ** **
>
> Then AS can decide whether the provided token is valid or not and include
> "valid" attribute in the introspection response.****
>
> ** **
>
> Thanks & regards,****
>
> -Prabath****
>
> On Thu, Feb 14, 2013 at 7:52 PM, Prabath Siriwardena 
> wrote:****
>
> Both the client and the resource owner should be aware of the token type.
> ****
>
> ** **
>
> My argument is, if the authorization server to decide whether the token i=
s
> valid or not ( irrespective of who asked the question) - AS needs to know
> the token type - because to validate a token AS should know the token typ=
e.
> ****
>
> ** **
>
> The token type could be, bearer or MAC or any other token type.****
>
> ** **
>
> Thanks & regards,****
>
> -Prabath ****
>
> ** **
>
> On Thu, Feb 14, 2013 at 7:33 PM, Justin Richer  wrote:=
*
> ***
>
> What exactly are you suggesting be added to introspection? The
> "token_type_hint" is from the client to the server, but what you've asked
> for in terms of "token type" is from the server to the client. And there
> was never an answer to what exactly is meant by "token type" in this case=
,
> particularly because you seem to want to call out things like SAML and
> Bearer as separate types.
>
>  -- Justin ****
>
>
>
> ****
>
> On 02/14/2013 06:59 AM, Prabath Siriwardena wrote:****
>
> I noticed that the latest Token Revocation draft [1] has introduced the
> parameter "token_type_hint". I would suggest the same here, as that would
> make what is meant by "valid" much clear.. ****
>
> ** **
>
> [1]: http://tools.ietf.org/html/draft-ietf-oauth-revocation-05****
>
> ** **
>
> Thanks & regards,****
>
> -Prabath****
>
> On Tue, Feb 12, 2013 at 9:35 PM, Prabath Siriwardena 
> wrote:****
>
> Hi Justin, ****
>
> ** **
>
> I doubt whether valid_token would make a difference..?****
>
> ** **
>
> My initial argument is what is the validation criteria..? Validation
> criteria depends on the token_type..****
>
> ** **
>
> If we are talking only about metadata - then I believe "revoked",
> "expired" would be more meaningful..****
>
> ** **
>
> Thanks & regards,****
>
> -Prabath ****
>
> ** **
>
> On Tue, Feb 12, 2013 at 7:53 PM, Justin Richer  wrote:=
*
> ***
>
> OK, I can see the wisdom in changing this term.
>
> I picked "valid" because I wanted a simple "boolean" value that would
> require no additional parsing or string-matching on the client's behalf,
> and I'd like to stick with that. OAuth is built with the assumption that
> clients need to be able to recover from invalid tokens at any stage, so I
> think a simple yes/no is the right step here.
>
> That said, I think you're both right that "valid" seems to have caused a
> bit of confusion. I don't want to go with "revoked" because I'd rather ha=
ve
> the "token is OK" be the positive boolean value.
>
> Would "valid_token" be more clear? Or do we need a different adjective al=
l
> together?
>
>  -- Justin ****
>
> ** **
>
> On 02/11/2013 08:02 PM, Richard Harrington wrote:****
>
>  Have you considered "status" instead of "valid"?  It could have values
> like "active", "expired", and "revoked".****
>
> ** **
>
> Is it worthwhile including the status of the client also?  For example, a
> client application could be disabled, temporarily or permanently, and thu=
s
> disabling its access tokens as well.****
>
> ** **
>
>
> On Feb 11, 2013, at 1:56 PM, Prabath Siriwardena  wrote=
:
> ****
>
>  I guess confusion is with 'valid' parameter is in the response.. ****
>
> ** **
>
> I thought this will be helpful to standardize the communication between
> Resource Server and the Authorization Server..****
>
> ** **
>
> I would suggest we completely remove "valid" from the response - or defin=
e
> it much clearly..****
>
> ** **
>
> May be can add "revoked" with a boolean attribute..****
>
> ** **
>
> Thanks & regards,****
>
> -Prabath****
>
> On Tue, Feb 12, 2013 at 3:19 AM, Justin Richer  wrote:=
*
> ***
>
> ** **
>
> On 02/08/2013 12:51 AM, Prabath Siriwardena wrote:****
>
> Hi Justin, ****
>
> ** **
>
> I have couple of questions related to "valid" parameter...****
>
> ** **
>
> This endpoint can be invoked by the Resource Server in runtime...****
>
>
> That's correct. ****
>
>
>
>
> ****
>
> ** **
>
> In that case what is exactly meant by the "resource_id" in request ?****
>
> ** **
>
> The resource_id field is a service-specific string that basically lets th=
e
> resource server provide some context to the request to the auth server.
> There have been some other suggestions like client IP address, but I want=
ed
> to put this one in because it seemed to be a common theme. The client is
> trying to do *something* with the token, after all, and the rights,
> permissions, and metadata associated with the token could change based on
> that. Since the Introspection endpoint is all about getting that metadata
> back to the PR, this seemed like a good idea. ****
>
>
>
>
> ****
>
> ** **
>
> IMO a token to be valid depends on set of criteria based on it's type..**=
*
> *
>
> ** **
>
> For a Bearer token..****
>
> ** **
>
> 1. Token should not be expired****
>
> 2. Token should not be revoked.****
>
> 3. The scope the token issued should match with the scope required for th=
e
> resource.****
>
> ** **
>
> For a MAC token...****
>
> ** **
>
> 1. Token not expired (mac id)****
>
> 2. Token should not be revoked****
>
> 3. The scope the token issued should match with the scope required for th=
e
> resource.****
>
> 4. HMAC check should be valid****
>
> ** **
>
> There are similar conditions for SAML bearer too..****
>
> ** **
>
> This isn't really true. The SAML bearer token is fully self-contained and
> doesn't change based on other parameters in the message, unlike MAC. Same
> with JWT. When it hands a SAML or JWT token to the AS, the PR has given
> *everything* the server needs to check that token's validity and use.
>
> MAC signatures change with every message, and they're done across several
> components of the HTTP message. Therefor, the HMAC check for MAC style
> tokens will still need to be done by the protected resource. Introspectio=
n
> would help in the case that the signature validated just fine, but the
> token might have expired. Or you need to know what scopes apply.
> Introspection isn't to fully validate the call to the protected resource =
--
> if that were the case, the PR would have to send some kind of encapsulate=
d
> version of the original request. Otherwise, the AS won't have all of the
> information it needs to check the MAC.
>
>
> I think what you're describing is ultimately *not* what the introspection
> endpoint is intended to do. If that's unclear from the document, can you
> please suggest text that would help clear the use case up? I wouldn't wan=
t
> it to be ambiguous.
>
>  -- Justin ****
>
>
>
>
> ****
>
> ** **
>
> Thanks & regards,****
>
> -Prabath****
>
> ** **
>
> ** **
>
> On Thu, Feb 7, 2013 at 10:30 PM, Justin Richer  wrote:=
*
> ***
>
> It validates the token, which would be either the token itself in the cas=
e
> of Bearer or the token "id" part of something more complex like MAC. It
> doesn't directly validate the usage of the token, that's still up to the =
PR
> to do that.
>
> I nearly added a "token type" field in this draft, but held back because
> there are several kinds of "token type" that people talk about in OAuth.
> First, there's "Bearer" vs. "MAC" vs. "HOK", or what have you. Then withi=
n
> Bearer you have "JWT" or "SAML" or "unstructured blob". Then you've also
> got "access" vs. "refresh" and other flavors of token, like the id_token =
in
> OpenID Connect.
>
> Thing is, the server running the introspection endpoint will probably kno=
w
> *all* of these. But should it tell the client? If so, which of the three,
> and what names should the fields be?
>
>  -- Justin ****
>
> ** **
>
> On 02/07/2013 11:26 AM, Prabath Siriwardena wrote:****
>
> Okay.. I was thinking this could be used as a way to validate the token a=
s
> well. BTW even in this case shouldn't communicate the type of token to AS=
?
> For example in the case of SAML profile - it could be SAML token.. ****
>
> ** **
>
> Thanks & regards,****
>
> -Prabath****
>
> On Thu, Feb 7, 2013 at 8:39 PM, Justin Richer  wrote:*=
*
> **
>
> "valid" might not be the best term, but it's meant to be a field where th=
e
> server says "yes this token is still good" or "no this token isn't good
> anymore". We could instead do this with HTTP codes or something but I wen=
t
> with a pure JSON response.
>
>  -- Justin ****
>
> ** **
>
> On 02/06/2013 10:47 PM, Prabath Siriwardena wrote:****
>
> Hi Justin, ****
>
> ** **
>
> I believe this is addressing one of the key missing part in OAuth 2.0...*=
*
> **
>
> ** **
>
> One question - I guess this was discussed already...****
>
> ** **
>
> In the spec - in the introspection response it has the attribute "valid" =
-
> this is basically the validity of the token provided in the request.****
>
> ** **
>
> Validation criteria depends on the token and well as token type ( Bearer,
> MAC..).****
>
> ** **
>
> In the spec it seems like it's coupled with Bearer token type... But I
> guess, by adding "token_type" to the request we can remove this dependenc=
y.
> ****
>
> ** **
>
> WDYT..?****
>
> ** **
>
> Thanks & regards,****
>
> -Prabath ****
>
> ** **
>
> On Thu, Feb 7, 2013 at 12:54 AM, Justin Richer  wrote:=
*
> ***
>
> Updated introspection draft based on recent comments. Changes include:
>
>  - "scope" return parameter now follows RFC6749 format instead of JSON
> array
>  - "subject" -> "sub", and "audience" -> "aud", to be parallel with JWT
> claims
>  - clarified what happens if the authentication is bad
>
>  -- Justin****
>
>
>
> -------- Original Message -------- ****
>
> *Subject: *
>
> New Version Notification for draft-richer-oauth-introspection-02.txt****
>
> *Date: *
>
> Wed, 6 Feb 2013 11:24:20 -0800****
>
> *From: *
>
>  ****
>
> *To: *
>
>  ****
>
> ** **
>
> A new version of I-D, draft-richer-oauth-introspection-02.txt****
>
> has been successfully submitted by Justin Richer and posted to the****
>
> IETF repository.****
>
> ** **
>
> Filename:       draft-richer-oauth-introspection****
>
> Revision:       02****
>
> Title:             OAuth Token Introspection****
>
> Creation date:       2013-02-06****
>
> WG ID:             Individual Submission****
>
> Number of pages: 6****
>
> URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-i=
ntrospection-02.txt****
>
> Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-intro=
spection****
>
> Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspect=
ion-02****
>
> Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-richer-oauth-in=
trospection-02****
>
> ** **
>
> Abstract:****
>
>    This specification defines a method for a client or protected****
>
>    resource to query an OAuth authorization server to determine meta-****
>
>    information about an OAuth token.****
>
> ** **
>
> ** **
>
>                                                                          =
         ****
>
> ** **
>
> ** **
>
> The IETF Secretariat****
>
> ** **
>
> ** **
>
> ** **
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth****
>
>
>
> ****
>
> ** **
>
> --
> Thanks & Regards,
> Prabath ****
>
> ** **
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com****
>
> ** **
>
>
>
> ****
>
> ** **
>
> --
> Thanks & Regards,
> Prabath ****
>
> ** **
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com****
>
> ** **
>
>
>
> ****
>
> ** **
>
> --
> Thanks & Regards,
> Prabath ****
>
> ** **
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com****
>
> ** **
>
>
>
> ****
>
> ** **
>
> --
> Thanks & Regards,
> Prabath ****
>
> ** **
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com****
>
>  _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth****
>
>  ** **
>
>
>
> ****
>
> ** **
>
> --
> Thanks & Regards,
> Prabath ****
>
> ** **
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com****
>
>
>
> ****
>
> ** **
>
> --
> Thanks & Regards,
> Prabath ****
>
> ** **
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com****
>
> ** **
>
>
>
> ****
>
> ** **
>
> --
> Thanks & Regards,
> Prabath ****
>
> ** **
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com****
>
>
>
> ****
>
> ** **
>
> --
> Thanks & Regards,
> Prabath ****
>
> ** **
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com****
>
> ** **
>
>
>
> ****
>
> ** **
>
> --
> Thanks & Regards,
> Prabath ****
>
> ** **
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com****
>
> ** **
>
>
>
> ****
>
> ** **
>
> --
> Thanks & Regards,
> Prabath ****
>
> ** **
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com****
>
> ** **
>
>
>
> ****
>
> ** **
>
> --
> Thanks & Regards,
> Prabath ****
>
> ** **
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com****
>
> ** **
>
>
>

--=20
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.com

--047d7b343a9e971d2f04d5b601ea
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

+1 for active.
Thanks & regards,
-Prabath<=
br>
On Fri, Feb 15, 2013 at 2:53 AM, Justin R=
icher <jricher@mitre.org> wrote:

 =20
   =20
 =20

    That could work for me. Anyone else?

    =A0-- Justin

    On 02/14/2013 04:19 PM, Donald F Coffin
      wrote:

     =20
     =20
     =20

        Does
            the term =93Active=94 help clarify the meaning but still confir=
m
            to your intention, Justin?
        =A0

          Best
              regards,
          Don
          Donald
              F. Coffin
          Founder/CTO
          =A0
          REMI
              Networks
          22751
              El Prado Suite 6216
          Rancho
              Santa Margarita, CA=A0 92688-3836
          =A0
          Phone:=A0=A0=A0=A0=A0
              (949) 636-8571
          Email:=A0=A0=A0=A0=A0=A0
              donald.coffin@reminetworks.com=

        =A0

            From:
                Justin Richer [mailto:jricher@mitre.org] 

                Sent: Thursday, February 14, 2013 8:16 AM

                To: Prabath Siriwardena

                Cc: oauth@ietf.org

                Subject: Re: [OAUTH-WG] Fwd: New Version
                Notification for draft-richer-oauth-introspection-02.txt=

        =A0
        That much I
          can at least do. I'd be happy with another term if there was =
a
          good one we could drop in its place without changing the
          intended semantics.

          =A0-- Justin

          On 02/14/2013 10:57 AM, Prabath
            Siriwardena wrote:

          Not quite convinced :-) Valid has a
            meaning attached to that.. 

            =A0

            In case we are going ahead with this
              please define it clearly in the draft - with the one you
              shared in this thread.

            =A0

            Thanks & regards,

            -Prabath<=
u>

              On Thu, Feb 14, 2013 at 8:16 PM,
                Justin Richer <jricher@mitre.org>
                wrote:

                  =A0

                    On 02/14/2013 09:37 AM, Prabath
                      Siriwardena wrote:

                      The definition of valid is
                        bit ambiguous=A0in the draft...

                      =A0

                      Okay.. If that is the
                        definition... and if we beak that in to parts...=

                      =A0

                      "it hasn't expired&qu=
ot; : In the
                        response it self we have parameter for issued_at
                        and and expires_at - so whether the token is not
                        expired or not can even be derived at the
                        requestor's end.

                  =A0

                If the token isn't good anymore,=
 it
                  doesn't matter when it was issued or when it was
                  expired, just that it has. 

                    =A0

                    "token was issued from here=
" :
                      For this IMO we need to send an error code.
                      Requestor has picked the wrong AS.

                We don't know if it came from
                  another AS or if someone's just making things up.
                  Either way it's not a good token. 

                    =A0

                    The remaining is =A0"revoke=
d"..
                      That is why I proposed=A0earlier=A0- we better have a=
n
                      attribute "revoked" - instead of "vali=
d" in the
                      response..

                  =A0

                The end result of all three is the
                  same: either the token is good, or it isn't. I think
                  it's much simpler and more useful to leave it at that=
.

                    =A0-- Justin 

                      =A0

                      WDYT...?

                      =A0

                      Thanks & regards,

                      -Prabath

                      =A0

                      =A0

                        On Thu, Feb 14, 2013 at
                          7:58 PM, Justin Richer <jricher@mitre.org>
                          wrote:

                          Because it will be the
                            one that issued the token in the first
                            place. 

                            Validity means "token was issued from here=
,
                            it hasn't been revoked, it hasn't expir=
ed".

                              =A0-- Justin 

                              =A0

                                On 02/14/2013 09:28
                                  AM, Prabath Siriwardena wrote:<=
/u>

                                Okay. With out
                                  knowing the type of the token how can
                                  the AS validate the token ? What is
                                  meant by the validity there? 

                                  =A0<=
/p>

                                  Thanks &
                                    regards,

                                  -Prabath

                                    On Thu, Feb 14,
                                      2013 at 7:55 PM, Justin Richer
                                      <jricher@mitre.org>
                                      wrote:

                                      OK, I don'=
t
                                        see the utility in that at all.
                                        What would it accomplish?

                                          =A0-- Justin 

                                          =A0

                                            On
                                              02/14/2013 09:25 AM,
                                              Prabath Siriwardena wrote:=

                                            To make
                                              it clear - my suggestion
                                              is to add token_type_hint
                                              to the introspection
                                              request. It can be from
                                              client to AS or from RS to
                                              AS. 

                                              =A0

                                              Then
                                                AS can decide whether
                                                the provided token is
                                                valid or not and include
                                                "valid" attribute=
 in the
                                                introspection response.<=
/u>

                                              =A0

                                              Thanks
                                                & regards,

                                              -Prabath

                                                On
                                                  Thu, Feb 14, 2013 at
                                                  7:52 PM, Prabath
                                                  Siriwardena <prabath@wso2.com>
                                                  wrote:
                                                Both
                                                  the client and the
                                                  resource owner should
                                                  be aware of the token
                                                  type. 

                                                  =A0

                                                  My
                                                    argument is, if the
                                                    authorization server
                                                    to decide whether
                                                    the token is valid
                                                    or not (
                                                    irrespective of who
                                                    asked the question)
                                                    - AS needs to know
                                                    the token type -
                                                    because to validate
                                                    a token AS should
                                                    know the token type.=

                                                  =A0

                                                  Th=
e
                                                    token type could be,
                                                    bearer or MAC or any
                                                    other token type.

                                                  =A0

                                                  Th=
anks
                                                    & regards,

                                                  -P=
rabath

                                                      =A0

                                                        On
                                                          Thu, Feb 14,
                                                          2013 at 7:33
                                                          PM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:<=
/u>

                                                          What
                                                          exactly are
                                                          you suggesting
                                                          be added to
                                                          introspection?
                                                          The
                                                          "token_type_=
hint"
                                                          is from the
                                                          client to the
                                                          server, but
                                                          what you've
                                                          asked for in
                                                          terms of
                                                          "token type&=
quot;
                                                          is from the
                                                          server to the
                                                          client. And
                                                          there was
                                                          never an
                                                          answer to what
                                                          exactly is
                                                          meant by
                                                          "token type&=
quot;
                                                          in this case,
                                                          particularly
                                                          because you
                                                          seem to want
                                                          to call out
                                                          things like
                                                          SAML and
                                                          Bearer as
                                                          separate
                                                          types. 

                                                          =A0-- Justin

                                                          On
                                                          02/14/2013
                                                          06:59 AM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:<=
/u>

                                                          I
                                                          noticed that
                                                          the latest
                                                          Token
                                                          Revocation
                                                          draft [1] has
                                                          introduced the
                                                          parameter
                                                          "token_type_=
hint".
                                                          I would
                                                          suggest the
                                                          same here, as
                                                          that would
                                                          make what is
                                                          meant by
                                                          "valid"=
 much
                                                          clear.. 

                                                          =A0

                                                          [1]:=A0http://tools.ietf.org/htm=
l/draft-ietf-oauth-revocation-05

                                                          =A0

                                                          Thanks
                                                          & regards,=

                                                          -Prabath

                                                          On
                                                          Tue, Feb 12,
                                                          2013 at 9:35
                                                          PM, Prabath
                                                          Siriwardena
                                                          <prabath@wso2.com>
                                                          wrote:<=
/u>

                                                          Hi
                                                          Justin, 

                                                          =A0

                                                          I
                                                          doubt whether
                                                          valid_token
                                                          would make a
                                                          difference..?<=
/u>

                                                          =A0

                                                          My
                                                          initial
                                                          argument is
                                                          what is the
                                                          validation
                                                          criteria..?
                                                          Validation
                                                          criteria
                                                          depends on the
                                                          token_type..

                                                          =A0

                                                          If
                                                          we are talking
                                                          only about
                                                          metadata -
                                                          then I believe
                                                          "revoked&quo=
t;,
                                                          "expired&quo=
t;
                                                          would be more
                                                          meaningful..

                                                          =A0

                                                          Thanks
                                                          & regards,=

                                                          -Prabath

                                                          =A0

                                                          On
                                                          Tue, Feb 12,
                                                          2013 at 7:53
                                                          PM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:<=
/u>

                                                          OK,
                                                          I can see the
                                                          wisdom in
                                                          changing this
                                                          term. 

                                                          I picked
                                                          "valid"
                                                          because I
                                                          wanted a
                                                          simple
                                                          "boolean&quo=
t;
                                                          value that
                                                          would require
                                                          no additional
                                                          parsing or
                                                          string-matching
                                                          on the
                                                          client's
                                                          behalf, and
                                                          I'd like to
                                                          stick with
                                                          that. OAuth is
                                                          built with the
                                                          assumption
                                                          that clients
                                                          need to be
                                                          able to
                                                          recover from
                                                          invalid tokens
                                                          at any stage,
                                                          so I think a
                                                          simple yes/no
                                                          is the right
                                                          step here. 

                                                          That said, I
                                                          think you're
                                                          both right
                                                          that "valid&=
quot;
                                                          seems to have
                                                          caused a bit
                                                          of confusion.
                                                          I don't want
                                                          to go with
                                                          "revoked&quo=
t;
                                                          because I'd
                                                          rather have
                                                          the "token i=
s
                                                          OK" be the
                                                          positive
                                                          boolean value.

                                                          Would
                                                          "valid_token=
"
                                                          be more clear?
                                                          Or do we need
                                                          a different
                                                          adjective all
                                                          together?

                                                          =A0-- Justin

                                                          =A0

                                                          On
                                                          02/11/2013
                                                          08:02 PM,
                                                          Richard
                                                          Harrington
                                                          wrote:<=
/u>

                                                          Have
                                                          you considered
                                                          "status"=
;
                                                          instead of
                                                          "valid"=
? =A0It
                                                          could have
                                                          values like
                                                          "active"=
;,
                                                          "expired&quo=
t;, and
                                                          "revoked&quo=
t;.

                                                          =A0

                                                          Is
                                                          it worthwhile
                                                          including the
                                                          status of the
                                                          client also?
                                                          =A0For example,
                                                          a client
                                                          application
                                                          could be
                                                          disabled,
                                                          temporarily or
                                                          permanently,
                                                          and thus
                                                          disabling its
                                                          access tokens
                                                          as well.

                                                          =A0

                                                          On Feb 11,
                                                          2013, at 1:56
                                                          PM, Prabath
                                                          Siriwardena
                                                          <prabath@wso2.com>
                                                          wrote:<=
/u>

                                                          I
                                                          guess
                                                          confusion is
                                                          with 'valid&#=
39;
                                                          parameter is
                                                          in the
                                                          response.. 

                                                          =A0

                                                          I
                                                          thought this
                                                          will be
                                                          helpful
                                                          to=A0standardize=
=A0the
                                                          communication
                                                          between
                                                          Resource
                                                          Server and the
                                                          Authorization
                                                          Server..

                                                          =A0

                                                          I
                                                          would suggest
                                                          we completely
                                                          remove "vali=
d"
                                                          from the
                                                          response - or
                                                          define it much
                                                          clearly..<=
u>

                                                          =A0

                                                          May
                                                          be can add
                                                          "revoked&quo=
t; with
                                                          a boolean
                                                          attribute..

                                                          =A0

                                                          Thanks
                                                          & regards,=

                                                          -Prabath

                                                          On
                                                          Tue, Feb 12,
                                                          2013 at 3:19
                                                          AM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:<=
/u>

                                                          =A0

                                                          On
                                                          02/08/2013
                                                          12:51 AM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:<=
/u>

                                                          Hi=A0Justin,

                                                          =A0

                                                          I
                                                          have couple of
                                                          questions
                                                          related to
                                                          "valid"
                                                          parameter...

                                                          =A0

                                                          This
                                                          endpoint can
                                                          be invoked by
                                                          the Resource
                                                          Server in
                                                          runtime...=

                                                          That's
                                                          correct. <=
u>

                                                          =A0

                                                          In
                                                          that case what
                                                          is exactly
                                                          meant by the
                                                          "resource_id=
"
                                                          in request ?

                                                          =A0

                                                          The
                                                          resource_id
                                                          field is a
                                                          service-specific
                                                          string that
                                                          basically lets
                                                          the resource
                                                          server provide
                                                          some context
                                                          to the request
                                                          to the auth
                                                          server. There
                                                          have been some
                                                          other
                                                          suggestions
                                                          like client IP
                                                          address, but I
                                                          wanted to put
                                                          this one in
                                                          because it
                                                          seemed to be a
                                                          common theme.
                                                          The client is
                                                          trying to do
                                                          *something*
                                                          with the
                                                          token, after
                                                          all, and the
                                                          rights,
                                                          permissions,
                                                          and metadata
                                                          associated
                                                          with the token
                                                          could change
                                                          based on that.
                                                          Since the
                                                          Introspection
                                                          endpoint is
                                                          all about
                                                          getting that
                                                          metadata back
                                                          to the PR,
                                                          this seemed
                                                          like a good
                                                          idea. <=
/u>

                                                          =A0

                                                          IMO
                                                          a token to be
                                                          valid depends
                                                          on set of
                                                          criteria based
                                                          on it's type.=
.

                                                          =A0

                                                          For
                                                          a Bearer
                                                          token..=

                                                          =A0

                                                          1.
                                                          Token should
                                                          not be expired=

                                                          2.
                                                          Token should
                                                          not be
                                                          revoked.

                                                          3.
                                                          The scope the
                                                          token issued
                                                          should match
                                                          with the scope
                                                          required for
                                                          the resource.<=
/u>

                                                          =A0

                                                          For
                                                          a MAC token...=

                                                          =A0

                                                          1.
                                                          Token not
                                                          expired (mac
                                                          id)=

                                                          2.
                                                          Token should
                                                          not be revoked=

                                                          3.
                                                          The scope the
                                                          token issued
                                                          should match
                                                          with the scope
                                                          required for
                                                          the resource.<=
/u>

                                                          4.
                                                          HMAC check
                                                          should be
                                                          valid

                                                          =A0

                                                          There
                                                          are similar
                                                          conditions for
                                                          SAML bearer
                                                          too..

                                                          =A0

                                                          This
                                                          isn't really
                                                          true. The SAML
                                                          bearer token
                                                          is fully
                                                          self-contained
                                                          and doesn't
                                                          change based
                                                          on other
                                                          parameters in
                                                          the message,
                                                          unlike MAC.
                                                          Same with JWT.
                                                          When it hands
                                                          a SAML or JWT
                                                          token to the
                                                          AS, the PR has
                                                          given
                                                          *everything*
                                                          the server
                                                          needs to check
                                                          that token's
                                                          validity and
                                                          use. 

                                                          MAC signatures
                                                          change with
                                                          every message,
                                                          and they're
                                                          done across
                                                          several
                                                          components of
                                                          the HTTP
                                                          message.
                                                          Therefor, the
                                                          HMAC check for
                                                          MAC style
                                                          tokens will
                                                          still need to
                                                          be done by the
                                                          protected
                                                          resource.
                                                          Introspection
                                                          would help in
                                                          the case that
                                                          the signature
                                                          validated just
                                                          fine, but the
                                                          token might
                                                          have expired.
                                                          Or you need to
                                                          know what
                                                          scopes apply.
                                                          Introspection
                                                          isn't to full=
y
                                                          validate the
                                                          call to the
                                                          protected
                                                          resource -- if
                                                          that were the
                                                          case, the PR
                                                          would have to
                                                          send some kind
                                                          of
                                                          encapsulated
                                                          version of the
                                                          original
                                                          request.
                                                          Otherwise, the
                                                          AS won't have
                                                          all of the
                                                          information it
                                                          needs to check
                                                          the MAC.

                                                          I think what
                                                          you're
                                                          describing is
                                                          ultimately
                                                          *not* what the
                                                          introspection
                                                          endpoint is
                                                          intended to
                                                          do. If that's
                                                          unclear from
                                                          the document,
                                                          can you please
                                                          suggest text
                                                          that would
                                                          help clear the
                                                          use case up? I
                                                          wouldn't want
                                                          it to be
                                                          ambiguous.

                                                          =A0-- Justin

                                                          =A0

                                                          Thanks
                                                          & regards,=

                                                          -Prabath

                                                          =A0

                                                          =A0

                                                          On
                                                          Thu, Feb 7,
                                                          2013 at 10:30
                                                          PM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:<=
/u>

                                                          It
                                                          validates the
                                                          token, which
                                                          would be
                                                          either the
                                                          token itself
                                                          in the case of
                                                          Bearer or the
                                                          token "id&qu=
ot;
                                                          part of
                                                          something more
                                                          complex like
                                                          MAC. It
                                                          doesn't
                                                          directly
                                                          validate the
                                                          usage of the
                                                          token, that's
                                                          still up to
                                                          the PR to do
                                                          that.

                                                          I nearly added
                                                          a "token typ=
e"
                                                          field in this
                                                          draft, but
                                                          held back
                                                          because there
                                                          are several
                                                          kinds of
                                                          "token type&=
quot;
                                                          that people
                                                          talk about in
                                                          OAuth. First,
                                                          there's
                                                          "Bearer"=
; vs.
                                                          "MAC" v=
s.
                                                          "HOK", =
or what
                                                          have you. Then
                                                          within Bearer
                                                          you have "JW=
T"
                                                          or "SAML&quo=
t; or
                                                          "unstructure=
d
                                                          blob". Then
                                                          you've also
                                                          got "access&=
quot;
                                                          vs. "refresh=
"
                                                          and other
                                                          flavors of
                                                          token, like
                                                          the id_token
                                                          in OpenID
                                                          Connect. 

                                                          Thing is, the
                                                          server running
                                                          the
                                                          introspection
                                                          endpoint will
                                                          probably know
                                                          *all* of
                                                          these. But
                                                          should it tell
                                                          the client? If
                                                          so, which of
                                                          the three, and
                                                          what names
                                                          should the
                                                          fields be?

                                                          =A0-- Justin

                                                          =A0

                                                          On
                                                          02/07/2013
                                                          11:26 AM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:<=
/u>

                                                          Okay..
                                                          I was thinking
                                                          this could be
                                                          used as a way
                                                          to validate
                                                          the token as
                                                          well. BTW even
                                                          in this case
                                                          shouldn't
                                                          communicate
                                                          the type of
                                                          token to AS?
                                                          For example in
                                                          the case of
                                                          SAML profile -
                                                          it could be
                                                          SAML token.. <=
/u>

                                                          =A0

                                                          Thanks
                                                          & regards,=

                                                          -Prabath

                                                          On
                                                          Thu, Feb 7,
                                                          2013 at 8:39
                                                          PM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:<=
/u>

                                                          "valid"
                                                          might not be
                                                          the best term,
                                                          but it's mean=
t
                                                          to be a field
                                                          where the
                                                          server says
                                                          "yes this
                                                          token is still
                                                          good" or &qu=
ot;no
                                                          this token
                                                          isn't good
                                                          anymore". We
                                                          could instead
                                                          do this with
                                                          HTTP codes or
                                                          something but
                                                          I went with a
                                                          pure JSON
                                                          response.

                                                          =A0-- Justin

                                                          =A0

                                                          On
                                                          02/06/2013
                                                          10:47 PM,
                                                          Prabath
                                                          Siriwardena
                                                          wrote:<=
/u>

                                                          Hi
                                                          Justin, 

                                                          =A0

                                                          I
                                                          believe this
                                                          is addressing
                                                          one of the key
                                                          missing part
                                                          in OAuth
                                                          2.0...<=
/u>

                                                          =A0

                                                          One
                                                          question - I
                                                          guess this was
                                                          discussed
                                                          already...=

                                                          =A0

                                                          In
                                                          the spec - in
                                                          the
                                                          introspection
                                                          response it
                                                          has the
                                                          attribute
                                                          "valid"=
 - this
                                                          is basically
                                                          the validity
                                                          of the token
                                                          provided in
                                                          the request.

                                                          =A0

                                                          Validation=A0criteria
                                                          depends on the
                                                          token and well
                                                          as token type
                                                          ( Bearer,
                                                          MAC..).=

                                                          =A0

                                                          In
                                                          the spec it
                                                          seems like
                                                          it's coupled
                                                          with Bearer
                                                          token type...
                                                          But I guess,
                                                          by adding
                                                          "token_type&=
quot;
                                                          to the request
                                                          we can remove
                                                          this
                                                          dependency.

                                                          =A0

                                                          WDYT..?

                                                          =A0

                                                          Thanks
                                                          & regards,=

                                                          -Prabath=A0

                                                          =A0

                                                          On
                                                          Thu, Feb 7,
                                                          2013 at 12:54
                                                          AM, Justin
                                                          Richer <jricher@mitre.org>
                                                          wrote:<=
/u>

                                                          Updated
                                                          introspection
                                                          draft based on
                                                          recent
                                                          comments.
                                                          Changes
                                                          include:

                                                          =A0- "scope&=
quot;
                                                          return
                                                          parameter now
                                                          follows
                                                          RFC6749 format
                                                          instead of
                                                          JSON array

                                                          =A0- "subjec=
t"
                                                          -> "sub&q=
uot;,
                                                          and "audienc=
e"
                                                          -> "aud&q=
uot;,
                                                          to be parallel
                                                          with JWT
                                                          claims

                                                          =A0- clarified
                                                          what happens
                                                          if the
                                                          authentication
                                                          is bad

                                                          =A0-- Justin

                                                          --------
                                                          Original
                                                          Message
                                                          -------- <=
u>

                                                          Subject: =

                                                          New
                                                          Version
                                                          Notification
                                                          for
                                                          draft-richer-oaut=
h-introspection-02.txt

                                                          Date: 

                                                          Wed,
                                                          6 Feb 2013
                                                          11:24:20 -0800=

                                                          From: 

                                                          <int=
ernet-drafts@ietf.org>

                                                          To: <=
/p>

                                                          <jricher@mi=
tre.org>

                                                          =A0
                                                          A new versio=
n of I-D, draft-richer-oauth-introspection-02.txt
                                                          has been suc=
cessfully submitted by Justin Richer and posted to the
                                                          IETF reposit=
ory.
                                                          =A0
                                                          Filename:=A0=
=A0=A0=A0=A0  draft-richer-oauth-introspection
                                                          Revision:=A0=
=A0=A0=A0=A0  02
                                                          Title:=A0=A0=
=A0=A0=A0 =A0=A0=A0=A0=A0  OAuth Token Introspection
                                                          Creation dat=
e:=A0=A0=A0=A0=A0  2013-02-06
                                                          WG ID:=A0=A0=
=A0=A0=A0 =A0=A0=A0=A0=A0  Individual Submission
                                                          Number of pa=
ges: 6
                                                          URL:=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0http://www.ie=
tf.org/internet-drafts/draft-richer-oauth-introspection-02.txt

                                                          Status:=A0=
=A0=A0=A0=A0=A0=A0=A0 =A0http://datatracker.ietf.org/do=
c/draft-richer-oauth-introspection

                                                          Htmlized:=A0=
=A0=A0=A0=A0=A0 =A0http://tools.ietf.org/html/draft-riche=
r-oauth-introspection-02

                                                          Diff:=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 =A0http://www.ietf.org/r=
fcdiff?url2=3Ddraft-richer-oauth-introspection-02

                                                          =A0
                                                          Abstract:=

                                                          =A0=A0 This =
specification defines a method for a client or protected
                                                          =A0=A0 resou=
rce to query an OAuth authorization server to determine meta-=

                                                          =A0=A0 infor=
mation about an OAuth token.
                                                          =A0
                                                          =A0
                                                          =A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 
                                                          =A0
                                                          =A0
                                                          The IETF Sec=
retariat
                                                          =A0
                                                          =A0

                                                          =A0

_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

                                                          https://www.ietf.o=
rg/mailman/listinfo/oauth

                                                          =A0

                                                          --

                                                          Thanks &
                                                          Regards,

                                                          Prabath 

                                                          =A0

                                                          Mobile
                                                          : +94 71 809 6732=A0

                                                          http://blog.facilelogin.com
                                                          http://RampartFAQ.com<=
/p>

                                                          =A0

                                                          =A0

                                                          --

                                                          Thanks &
                                                          Regards,

                                                          Prabath 

                                                          =A0

                                                          Mobile
                                                          : +94 71 809 6732=A0

                                                          http://blog.facilelogin.com
                                                          http://RampartFAQ.com<=
/p>

                                                          =A0

                                                          =A0

                                                          --

                                                          Thanks &
                                                          Regards,

                                                          Prabath 

                                                          =A0

                                                          Mobile
                                                          : +94 71 809 6732=A0

                                                          http://blog.facilelogin.com
                                                          http://RampartFAQ.com<=
/p>

                                                          =A0

                                                          =A0

                                                          --

                                                          Thanks &
                                                          Regards,

                                                          Prabath 

                                                          =A0

                                                          Mobile
                                                          : +94 71 809 6732=A0

                                                          http://blog.facilelogin.com
                                                          http://RampartFAQ.com<=
/p>

                                                          _______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

                                                          https://www.ietf.o=
rg/mailman/listinfo/oauth

                                                          =A0

                                                          =A0

                                                          --

                                                          Thanks &
                                                          Regards,

                                                          Prabath 

                                                          =A0

                                                          Mobile
                                                          : +94 71 809 6732=A0

                                                          http://blog.facilelogin.com
                                                          http://RampartFAQ.com<=
/p>

                                                          =A0

                                                          --

                                                          Thanks &
                                                          Regards,

                                                          Prabath 

                                                          =A0

                                                          Mobile
                                                          : +94 71 809 6732=A0

                                                          http://blog.facilelogin.com
                                                          http://RampartFAQ.com<=
/p>

                                                          =A0

                                                        =A0

                                                      --

                                                        Thanks &
                                                        Regards,

                                                        Prabath <=
/u>

                                                        =A0

                                                        Mobile
                                                          : +94 71 809 6732=A0

                                                          http://blog.facilelogin.com
                                                          http://RampartFAQ.com<=
/p>

                                                <=
/u>=A0

                                              -- 
                                                Thanks & Regards,

                                                Prabath 

                                                <=
/u>=A0

                                                Mobi=
le
                                                  : +94 71 809 6732=A0

                                                  http://blog.facilelogin.com

                                                  http://RampartFAQ.com

                                          =A0=

                                    =A0

                                  -- 

                                    Thanks & Regards,

                                    Prabath 

                                    =A0

                                    Mobile : +94 71 809 6732=A0

                                      http://blog.facilelogin.com

                                      http://RampartFAQ.com

                              =A0

                        =A0

                      -- 

                        Thanks & Regards,

                        Prabath 

                        =A0

                        Mobile : +94 71 809 6732=A0

                          http://blog.facilelogin.com

                          http://RampartFAQ.com

                    =A0

              =A0

            -- 

              Thanks & Regards,

              Prabath 

              =A0

              Mobile : +94 71 809 6732=A0<=
br>

                h=
ttp://blog.facilelogin.com

                http://=
RampartFAQ.com

        =A0

-- 
Thanks &=
 Regards,
Prabath
Mobile : +94 71 809 6732=A0

=
http://blog.facil=
elogin.com

http://RampartFAQ.com

--047d7b343a9e971d2f04d5b601ea--

From Michael.Jones@microsoft.com  Thu Feb 14 13:44:44 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAC121F855C for ; Thu, 14 Feb 2013 13:44:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.585
X-Spam-Level: 
X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfHnVRpkzEwx for ; Thu, 14 Feb 2013 13:44:41 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACE721F84C7 for ; Thu, 14 Feb 2013 13:44:40 -0800 (PST)
Received: from BL2FFO11FD022.protection.gbl (10.173.161.202) by BL2FFO11HUB003.protection.gbl (10.173.161.21) with Microsoft SMTP Server (TLS) id 15.0.620.12; Thu, 14 Feb 2013 21:44:31 +0000
Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD022.mail.protection.outlook.com (10.173.161.101) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Thu, 14 Feb 2013 21:44:31 +0000
Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.232]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Thu, 14 Feb 2013 21:44:11 +0000
From: Mike Jones 
To: Justin Richer , Phil Hunt 
Thread-Topic: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
Thread-Index: AQHOCUdbOV5B7lAK3kmkqyu4eMgvZZh55eFg
Date: Thu, 14 Feb 2013 21:44:10 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436744BD23@TK5EX14MBXC285.redmond.corp.microsoft.com>
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net>  <511A7D27.8010209@mitre.org>
In-Reply-To: <511A7D27.8010209@mitre.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.71]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(24454001)(377424002)(377454001)(479174001)(13464002)(51704002)(30513003)(52604002)(79102001)(53806001)(66066001)(63696002)(80022001)(31966008)(15202345001)(47736001)(47446002)(65816001)(33656001)(55846006)(20776003)(56776001)(46406002)(5343655001)(15974865001)(51856001)(49866001)(5343635001)(74502001)(4396001)(47976001)(77982001)(47776003)(74662001)(50466001)(50986001)(56816002)(59766001)(54356001)(54316002)(46102001)(23726001)(16406001)(76482001)(44976002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB003; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0757EEBDCA
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2013 21:44:44 -0000

I'm in favor of reusing the JWT work that this WG is also doing. :-)

I'm pretty skeptical of us inventing another custom scheme for signing HTTP=
 headers.  That was the impediment to OAuth 1.0 adoption that OAuth 2.0 sol=
ved in the first place.

				-- Mike

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J=
ustin Richer
Sent: Tuesday, February 12, 2013 9:35 AM
To: Phil Hunt
Cc: IETF oauth WG
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call =
- 11th February 2013

That's my reading of it as well, Phil, thanks for providing the clarificati=
on. One motivator behind using a JSON-based token is to be able to re-use s=
ome of the great work that the JOSE group is doing but apply it to an HTTP =
payload.

What neither of us want is a token type that requires stuffing all query, h=
eader, and other parameters *into* the JSON object itself, which would be a=
 more SOAPy approach.

  -- Justin

On 02/12/2013 12:30 PM, Phil Hunt wrote:
> Clarification.  I think Justin and I were in agreement that we don't want=
 to see a format that requires JSON payloads.  We are both interested in a =
JSON token used in the authorization header that could be based on a comput=
ed signature of some combination of http headers and body if possible.
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>
>
>
>
> On 2013-02-12, at 1:10 AM, Hannes Tschofenig wrote:
>
>> Here are my notes.
>>
>> Participants:
>>
>> * John Bradley
>> * Derek Atkins
>> * Phil Hunt
>> * Prateek Mishra
>> * Hannes Tschofenig
>> * Mike Jones
>> * Antonio Sanso
>> * Justin Richer
>>
>> Notes:
>>
>> My slides are available here:=20
>> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
>>
>> Slide #2 summarizes earlier discussions during the conference calls.
>>
>> -- HTTP vs. JSON
>>
>> Phil noted that he does not like to use the MAC Token draft as a startin=
g point because it does not re-use any of the work done in the JOSE working=
 group and in particular all the libraries that are available today. He men=
tioned that earlier attempts to write the MAC Token code lead to problems f=
or implementers.
>>
>> Justin responded that he does not agree with using JSON as a transport m=
echanism since this would replicate a SOAP style.
>>
>> Phil noted that he wants to send JSON but the signature shall be compute=
d over the HTTP header field.
>>
>> -- Flexibility for the keyed message digest computation
>>
>>  From earlier discussion it was clear that the conference call participa=
nts wanted more flexibility regarding the keyed message digest computation.=
 For this purpose Hannes presented the DKIM based approach, which allows se=
lective header fields to be included in the digest. This is shown in slide =
#4.
>>
>> After some discussion the conference call participants thought that this=
 would meet their needs. Further investigations would still be useful to de=
termine the degree of failed HMAC calculations due to HTTP proxies modifyin=
g the content.
>>
>> -- Key Distribution
>>
>> Hannes presented the open issue regarding the choice of key=20
>> distribution. Slides #6-#8 present three techniques and Hannes asked=20
>> for feedback regarding the preferred style. Justin and others didn't=20
>> see the need to decide on one mechanism - they wanted to keep the=20
>> choice open. Derek indicated that this will not be an acceptable=20
>> approach. Since the resource server and the authorization server may,=20
>> in the OAuth 2.0 framework, be entities produced by different vendors=20
>> there is an interoperability need. Justin responded that he disagrees=20
>> and that the resource server needs to understand the access token and=20
>> referred to the recent draft submission for the token introspection=20
>> endpoint. Derek indicated that the resource server has to understand=20
>> the content of the access token and the token introspection endpoint=20
>> just pushes the problem around: the resource server has to send the=20
>> access token to the authorization server and then the resource server=20
>> gets the result back (which he the
 n
>    a
>> gain needs to understand) in order to make a meaningful authorization de=
cision.
>>
>> Everyone agreed that the client must receive the session key from the au=
thorization server and that this approach has to be standardized. It was al=
so agreed that this is a common approach among all three key distribution m=
echanisms.
>>
>> Hannes asked the participants to think about their preference.
>>
>> The questions regarding key naming and the indication for the intended r=
esource server the client wants to talk to have been postponed.
>>
>> 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

From wmills_92105@yahoo.com  Thu Feb 14 17:31:41 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C91721F866F for ; Thu, 14 Feb 2013 17:31:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.192
X-Spam-Level: 
X-Spam-Status: No, score=-2.192 tagged_above=-999 required=5 tests=[AWL=0.406,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIUZdJGZ8I8z for ; Thu, 14 Feb 2013 17:31:40 -0800 (PST)
Received: from nm34-vm5.bullet.mail.ne1.yahoo.com (nm34-vm5.bullet.mail.ne1.yahoo.com [98.138.229.85]) by ietfa.amsl.com (Postfix) with ESMTP id 1D26F21F8654 for ; Thu, 14 Feb 2013 17:31:40 -0800 (PST)
Received: from [98.138.90.49] by nm34.bullet.mail.ne1.yahoo.com with NNFMP; 15 Feb 2013 01:31:39 -0000
Received: from [98.138.89.174] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 15 Feb 2013 01:31:39 -0000
Received: from [127.0.0.1] by omp1030.mail.ne1.yahoo.com with NNFMP; 15 Feb 2013 01:31:39 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 415033.12072.bm@omp1030.mail.ne1.yahoo.com
Received: (qmail 18835 invoked by uid 60001); 15 Feb 2013 01:31:39 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360891898; bh=U6HZpJ/bZRbUAvt6Op3gxHSmiRCqS0PFx46IKw1EEzQ=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=lo/m/q8hCvmA/NV3U5rVSHvoqdkWjMSCWUCt1uAWGOGZx3Y1t7draR5K8LIelA4JI505kKoBjjCV2tdutH1M3jqJOn+lLf4RRsH8t020xCUqGkVP6cDygHJPsqVEeK2h3lxncKdAcLrMq+ut/6zlEySaLG1TFlsXTH/jDxP0w1I=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=iO3R6ItvUg0bRI91bZMX9w352dILfesDfVu+5y9PLwlfMAX2tlDNMuE5z9pbu+ThbtkZZQ7tDrCSzJHe8PuVo3Mn3gysfK8mwZ2Map3JC77R8De4RoauKEUCfwLFNotibKZf9cTqPQ32aHbEYXtKDULP8Wz+CzoXrrPU3S/W+TI=;
X-YMail-OSG: e6DdfREVM1n_UXQ2UyYm0s2dZrRqV.wla6m1KQtCpy2L2T8 DCKqnNmGqErKKtDI5EIlCrrOxK3Z2ZTfDGswfLvhv.Ps06r6X5bO0BxxZa23 SxzjO6NwiS6fwFPMl9n8di0ndsB9uulYpqxrbTrtQ_8n4mspe.Q4cM59pUC8 _6wWyb37pVS1lQZyGJoxH6B3IfOM3O2Trx9IpwlHe7YX2VkTEPyWrGH3xmZz vB6fwlSCXa0lm6sVp5v_T6Kf_A76__Hq1Ky301DCRxMIEEjt7NOJ5kUHGzIc QenUCdUZs7qyBCqTly6oAKXEjyw0WTDsToTSh0OSazj8Vwg45DFYmXFtTvKP WI13VCJlimtL7bPA1w4_ETL89tT1CBNSyOkwGA4aRbUC9NiJn7XescC1._PC CFUkXeGVtwVWLdvZJV8k8E7epHd1rsGbgweqL.2if6ZnI7IjGhwXFS2tk1j5 RkrCji.23pGxtbVymb4GeAoARXrMzPG9KOPkLL6_kKSJOKcBn_zwRZTLn6iE UQcga0U6G6a6z2Z0xOhyn9XqWTuC.0X4UNQbYFc4kZYdtPMBm5wvM9DsJPp9 hCdL81zSpwgNN7Zr2N1lrZC1rfmsErT3PS0hGNf0svQsl6DB8yawBhPBIoow OYdrXX30PYaWXVZFb9HLhkU5I7V.yTIVzg.ZSTdlfZleENlUZeLGR1klC.0_ LGHUXLwC7MvSY.54_XvjM40c9Uj.9W4d.9dl.huhw7b0hsnQ-
Received: from [209.131.62.145] by web31811.mail.mud.yahoo.com via HTTP; Thu, 14 Feb 2013 17:31:37 PST
X-Rocket-MIMEInfo: 001.001, SSBkaXNhZ3JlZSB3aXRoICJUaGF0IHdhcyB0aGUgaW1wZWRpbWVudCB0byBPQXV0aCAxLjAgYWRvcHRpb24gdGhhdCBPQXV0aCAyLjAgc29sdmVkIGluIHRoZSBmaXJzdCBwbGFjZS4iLCB1bmxlc3MgInNvbHZpbmciIG1lYW5zIGRvZXMgbm90IGFkZHJlc3MgdGhlIG5lZWQgZm9yIGl0IGF0IGFsbC4KCk9BdXRoIDIgZG9lcyBzZXZlcmFsIGdvb2QgdGhpbmdzLCBidXQgaXQgc3RpbGwgbGFja3MgYSBkZWZpbmVkIHRva2VuIHR5cGUgdGhhdCBpcyBzYWZlIHRvIHVzZXIgb3ZlciBwbGFpbiB0ZXh0IEhUVFAuIAEwAQEBAQ--
X-Mailer: YahooMailWebService/0.8.134.513
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net>  <511A7D27.8010209@mitre.org> <4E1F6AAD24975D4BA5B16804296739436744BD23@TK5EX14MBXC285.redmond.corp.microsoft.com>
Message-ID: <1360891897.14004.YahooMailNeo@web31811.mail.mud.yahoo.com>
Date: Thu, 14 Feb 2013 17:31:37 -0800 (PST)
From: William Mills 
To: Mike Jones , Justin Richer , Phil Hunt 
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436744BD23@TK5EX14MBXC285.redmond.corp.microsoft.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="764183289-1761209499-1360891897=:14004"
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Feb 2013 01:31:41 -0000

--764183289-1761209499-1360891897=:14004
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I disagree with "That was the impediment to OAuth 1.0 adoption that OAuth 2=
.0 solved in the first place.", unless "solving" means does not address the=
 need for it at all.=0A=0AOAuth 2 does several good things, but it still la=
cks a defined token type that is safe to user over plain text HTTP. =A01.0a=
 solved that.=0A=0A=0A________________________________=0A From: Mike Jones =
=0ATo: Justin Richer ; Phil=
 Hunt  =0ACc: IETF oauth WG  =0ASent:=
 Thursday, February 14, 2013 1:44 PM=0ASubject: Re: [OAUTH-WG] Minutes from=
 the OAuth Design Team Conference Call - 11th February 2013=0A =0AI'm in fa=
vor of reusing the JWT work that this WG is also doing. :-)=0A=0AI'm pretty=
 skeptical of us inventing another custom scheme for signing HTTP headers.=
=A0 That was the impediment to OAuth 1.0 adoption that OAuth 2.0 solved in =
the first place.=0A=0A=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 -- Mike=0A=0A=
-----Original Message-----=0AFrom: oauth-bounces@ietf.org [mailto:oauth-bou=
nces@ietf.org] On Behalf Of Justin Richer=0ASent: Tuesday, February 12, 201=
3 9:35 AM=0ATo: Phil Hunt=0ACc: IETF oauth WG=0ASubject: Re: [OAUTH-WG] Min=
utes from the OAuth Design Team Conference Call - 11th February 2013=0A=0AT=
hat's my reading of it as well, Phil, thanks for providing the clarificatio=
n. One motivator behind using a JSON-based token is to be able to re-use so=
me of the great work that the JOSE group is doing but apply it to an HTTP p=
ayload.=0A=0AWhat neither of us want is a token type that requires stuffing=
 all query, header, and other parameters *into* the JSON object itself, whi=
ch would be a more SOAPy approach.=0A=0A=A0 -- Justin=0A=0AOn 02/12/2013 12=
:30 PM, Phil Hunt wrote:=0A> Clarification.=A0 I think Justin and I were in=
 agreement that we don't want to see a format that requires JSON payloads.=
=A0 We are both interested in a JSON token used in the authorization header=
 that could be based on a computed signature of some combination of http he=
aders and body if possible.=0A>=0A> Phil=0A>=0A> @independentid=0A> www.ind=
ependentid.com=0A> phil.hunt@oracle.com=0A>=0A>=0A>=0A>=0A>=0A> On 2013-02-=
12, at 1:10 AM, Hannes Tschofenig wrote:=0A>=0A>> Here are my notes.=0A>>=
=0A>> Participants:=0A>>=0A>> * John Bradley=0A>> * Derek Atkins=0A>> * Phi=
l Hunt=0A>> * Prateek Mishra=0A>> * Hannes Tschofenig=0A>> * Mike Jones=0A>=
> * Antonio Sanso=0A>> * Justin Richer=0A>>=0A>> Notes:=0A>>=0A>> My slides=
 are available here: =0A>> http://www.tschofenig.priv.at/OAuth2-Security-11=
Feb2013.ppt=0A>>=0A>> Slide #2 summarizes earlier discussions during the co=
nference calls.=0A>>=0A>> -- HTTP vs. JSON=0A>>=0A>> Phil noted that he doe=
s not like to use the MAC Token draft as a starting point because it does n=
ot re-use any of the work done in the JOSE working group and in particular =
all the libraries that are available today. He mentioned that earlier attem=
pts to write the MAC Token code lead to problems for implementers.=0A>>=0A>=
> Justin responded that he does not agree with using JSON as a transport me=
chanism since this would replicate a SOAP style.=0A>>=0A>> Phil noted that =
he wants to send JSON but the signature shall be computed over the HTTP hea=
der field.=0A>>=0A>> -- Flexibility for the keyed message digest computatio=
n=0A>>=0A>>=A0 From earlier discussion it was clear that the conference cal=
l participants wanted more flexibility regarding the keyed message digest c=
omputation. For this purpose Hannes presented the DKIM based approach, whic=
h allows selective header fields to be included in the digest. This is show=
n in slide #4.=0A>>=0A>> After some discussion the conference call particip=
ants thought that this would meet their needs. Further investigations would=
 still be useful to determine the degree of failed HMAC calculations due to=
 HTTP proxies modifying the content.=0A>>=0A>> -- Key Distribution=0A>>=0A>=
> Hannes presented the open issue regarding the choice of key =0A>> distrib=
ution. Slides #6-#8 present three techniques and Hannes asked =0A>> for fee=
dback regarding the preferred style. Justin and others didn't =0A>> see the=
 need to decide on one mechanism - they wanted to keep the =0A>> choice ope=
n. Derek indicated that this will not be an acceptable =0A>> approach. Sinc=
e the resource server and the authorization server may, =0A>> in the OAuth =
2.0 framework, be entities produced by different vendors =0A>> there is an =
interoperability need. Justin responded that he disagrees =0A>> and that th=
e resource server needs to understand the access token and =0A>> referred t=
o the recent draft submission for the token introspection =0A>> endpoint. D=
erek indicated that the resource server has to understand =0A>> the content=
 of the access token and the token introspection endpoint =0A>> just pushes=
 the problem around: the resource server has to send the =0A>> access token=
 to the authorization server and then the resource server =0A>> gets the re=
sult back (which he the=0An=0A>=A0 =A0 a=0A>> gain needs to understand) in =
order to make a meaningful authorization decision.=0A>>=0A>> Everyone agree=
d that the client must receive the session key from the authorization serve=
r and that this approach has to be standardized. It was also agreed that th=
is is a common approach among all three key distribution mechanisms.=0A>>=
=0A>> Hannes asked the participants to think about their preference.=0A>>=
=0A>> The questions regarding key naming and the indication for the intende=
d resource server the client wants to talk to have been postponed.=0A>>=0A>=
> Ciao=0A>> Hannes=0A>>=0A>>=0A>> _________________________________________=
______=0A>> OAuth mailing list=0A>> OAuth@ietf.org=0A>> https://www.ietf.or=
g/mailman/listinfo/oauth=0A> ______________________________________________=
_=0A> OAuth mailing list=0A> OAuth@ietf.org=0A> https://www.ietf.org/mailma=
n/listinfo/oauth=0A=0A=0A_______________________________________________=0A=
OAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo=
/oauth=0A_______________________________________________=0AOAuth mailing li=
st=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth
--764183289-1761209499-1360891897=:14004
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I disagree with "That was the impediment to OAuth =
1.0 adoption that OAuth 2.0 solved in the first place.", unless "solving" m=
eans does not address the need for it at all.

OAuth 2 does severa=
l
 good things, but it still lacks a defined token type that is safe to user =
over plain text HTTP.  1.0a solved that.

  =

  Fro=
m: Mike Jones <Michael.Jones@microsoft.com>
 To: Justin Richer <jricher@mitre.=
org>; Phil Hunt <phil.hunt@oracle.com> 
Cc: IETF oauth WG <oauth@ietf.org> 
 =
Sent: Thursday, February 14, =
2013 1:44 PM
 Subject: =
Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th Fe=
bruary 2013

=0AI'm in favor of reusing the JWT work that this WG is=
 also doing. :-)

I'm pretty skeptical of us inventing another custom=
 scheme for signing HTTP headers.  That was the impediment to OAuth 1.=
0 adoption that OAuth 2.0 solved in the first place.

  &nb=
sp;             -- Mike
-----Original Message-----
From: oauth-bounces@ietf.org [m=
ailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Se=
nt: Tuesday, February 12, 2013 9:35 AM
To: Phil Hunt
Cc: IETF oauth W=
G
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference =
Call - 11th February 2013

That's my reading of it as well, Phil, tha=
nks for providing the clarification. One motivator behind using a JSON-base=
d token is to be able to
 re-use some of the great work that the JOSE group is doing but apply it to=
 an HTTP payload.

What neither of us want is a token type that requi=
res stuffing all query, header, and other parameters *into* the JSON object=
 itself, which would be a more SOAPy approach.

  -- Justin
<=
br>On 02/12/2013 12:30 PM, Phil Hunt wrote:
> Clarification.  I =
think Justin and I were in agreement that we don't want to see a format tha=
t requires JSON payloads.  We are both interested in a JSON token used=
 in the authorization header that could be based on a computed signature of=
 some combination of http headers and body if possible.
>
> Phi=
l
>
> @independentid
> www.independentid.com
> phil.hunt@=
oracle.com
>
>
>
>
>
> On
 2013-02-12, at 1:10 AM, Hannes Tschofenig wrote:
>
>> Here =
are my notes.
>>
>> Participants:
>>
>>=
 * John Bradley
>> * Derek Atkins
>> * Phil Hunt
>&=
gt; * Prateek Mishra
>> * Hannes Tschofenig
>> * Mike Jon=
es
>> * Antonio Sanso
>> * Justin Richer
>>
&=
gt;> Notes:
>>
>> My slides are available here: 
&g=
t;> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
>&=
gt;
>> Slide #2 summarizes earlier discussions during the conferen=
ce calls.
>>
>> -- HTTP vs. JSON
>>
>> =
Phil noted that he does not like to use the MAC Token draft as a starting p=
oint because it does not re-use any of the work done in the JOSE working gr=
oup and in particular all the libraries that are available today. He mentio=
ned that earlier attempts to write the MAC Token code lead to
 problems for implementers.
>>
>> Justin responded that h=
e does not agree with using JSON as a transport mechanism since this would =
replicate a SOAP style.
>>
>> Phil noted that he wants to=
 send JSON but the signature shall be computed over the HTTP header field.<=
br>>>
>> -- Flexibility for the keyed message digest computa=
tion
>>
>>  From earlier discussion it was clear tha=
t the conference call participants wanted more flexibility regarding the ke=
yed message digest computation. For this purpose Hannes presented the DKIM =
based approach, which allows selective header fields to be included in the =
digest. This is shown in slide #4.
>>
>> After some discu=
ssion the conference call participants thought that this would meet their n=
eeds. Further investigations would still be useful to determine the degree =
of failed HMAC calculations due to HTTP proxies modifying the
 content.
>>
>> -- Key Distribution
>>
>&g=
t; Hannes presented the open issue regarding the choice of key 
>>=
 distribution. Slides #6-#8 present three techniques and Hannes asked 
&=
gt;> for feedback regarding the preferred style. Justin and others didn'=
t 
>> see the need to decide on one mechanism - they wanted to kee=
p the 
>> choice open. Derek indicated that this will not be an ac=
ceptable 
>> approach. Since the resource server and the authoriza=
tion server may, 
>> in the OAuth 2.0 framework, be entities produ=
ced by different vendors 
>> there is an interoperability need. Ju=
stin responded that he disagrees 
>> and that the resource server =
needs to understand the access token and 
>> referred to the recen=
t draft submission for the token introspection 
>> endpoint. Derek=
 indicated that the resource server has to understand 
>>
 the content of the access token and the token introspection endpoint 
&=
gt;> just pushes the problem around: the resource server has to send the=

>> access token to the authorization server and then the resourc=
e server 
>> gets the result back (which he the
 n
> =
;   a
>> gain needs to understand) in order to make a meaning=
ful authorization decision.
>>
>> Everyone agreed that th=
e client must receive the session key from the authorization server and tha=
t this approach has to be standardized. It was also agreed that this is a c=
ommon approach among all three key distribution mechanisms.
>>
=
>> Hannes asked the participants to think about their preference.
=
>>
>> The questions regarding key naming and the indication =
for the intended resource server the client wants to talk to have been post=
poned.
>>
>> 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@iet=
f.org
https://www.ietf.org/mailman/listinfo/oauth
_____=
__________________________________________
OAuth mailing list
OAuth@ietf.org=

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

  <=
/div>  
--764183289-1761209499-1360891897=:14004--

From bcampbell@pingidentity.com  Thu Feb 14 18:47:35 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E53C21F8464 for ; Thu, 14 Feb 2013 18:47:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.984
X-Spam-Level: 
X-Spam-Status: No, score=-5.984 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4g2yMDFtgm3 for ; Thu, 14 Feb 2013 18:47:34 -0800 (PST)
Received: from na3sys009aog135.obsmtp.com (na3sys009aog135.obsmtp.com [74.125.149.84]) by ietfa.amsl.com (Postfix) with ESMTP id 65D5121F844C for ; Thu, 14 Feb 2013 18:47:33 -0800 (PST)
Received: from mail-la0-f71.google.com ([209.85.215.71]) (using TLSv1) by na3sys009aob135.postini.com ([74.125.148.12]) with SMTP ID DSNKUR2hxJEiuCR+TGhndVKHpWOLoaM3KJcj@postini.com; Thu, 14 Feb 2013 18:47:33 PST
Received: by mail-la0-f71.google.com with SMTP id fr10so3830808lab.2 for ; Thu, 14 Feb 2013 18:47:31 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=gWYHNBxgvBNHiZuexWIpk5g5MsSBzkJRphsABX/9j1Y=; b=b+56VT8ST9hzbyutzFrGM4CAsXhoC5CcrZNYASrb3BuBQdYArjnP9hh74q4lCtqyFG 2m5iXEygtTdHCEMx/KNbVa5nz9Pq1CrjCtU2ox32NJUc2hTyTBD2g2YF7Ta1JWk3/exC xVV6eQbG2cheTOOh6cRWPf6GXb/DJn6podVfaZP4/jQtEZzA5cWJdBqiv/bEzmP0X05m bRcScueOA10CzCJ82odAE7+LnRSEtXDY34eSMQNG1voP5/ABtC5x0uNvVaHNVVN9SjvR Vp/04QEhkuPC7JKwGPjcmG1aqFB/kR0Q/Dh91yO37mf0JmUEtixjO6R0ZcrezDUkQvMU 3sJQ==
X-Received: by 10.14.182.71 with SMTP id n47mr3301123eem.11.1360896450781; Thu, 14 Feb 2013 18:47:30 -0800 (PST)
X-Received: by 10.14.182.71 with SMTP id n47mr3301076eem.11.1360896450472; Thu, 14 Feb 2013 18:47:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.14.173.9 with HTTP; Thu, 14 Feb 2013 18:47:00 -0800 (PST)
In-Reply-To: <511C1980.6030603@oracle.com>
References: <51195F36.6040705@mitre.org> <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com> <511BAA8B.8030309@mitre.org>  <-4554688250617930935@unknownmsgid>    <511C1980.6030603@oracle.com>
From: Brian Campbell 
Date: Thu, 14 Feb 2013 19:47:00 -0700
Message-ID: 
To: Prateek Mishra 
Content-Type: multipart/alternative; boundary=047d7b34389681aca504d5ba6529
X-Gm-Message-State: ALoCoQmnqI7NzfpRWII9obkenbdKH/Tl3RtoTWLg1A4OG3ZzoTQBjYnBu1N7FzgWeTTUq1MY5klOMSHtrWOK/mrinLSFxoTQxqcTL0rb2SyDUqMsmq4uyWzL6JATBT08JBd6Zinf6Lu7
Cc: oauth 
Subject: Re: [OAUTH-WG] comments on draft-ietf-oauth-saml2-bearer-15
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Feb 2013 02:47:35 -0000

--047d7b34389681aca504d5ba6529
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thanks for the feedback Prateek. I've tried to address some of you comments
and questions inline below.

On Wed, Feb 13, 2013 at 3:53 PM, Prateek Mishra
wrote:

> It would be helpful if the draft identified the various cases that are
> intended to be supported. For example,
> in draft-ietf-oauth-assertions-**10, there is a helpful distinction made
> between "Client acting on behalf of a user" vs.
> "Client Action on behalf of an anonymous user" (vs. even more advanced
> use-cases). Otherwise, folks
> have a hard time figuring out the pieces they need to implement and the
> required behavior.
>

The guidance in =A76 of draft-ietf-oauth-assertions-10 provides some
particular details of the more general general cases and they apply here as
well as the JWT draft. I'd like to avoid repeating the text and bloating
the documents.

>
> It feels like Section 3 speaks to all of these cases simultaneously. I
> think this is confusing and
> our developers have raised some questions about it.
>

It's not really intended to speak to the cases so much as provide the
required processing rules to validate the assertion in a reasonably secure
way. There is some simultaneous treatment of the client authentication case
and the authorization grant case because they have much more in common than
they have that's different. I can make a pass at better pointing out where
the differences are.

>
> BTW, it would also help if the rules in Section 3 were numbered.
>

I'll see what I can do. I assume it's possible with the xml2rfc markup but
have never done it.

>
> 1) For the case where we have "Client acting on behalf of user" - this
> case seems to be where we
> have something like a SAML SSO assertion - complete with Subject
> identifying the
> "authorized accessor or delegate". The Client offers this bearer
> instrument as an access grant and the Authorization
> server understands that its "acting on behalf a user".
>
> a) As the SAML assertion is a bearer instrument and can be stolen, the
> authorization server should insist on client credentials being present.
> In other words, the client should be confidential. What is the value in
> permitting a public client to participate in this exchange?
>

Very similar to SAML Web SSO where the client (HTTP user agent browser in
that case) is unidentified and the bearer assertion is the sole token
provided to identify/authenticate the subject and gain access. In some
cases there is a quite a bit of value in not having to provision or manage
the clients.

>
> b) Further, as part of its processing rules, once the client has been
> authenticated
> the authorization server should determine whether the particular client
> has the right to present the SAML bearer assertion.
>

An AS is free to deploy that kind of policy as needed for the deployment or
product. But the spec intentionally does not dictate any such policy.  And
intentionally allows for unidentified clients.

>
> c)  What is the value of including an AuthNStatement? Specifically, what
> does the Authorization server understand by its
> presence or absence? What is the guidance to deployers? Should they
> require end-user authentication to have taken place?
>
>
It's intended to convey whether or not the issuer actually authenticated
the subject or not. It's a distinction that, based on some conversations
I'd had, seemed like it might be useful for some. But much existing SAML
software doesn't work that way currently, which is why there's not a MUST
there. I'm trying to accommodate existing practice, within reason, while
also provide potentially useful functionality.

> 2) Bullet 5 (counting from the bottom of Section 3) references a more
> advanced use case based on a SAML delegation
> model. Is this the ONLY case where AuthNStatement's are allowed to be
> omitted? If so, that should be stated clearly.
>

I've got a SHOULD NOT there. I don't think a MUST is reasonable based on
what I've seen actual deployments do. Please suggest some text, if you
think it can be improved.

>
>  I think this bullet refers to an advanced use-case and should be moved t=
o
> an independent section.
>

I think it's pretty common actually.

>
> I think by "the presenter act autonomously on behalf of the subject" you
> mean something like "Client acts on Behalf of Anonymous Users".
> as identified in draft-ietf-oauth-assertions-**10.
>

No. I mean that the presenter (client) is acting on behalf of the user.
And the user probably isn't present for the transactions. "Autonomous" is a
word that kind of got inherited from the very early OAuth 2.0 drafts (
http://tools.ietf.org/html/draft-ietf-oauth-v2-08#section-1.4.4) and maybe
causes more trouble than it's worth here?

>
> I also found the sentence "The presented SHOULD be identified in the
>  or similar element,.." problematic. Its pretty open ended
> and it seems to me it will be difficult to have an interoperable
> implementation based on this text.
>

I agree that it's confusing and I believe it's partly because there's a
mistake in that text. It should say something more like "The presenter
SHOULD be identified in the  or similar element *within* the
 element, or by other available means like [
OASIS.saml-deleg-cs
]"

Which is less open ended but still pretty open. The  or similar
text is becasue there can be a , , or  child
of the  and I was trying to avoid writing all that
out. The "SAML V2.0 Condition for Delegation Restriction" reference (which
probably should be expanded) is to a document that came along well after
regular SAML 2 and isn't widely supported, as far as I know. Neither of
these ways of expressing delegation is really used much in practice, as far
as I know, which makes it difficult to dictate particular requirements here=
.

>
> Finally, what are the additional processing rules that the authorization
> server needs to implement when processing this class of SAML assertions?
>

I don't understand? That's what 3 is all about. Or should be.

>
> 3) Has there been any interoperability testing of this profile? This is a=
n
> activity we would be interested in.
>

Nothing official that I know of. I'd probably be worthwhile. But of course,
there's a lot involved in something like that.

--047d7b34389681aca504d5ba6529
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thanks for the feedback Prateek. I've tried to address=
 some of you comments and questions inline below.

On Wed, Feb 13, 2013 at 3:53 PM, Prateek Mishra <prateek.mishra=
@oracle.com> wrote:

It would be helpful if th=
e draft identified the various cases that are intended to be supported. For=
 example,

in draft-ietf-oauth-assertions-10, there is a helpful distinction ma=
de between "Client acting on behalf of a user" vs.

"Client Action on behalf of an anonymous user" (vs. even more adv=
anced use-cases). Otherwise, folks

have a hard time figuring out the pieces they need to implement and the req=
uired behavior.

The guidance in =A76 of=
 draft-ietf-oauth-assertions-10 provides some particular details of the mor=
e general general cases and they apply here as well as the JWT draft. I'=
;d like to avoid repeating the text and bloating the documents.

=A0

It feels like Section 3 speaks to all of these cases simultaneously. I thin=
k this is confusing and

our developers have raised some questions about it.
It's not really intended to speak to the cases so much as =
provide the required processing rules to validate the assertion in a reason=
ably secure way. There is some simultaneous treatment of the client authent=
ication case and the authorization grant case because they have much more i=
n common than they have that's different. I can make a pass at better p=
ointing out where the differences are.

=A0

BTW, it would also help if the rules in Section 3 were numbered.

I'll see what I can do. I assume it's pos=
sible with the xml2rfc markup but have never done it.
=A0

1) For the case where we have "Client acting on behalf of user" -=
 this case seems to be where we

have something like a SAML SSO assertion - complete with Subject identifyin=
g the

"authorized accessor or delegate". The Client offers this bearer =
instrument as an access grant and the Authorization

server understands that its "acting on behalf a user".

a) As the SAML assertion is a bearer instrument and can be stolen, the auth=
orization server should insist on client credentials being present.

In other words, the client should be confidential. What is the value in per=
mitting a public client to participate in this exchange?

Very similar to SAML Web SSO where the client (HTTP user =
agent browser in that case) is unidentified and the bearer assertion is the=
 sole token provided to identify/authenticate the subject and gain access. =
In some cases there is a quite a bit of value in not having to provision or=
 manage the clients.

=A0

b) Further, as part of its processing rules, once the client has been authe=
nticated

the authorization server should determine whether the particular client has=
 the right to present the SAML bearer assertion.

<=
/div>An AS is free to deploy that kind of policy as needed for the dep=
loyment or product. But the spec intentionally does not dictate any such po=
licy.=A0 And intentionally allows for unidentified clients.

=A0

c) =A0What is the value of including an AuthNStatement? Specifically, what =
does the Authorization server understand by its

presence or absence? What is the guidance to deployers? Should they require=
 end-user authentication to have taken place?

It's intended to convey whether or=
 not the issuer actually authenticated the subject or not. It's a disti=
nction that, based on some conversations I'd had, seemed like it might =
be useful for some. But much existing SAML software doesn't work that w=
ay currently, which is why there's not a MUST there. I'm trying to =
accommodate existing practice, within reason, while also provide potentiall=
y useful functionality.

=A0

2) Bullet 5 (counting from the bottom of Section 3) references a more advan=
ced use case based on a SAML delegation

model. Is this the ONLY case where AuthNStatement's are allowed to be o=
mitted? If so, that should be stated clearly.

I've got a SHOULD NOT there. I don't think a MUST is reasona=
ble based on what I've seen actual deployments do. Please suggest some =
text, if you think it can be improved.

=A0

=A0I think this bullet refers to an advanced use-case and should be moved t=
o an independent section.

I think it=
9;s pretty common actually.
=A0

I think by "the presenter act autonomously on behalf of the subject&qu=
ot; you mean something like "Client acts on Behalf of Anonymous Users&=
quot;.

as identified in draft-ietf-oauth-assertions-10.

No. I mean that the presenter (client) is acting on behalf=
 of the user.=A0 And the user probably isn't present for the transactio=
ns. "Autonomous" is a word that kind of got inherited from the ve=
ry early OAuth 2.0 drafts (http://tools.ietf.org/html/draft-ietf-oauth-v2-=
08#section-1.4.4) and maybe causes more trouble than it's worth her=
e?

=A0

I also found the sentence "The presented SHOULD be identified in the &=
lt;NameID> or similar element,.." problematic. Its pretty open ende=
d

and it seems to me it will be difficult to have an interoperable implementa=
tion based on this text.

I agree that i=
t's confusing and I believe it's partly because there's a mista=
ke in that text. It should say something more like "The presenter SHOU=
LD be identified in the
      <NameID> or similar element *within* the <SubjectConfirmatio=
n> element, or
      by other available means like [OASIS.saml-deleg-=
cs]"

Which is less open ended but still pretty o=
pen. The <NameID> or similar text is becasue there can be a <BaseI=
D>, <NameID>, or <EncryptedID> child of the <SubjectConfi=
rmation> and I was trying to avoid writing all that out. The "SAML =
V2.0 Condition for Delegation
              Restriction" reference (which probably should be expande=
d) is to a document that came along well after regular SAML 2 and isn't=
 widely supported, as far as I know. Neither of these ways of expressing de=
legation is really used much in practice, as far as I know, which makes it =
difficult to dictate particular requirements here.

			=09
		=09
	=09
=09
=A0

Finally, what are the additional processing rules that the authorization se=
rver needs to implement when processing this class of SAML assertions?
<=
/blockquote>
I don't understand? That's what 3 i=
s all about. Or should be.

=A0

3) Has there been any interoperability testing of this profile? This is an =
activity we would be interested in.

Not=
hing official that I know of. I'd probably be worthwhile. But of course=
, there's a lot involved in something like that.

=A0

--047d7b34389681aca504d5ba6529--

From torsten@lodderstedt.net  Thu Feb 14 22:05:38 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436FE21F8717 for ; Thu, 14 Feb 2013 22:05:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.258
X-Spam-Level: 
X-Spam-Status: No, score=-1.258 tagged_above=-999 required=5 tests=[AWL=-0.406, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTdbdS0l6eY7 for ; Thu, 14 Feb 2013 22:05:36 -0800 (PST)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.18.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4081821F8B2E for ; Thu, 14 Feb 2013 22:05:35 -0800 (PST)
Received: from [91.2.95.252] (helo=[192.168.71.56]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1U6EQP-0000By-B8; Fri, 15 Feb 2013 07:05:33 +0100
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net>  <511A7D27.8010209@mitre.org> <4E1F6AAD24975D4BA5B16804296739436744BD23@TK5EX14MBXC285.redmond.corp.microsoft.com> <1360891897.14004.YahooMailNeo@web31811.mail.mud.yahoo.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <1360891897.14004.YahooMailNeo@web31811.mail.mud.yahoo.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-B66DAEAC-1D9A-4813-8A97-C9FAC28EB1B1
Content-Transfer-Encoding: 7bit
Message-Id: 
X-Mailer: iPad Mail (10B141)
From: Torsten Lodderstedt 
Date: Fri, 15 Feb 2013 07:05:34 +0100
To: William Mills 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Feb 2013 06:05:38 -0000

--Apple-Mail-B66DAEAC-1D9A-4813-8A97-C9FAC28EB1B1
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Hi Bill,

OAuth 2.0 took a different direction by relying on HTTPS to provide the basi=
c protection. So the need to have a token, which can be used for service req=
uests over plain HTTP is arguable. My understanding of this activity was, th=
e intend is to provide additional protection on top of HTTPS.

regards,
Torsten.

Am 15.02.2013 um 02:31 schrieb William Mills :

> I disagree with "That was the impediment to OAuth 1.0 adoption that OAuth 2=
.0 solved in the first place.", unless "solving" means does not address the n=
eed for it at all.
>=20
> OAuth 2 does several good things, but it still lacks a defined token type t=
hat is safe to user over plain text HTTP.  1.0a solved that.
>=20
> From: Mike Jones 
> To: Justin Richer ; Phil Hunt =20=

> Cc: IETF oauth WG =20
> Sent: Thursday, February 14, 2013 1:44 PM
> Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call=
 - 11th February 2013
>=20
> I'm in favor of reusing the JWT work that this WG is also doing. :-)
>=20
> I'm pretty skeptical of us inventing another custom scheme for signing HTT=
P headers.  That was the impediment to OAuth 1.0 adoption that OAuth 2.0 sol=
ved in the first place.
>=20
>                 -- Mike
>=20
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J=
ustin Richer
> Sent: Tuesday, February 12, 2013 9:35 AM
> To: Phil Hunt
> Cc: IETF oauth WG
> Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call=
 - 11th February 2013
>=20
> That's my reading of it as well, Phil, thanks for providing the clarificat=
ion. One motivator behind using a JSON-based token is to be able to re-use s=
ome of the great work that the JOSE group is doing but apply it to an HTTP p=
ayload.
>=20
> What neither of us want is a token type that requires stuffing all query, h=
eader, and other parameters *into* the JSON object itself, which would be a m=
ore SOAPy approach.
>=20
>   -- Justin
>=20
> On 02/12/2013 12:30 PM, Phil Hunt wrote:
> > Clarification.  I think Justin and I were in agreement that we don't wan=
t to see a format that requires JSON payloads.  We are both interested in a J=
SON token used in the authorization header that could be based on a computed=
 signature of some combination of http headers and body if possible.
> >
> > Phil
> >
> > @independentid
> > www.independentid.com
> > phil.hunt@oracle.com
> >
> >
> >
> >
> >
> > On 2013-02-12, at 1:10 AM, Hannes Tschofenig wrote:
> >
> >> Here are my notes.
> >>
> >> Participants:
> >>
> >> * John Bradley
> >> * Derek Atkins
> >> * Phil Hunt
> >> * Prateek Mishra
> >> * Hannes Tschofenig
> >> * Mike Jones
> >> * Antonio Sanso
> >> * Justin Richer
> >>
> >> Notes:
> >>
> >> My slides are available here:=20
> >> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
> >>
> >> Slide #2 summarizes earlier discussions during the conference calls.
> >>
> >> -- HTTP vs. JSON
> >>
> >> Phil noted that he does not like to use the MAC Token draft as a starti=
ng point because it does not re-use any of the work done in the JOSE working=
 group and in particular all the libraries that are available today. He ment=
ioned that earlier attempts to write the MAC Token code lead to problems for=
 implementers.
> >>
> >> Justin responded that he does not agree with using JSON as a transport m=
echanism since this would replicate a SOAP style.
> >>
> >> Phil noted that he wants to send JSON but the signature shall be comput=
ed over the HTTP header field.
> >>
> >> -- Flexibility for the keyed message digest computation
> >>
> >>  =46rom earlier discussion it was clear that the conference call partic=
ipants wanted more flexibility regarding the keyed message digest computatio=
n. For this purpose Hannes presented the DKIM based approach, which allows s=
elective header fields to be included in the digest. This is shown in slide #=
4.
> >>
> >> After some discussion the conference call participants thought that thi=
s would meet their needs. Further investigations would still be useful to de=
termine the degree of failed HMAC calculations due to HTTP proxies modifying=
 the content.
> >>
> >> -- Key Distribution
> >>
> >> Hannes presented the open issue regarding the choice of key=20
> >> distribution. Slides #6-#8 present three techniques and Hannes asked=20=

> >> for feedback regarding the preferred style. Justin and others didn't=20=

> >> see the need to decide on one mechanism - they wanted to keep the=20
> >> choice open. Derek indicated that this will not be an acceptable=20
> >> approach. Since the resource server and the authorization server may,=20=

> >> in the OAuth 2.0 framework, be entities produced by different vendors=20=

> >> there is an interoperability need. Justin responded that he disagrees=20=

> >> and that the resource server needs to understand the access token and=20=

> >> referred to the recent draft submission for the token introspection=20
> >> endpoint. Derek indicated that the resource server has to understand=20=

> >> the content of the access token and the token introspection endpoint=20=

> >> just pushes the problem around: the resource server has to send the=20
> >> access token to the authorization server and then the resource server=20=

> >> gets the result back (which he the
> n
> >    a
> >> gain needs to understand) in order to make a meaningful authorization d=
ecision.
> >>
> >> Everyone agreed that the client must receive the session key from the a=
uthorization server and that this approach has to be standardized. It was al=
so agreed that this is a common approach among all three key distribution me=
chanisms.
> >>
> >> Hannes asked the participants to think about their preference.
> >>
> >> The questions regarding key naming and the indication for the intended r=
esource server the client wants to talk to have been postponed.
> >>
> >> 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
>=20
>=20
> _______________________________________________
> 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
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-B66DAEAC-1D9A-4813-8A97-C9FAC28EB1B1
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Bill,

OAut=
h 2.0 took a different direction by relying on HTTPS to provide the basic pr=
otection. So the need to have a token, which can be used for service request=
s over plain HTTP is arguable. My understanding of this activity was, the in=
tend is to provide additional protection on top of HTTPS.

regards,
Torsten.

Am 15.02.2013 um 02:31 schr=
ieb William Mills <wmills_92105=
@yahoo.com>:

I disagree with "<=
span style=3D"font-family: 'times new roman', 'new york', times, serif; font=
-size: 12pt;">That was the impediment to OAuth 1.0 adoption that OAuth 2.0 s=
olved in the first place.", unless "solving" means does not address the need=
 for it at all.

OAuth 2 does several
 good things, but it still lacks a defined token type that is safe to user o=
ver plain text HTTP.  1.0a solved that.

  From: Mike Jones <Michae=
l.Jones@microsoft.com>
 To:<=
/span> Justin Richer <jricher@mi=
tre.org>; Phil Hunt <phil.=
hunt@oracle.com> 
Cc:=
 IETF oauth WG <oauth@ietf.org&=
gt; 
 Sent: Thursday, Fe=
bruary 14, 2013 1:44 PM
 Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call -=
 11th February 2013

I'm in favor of reusing the JWT work that this WG is also doing. :-)

=
I'm pretty skeptical of us inventing another custom scheme for signing HTTP h=
eaders.  That was the impediment to OAuth 1.0 adoption that OAuth 2.0 s=
olved in the first place.

         =
;       -- Mike

-----Original Message-----From: oauth-bounces@ietf.org [mailto:oauth-bounces@iet=
f.org] On Behalf Of Justin Richer
Sent: Tuesday, February 12, 2013 9:=
35 AM
To: Phil Hunt
Cc: IETF oauth WG
Subject: Re: [OAUTH-WG] Minut=
es from the OAuth Design Team Conference Call - 11th February 2013

Th=
at's my reading of it as well, Phil, thanks for providing the clarification.=
 One motivator behind using a JSON-based token is to be able to
 re-use some of the great work that the JOSE group is doing but apply it to a=
n HTTP payload.

What neither of us want is a token type that requires=
 stuffing all query, header, and other parameters *into* the JSON object its=
elf, which would be a more SOAPy approach.

  -- Justin

On=
 02/12/2013 12:30 PM, Phil Hunt wrote:
> Clarification.  I think J=
ustin and I were in agreement that we don't want to see a format that requir=
es JSON payloads.  We are both interested in a JSON token used in the a=
uthorization header that could be based on a computed signature of some comb=
ination of http headers and body if possible.
>
> Phil
>> @independentid
> www.independentid.com
> phil.hunt@oracle.com=

>
>
>
>
>
> On
 2013-02-12, at 1:10 AM, Hannes Tschofenig wrote:
>
>> Here a=
re my notes.
>>
>> Participants:
>>
>> *=
 John Bradley
>> * Derek Atkins
>> * Phil Hunt
>>=
 * Prateek Mishra
>> * Hannes Tschofenig
>> * Mike Jones>> * Antonio Sanso
>> * Justin Richer
>>
>&g=
t; Notes:
>>
>> My slides are available here: 
>>=
 htt=
p://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
>>
=
>> Slide #2 summarizes earlier discussions during the conference calls=
.
>>
>> -- HTTP vs. JSON
>>
>> Phil note=
d that he does not like to use the MAC Token draft as a starting point becau=
se it does not re-use any of the work done in the JOSE working group and in p=
articular all the libraries that are available today. He mentioned that earl=
ier attempts to write the MAC Token code lead to
 problems for implementers.
>>
>> Justin responded that he=
 does not agree with using JSON as a transport mechanism since this would re=
plicate a SOAP style.
>>
>> Phil noted that he wants to se=
nd JSON but the signature shall be computed over the HTTP header field.
&=
gt;>
>> -- Flexibility for the keyed message digest computation<=
br>>>
>>  =46rom earlier discussion it was clear that th=
e conference call participants wanted more flexibility regarding the keyed m=
essage digest computation. For this purpose Hannes presented the DKIM based a=
pproach, which allows selective header fields to be included in the digest. T=
his is shown in slide #4.
>>
>> After some discussion the c=
onference call participants thought that this would meet their needs. Furthe=
r investigations would still be useful to determine the degree of failed HMA=
C calculations due to HTTP proxies modifying the
 content.
>>
>> -- Key Distribution
>>
>>=
; Hannes presented the open issue regarding the choice of key 
>> d=
istribution. Slides #6-#8 present three techniques and Hannes asked 
>=
> for feedback regarding the preferred style. Justin and others didn't >> see the need to decide on one mechanism - they wanted to keep the=

>> choice open. Derek indicated that this will not be an acceptab=
le 
>> approach. Since the resource server and the authorization se=
rver may, 
>> in the OAuth 2.0 framework, be entities produced by d=
ifferent vendors 
>> there is an interoperability need. Justin resp=
onded that he disagrees 
>> and that the resource server needs to u=
nderstand the access token and 
>> referred to the recent draft sub=
mission for the token introspection 
>> endpoint. Derek indicated t=
hat the resource server has to understand 
>>
 the content of the access token and the token introspection endpoint 
&g=
t;> just pushes the problem around: the resource server has to send the <=
br>>> access token to the authorization server and then the resource s=
erver 
>> gets the result back (which he the
 n
>  &n=
bsp; a
>> gain needs to understand) in order to make a meaningful a=
uthorization decision.
>>
>> Everyone agreed that the clie=
nt must receive the session key from the authorization server and that this a=
pproach has to be standardized. It was also agreed that this is a common app=
roach among all three key distribution mechanisms.
>>
>> H=
annes asked the participants to think about their preference.
>>>> The questions regarding key naming and the indication for the inte=
nded resource server the client wants to talk to have been postponed.
>=
;>
>> 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.orgh=
ttps://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
=

--Apple-Mail-B66DAEAC-1D9A-4813-8A97-C9FAC28EB1B1--

From wmills_92105@yahoo.com  Thu Feb 14 23:08:39 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1AB921F86D9 for ; Thu, 14 Feb 2013 23:08:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.078
X-Spam-Level: 
X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=0.520,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3+icQtyxCZW for ; Thu, 14 Feb 2013 23:08:38 -0800 (PST)
Received: from nm40.bullet.mail.bf1.yahoo.com (nm40.bullet.mail.bf1.yahoo.com [72.30.239.128]) by ietfa.amsl.com (Postfix) with ESMTP id C785521F85D8 for ; Thu, 14 Feb 2013 23:08:37 -0800 (PST)
Received: from [98.139.214.32] by nm40.bullet.mail.bf1.yahoo.com with NNFMP; 15 Feb 2013 07:08:37 -0000
Received: from [98.139.215.228] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 15 Feb 2013 07:08:37 -0000
Received: from [127.0.0.1] by omp1068.mail.bf1.yahoo.com with NNFMP; 15 Feb 2013 07:08:37 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 264797.62767.bm@omp1068.mail.bf1.yahoo.com
Received: (qmail 65058 invoked by uid 60001); 15 Feb 2013 07:08:36 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360912116; bh=alSOdBK5sm8jcni55nRtclWnzQ2qu7hL4QRT1mGSDaY=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=1cqJZWkr3Y2KrSmpHTIT0mZuiqaEcr5k93O33RbXy9eEwOzlE76LyQdYyjib4CB8hXOhw6FAyOlvyKI7Q20U6CgctKX768gAmXQjC5wa36FID9C6xQKt6VWwiZZNDN9uz9bu/1noq1qIgO7+RQi61eSLx8mCO92wW1O/LugP3oc=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=diaf/dpG0mrGk6SkPQEGYDDz50M0oGHzeytEDaJbvRsP5N/FSxW0HZKMnqdENLPAWFo7JioItiq91MXt+9LEa9+Q05Px+nmwWUdbrZ/lrk33WLN2nBMGkAwb7WDelqELhUAlfGsl5Pn+zsdh5c1BIwangFSGCG+TaBZQ2twbe7g=;
X-YMail-OSG: g3b_TFYVM1kdpXkVf4IXEjzdhtnltA4hKo6fGK_RplxCjXJ LNb8Vd9dtgLSShOkAusaqbwe3oRcrbIova0tbxBpBDEvvK4SVd91JePvouDp .oPn8sOQ4SNu3aRDiUdqUkAfKefPfW3s0_PSA44JLmQVO6jQt26NfCFj4UbX wRcTcZ16gpHUuGnaHth9FSBu3SYC6EwEatvYJP5pf8yaaL3aASvucNf4hkdK U0MRXyv163rTcJGVSaoT5NFLYwXSwh0JrqDJr_HCimNbfagha1umE0SxGbhZ hgl5s2apDs83qcELJxYarPDVOKDynhPitBtdfX7NihhW4U6TC2WFYUSckWZB zuLLkNxN0mgngOLCSouSQgW0HFkT5UjCMsvzfCmuOJ1MSMemjLi6BGIGsbHu cGP3LOqwIugO26WUntCWUSy5Dt.hxwcYadjsYRSL.TrzS5oVrrqudX_btdsz rZX3B_ugK7Wt.Freli7598XaOoyoEkkTtbGFwb4jOh4hJaNgkHfzHJF0knes tDbKu5sMJcWsmGTtpSiP.7lfjUv03OBakIOTz8ayC.D7H8mSUY5Sng4PbXBl JS4PLqlPRlqsuSe8Rb9A0MyouJ1dH8LD0F3G1ScrvB7JdN9PXHOh90z9zVvf qQk.NNuKmrqvN3s8trH9_EXhEsIkKKKLbv3jF9sLnCE.7Eo7S9n3BA_lTlyL _bzmAKg--
Received: from [99.31.212.42] by web31811.mail.mud.yahoo.com via HTTP; Thu, 14 Feb 2013 23:08:35 PST
X-Rocket-MIMEInfo: 001.001, SSBmdW5kYW1lbnRhbGx5IGRpc2FncmVlIHdpdGggdGhhdCB0b28uIMKgT0F1dGggMiBpcyB0aGUgKmZyYW1ld29yayosIG9uZSB3aGljaCBzdXBwb3J0cyBtdWx0aXBsZSB0b2tlbiB0eXBlcy4gwqBCZWFyZXIgdG9rZW5zIHdlcmUgdGhlIGZpcnN0IGNyZWRlbnRpYWwgdHlwZSBkZWZpbmVkLgoKT0F1dGggMS4wYSBhbHNvIHJlcXVpcmVzIEhUVFBTIHRyYW5zcG9ydCBmb3IgYXV0aGVudGljYXRpb24gYW5kIGdldHRpbmcgdGhlIHRva2VuLgoKVGhlcmUgYXJlIMKgcmVhbCB1c2UgY2FzZXMgZm9yIHRva2VucyABMAEBAQE-
X-Mailer: YahooMailWebService/0.8.134.513
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net>  <511A7D27.8010209@mitre.org> <4E1F6AAD24975D4BA5B16804296739436744BD23@TK5EX14MBXC285.redmond.corp.microsoft.com> <1360891897.14004.YahooMailNeo@web31811.mail.mud.yahoo.com> 
Message-ID: <1360912115.36543.YahooMailNeo@web31811.mail.mud.yahoo.com>
Date: Thu, 14 Feb 2013 23:08:35 -0800 (PST)
From: William Mills 
To: Torsten Lodderstedt 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="764183289-258296331-1360912115=:36543"
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Feb 2013 07:08:39 -0000

--764183289-258296331-1360912115=:36543
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I fundamentally disagree with that too. =A0OAuth 2 is the *framework*, one =
which supports multiple token types. =A0Bearer tokens were the first creden=
tial type defined.=0A=0AOAuth 1.0a also requires HTTPS transport for authen=
tication and getting the token.=0A=0AThere are =A0real use cases for tokens=
 usable over plain text with integrity protection.=0A=0A-bill=0A=0A=0A_____=
___________________________=0A From: Torsten Lodderstedt =0ATo: William Mills  =0ACc: Mike Jones ; Justin Richer ; Phil Hunt ; IETF oauth WG  =0ASent: Thursday, Febr=
uary 14, 2013 10:05 PM=0ASubject: Re: [OAUTH-WG] Minutes from the OAuth Des=
ign Team Conference Call - 11th February 2013=0A =0A=0AHi Bill,=0A=0AOAuth =
2.0 took a different direction by relying on HTTPS to provide the basic pro=
tection. So the need to have a token, which can be used for service request=
s over plain HTTP is arguable. My understanding of this activity was, the i=
ntend is to provide additional protection on top of HTTPS.=0A=0Aregards,=0A=
Torsten.=0A=0AAm 15.02.2013 um 02:31 schrieb William Mills :=0A=0A=0AI disagree with "That was the impediment to OAuth 1.0 ado=
ption that OAuth 2.0 solved in the first place.", unless "solving" means do=
es not address the need for it at all.=0A>=0A>=0A>OAuth 2 does several good=
 things, but it still lacks a defined token type that is safe to user over =
plain text HTTP. =A01.0a solved that.=0A>=0A>=0A>=0A>______________________=
__________=0A> From: Mike Jones =0A>To: Justin=
 Richer ; Phil Hunt  =0A>Cc: IETF =
oauth WG  =0A>Sent: Thursday, February 14, 2013 1:44 PM=0A>=
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call =
- 11th February 2013=0A> =0A>I'm in favor of reusing the JWT work that this=
 WG is also doing. :-)=0A>=0A>I'm pretty skeptical of us inventing another =
custom scheme for signing HTTP headers.=A0 That was the impediment to OAuth=
 1.0 adoption that OAuth 2.0 solved in the first place.=0A>=0A>=A0=A0=A0 =
=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 -- Mike=0A>=0A>-----Original Message-----=0A>=
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J=
ustin Richer=0A>Sent: Tuesday, February 12, 2013 9:35 AM=0A>To: Phil Hunt=
=0A>Cc: IETF oauth WG=0A>Subject: Re: [OAUTH-WG] Minutes from the OAuth Des=
ign Team Conference Call - 11th February 2013=0A>=0A>That's my reading of i=
t as well, Phil, thanks for providing the clarification. One motivator behi=
nd using a JSON-based token is to be able to=0A re-use some of the great wo=
rk that the JOSE group is doing but apply it to an HTTP payload.=0A>=0A>Wha=
t neither of us want is a token type that requires stuffing all query, head=
er, and other parameters *into* the JSON object itself, which would be a mo=
re SOAPy approach.=0A>=0A>=A0 -- Justin=0A>=0A>On 02/12/2013 12:30 PM, Phil=
 Hunt wrote:=0A>> Clarification.=A0 I think Justin and I were in agreement =
that we don't want to see a format that requires JSON payloads.=A0 We are b=
oth interested in a JSON token used in the authorization header that could =
be based on a computed signature of some combination of http headers and bo=
dy if possible.=0A>>=0A>> Phil=0A>>=0A>> @independentid=0A>> www.independen=
tid.com=0A>> phil.hunt@oracle.com=0A>>=0A>>=0A>>=0A>>=0A>>=0A>> On=0A 2013-=
02-12, at 1:10 AM, Hannes Tschofenig wrote:=0A>>=0A>>> Here are my notes.=
=0A>>>=0A>>> Participants:=0A>>>=0A>>> * John Bradley=0A>>> * Derek Atkins=
=0A>>> * Phil Hunt=0A>>> * Prateek Mishra=0A>>> * Hannes Tschofenig=0A>>> *=
 Mike Jones=0A>>> * Antonio Sanso=0A>>> * Justin Richer=0A>>>=0A>>> Notes:=
=0A>>>=0A>>> My slides are available here: =0A>>> http://www.tschofenig.pri=
v.at/OAuth2-Security-11Feb2013.ppt=0A>>>=0A>>> Slide #2 summarizes earlier =
discussions during the conference calls.=0A>>>=0A>>> -- HTTP vs. JSON=0A>>>=
=0A>>> Phil noted that he does not like to use the MAC Token draft as a sta=
rting point because it does not re-use any of the work done in the JOSE wor=
king group and in particular all the libraries that are available today. He=
 mentioned that earlier attempts to write the MAC Token code lead to=0A pro=
blems for implementers.=0A>>>=0A>>> Justin responded that he does not agree=
 with using JSON as a transport mechanism since this would replicate a SOAP=
 style.=0A>>>=0A>>> Phil noted that he wants to send JSON but the signature=
 shall be computed over the HTTP header field.=0A>>>=0A>>> -- Flexibility f=
or the keyed message digest computation=0A>>>=0A>>>=A0 From earlier discuss=
ion it was clear that the conference call participants wanted more flexibil=
ity regarding the keyed message digest computation. For this purpose Hannes=
 presented the DKIM based approach, which allows selective header fields to=
 be included in the digest. This is shown in slide #4.=0A>>>=0A>>> After so=
me discussion the conference call participants thought that this would meet=
 their needs. Further investigations would still be useful to determine the=
 degree of failed HMAC calculations due to HTTP proxies modifying the=0A co=
ntent.=0A>>>=0A>>> -- Key Distribution=0A>>>=0A>>> Hannes presented the ope=
n issue regarding the choice of key =0A>>> distribution. Slides #6-#8 prese=
nt three techniques and Hannes asked =0A>>> for feedback regarding the pref=
erred style. Justin and others didn't =0A>>> see the need to decide on one =
mechanism - they wanted to keep the =0A>>> choice open. Derek indicated tha=
t this will not be an acceptable =0A>>> approach. Since the resource server=
 and the authorization server may, =0A>>> in the OAuth 2.0 framework, be en=
tities produced by different vendors =0A>>> there is an interoperability ne=
ed. Justin responded that he disagrees =0A>>> and that the resource server =
needs to understand the access token and =0A>>> referred to the recent draf=
t submission for the token introspection =0A>>> endpoint. Derek indicated t=
hat the resource server has to understand =0A>>>=0A the content of the acce=
ss token and the token introspection endpoint =0A>>> just pushes the proble=
m around: the resource server has to send the =0A>>> access token to the au=
thorization server and then the resource server =0A>>> gets the result back=
 (which he the=0A>n=0A>>=A0 =A0 a=0A>>> gain needs to understand) in order =
to make a meaningful authorization decision.=0A>>>=0A>>> Everyone agreed th=
at the client must receive the session key from the authorization server an=
d that this approach has to be standardized. It was also agreed that this i=
s a common approach among all three key distribution mechanisms.=0A>>>=0A>>=
> Hannes asked the participants to think about their preference.=0A>>>=0A>>=
> The questions regarding key naming and the indication for the intended re=
source server the client wants to talk to have been postponed.=0A>>>=0A>>> =
Ciao=0A>>>=0A Hannes=0A>>>=0A>>>=0A>>> ____________________________________=
___________=0A>>> OAuth mailing list=0A>>> OAuth@ietf.org=0A>>> https://www=
.ietf.org/mailman/listinfo/oauth=0A>> _____________________________________=
__________=0A>> OAuth mailing list=0A>> OAuth@ietf.org=0A>> https://www.iet=
f.org/mailman/listinfo/oauth=0A>=0A>=0A>___________________________________=
____________=0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https://www.ietf.or=
g/mailman/listinfo/oauth=0A>_______________________________________________=
=0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https://www.ietf.org/mailman/li=
stinfo/oauth=0A>=0A>=0A>=0A_______________________________________________=
=0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https://www.ietf.org/mailman/li=
stinfo/oauth=0A>
--764183289-258296331-1360912115=:36543
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I fundamentally disagree with that too.  OAuth 2 is the *framework*,=
 one which supports multiple token types.  Bearer tokens were the firs=
t credential type defined.

OAuth 1.0a also requires HTTPS transpo=
rt for authentication and getting the token.

There are &nbs=
p;real use cases for tokens usable over plain text with integrity protectio=
n.

-bill

   <=
div style=3D"font-family: 'times new roman', 'new york', times, serif; font=
-size: 12pt;">   =20
 From: Torsten Lodderstedt =
<torsten@lodderstedt.net>
 T=
o: William Mills <wmills_92105@yahoo.com> 
Cc: Mike Jones <Michael.Jones@micro=
soft.com>; Justin Richer <jricher@mitre.org>; Phil Hunt <phil.h=
unt@oracle.com>; IETF oauth WG <oauth@ietf.org> 
 Sent: Thursday, February 14, 2013 10:05=
 PM
 Subject: Re: [OAUT=
H-WG] Minutes from the OAuth Design Team Conference Call - 11th February 20=
13

=0AHi Bill,
OAuth 2.0 took a different direction by relying on =
HTTPS to provide the basic protection. So the need to have a token, which c=
an be used for service requests over plain HTTP is arguable. My understandi=
ng of this activity was, the intend is to provide additional protection on =
top of HTTPS.

regards,
Torsten.

Am 15.02.2013 um 02:31 schrieb William Mills <wmills_92105@yahoo.com>:

I disagree with "That was the impediment to
 OAuth 1.0 adoption that OAuth 2.0 solved in the first place.", unless "sol=
ving" means does not address the need for it at all.

OAuth 2 does=
 several=0A good things, but it still lacks a defined token type that is sa=
fe to user over plain text HTTP.  1.0a solved that.
<=
br>

  From: Mike Jones <Michael.Jones@microsoft.com>
 To: Justin Richer <jricher@mitre.org>; Phil Hunt <phil.hunt@oracle.com> 
<=
span style=3D"font-weight:bold;">Cc: IETF oauth WG <oauth@ietf.org> 
 Sent: Thursday, February 14, 2013 1:44 PM
 Subject: Re: [OAUTH-WG] Minutes from=
 the OAuth Design Team Conference Call - 11th February 2013
=0A  =

=0AI'm in favor of reusing the JWT work that this WG is also doi=
ng. :-)

I'm pretty skeptical of us inventing another custom scheme f=
or signing HTTP headers.  That was the impediment to OAuth 1.0 adoptio=
n that OAuth 2.0 solved in the first place.

     =
;           -- Mike

-----Ori=
ginal Message-----
From: oau=
th-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Tuesday, F=
ebruary 12, 2013 9:35 AM
To: Phil Hunt
Cc: IETF oauth WG
Subject: =
Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th Fe=
bruary 2013

That's my reading of it as well, Phil, thanks for provid=
ing the clarification.
 One motivator behind using a JSON-based token is to be able to=0A re-use s=
ome of the great work that the JOSE group is doing but apply it to an HTTP =
payload.

What neither of us want is a token type that requires stuff=
ing all query, header, and other parameters *into* the JSON object itself, =
which would be a more SOAPy approach.

  -- Justin

On 02/=
12/2013 12:30 PM, Phil Hunt wrote:
> Clarification.  I think Jus=
tin and I were in agreement that we don't want to see a format that require=
s JSON payloads.  We are both interested in a JSON token used in the a=
uthorization header that could be based on a computed signature of some com=
bination of http headers and body if possible.
>
> Phil
>=

> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
&=
gt;
>
>
>
> On=0A 2013-02-12, at 1:10 AM, Hannes Ts=
chofenig wrote:
>
>> Here are my notes.
>>
>&=
gt; Participants:
>>
>> * John Bradley
>> * Dere=
k Atkins
>> * Phil Hunt
>> * Prateek Mishra
>> *=
 Hannes Tschofenig
>> * Mike Jones
>> * Antonio Sanso
=
>> * Justin Richer
>>
>> Notes:
>>
>=
> My slides are available here: 
>> http://www.tschofenig.priv.=
at/OAuth2-Security-11Feb2013.ppt
>>
>> Slide #2 summarize=
s earlier discussions during the conference calls.
>>
>> =
-- HTTP vs. JSON
>>
>> Phil noted that he does not like t=
o use the MAC Token draft as a starting point because it does not re-use an=
y of the work done in the JOSE working group and in particular all the libr=
aries that are available today. He mentioned that earlier attempts to write=
 the MAC Token code lead to=0A problems for implementers.
>>
&g=
t;> Justin responded that he does not agree with using JSON as a transpo=
rt mechanism since this would replicate a SOAP style.
>>
>&g=
t; Phil noted that he wants to send JSON but the signature shall be compute=
d over the HTTP header field.
>>
>> -- Flexibility for th=
e keyed message digest computation
>>
>>  From earli=
er discussion it was clear that the conference call participants wanted mor=
e flexibility regarding the keyed message digest computation. For this purp=
ose Hannes presented the DKIM based approach, which allows selective header=
 fields to be included in the digest. This is shown in slide #4.
>>=
;
>> After some discussion the conference call participants though=
t that this would meet their needs. Further investigations would still be u=
seful to determine the degree of failed HMAC calculations due to HTTP proxi=
es modifying the=0A content.
>>
>> -- Key Distribution>>
>> Hannes presented the open issue regarding the choice =
of key 
>> distribution. Slides #6-#8 present three techniques and=
 Hannes asked 
>> for feedback regarding the preferred style. Just=
in and others didn't 
>> see the need to decide on one mechanism -=
 they wanted to keep the 
>> choice open. Derek indicated that thi=
s will not be an acceptable 
>> approach. Since the resource serve=
r and the authorization server may, 
>> in the OAuth 2.0 framework=
, be entities produced by different vendors 
>> there is an intero=
perability need. Justin responded that he disagrees 
>> and that t=
he resource server needs to understand the access token and 
>> re=
ferred to the recent draft submission for the token introspection 
>&=
gt; endpoint. Derek indicated that the resource server has to understand >>=0A the content of the access token and the token introspection e=
ndpoint 
>> just pushes the problem around: the resource server ha=
s to send the 
>> access token to the authorization server and the=
n the resource server 
>> gets the result back (which he the
 n=

>    a
>> gain needs to understand) in order to m=
ake a meaningful authorization decision.
>>
>> Everyone a=
greed that the client must receive the session key from the authorization s=
erver and that this approach has to be standardized. It was also agreed tha=
t this is a common approach among all three key distribution mechanisms.>>
>> Hannes asked the participants to think about their pr=
eference.
>>
>> The questions regarding key naming and th=
e indication for the intended resource server the client wants to talk to h=
ave been postponed.
>>
>> Ciao
>>=0A Hannes
&=
gt;>
>>
>> ___________________________________________=
____
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailm=
an/listinfo/oauth
> _____________________________________________=
__
> OAuth mailing list
> OAuth@iet=
f.org
> https://www.ietf.org/mailman/listinfo/oau=
th

_______________________________________________
OAuth =
mailing list
OAuth@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/oauth
___________________________=
____________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinf=
o/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/=
mailman/listinfo/oauth

 =20

--764183289-258296331-1360912115=:36543--

From jricher@mitre.org  Fri Feb 15 06:59:19 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D8F21F85C3 for ; Fri, 15 Feb 2013 06:59:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.572
X-Spam-Level: 
X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8tZs0w-kIEl for ; Fri, 15 Feb 2013 06:59:18 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id B1AC121F8803 for ; Fri, 15 Feb 2013 06:59:18 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 102C55310093 for ; Fri, 15 Feb 2013 09:59:18 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C56C1439002F for ; Fri, 15 Feb 2013 09:59:17 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 15 Feb 2013 09:59:17 -0500
Message-ID: <511E4D17.1020805@mitre.org>
Date: Fri, 15 Feb 2013 09:58:31 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: "oauth@ietf.org" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.58]
Subject: Re: [OAUTH-WG] Registration: JSON Encoded Input
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Feb 2013 14:59:19 -0000

In case people missed a subtle change, I wanted to bring it to the 
group's attention:

The metadata parameters "request_uri" and "grant_type" are now JSON 
lists instead of space-separated lists of strings. The "scope" parameter 
remains a space-separated string, taking its definition from RFC6749 
section 3.3. This is due to a conversation that came up around the use 
of the "scope" parameter in the introspection endpoint, and folks 
generally thought that the definitions should match.

If we do JSON input (which there seems to be overwhelming support for), 
then I believe we should at the very least split up lists that are lists 
instead of forcing clients and servers to do string parsing.

  -- Justin

On 02/11/2013 04:14 PM, Justin Richer wrote:
> Draft -05 of OAuth Dynamic Client Registration [1] switched from a 
> form-encoded input that had been used by drafts -01 through -04 to a 
> JSON encoded input that was used originally in -00. Note that all 
> versions keep JSON-encoded output from all operations.
>
> Pro:
>  - JSON gives us a rich data structure so that things such as lists, 
> numbers, nulls, and objects can be represented natively
>  - Allows for parallelism between the input to the endpoint and output 
> from the endpoint, reducing possible translation errors between the two
>  - JSON specifies UTF8 encoding for all strings, forms may have many 
> different encodings
>  - JSON has minimal character escaping required for most strings, 
> forms require escaping for common characters such as space, slash, 
> comma, etc.
>
> Con:
>  - the rest of OAuth is form-in/JSON-out
>  - nothing else in OAuth requires the Client to create a JSON object, 
> merely to parse one
>  - form-in/JSON-out is a very widely established pattern on the web today
>  - Client information (client_name, client_id, etc.) is conflated with 
> access information (registration_access_token, _links, expires_at, 
> etc.) in root level of the same JSON object, leaving the client to 
> decide what needs to (can?) be sent back to the server for update 
> operations.
>
>
> Alternatives include any number of data encoding schemes, including 
> form (like the old drafts), XML, ASN.1, etc.
>
>
>  -- Justin
>
> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

From ve7jtb@ve7jtb.com  Fri Feb 15 07:11:15 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8597B21F8839 for ; Fri, 15 Feb 2013 07:11:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.395
X-Spam-Level: 
X-Spam-Status: No, score=-3.395 tagged_above=-999 required=5 tests=[AWL=0.204,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClNQcHjaMn+P for ; Fri, 15 Feb 2013 07:11:14 -0800 (PST)
Received: from mail-gh0-f175.google.com (mail-gh0-f175.google.com [209.85.160.175]) by ietfa.amsl.com (Postfix) with ESMTP id B3E2D21F8824 for ; Fri, 15 Feb 2013 07:11:14 -0800 (PST)
Received: by mail-gh0-f175.google.com with SMTP id g18so107156ghb.34 for ; Fri, 15 Feb 2013 07:11:14 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=RU2kHDLbkMIKNc4/SgCVnaFu/AtZ8/yknJbaX3HTRsY=; b=Z9f8qXWdRTCEpdxKJUEWbf7RqME5VbWnHH5CL+8rsLJtV/1TSbmNJ+so+V9UKaN9Za iPkyvOzj0HvhD72NbNIGy9WMkbunNQDcdl0k2gXVqycK0JrBU16/aMEpURSylXDpcqyx Vy9jriwxuqrB388SprUZJgp7a+WUYwzcoR0huSJH7Xtv3ID5yPy6MjMbiGwT90whR3cv WL/oSaQWa5F9qORbMVAkLDYiIDKX26mB/D0RIHcVHe/pNKB5QaJSz+JCkJq2fiDgnmPO 8lML1dcxrHTscNPC8r2DKJX4zO1i4d8pNPqfVOJ2ehfVH8tZ8r9is3SYsplIQw14KxbI fGYw==
X-Received: by 10.101.180.21 with SMTP id h21mr874693anp.71.1360941074019; Fri, 15 Feb 2013 07:11:14 -0800 (PST)
Received: from [192.168.1.213] (190-20-20-115.baf.movistar.cl. [190.20.20.115]) by mx.google.com with ESMTPS id v43sm90068294yhm.11.2013.02.15.07.11.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Feb 2013 07:11:12 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$)
From: John Bradley 
In-Reply-To: <511E4D17.1020805@mitre.org>
Date: Fri, 15 Feb 2013 12:11:04 -0300
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <511E4D17.1020805@mitre.org>
To: Justin Richer 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQm2qYWRCO4hUVdA1xvFt2OU7P37zGYxT2xIZ9nOwIBNkJZDJ0qfzuUxTcDAwb2DJslDCUS9
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: JSON Encoded Input
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Feb 2013 15:11:15 -0000

Parameters that can be JSON lists rather than space separated sting s =
probably should be unless there is some compelling reason as in scopes =
to keep them space separated.   May as well save unnecessary string =
parsing.
=20
John B.

On 2013-02-15, at 11:58 AM, Justin Richer  wrote:

> In case people missed a subtle change, I wanted to bring it to the =
group's attention:
>=20
> The metadata parameters "request_uri" and "grant_type" are now JSON =
lists instead of space-separated lists of strings. The "scope" parameter =
remains a space-separated string, taking its definition from RFC6749 =
section 3.3. This is due to a conversation that came up around the use =
of the "scope" parameter in the introspection endpoint, and folks =
generally thought that the definitions should match.
>=20
> If we do JSON input (which there seems to be overwhelming support =
for), then I believe we should at the very least split up lists that are =
lists instead of forcing clients and servers to do string parsing.
>=20
> -- Justin
>=20
> On 02/11/2013 04:14 PM, Justin Richer wrote:
>> Draft -05 of OAuth Dynamic Client Registration [1] switched from a =
form-encoded input that had been used by drafts -01 through -04 to a =
JSON encoded input that was used originally in -00. Note that all =
versions keep JSON-encoded output from all operations.
>>=20
>> Pro:
>> - JSON gives us a rich data structure so that things such as lists, =
numbers, nulls, and objects can be represented natively
>> - Allows for parallelism between the input to the endpoint and output =
from the endpoint, reducing possible translation errors between the two
>> - JSON specifies UTF8 encoding for all strings, forms may have many =
different encodings
>> - JSON has minimal character escaping required for most strings, =
forms require escaping for common characters such as space, slash, =
comma, etc.
>>=20
>> Con:
>> - the rest of OAuth is form-in/JSON-out
>> - nothing else in OAuth requires the Client to create a JSON object, =
merely to parse one
>> - form-in/JSON-out is a very widely established pattern on the web =
today
>> - Client information (client_name, client_id, etc.) is conflated with =
access information (registration_access_token, _links, expires_at, etc.) =
in root level of the same JSON object, leaving the client to decide what =
needs to (can?) be sent back to the server for update operations.
>>=20
>>=20
>> Alternatives include any number of data encoding schemes, including =
form (like the old drafts), XML, ASN.1, etc.
>>=20
>>=20
>> -- Justin
>>=20
>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From torsten@lodderstedt.net  Fri Feb 15 07:22:39 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3963821F8A49 for ; Fri, 15 Feb 2013 07:22:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.208
X-Spam-Level: 
X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzdJeDfa9BCg for ; Fri, 15 Feb 2013 07:22:37 -0800 (PST)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.30]) by ietfa.amsl.com (Postfix) with ESMTP id DD44221F8A47 for ; Fri, 15 Feb 2013 07:22:36 -0800 (PST)
Received: from [91.2.95.252] (helo=[192.168.71.56]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1U6N7S-0007LE-Gv; Fri, 15 Feb 2013 16:22:34 +0100
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net>  <511A7D27.8010209@mitre.org> <4E1F6AAD24975D4BA5B16804296739436744BD23@TK5EX14MBXC285.redmond.corp.microsoft.com> <1360891897.14004.YahooMailNeo@web31811.mail.mud.yahoo.com>  <1360912115.36543.YahooMailNeo@web31811.mail.mud.yahoo.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <1360912115.36543.YahooMailNeo@web31811.mail.mud.yahoo.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-1E6E942E-DD8B-48EB-B86A-D13097EF24A5
Content-Transfer-Encoding: 7bit
Message-Id: <2A0F585F-2CEF-418D-9654-5084E6C9BD0D@lodderstedt.net>
X-Mailer: iPad Mail (10B141)
From: Torsten Lodderstedt 
Date: Fri, 15 Feb 2013 16:22:34 +0100
To: William Mills 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Feb 2013 15:22:39 -0000

--Apple-Mail-1E6E942E-DD8B-48EB-B86A-D13097EF24A5
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Hi Bill,

I think one needs to compare the costs/impact of HTTPS on one side and the i=
mplementation of integrity protection and replay detection on the other. We h=
ad this discussion several times.

regards,
Torsten.

Am 15.02.2013 um 08:08 schrieb William Mills :

> I fundamentally disagree with that too.  OAuth 2 is the *framework*, one w=
hich supports multiple token types.  Bearer tokens were the first credential=
 type defined.
>=20
> OAuth 1.0a also requires HTTPS transport for authentication and getting th=
e token.
>=20
> There are  real use cases for tokens usable over plain text with integrity=
 protection.
>=20
> -bill
>=20
> From: Torsten Lodderstedt 
> To: William Mills =20
> Cc: Mike Jones ; Justin Richer ; Phil Hunt ; IETF oauth WG =20
> Sent: Thursday, February 14, 2013 10:05 PM
> Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call=
 - 11th February 2013
>=20
> Hi Bill,
>=20
> OAuth 2.0 took a different direction by relying on HTTPS to provide the ba=
sic protection. So the need to have a token, which can be used for service r=
equests over plain HTTP is arguable. My understanding of this activity was, t=
he intend is to provide additional protection on top of HTTPS.
>=20
> regards,
> Torsten.
>=20
> Am 15.02.2013 um 02:31 schrieb William Mills :
>=20
>> I disagree with "That was the impediment to OAuth 1.0 adoption that OAuth=
 2.0 solved in the first place.", unless "solving" means does not address th=
e need for it at all.
>>=20
>> OAuth 2 does several good things, but it still lacks a defined token type=
 that is safe to user over plain text HTTP.  1.0a solved that.
>>=20
>> From: Mike Jones 
>> To: Justin Richer ; Phil Hunt =20=

>> Cc: IETF oauth WG =20
>> Sent: Thursday, February 14, 2013 1:44 PM
>> Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Cal=
l - 11th February 2013
>>=20
>> I'm in favor of reusing the JWT work that this WG is also doing. :-)
>>=20
>> I'm pretty skeptical of us inventing another custom scheme for signing HT=
TP headers.  That was the impediment to OAuth 1.0 adoption that OAuth 2.0 so=
lved in the first place.
>>=20
>>                 -- Mike
>>=20
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of=
 Justin Richer
>> Sent: Tuesday, February 12, 2013 9:35 AM
>> To: Phil Hunt
>> Cc: IETF oauth WG
>> Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Cal=
l - 11th February 2013
>>=20
>> That's my reading of it as well, Phil, thanks for providing the clarifica=
tion. One motivator behind using a JSON-based token is to be able to re-use s=
ome of the great work that the JOSE group is doing but apply it to an HTTP p=
ayload.
>>=20
>> What neither of us want is a token type that requires stuffing all query,=
 header, and other parameters *into* the JSON object itself, which would be a=
 more SOAPy approach.
>>=20
>>   -- Justin
>>=20
>> On 02/12/2013 12:30 PM, Phil Hunt wrote:
>> > Clarification.  I think Justin and I were in agreement that we don't wa=
nt to see a format that requires JSON payloads.  We are both interested in a=
 JSON token used in the authorization header that could be based on a comput=
ed signature of some combination of http headers and body if possible.
>> >
>> > Phil
>> >
>> > @independentid
>> > www.independentid.com
>> > phil.hunt@oracle.com
>> >
>> >
>> >
>> >
>> >
>> > On 2013-02-12, at 1:10 AM, Hannes Tschofenig wrote:
>> >
>> >> Here are my notes.
>> >>
>> >> Participants:
>> >>
>> >> * John Bradley
>> >> * Derek Atkins
>> >> * Phil Hunt
>> >> * Prateek Mishra
>> >> * Hannes Tschofenig
>> >> * Mike Jones
>> >> * Antonio Sanso
>> >> * Justin Richer
>> >>
>> >> Notes:
>> >>
>> >> My slides are available here:=20
>> >> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
>> >>
>> >> Slide #2 summarizes earlier discussions during the conference calls.
>> >>
>> >> -- HTTP vs. JSON
>> >>
>> >> Phil noted that he does not like to use the MAC Token draft as a start=
ing point because it does not re-use any of the work done in the JOSE workin=
g group and in particular all the libraries that are available today. He men=
tioned that earlier attempts to write the MAC Token code lead to problems fo=
r implementers.
>> >>
>> >> Justin responded that he does not agree with using JSON as a transport=
 mechanism since this would replicate a SOAP style.
>> >>
>> >> Phil noted that he wants to send JSON but the signature shall be compu=
ted over the HTTP header field.
>> >>
>> >> -- Flexibility for the keyed message digest computation
>> >>
>> >>  =46rom earlier discussion it was clear that the conference call parti=
cipants wanted more flexibility regarding the keyed message digest computati=
on. For this purpose Hannes presented the DKIM based approach, which allows s=
elective header fields to be included in the digest. This is shown in slide #=
4.
>> >>
>> >> After some discussion the conference call participants thought that th=
is would meet their needs. Further investigations would still be useful to d=
etermine the degree of failed HMAC calculations due to HTTP proxies modifyin=
g the content.
>> >>
>> >> -- Key Distribution
>> >>
>> >> Hannes presented the open issue regarding the choice of key=20
>> >> distribution. Slides #6-#8 present three techniques and Hannes asked=20=

>> >> for feedback regarding the preferred style. Justin and others didn't=20=

>> >> see the need to decide on one mechanism - they wanted to keep the=20
>> >> choice open. Derek indicated that this will not be an acceptable=20
>> >> approach. Since the resource server and the authorization server may,=20=

>> >> in the OAuth 2.0 framework, be entities produced by different vendors=20=

>> >> there is an interoperability need. Justin responded that he disagrees=20=

>> >> and that the resource server needs to understand the access token and=20=

>> >> referred to the recent draft submission for the token introspection=20=

>> >> endpoint. Derek indicated that the resource server has to understand=20=

>> >> the content of the access token and the token introspection endpoint=20=

>> >> just pushes the problem around: the resource server has to send the=20=

>> >> access token to the authorization server and then the resource server=20=

>> >> gets the result back (which he the
>> n
>> >    a
>> >> gain needs to understand) in order to make a meaningful authorization d=
ecision.
>> >>
>> >> Everyone agreed that the client must receive the session key from the a=
uthorization server and that this approach has to be standardized. It was al=
so agreed that this is a common approach among all three key distribution me=
chanisms.
>> >>
>> >> Hannes asked the participants to think about their preference.
>> >>
>> >> The questions regarding key naming and the indication for the intended=
 resource server the client wants to talk to have been postponed.
>> >>
>> >> 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
>>=20
>>=20
>> _______________________________________________
>> 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
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20

--Apple-Mail-1E6E942E-DD8B-48EB-B86A-D13097EF24A5
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Bill,

I th=
ink one needs to compare the costs/impact of HTTPS on one side and the imple=
mentation of integrity protection and replay detection on the other. We had t=
his discussion several times.

regards,
To=
rsten.

Am 15.02.2013 um 08:08 schrieb William Mills <wmills_92105@yahoo.com>:

<=
/div>I fundamentally disagree with that too.  OAuth 2=
 is the *framework*, one which supports multiple token types.  Bearer t=
okens were the first credential type defined.
OAuth 1.0a also requires H=
TTPS transport for authentication and getting the token.

There are  r=
eal use cases for tokens usable over plain text with integrity protection.

-bill

      =20
 From: Torsten Lodderstedt &=
lt;torsten@lodderstedt.net>=
;
 To: William Mills <=
;wmills_92105@yahoo.com> Cc: Mike Jones <Michael.Jones@microsoft.com>=
; Justin Richer <jricher@mitre.org>; Phil Hunt <phil.hunt@orac=
le.com>; IETF oauth WG <oauth@ie=
tf.org> 
 Sent: T=
hursday, February 14, 2013 10:05 PM
 Hi Bill,

OAuth 2=
.0 took a different direction by relying on HTTPS to provide the basic prote=
ction. So the need to have a token, which can be used for service requests o=
ver plain HTTP is arguable. My understanding of this activity was, the inten=
d is to provide additional protection on top of HTTPS.

<=
div>regards,
Torsten.

Am 15.02.2013 um 02:31 schrieb=
 William Mills <wmills_92105@y=
ahoo.com>:

I disagree with "That was the impediment to
 OAuth 1.0 adoption that OAuth 2.0 solved in the first place.", unless "solv=
ing" means does not address the need for it at all.

OAuth 2 does several
 good things, but it still lacks a defined token type that is safe to user o=
ver plain text HTTP.  1.0a solved that.

  From: Mike Jones <=
Michael.Jones@microsoft.com>
 To: Justin Richer <jricher@m=
itre.org>; Phil Hunt <phil.=
hunt@oracle.com> 
Cc:<=
/b> IETF oauth WG <oauth@ietf.org> 
 <=
b>Sent: Thursday, February 14, 2=
013 1:44 PM
 Subject: Re:=
 [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th Februa=
ry 2013

I'm in favor of reusing the JWT work that this WG is also doing. :-)

=
I'm pretty skeptical of us inventing another custom scheme for signing HTTP h=
eaders.  That was the impediment to OAuth 1.0 adoption that OAuth 2.0 s=
olved in the first place.

         =
;       -- Mike

-----Original Message-----From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org<=
/a>] On Behalf Of Justin Richer
Sent: Tuesday, February 12, 2013 9:35 AM<=
br>To: Phil Hunt
Cc: IETF oauth WG
Subject: Re: [OAUTH-WG] Minutes fro=
m the OAuth Design Team Conference Call - 11th February 2013

That's m=
y reading of it as well, Phil, thanks for providing the clarification.
 One motivator behind using a JSON-based token is to be able to
 re-use some of the great work that the JOSE group is doing but apply it to a=
n HTTP payload.

What neither of us want is a token type that requires=
 stuffing all query, header, and other parameters *into* the JSON object its=
elf, which would be a more SOAPy approach.

  -- Justin

On=
 02/12/2013 12:30 PM, Phil Hunt wrote:
> Clarification.  I think J=
ustin and I were in agreement that we don't want to see a format that requir=
es JSON payloads.  We are both interested in a JSON token used in the a=
uthorization header that could be based on a computed signature of some comb=
ination of http headers and body if possible.
>
> Phil
>> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>
>=

>
>
> On
 2013-02-12, at 1:10 AM, Hannes Tschofenig wrote:
>
>> Here a=
re my notes.
>>
>> Participants:
>>
>> *=
 John Bradley
>> * Derek Atkins
>> * Phil Hunt
>>=
 * Prateek Mishra
>> * Hannes Tschofenig
>> * Mike Jones>> * Antonio Sanso
>> * Justin Richer
>>
>&g=
t; Notes:
>>
>> My slides are available here: 
>>=
 htt=
p://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
>>
=
>> Slide #2 summarizes earlier discussions during the conference calls=
.
>>
>> -- HTTP vs. JSON
>>
>> Phil note=
d that he does not like to use the MAC Token draft as a starting point becau=
se it does not re-use any of the work done in the JOSE working group and in p=
articular all the libraries that are available today. He mentioned that earl=
ier attempts to write the MAC Token code lead to
 problems for implementers.
>>
>> Justin responded that he=
 does not agree with using JSON as a transport mechanism since this would re=
plicate a SOAP style.
>>
>> Phil noted that he wants to se=
nd JSON but the signature shall be computed over the HTTP header field.
&=
gt;>
>> -- Flexibility for the keyed message digest computation<=
br>>>
>>  =46rom earlier discussion it was clear that th=
e conference call participants wanted more flexibility regarding the keyed m=
essage digest computation. For this purpose Hannes presented the DKIM based a=
pproach, which allows selective header fields to be included in the digest. T=
his is shown in slide #4.
>>
>> After some discussion the c=
onference call participants thought that this would meet their needs. Furthe=
r investigations would still be useful to determine the degree of failed HMA=
C calculations due to HTTP proxies modifying the
 content.
>>
>> -- Key Distribution
>>
>>=
; Hannes presented the open issue regarding the choice of key 
>> d=
istribution. Slides #6-#8 present three techniques and Hannes asked 
>=
> for feedback regarding the preferred style. Justin and others didn't >> see the need to decide on one mechanism - they wanted to keep the=

>> choice open. Derek indicated that this will not be an acceptab=
le 
>> approach. Since the resource server and the authorization se=
rver may, 
>> in the OAuth 2.0 framework, be entities produced by d=
ifferent vendors 
>> there is an interoperability need. Justin resp=
onded that he disagrees 
>> and that the resource server needs to u=
nderstand the access token and 
>> referred to the recent draft sub=
mission for the token introspection 
>> endpoint. Derek indicated t=
hat the resource server has to understand 
>>
 the content of the access token and the token introspection endpoint 
&g=
t;> just pushes the problem around: the resource server has to send the <=
br>>> access token to the authorization server and then the resource s=
erver 
>> gets the result back (which he the
 n
>  &n=
bsp; a
>> gain needs to understand) in order to make a meaningful a=
uthorization decision.
>>
>> Everyone agreed that the clie=
nt must receive the session key from the authorization server and that this a=
pproach has to be standardized. It was also agreed that this is a common app=
roach among all three key distribution mechanisms.
>>
>> H=
annes asked the participants to think about their preference.
>>>> The questions regarding key naming and the indication for the inte=
nded resource server the client wants to talk to have been postponed.
>=
;>
>> 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/oa=
uth

_______________________________________________
OAuth m=
ailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
________________________=
_______________________
OAuth mailing list
=
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/o=
auth

_______________________________________________=

OAuth mailing list
OAut=
h@ietf.org
https://www.ietf.org/mailman/l=
istinfo/oauth

 <=
/div>=20
 =

--Apple-Mail-1E6E942E-DD8B-48EB-B86A-D13097EF24A5--

From ve7jtb@ve7jtb.com  Fri Feb 15 07:46:23 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F3921F878F for ; Fri, 15 Feb 2013 07:46:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.101
X-Spam-Level: 
X-Spam-Status: No, score=-3.101 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_00=-2.599, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzsuGzcmi-ot for ; Fri, 15 Feb 2013 07:46:21 -0800 (PST)
Received: from mail-gh0-f181.google.com (mail-gh0-f181.google.com [209.85.160.181]) by ietfa.amsl.com (Postfix) with ESMTP id 8137121F8650 for ; Fri, 15 Feb 2013 07:46:21 -0800 (PST)
Received: by mail-gh0-f181.google.com with SMTP id y8so120132ghb.26 for ; Fri, 15 Feb 2013 07:46:20 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=kuiWQmz5E+KuaN7c3Ko73yOCcDIZrtKExQhFEJWqujw=; b=OWkvx5sKp1LSo8ED2XEQZIhdc4bcuDKSXcK1s5ghMmdv2yU03eL6oJbYn4F0q6yAgJ E0hiCKXffJVJZDfzuQqqkwb522rk1ns5LVvvhUk6ZwziiVCZgPliHrSFuJLW3bMxIMoV gQld6c7SXliF5EEWRHDf9RcZ0b+nD0GfI3SKg9HKme5oITQahLHc+e7P28oYEu8AUlPq B/hyVZNnzmxSXENAIJNp+HZ4/FMVhIUOLtfcetw7sGI+6EtOERrB2t21ash/kbeovw8D rcJvtB5IzmBEVlEjKj9+FRnwQK/0nV46k7FTrQmO1nZM0Mm6zr3/V+0fqJYoGvPYXWUX 3C9w==
X-Received: by 10.236.123.109 with SMTP id u73mr3177923yhh.108.1360943180699;  Fri, 15 Feb 2013 07:46:20 -0800 (PST)
Received: from [192.168.1.213] (190-20-20-115.baf.movistar.cl. [190.20.20.115]) by mx.google.com with ESMTPS id p7sm11837226anl.20.2013.02.15.07.46.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Feb 2013 07:46:19 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_76435579-B0FA-450E-A9F6-934B00462EFA"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <511D3919.4090906@oracle.com>
Date: Fri, 15 Feb 2013 12:45:30 -0300
Message-Id: <31EAE509-0850-4F09-B29B-D02FB1156936@ve7jtb.com>
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net> <511BBBAC.9060502@oracle.com> <0DF3F088-7F15-4C0F-85C4-35DE80CB01E0@gmx.net> <511CEDFB.6010908@mitre.org> <511D3919.4090906@oracle.com>
To: Prateek Mishra 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQmxL02pHAO7pduAEc0CGcIqKmeroj1qFBEOmvWI8qxVJtUPD6EBkyPKi99xkObRpVRmtluT
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Feb 2013 15:46:23 -0000

--Apple-Mail=_76435579-B0FA-450E-A9F6-934B00462EFA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Remember that proof of possession is intended to prove that the client =
that was issued the token is the one presenting it.  =20
We tend to mix that up with replay and other protection issues.

To do this you don't need to authenticate the client. =20
The client can prove it controls a key by signing something for the =
Authorization server,  the AS then includes the public key in the JWS =
access token.   The client then produces a hash over some number of =
elements and signs that with its private key in a JWS.

With asymmetric there is no need for the AS to produce the key.    =
Having the client produce the key pair is quite traditional proof of =
possession.

The RS only needs to verify the access token in the way a RS would =
normally all the key distribution can be public as it is public keys.

I have always found the symmetric proof of possession mechanisms to be =
painfully complex to do properly with DH etc.

Encrypting the symmetric key to the RS would work but relays on an =
implicit assumption about what RS the client may present the token to =
otherwise all the RS have to share private keys(probably a bad thing)

John B.

On 2013-02-14, at 4:20 PM, Prateek Mishra  =
wrote:

> Justin - my comment was scoped to *key distribution* - not to the =
general use of public clients.
>=20
> I was wondering how one can distribute keys or have key agreement =
between an AS and a client, if there is no existing trust relationship =
between them. Maybe there is some
> clever crypto way of achieving this, but I personally dont understand =
how this might happen.
>=20
> - prateek
>=20
>>=20
>>>> 2) Regarding (symmetric) key distribution, dont we need some kind =
of existing trust relationship between the client and AS to make this =
possible? I guess it
>>>> would be enough to require use of a "confidential" client, that =
would make it possible for the two parties to agree on a session key at =
the point where an access token
>>>> is  issued by the AS.
>>> That's a very good question. I have not formed an option about this =
issue yet particularly given the recent capability to dynamically =
register clients.
>>=20
>> I don't think that signing tokens should require confidential =
clients. This was one of the implementation issues with OAuth 1, as it =
required a "consumer_secret" at all times. This led to Google telling =
people to use "anonymous" as the "consumer_secret" for what were =
effectively public clients. Even with dynamic registration, there's =
still a place for public clients, in my opinion.
>>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail=_76435579-B0FA-450E-A9F6-934B00462EFA
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINTTCCBjQw
ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX
DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK
75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC
+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD
z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr
/+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc
fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG
XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt
UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R
HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv
sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s
sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq
+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT
zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq
Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1
9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHETCCBfmg
AwIBAgIDBOksMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN
MTIwOTEyMDIzOTAxWhcNMTMwOTEzMDgwMTI2WjBZMRkwFwYDVQQNExBiOGllSVBENlkyc2Q3UTNx
MRowGAYDVQQDDBF2ZTdqdGJAdmU3anRiLmNvbTEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0
Yi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ohs8ck2PVlK8aOtADZe7EBa5
TOxxLczMptoUqLTUtznvutheiBa2oQtAGbIfckjyHkLpxlrYhDVHEKObDYNAueWMMVSmEFoRLz3Q
Qui0f2cLyuim8+Xcr+7OtmR+ndeDyEYDhdkAMQ8rZwQSQPfSKVqC8Q9rhMfVl9fVZ5iRzPRQso3J
q31wcOqOfvT+t+sbTxMTMFSt7jZoF0aNN8tAbPYP5o0ZEHIrkbI74JPAGzb91Ezd8rEFPaCTiKY6
RlYfaX+zdspzFmjhsewh7jRAsZJ7yeFHK+UDZiHhf1/y6xxt/IdrIqz609nV18/BJ9KbDHWbBWn6
TJt0xugqhExXAgMBAAGjggOsMIIDqDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAU
BggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLNXqc9hE1qG3GFGwE9VIl/4SNVvMB8GA1Ud
IwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29t
MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3Rh
cnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQg
YWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBT
dGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3Nl
IGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEF
BQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxp
dHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGlt
aXRhdGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0
dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBC
BggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGll
bnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0B
AQUFAAOCAQEAfZgjJCgKtxwFgETwYuafNtdxgNpVR7YNHVRraJWiXAHUFJo4X3STJJP3nBYi7zmq
wAUUpDiIcH6KcJxlTq0GSU/UEWivMeI6roy8ySebFGBDM/GiN9Kl/PEZWIpZX9f2BmLGtFMsa7Mx
UuhlF55zeN52f/SCWHO5fCVr+sOmb1HMdo3YN2k/BYT+5S0xPxQn7U7mbuew+FG5iouFu6anB5tI
26nTcu3B1HTLVWVfViH/v7KiTnkT7lCejRANERBTrC9j2KVDNrMpysaCjWShBnYyhLxxgUSismIg
gPfj8G2i3NKHV6ZCOFKXMOpUAZ9WtJVz6vnBP4XDF7FpQjjiBzGCA28wggNrAgEBMIGUMIGMMQsw
CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0
YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5
IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwTpLDAJBgUrDgMCGgUAoIIBrzAYBgkqhkiG9w0BCQMx
CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzAyMTUxNTQ1MzRaMCMGCSqGSIb3DQEJBDEW
BBS1CXnu3YFbd80aa/czEKShVK3w0TCBpQYJKwYBBAGCNxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJ
TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm
aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVk
aWF0ZSBDbGllbnQgQ0ECAwTpLDCBpwYLKoZIhvcNAQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklM
MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp
Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQIDBOksMA0GCSqGSIb3DQEBAQUABIIBAIzf1Yp4nCFcgjjEuee0H4MpfQHP
Rf+4PjQ96Kphg6zwqPvqS2U/LefaTswwo++nHvZWtB0U0ZbLvUxWyYAD3nB4E5I3wFNwq0IxvgZJ
REwB+uKYgmVUAdgaVjOHH7dzZOiqGRqzYRPsEuRYAJrRGDpG0pfk9ppeeWpDwak9Q2fLL6FBIrbF
STlC5q/6qrtjZK2JyG0KFagP6kscUQQdbqHHEKMnrlBRwq50/XlVJfyqLRMDJ4mQbEqyxDiEw6fP
jlEDQ2wSRUFV16L+CIkXNlT7hAU5ThCwt7ap5OlkoJR0wLytVmi712Cjit8lgsOETInVAYOQE2jC
/gYEtP2JMssAAAAAAAA=

--Apple-Mail=_76435579-B0FA-450E-A9F6-934B00462EFA--

From prateek.mishra@oracle.com  Fri Feb 15 08:00:57 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C70621F8522 for ; Fri, 15 Feb 2013 08:00:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xd76bfvkXIa4 for ; Fri, 15 Feb 2013 08:00:55 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id B05E721F8519 for ; Fri, 15 Feb 2013 08:00:55 -0800 (PST)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1FG0svj003724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 Feb 2013 16:00:55 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1FG0rhG016984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Feb 2013 16:00:53 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1FG0qf7026140; Fri, 15 Feb 2013 10:00:53 -0600
Received: from [192.168.1.4] (/71.184.95.145) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 15 Feb 2013 08:00:53 -0800
Message-ID: <511E5BB7.9060104@oracle.com>
Date: Fri, 15 Feb 2013 11:00:55 -0500
From: Prateek Mishra 
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: John Bradley 
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net> <511BBBAC.9060502@oracle.com> <0DF3F088-7F15-4C0F-85C4-35DE80CB01E0@gmx.net> <511CEDFB.6010908@mitre.org> <511D3919.4090906@oracle.com> <31EAE509-0850-4F09-B29B-D02FB1156936@ve7jtb.com>
In-Reply-To: <31EAE509-0850-4F09-B29B-D02FB1156936@ve7jtb.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Feb 2013 16:00:57 -0000

John - two separate issues here -

(i) for the symmetric key case, whether we need a key distribution 
method for the client and AS/RS, and if so, what form should it take?

(ii) asymmetric case is quite different, I agree with your point - the 
client could be pre-provisioned with a managed key pair (many enterprise 
cases)
or generate them ephemerally. We dont need a key distribution method here.

Unfortunately, its hard to get away from the symmetric key case, maybe 
this will change once we have widespread support for ecc.

- prateek
> Remember that proof of possession is intended to prove that the client that was issued the token is the one presenting it.
> We tend to mix that up with replay and other protection issues.
>
> To do this you don't need to authenticate the client.
> The client can prove it controls a key by signing something for the Authorization server,  the AS then includes the public key in the JWS access token.   The client then produces a hash over some number of elements and signs that with its private key in a JWS.
>
> With asymmetric there is no need for the AS to produce the key.    Having the client produce the key pair is quite traditional proof of possession.
>
> The RS only needs to verify the access token in the way a RS would normally all the key distribution can be public as it is public keys.
>
> I have always found the symmetric proof of possession mechanisms to be painfully complex to do properly with DH etc.
>
> Encrypting the symmetric key to the RS would work but relays on an implicit assumption about what RS the client may present the token to otherwise all the RS have to share private keys(probably a bad thing)
>
> John B.
>
> On 2013-02-14, at 4:20 PM, Prateek Mishra  wrote:
>
>> Justin - my comment was scoped to *key distribution* - not to the general use of public clients.
>>
>> I was wondering how one can distribute keys or have key agreement between an AS and a client, if there is no existing trust relationship between them. Maybe there is some
>> clever crypto way of achieving this, but I personally dont understand how this might happen.
>>
>> - prateek
>>
>>>>> 2) Regarding (symmetric) key distribution, dont we need some kind of existing trust relationship between the client and AS to make this possible? I guess it
>>>>> would be enough to require use of a "confidential" client, that would make it possible for the two parties to agree on a session key at the point where an access token
>>>>> is  issued by the AS.
>>>> That's a very good question. I have not formed an option about this issue yet particularly given the recent capability to dynamically register clients.
>>> I don't think that signing tokens should require confidential clients. This was one of the implementation issues with OAuth 1, as it required a "consumer_secret" at all times. This led to Google telling people to use "anonymous" as the "consumer_secret" for what were effectively public clients. Even with dynamic registration, there's still a place for public clients, in my opinion.
>>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth

From wmills_92105@yahoo.com  Fri Feb 15 08:09:53 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85B421F84E2 for ; Fri, 15 Feb 2013 08:09:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.223
X-Spam-Level: 
X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=0.375,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60XXIBltmFOS for ; Fri, 15 Feb 2013 08:09:52 -0800 (PST)
Received: from nm37-vm3.bullet.mail.ne1.yahoo.com (nm37-vm3.bullet.mail.ne1.yahoo.com [98.138.229.131]) by ietfa.amsl.com (Postfix) with ESMTP id F32ED21F8438 for ; Fri, 15 Feb 2013 08:09:51 -0800 (PST)
Received: from [98.138.90.51] by nm37.bullet.mail.ne1.yahoo.com with NNFMP; 15 Feb 2013 16:09:51 -0000
Received: from [98.138.89.198] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 15 Feb 2013 16:09:51 -0000
Received: from [127.0.0.1] by omp1056.mail.ne1.yahoo.com with NNFMP; 15 Feb 2013 16:09:51 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 331015.13184.bm@omp1056.mail.ne1.yahoo.com
Received: (qmail 52388 invoked by uid 60001); 15 Feb 2013 16:09:50 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360944590; bh=qswXL470pyXxOV8TxuIlv1yJd+cipf6phFf9m+715ck=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=2Yk80yLWShATyXSIJk/SHOp10umC4d64bkwKEPin6VL78Zn8YrJHy3epFPGo/Qf6kILqgr9jy9hfIEsocGY39CpnfrN7ihfl0Pnnpu+9EZOGENzJNmId9T0fs9DdlqQQva8yalGN4QVn3Y/VRfjsbJ9WeKtSbubgWYw2nPXwyg4=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=hLgkyVnutIIU1v48LVR6Wc+hMd2FEOLbOTbNVHJOPXQLBEgzQKFaOvosd9UJnJS1Fq/odabQFJoLJFEpEws8X2Rvmvv9n8GkXJ+ov/M13DXOxcuBoXq/FTSu1FttIspeVj3pwKHt2Kwbz/twI1RvHkxA2Hv3Z1fZ1OZonmcT5oA=;
X-YMail-OSG: R_2tXvwVM1mI.ZSWKikn4gEhuJ33diPPKbEuP3HVyRiGIys Gkpo5Y3Lraa7Yhes2n82ZcEnpobpl2fFcPWc41BsezStoL0QnJ6pOG7FWMSt 3sp53DhzhxctooBkve4b962R8sV1KNiJzdb.oed9axdfTM7K0k9OVmd0WjxN 7OSmpffeeKO2pZGtrMKzkegQOt184W63CL5XUOTBUK2q0XZ_25igCJkCqvSN q0RIiAWi9VS_fDtdb3dHQAnuylA9vaPzsqQK2i7xytQS4vbW2.woRGRW1Xms EWpf.EQjJhz0p8fbfbbDKpCuRadNShuziCtpZeM87Yyscvog3vHQ7fjDHq3_ .Vtnm9CVnZ0Ljzc6SIaspZNcEV6sguODMti9kWIWoGqXhdTxm4RvXlx50HXu UH11QCwm9Tg9u3fY5RtM6bNOjbOmjDuwjuZqX5duoZHdTSo6x431c6fb.GkO NgZ4PGo_KibpBlPKrSscvtKkUoYvkQCRkff0Mou75h8qD5y_ygH5wbBC7mFi hIrEQS.DW9FFs9.l16C0gNtlY2DKahx3ksdnLaEV5ub7cuzs0rocJ3xk3bpT z8ROlHlL3ar4OCpiK1QQehdymWn1Imy8JbIEr8lfbwNUHy_83r0v8Mir.5wI oXn1aDQlUHPDEGC.OAMmHb2VEjuWNfPbTWguuF60H8PgHyC4ykHCbW_Vu9Oz c8P7nuNhgzoV6l_pS686t44EdwMlZywuLJC3Pb6MybTcnFP8-
Received: from [209.131.62.115] by web31808.mail.mud.yahoo.com via HTTP; Fri, 15 Feb 2013 08:09:49 PST
X-Rocket-MIMEInfo: 001.001, SSdsbCByZXBlYXQgdGhlIHVzZSBjYXNlIGZvciBGbGlja3IsIHdoaWNoIHJlcXVpcmVzIE9BdXRoIDEuMGEgdHlwZSBjYXBhYmlsaXRlcyB0aGF0IE9BdXRoIDIgZG9lcyBub3QgcHJvdmlkZS4gwqBTaW1wbHkgc3RhdGluZyAibW92ZSB0byBIVFRQUyIgaXMgbm90IGEgdmlhYmxlIHJlc3BvbnNlIGhlcmUuIMKgCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KIEZyb206IFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PgpUbzogV2lsbGlhbSBNaWxscyA8d21pbGwBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.134.513
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net>  <511A7D27.8010209@mitre.org> <4E1F6AAD24975D4BA5B16804296739436744BD23@TK5EX14MBXC285.redmond.corp.microsoft.com> <1360891897.14004.YahooMailNeo@web31811.mail.mud.yahoo.com>  <1360912115.36543.YahooMailNeo@web31811.mail.mud.yahoo.com> <2A0F585F-2CEF-418D-9654-5084E6C9BD0D@lodderstedt.net>
Message-ID: <1360944589.51724.YahooMailNeo@web31808.mail.mud.yahoo.com>
Date: Fri, 15 Feb 2013 08:09:49 -0800 (PST)
From: William Mills 
To: Torsten Lodderstedt 
In-Reply-To: <2A0F585F-2CEF-418D-9654-5084E6C9BD0D@lodderstedt.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="258328648-134066345-1360944589=:51724"
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Feb 2013 16:09:53 -0000

--258328648-134066345-1360944589=:51724
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I'll repeat the use case for Flickr, which requires OAuth 1.0a type capabil=
ites that OAuth 2 does not provide. =A0Simply stating "move to HTTPS" is no=
t a viable response here. =A0=0A=0A=0A________________________________=0A F=
rom: Torsten Lodderstedt =0ATo: William Mills  =0ACc: Mike Jones ; Justi=
n Richer ; Phil Hunt ; IETF oauth =
WG  =0ASent: Friday, February 15, 2013 7:22 AM=0ASubject: R=
e: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th Feb=
ruary 2013=0A =0A=0AHi Bill,=0A=0AI think one needs to compare the costs/im=
pact of HTTPS on one side and the implementation of integrity protection an=
d replay detection on the other. We had this discussion several times.=0A=
=0Aregards,=0ATorsten.=0A=0AAm 15.02.2013 um 08:08 schrieb William Mills :=0A=0A=0AI fundamentally disagree with that too. =A0=
OAuth 2 is the *framework*, one which supports multiple token types. =A0Bea=
rer tokens were the first credential type defined.=0A>=0A>=0A>OAuth 1.0a al=
so requires HTTPS transport for authentication and getting the token.=0A>=
=0A>=0A>There are =A0real use cases for tokens usable over plain text with =
integrity protection.=0A>=0A>=0A>-bill=0A>=0A>=0A>=0A>_____________________=
___________=0A> From: Torsten Lodderstedt =0A>To: =
William Mills  =0A>Cc: Mike Jones ; Justin Richer ; Phil Hunt ; IETF oauth WG  =0A>Sent: Thursday, February 14, 201=
3 10:05 PM=0A>Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Co=
nference Call - 11th February 2013=0A> =0A>=0A>Hi Bill,=0A>=0A>=0A>OAuth 2.=
0 took a different direction by relying on HTTPS to provide the basic prote=
ction. So the need to have a token, which can be used for service requests =
over plain HTTP is arguable. My understanding of this activity was, the int=
end is to provide additional protection on top of HTTPS.=0A>=0A>=0A>regards=
,=0A>Torsten.=0A>=0A>Am 15.02.2013 um 02:31 schrieb William Mills :=0A>=0A>=0A>I disagree with "That was the impediment to OAu=
th 1.0 adoption that OAuth 2.0 solved in the first place.", unless "solving=
" means does not address the need for it at all.=0A>>=0A>>=0A>>OAuth 2 does=
 several good things, but it still lacks a defined token type that is safe =
to user over plain text HTTP. =A01.0a solved that.=0A>>=0A>>=0A>>=0A>>_____=
___________________________=0A>> From: Mike Jones =0A>>To: Justin Richer ; Phil Hunt  =0A>>Cc: IETF oauth WG  =0A>>Sent: Thursday, February=
 14, 2013 1:44 PM=0A>>Subject: Re: [OAUTH-WG] Minutes from the OAuth Design=
 Team Conference Call - 11th February 2013=0A>> =0A>>I'm in favor of reusin=
g the JWT work that this WG is also doing. :-)=0A>>=0A>>I'm pretty skeptica=
l of us inventing another custom scheme for signing HTTP headers.=A0 That w=
as the impediment to OAuth 1.0 adoption that OAuth 2.0 solved in the first =
place.=0A>>=0A>>=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 -- Mike=0A>>=0A>>--=
---Original Message-----=0A>>From: oauth-bounces@ietf.org [mailto:oauth-bou=
nces@ietf.org] On Behalf Of Justin Richer=0A>>Sent: Tuesday, February 12, 2=
013 9:35 AM=0A>>To: Phil Hunt=0A>>Cc: IETF oauth WG=0A>>Subject: Re: [OAUTH=
-WG] Minutes from the OAuth Design Team Conference Call - 11th February 201=
3=0A>>=0A>>That's my reading of it as well, Phil, thanks for providing the =
clarification.=0A One motivator behind using a JSON-based token is to be ab=
le to=0A re-use some of the great work that the JOSE group is doing but app=
ly it to an HTTP payload.=0A>>=0A>>What neither of us want is a token type =
that requires stuffing all query, header, and other parameters *into* the J=
SON object itself, which would be a more SOAPy approach.=0A>>=0A>>=A0 -- Ju=
stin=0A>>=0A>>On 02/12/2013 12:30 PM, Phil Hunt wrote:=0A>>> Clarification.=
=A0 I think Justin and I were in agreement that we don't want to see a form=
at that requires JSON payloads.=A0 We are both interested in a JSON token u=
sed in the authorization header that could be based on a computed signature=
 of some combination of http headers and body if possible.=0A>>>=0A>>> Phil=
=0A>>>=0A>>> @independentid=0A>>> www.independentid.com=0A>>> phil.hunt@ora=
cle.com=0A>>>=0A>>>=0A>>>=0A>>>=0A>>>=0A>>> On=0A 2013-02-12, at 1:10 AM, H=
annes Tschofenig wrote:=0A>>>=0A>>>> Here are my notes.=0A>>>>=0A>>>> Parti=
cipants:=0A>>>>=0A>>>> * John Bradley=0A>>>> * Derek Atkins=0A>>>> * Phil H=
unt=0A>>>> * Prateek Mishra=0A>>>> * Hannes Tschofenig=0A>>>> * Mike Jones=
=0A>>>> * Antonio Sanso=0A>>>> * Justin Richer=0A>>>>=0A>>>> Notes:=0A>>>>=
=0A>>>> My slides are available here: =0A>>>> http://www.tschofenig.priv.at=
/OAuth2-Security-11Feb2013.ppt=0A>>>>=0A>>>> Slide #2 summarizes earlier di=
scussions during the conference calls.=0A>>>>=0A>>>> -- HTTP vs. JSON=0A>>>=
>=0A>>>> Phil noted that he does not like to use the MAC Token draft as a s=
tarting point because it does not re-use any of the work done in the JOSE w=
orking group and in particular all the libraries that are available today. =
He mentioned that earlier attempts to write the MAC Token code lead to=0A p=
roblems for implementers.=0A>>>>=0A>>>> Justin responded that he does not a=
gree with using JSON as a transport mechanism since this would replicate a =
SOAP style.=0A>>>>=0A>>>> Phil noted that he wants to send JSON but the sig=
nature shall be computed over the HTTP header field.=0A>>>>=0A>>>> -- Flexi=
bility for the keyed message digest computation=0A>>>>=0A>>>>=A0 From earli=
er discussion it was clear that the conference call participants wanted mor=
e flexibility regarding the keyed message digest computation. For this purp=
ose Hannes presented the DKIM based approach, which allows selective header=
 fields to be included in the digest. This is shown in slide #4.=0A>>>>=0A>=
>>> After some discussion the conference call participants thought that thi=
s would meet their needs. Further investigations would still be useful to d=
etermine the degree of failed HMAC calculations due to HTTP proxies modifyi=
ng the=0A content.=0A>>>>=0A>>>> -- Key Distribution=0A>>>>=0A>>>> Hannes p=
resented the open issue regarding the choice of key =0A>>>> distribution. S=
lides #6-#8 present three techniques and Hannes asked =0A>>>> for feedback =
regarding the preferred style. Justin and others didn't =0A>>>> see the nee=
d to decide on one mechanism - they wanted to keep the =0A>>>> choice open.=
 Derek indicated that this will not be an acceptable =0A>>>> approach. Sinc=
e the resource server and the authorization server may, =0A>>>> in the OAut=
h 2.0 framework, be entities produced by different vendors =0A>>>> there is=
 an interoperability need. Justin responded that he disagrees =0A>>>> and t=
hat the resource server needs to understand the access token and =0A>>>> re=
ferred to the recent draft submission for the token introspection =0A>>>> e=
ndpoint. Derek indicated that the resource server has to understand =0A>>>>=
=0A the content of the access token and the token introspection endpoint =
=0A>>>> just pushes the problem around: the resource server has to send the=
 =0A>>>> access token to the authorization server and then the resource ser=
ver =0A>>>> gets the result back (which he the=0A>>n=0A>>>=A0 =A0 a=0A>>>> =
gain needs to understand) in order to make a meaningful authorization decis=
ion.=0A>>>>=0A>>>> Everyone agreed that the client must receive the session=
 key from the authorization server and that this approach has to be standar=
dized. It was also agreed that this is a common approach among all three ke=
y distribution mechanisms.=0A>>>>=0A>>>> Hannes asked the participants to t=
hink about their preference.=0A>>>>=0A>>>> The questions regarding key nami=
ng and the indication for the intended resource server the client wants to =
talk to have been postponed.=0A>>>>=0A>>>> Ciao=0A>>>>=0A Hannes=0A>>>>=0A>=
>>>=0A>>>> _______________________________________________=0A>>>> OAuth mai=
ling list=0A>>>> OAuth@ietf.org=0A>>>> https://www.ietf.org/mailman/listinf=
o/oauth=0A>>> _______________________________________________=0A>>> OAuth m=
ailing list=0A>>> OAuth@ietf.org=0A>>> https://www.ietf.org/mailman/listinf=
o/oauth=0A>>=0A>>=0A>>_______________________________________________=0A>>O=
Auth mailing list=0A>>OAuth@ietf.org=0A>>https://www.ietf.org/mailman/listi=
nfo/oauth=0A>>_______________________________________________=0A>>OAuth mai=
ling list=0A>>OAuth@ietf.org=0A>>https://www.ietf.org/mailman/listinfo/oaut=
h=0A>>=0A>>=0A>>=0A>_______________________________________________=0A>>OAu=
th mailing list=0A>>OAuth@ietf.org=0A>>https://www.ietf.org/mailman/listinf=
o/oauth=0A>>=0A>=0A>
--258328648-134066345-1360944589=:51724
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I'll repeat the use case for Flickr, which requires OAuth 1.0a type capab=
ilites that OAuth 2 does not provide.  Simply stating "move to HTTPS" =
is not a viable response here.  

  From: Torsten Lodderstedt <torsten@lodderstedt.net>
 To: William Mills <wmills_92105@ya=
hoo.com> 
Cc: Mike J=
ones <Michael.Jones@microsoft.com>; Justin Richer <jricher@mitre.o=
rg>; Phil
 Hunt <phil.hunt@oracle.com>; IETF oauth WG <oauth@ietf.org>  Sent: Friday, February =
15, 2013 7:22 AM
 Subject:<=
/b> Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11t=
h February 2013

=0AHi Bill,

I think one needs to compare the costs/=
impact of HTTPS on one side and the implementation of integrity protection =
and replay detection on the other. We had this discussion several times.
regards,
Torsten.

Am 15.02.2=
013 um 08:08 schrieb William Mills <wmills_92105@yahoo.com>:

I fundamentally disagree with that too.  =
OAuth 2 is the *framework*, one which supports multiple token types.  =
Bearer tokens were the first credential type defined.

OAuth 1.0a also requires HTTPS transport for authenti=
cation and getting the token.

<=
/span>
There are  real use cases for =
tokens usable over plain text with integrity protection.

-bill<=
/span>

 =0A From: Torsten Lodderstedt <torsten@lodderstedt.net> To: William Mills <wmills_92105@yahoo.com> Cc: Mike Jones <Michael.Jones@microsoft.com=
>; Justin Richer <jricher@mitre=
.org>; Phil Hunt <phil.hu=
nt@oracle.com>; IETF
 oauth WG <oauth@ietf.org> 
 <=
span style=3D"font-weight:bold;">Sent: Thursday, February 14, 20=
13 10:05 PM
 Subject: Re=
: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th Febr=
uary 2013

=0AHi B=
ill,

OAuth 2.0 took a different direction by relyi=
ng on HTTPS to provide the basic protection. So the need to have a token, w=
hich can be used for service requests over plain HTTP is arguable. My under=
standing of this activity was, the intend is to provide additional protecti=
on on top of HTTPS.

regards,
Torsten.
Am 15.02.2013 um 02:31 schrieb William Mills <wmills_92105@yahoo.com>:

=
I disagree with "=
That was the impediment to=0A OAuth 1.0 adoption that OAuth=
 2.0 solved in the first place.", unless "solving" means does not address t=
he need for it at all.

<=
/div>OAuth 2 does several=0A good things, but i=
t still lacks a defined token type that is safe to user over plain text HTT=
P.  1.0a solved that.

      <=
hr size=3D"1">  From: Mike =
Jones <Michael.Jon=
es@microsoft.com>
 To: Justin Richer <jricher@mitre.org=
>; Phil Hunt <phil.hunt@oracle.com> 
<=
span style=3D"font-weight:bold;">Cc: IETF oauth WG <oauth@ietf.org> 
 Sent: Thursday, February 14, 2013 1:44 PM
 Subject: Re: [OAUTH-WG] Minutes from=
 the OAuth Design Team Conference Call - 11th February 2013
=0A  =

=0AI'm in favor of reusing the JWT work that this WG is also doi=
ng. :-)

I'm pretty skeptical of us inventing another custom scheme f=
or signing HTTP headers.  That was the impediment to OAuth 1.0 adoptio=
n that OAuth 2.0 solved in the first place.

     =
;           -- Mike

-----Ori=
ginal Message-----
From: oau=
th-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Tuesday, F=
ebruary 12, 2013 9:35 AM
To: Phil Hunt
Cc: IETF oauth WG
Subject: =
Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th Fe=
bruary 2013

That's my reading of it as well, Phil, thanks for provid=
ing the clarification.=0A One motivator behind using a JSON-based token is =
to be able to=0A re-use some of the great work that the JOSE group is doing=
 but apply it to an HTTP payload.

What neither of us want is a token=
 type that requires stuffing all query, header, and other parameters *into*=
 the JSON object itself, which would be a more SOAPy approach.

 =
; -- Justin

On 02/12/2013 12:30 PM, Phil Hunt wrote:
> Clarifi=
cation.  I think Justin and I were in agreement that we don't want to =
see a format that requires JSON payloads.  We are both interested in a=
 JSON token used in the authorization header that could be based on a compu=
ted signature of some combination of http headers and body if possible.
=
>
> Phil
>
> @independentid
> www.independenti=
d.com
> phil.hunt@oracle.com
>
&=
gt;
>
>
>
> On=0A 2013-02-12, at 1:10 AM, Hannes Ts=
chofenig wrote:
>
>> Here are my notes.
>>
>&=
gt; Participants:
>>
>> * John Bradley
>> * Dere=
k Atkins
>> * Phil Hunt
>> * Prateek Mishra
>> *=
 Hannes Tschofenig
>> * Mike Jones
>> * Antonio Sanso
=
>> * Justin Richer
>>
>> Notes:
>>
>=
> My slides are available here: 
>> http://www.tschofenig.priv.=
at/OAuth2-Security-11Feb2013.ppt
>>
>> Slide #2 summarize=
s earlier discussions during the conference calls.
>>
>> =
-- HTTP vs. JSON
>>
>> Phil noted that he does not like t=
o use the MAC Token draft as a starting point because it does not re-use an=
y of the work done in the JOSE working group and in particular all the libr=
aries that are available today. He mentioned that earlier attempts to write=
 the MAC Token code lead to=0A problems for implementers.
>>
&g=
t;> Justin responded that he does not agree with using JSON as a transpo=
rt mechanism since this would replicate a SOAP style.
>>
>&g=
t; Phil noted that he wants to send JSON but the signature shall be compute=
d over the HTTP header field.
>>
>> -- Flexibility for th=
e keyed message digest computation
>>
>>  From earli=
er discussion it was clear that the conference call participants wanted mor=
e flexibility regarding the keyed message digest computation. For this purp=
ose Hannes presented the DKIM based approach, which allows selective header=
 fields to be included in the digest. This is shown in slide #4.
>>=
;
>> After some discussion the conference call participants though=
t that this would meet their needs. Further investigations would still be u=
seful to determine the degree of failed HMAC calculations due to HTTP proxi=
es modifying the=0A content.
>>
>> -- Key Distribution>>
>> Hannes presented the open issue regarding the choice =
of key 
>> distribution. Slides #6-#8 present three techniques and=
 Hannes asked 
>> for feedback regarding the preferred style. Just=
in and others didn't 
>> see the need to decide on one mechanism -=
 they wanted to keep the 
>> choice open. Derek indicated that thi=
s will not be an acceptable 
>> approach. Since the resource serve=
r and the authorization server may, 
>> in the OAuth 2.0 framework=
, be entities produced by different vendors 
>> there is an intero=
perability need. Justin responded that he disagrees 
>> and that t=
he resource server needs to understand the access token and 
>> re=
ferred to the recent draft submission for the token introspection 
>&=
gt; endpoint. Derek indicated that the resource server has to understand >>=0A the content of the access token and the token introspection e=
ndpoint 
>> just pushes the problem around: the resource server ha=
s to send the 
>> access token to the authorization server and the=
n the resource server 
>> gets the result back (which he the
 n=

>    a
>> gain needs to understand) in order to m=
ake a meaningful authorization decision.
>>
>> Everyone a=
greed that the client must receive the session key from the authorization s=
erver and that this approach has to be standardized. It was also agreed tha=
t this is a common approach among all three key distribution mechanisms.>>
>> Hannes asked the participants to think about their pr=
eference.
>>
>> The questions regarding key naming and th=
e indication for the intended resource server the client wants to talk to h=
ave been postponed.
>>
>> Ciao
>>=0A Hannes
&=
gt;>
>>
>> ___________________________________________=
____
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailm=
an/listinfo/oauth
> _____________________________________________=
__
> OAuth mailing list
> OAuth@iet=
f.org
> https://www.ietf.org/mailman/listinfo/oau=
th

_______________________________________________
OAuth =
mailing list
OAuth@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/oauth
___________________________=
____________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinf=
o/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/=
mailman/listinfo/oauth

 =0A 

--258328648-134066345-1360944589=:51724--

From phil.hunt@oracle.com  Fri Feb 15 08:19:38 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9D121F896B for ; Fri, 15 Feb 2013 08:19:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.684
X-Spam-Level: 
X-Spam-Status: No, score=-5.684 tagged_above=-999 required=5 tests=[AWL=-0.482, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyQ0qfCdi1B1 for ; Fri, 15 Feb 2013 08:19:36 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 81CB921F8900 for ; Fri, 15 Feb 2013 08:19:36 -0800 (PST)
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1FGJZTk004891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 Feb 2013 16:19:35 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1FGJY4q006620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Feb 2013 16:19:34 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1FGJYuK009037; Fri, 15 Feb 2013 10:19:34 -0600
Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 15 Feb 2013 08:19:33 -0800
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net>  <511A7D27.8010209@mitre.org> <4E1F6AAD24975D4BA5B16804296739436744BD23@TK5EX14MBXC285.redmond.corp.microsoft.com> <1360891897.14004.YahooMailNeo@web31811.mail.mud.yahoo.com>  <1360912115.36543.YahooMailNeo@web31811.mail.mud.yahoo.com> <2A0F585F-2CEF-418D-9654-5084E6C9BD0D@lodderstedt.net> <1360944589.51724.YahooMailNeo@web31808.mail.mud.yahoo.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <1360944589.51724.YahooMailNeo@web31808.mail.mud.yahoo.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-14B1C5F1-F4AD-4183-8034-4DBE141D4104
Content-Transfer-Encoding: 7bit
Message-Id: <2DD050E1-DD8B-4788-B373-CDBED10C8048@oracle.com>
X-Mailer: iPhone Mail (10B142)
From: Phil Hunt 
Date: Fri, 15 Feb 2013 08:19:32 -0800
To: William Mills 
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Feb 2013 16:19:38 -0000

--Apple-Mail-14B1C5F1-F4AD-4183-8034-4DBE141D4104
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Bill

You aren't objecting to https in the as communications correct?  It is the r=
s comms which is plain http where you want to protect the credential from th=
eft. =20

Even replay is not the primary issue here.=20

Phil

Sent from my phone.

On 2013-02-15, at 8:09, William Mills  wrote:

> I'll repeat the use case for Flickr, which requires OAuth 1.0a type capabi=
lites that OAuth 2 does not provide.  Simply stating "move to HTTPS" is not a=
 viable response here. =20
>=20
> From: Torsten Lodderstedt 
> To: William Mills =20
> Cc: Mike Jones ; Justin Richer ; Phil Hunt ; IETF oauth WG =20
> Sent: Friday, February 15, 2013 7:22 AM
> Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call=
 - 11th February 2013
>=20
> Hi Bill,
>=20
> I think one needs to compare the costs/impact of HTTPS on one side and the=
 implementation of integrity protection and replay detection on the other. W=
e had this discussion several times.
>=20
> regards,
> Torsten.
>=20
> Am 15.02.2013 um 08:08 schrieb William Mills :
>=20
>> I fundamentally disagree with that too.  OAuth 2 is the *framework*, one w=
hich supports multiple token types.  Bearer tokens were the first credential=
 type defined.
>>=20
>> OAuth 1.0a also requires HTTPS transport for authentication and getting t=
he token.
>>=20
>> There are  real use cases for tokens usable over plain text with integrit=
y protection.
>>=20
>> -bill
>>=20
>> From: Torsten Lodderstedt 
>> To: William Mills =20
>> Cc: Mike Jones ; Justin Richer ; Phil Hunt ; IETF oauth WG =20
>> Sent: Thursday, February 14, 2013 10:05 PM
>> Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Cal=
l - 11th February 2013
>>=20
>> Hi Bill,
>>=20
>> OAuth 2.0 took a different direction by relying on HTTPS to provide the b=
asic protection. So the need to have a token, which can be used for service r=
equests over plain HTTP is arguable. My understanding of this activity was, t=
he intend is to provide additional protection on top of HTTPS.
>>=20
>> regards,
>> Torsten.
>>=20
>> Am 15.02.2013 um 02:31 schrieb William Mills :
>>=20
>>> I disagree with "That was the impediment to OAuth 1.0 adoption that OAut=
h 2.0 solved in the first place.", unless "solving" means does not address t=
he need for it at all.
>>>=20
>>> OAuth 2 does several good things, but it still lacks a defined token typ=
e that is safe to user over plain text HTTP.  1.0a solved that.
>>>=20
>>> From: Mike Jones 
>>> To: Justin Richer ; Phil Hunt =20=

>>> Cc: IETF oauth WG =20
>>> Sent: Thursday, February 14, 2013 1:44 PM
>>> Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Ca=
ll - 11th February 2013
>>>=20
>>> I'm in favor of reusing the JWT work that this WG is also doing. :-)
>>>=20
>>> I'm pretty skeptical of us inventing another custom scheme for signing H=
TTP headers.  That was the impediment to OAuth 1.0 adoption that OAuth 2.0 s=
olved in the first place.
>>>=20
>>>                 -- Mike
>>>=20
>>> -----Original Message-----
>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O=
f Justin Richer
>>> Sent: Tuesday, February 12, 2013 9:35 AM
>>> To: Phil Hunt
>>> Cc: IETF oauth WG
>>> Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Ca=
ll - 11th February 2013
>>>=20
>>> That's my reading of it as well, Phil, thanks for providing the clarific=
ation. One motivator behind using a JSON-based token is to be able to re-use=
 some of the great work that the JOSE group is doing but apply it to an HTTP=
 payload.
>>>=20
>>> What neither of us want is a token type that requires stuffing all query=
, header, and other parameters *into* the JSON object itself, which would be=
 a more SOAPy approach.
>>>=20
>>>   -- Justin
>>>=20
>>> On 02/12/2013 12:30 PM, Phil Hunt wrote:
>>> > Clarification.  I think Justin and I were in agreement that we don't w=
ant to see a format that requires JSON payloads.  We are both interested in a=
 JSON token used in the authorization header that could be based on a comput=
ed signature of some combination of http headers and body if possible.
>>> >
>>> > Phil
>>> >
>>> > @independentid
>>> > www.independentid.com
>>> > phil.hunt@oracle.com
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On 2013-02-12, at 1:10 AM, Hannes Tschofenig wrote:
>>> >
>>> >> Here are my notes.
>>> >>
>>> >> Participants:
>>> >>
>>> >> * John Bradley
>>> >> * Derek Atkins
>>> >> * Phil Hunt
>>> >> * Prateek Mishra
>>> >> * Hannes Tschofenig
>>> >> * Mike Jones
>>> >> * Antonio Sanso
>>> >> * Justin Richer
>>> >>
>>> >> Notes:
>>> >>
>>> >> My slides are available here:=20
>>> >> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
>>> >>
>>> >> Slide #2 summarizes earlier discussions during the conference calls.
>>> >>
>>> >> -- HTTP vs. JSON
>>> >>
>>> >> Phil noted that he does not like to use the MAC Token draft as a star=
ting point because it does not re-use any of the work done in the JOSE worki=
ng group and in particular all the libraries that are available today. He me=
ntioned that earlier attempts to write the MAC Token code lead to problems f=
or implementers.
>>> >>
>>> >> Justin responded that he does not agree with using JSON as a transpor=
t mechanism since this would replicate a SOAP style.
>>> >>
>>> >> Phil noted that he wants to send JSON but the signature shall be comp=
uted over the HTTP header field.
>>> >>
>>> >> -- Flexibility for the keyed message digest computation
>>> >>
>>> >>  =46rom earlier discussion it was clear that the conference call part=
icipants wanted more flexibility regarding the keyed message digest computat=
ion. For this purpose Hannes presented the DKIM based approach, which allows=
 selective header fields to be included in the digest. This is shown in slid=
e #4.
>>> >>
>>> >> After some discussion the conference call participants thought that t=
his would meet their needs. Further investigations would still be useful to d=
etermine the degree of failed HMAC calculations due to HTTP proxies modifyin=
g the content.
>>> >>
>>> >> -- Key Distribution
>>> >>
>>> >> Hannes presented the open issue regarding the choice of key=20
>>> >> distribution. Slides #6-#8 present three techniques and Hannes asked=20=

>>> >> for feedback regarding the preferred style. Justin and others didn't=20=

>>> >> see the need to decide on one mechanism - they wanted to keep the=20
>>> >> choice open. Derek indicated that this will not be an acceptable=20
>>> >> approach. Since the resource server and the authorization server may,=
=20
>>> >> in the OAuth 2.0 framework, be entities produced by different vendors=
=20
>>> >> there is an interoperability need. Justin responded that he disagrees=
=20
>>> >> and that the resource server needs to understand the access token and=
=20
>>> >> referred to the recent draft submission for the token introspection=20=

>>> >> endpoint. Derek indicated that the resource server has to understand=20=

>>> >> the content of the access token and the token introspection endpoint=20=

>>> >> just pushes the problem around: the resource server has to send the=20=

>>> >> access token to the authorization server and then the resource server=
=20
>>> >> gets the result back (which he the
>>> n
>>> >    a
>>> >> gain needs to understand) in order to make a meaningful authorization=
 decision.
>>> >>
>>> >> Everyone agreed that the client must receive the session key from the=
 authorization server and that this approach has to be standardized. It was a=
lso agreed that this is a common approach among all three key distribution m=
echanisms.
>>> >>
>>> >> Hannes asked the participants to think about their preference.
>>> >>
>>> >> The questions regarding key naming and the indication for the intende=
d resource server the client wants to talk to have been postponed.
>>> >>
>>> >> 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
>>>=20
>>>=20
>>> _______________________________________________
>>> 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
>>>=20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20

--Apple-Mail-14B1C5F1-F4AD-4183-8034-4DBE141D4104
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Bill

You aren=
't objecting to https in the as communications correct?  It is the rs c=
omms which is plain http where you want to protect the credential from theft=
.  

Even replay is not the primary issue here.=

Phil
Sent from my phone.
On 2013-02-15, at 8:09, William Mills <wmills_92105@yahoo.com> wrote:

I'll repeat the use case for Flickr, which requires OAuth 1.0a type capa=
bilites that OAuth 2 does not provide.  Simply stating "move to HTTPS" i=
s not a viable response here.  

  From: T=
orsten Lodderstedt <torsten@lo=
dderstedt.net>
 To: William Mills <wmills_92105@=
yahoo.com> 
Cc: M=
ike Jones <Michael.Jones@m=
icrosoft.com>; Justin Richer <jricher@mitre.org>; Phil
 Hunt <phil.hunt@oracle.com&g=
t;; IETF oauth WG <oauth@ietf.org&g=
t; 
 Sent: Friday, Febru=
ary 15, 2013 7:22 AM
 Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 1=
1th February 2013

Hi Bill,

I think=
 one needs to compare the costs/impact of HTTPS on one side and the implemen=
tation of integrity protection and replay detection on the other. We had thi=
s discussion several times.

regards,
Tors=
ten.

Am 15.02.2013 um 08:08 schrieb William Mills <wmills_92105@yahoo.com>:

I fundamentally disagree w=
ith that too.  OAuth 2 is the *framework*, one which supports multiple t=
oken types.  Bearer tokens were the first credential type defined.

OAuth 1.0a also requires HTTPS transport for authenticatio=
n and getting the token.

There are  real use cases for tokens usab=
le over plain text with integrity protection.

-bill

      =20
 From: Torsten Lodderstedt &=
lt;torsten@lodderstedt.net&=
gt;
 To: William Mills &l=
t;wmills_92105@yahoo.com> <=
br>Cc: Mike Jones <Michael.Jones@microsoft.com>; Justin Richer <jricher@mitre.org=
>; Phil Hunt <phil.hunt@ora=
cle.com>; IETF
 oauth WG <oauth@ietf.org> 
 Sent: Thursday, February 14, 2013 10=
:05 PM
 Subject: Re: [OAU=
TH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 20=
13

Hi Bill,

OAuth 2=
.0 took a different direction by relying on HTTPS to provide the basic prote=
ction. So the need to have a token, which can be used for service requests o=
ver plain HTTP is arguable. My understanding of this activity was, the inten=
d is to provide additional protection on top of HTTPS.

<=
div>regards,
Torsten.

Am 15.02.2013 um 02:31 schrieb=
 William Mills <wmills_92105@y=
ahoo.com>:

I disagree with "That was the impediment to
 OAuth 1.0 adoption that OAuth 2.0 solved in the first place.", unless "solv=
ing" means does not address the need for it at all.

OAuth 2 does several
 good things, but it still lacks a defined token type that is safe to user o=
ver plain text HTTP.  1.0a solved that.

  From: Mike Jones <=
Michael.Jones@microsoft.com>
 To: Justin Richer <jricher@m=
itre.org>; Phil Hunt <phil.=
hunt@oracle.com> 
Cc:<=
/b> IETF oauth WG <oauth@ietf.org> 
 <=
b>Sent: Thursday, February 14, 2=
013 1:44 PM
 Subject: Re:=
 [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th Februa=
ry 2013

I'm in favor of reusing the JWT work that this WG is also doing. :-)

=
I'm pretty skeptical of us inventing another custom scheme for signing HTTP h=
eaders.  That was the impediment to OAuth 1.0 adoption that OAuth 2.0 s=
olved in the first place.

         =
;       -- Mike

-----Original Message-----From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org<=
/a>] On Behalf Of Justin Richer
Sent: Tuesday, February 12, 2013 9:35 AM<=
br>To: Phil Hunt
Cc: IETF oauth WG
Subject: Re: [OAUTH-WG] Minutes fro=
m the OAuth Design Team Conference Call - 11th February 2013

That's m=
y reading of it as well, Phil, thanks for providing the clarification.
 One motivator behind using a JSON-based token is to be able to
 re-use some of the great work that the JOSE group is doing but apply it to a=
n HTTP payload.

What neither of us want is a token type that requires=
 stuffing all query, header, and other parameters *into* the JSON object its=
elf, which would be a more SOAPy approach.

  -- Justin

On=
 02/12/2013 12:30 PM, Phil Hunt wrote:
> Clarification.  I think J=
ustin and I were in agreement that we don't want to see a format that requir=
es JSON payloads.  We are both interested in a JSON token used in the a=
uthorization header that could be based on a computed signature of some comb=
ination of http headers and body if possible.
>
> Phil
>> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>
>=

>
>
> On
 2013-02-12, at 1:10 AM, Hannes Tschofenig wrote:
>
>> Here a=
re my notes.
>>
>> Participants:
>>
>> *=
 John Bradley
>> * Derek Atkins
>> * Phil Hunt
>>=
 * Prateek Mishra
>> * Hannes Tschofenig
>> * Mike Jones>> * Antonio Sanso
>> * Justin Richer
>>
>&g=
t; Notes:
>>
>> My slides are available here: 
>>=
 htt=
p://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
>>
=
>> Slide #2 summarizes earlier discussions during the conference calls=
.
>>
>> -- HTTP vs. JSON
>>
>> Phil note=
d that he does not like to use the MAC Token draft as a starting point becau=
se it does not re-use any of the work done in the JOSE working group and in p=
articular all the libraries that are available today. He mentioned that earl=
ier attempts to write the MAC Token code lead to
 problems for implementers.
>>
>> Justin responded that he=
 does not agree with using JSON as a transport mechanism since this would re=
plicate a SOAP style.
>>
>> Phil noted that he wants to se=
nd JSON but the signature shall be computed over the HTTP header field.
&=
gt;>
>> -- Flexibility for the keyed message digest computation<=
br>>>
>>  =46rom earlier discussion it was clear that th=
e conference call participants wanted more flexibility regarding the keyed m=
essage digest computation. For this purpose Hannes presented the DKIM based a=
pproach, which allows selective header fields to be included in the digest. T=
his is shown in slide #4.
>>
>> After some discussion the c=
onference call participants thought that this would meet their needs. Furthe=
r investigations would still be useful to determine the degree of failed HMA=
C calculations due to HTTP proxies modifying the
 content.
>>
>> -- Key Distribution
>>
>>=
; Hannes presented the open issue regarding the choice of key 
>> d=
istribution. Slides #6-#8 present three techniques and Hannes asked 
>=
> for feedback regarding the preferred style. Justin and others didn't >> see the need to decide on one mechanism - they wanted to keep the=

>> choice open. Derek indicated that this will not be an acceptab=
le 
>> approach. Since the resource server and the authorization se=
rver may, 
>> in the OAuth 2.0 framework, be entities produced by d=
ifferent vendors 
>> there is an interoperability need. Justin resp=
onded that he disagrees 
>> and that the resource server needs to u=
nderstand the access token and 
>> referred to the recent draft sub=
mission for the token introspection 
>> endpoint. Derek indicated t=
hat the resource server has to understand 
>>
 the content of the access token and the token introspection endpoint 
&g=
t;> just pushes the problem around: the resource server has to send the <=
br>>> access token to the authorization server and then the resource s=
erver 
>> gets the result back (which he the
 n
>  &n=
bsp; a
>> gain needs to understand) in order to make a meaningful a=
uthorization decision.
>>
>> Everyone agreed that the clie=
nt must receive the session key from the authorization server and that this a=
pproach has to be standardized. It was also agreed that this is a common app=
roach among all three key distribution mechanisms.
>>
>> H=
annes asked the participants to think about their preference.
>>>> The questions regarding key naming and the indication for the inte=
nded resource server the client wants to talk to have been postponed.
>=
;>
>> 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/oa=
uth

_______________________________________________
OAuth m=
ailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
________________________=
_______________________
OAuth mailing list
=
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/o=
auth

_______________________________________________=

OAuth mailing list
OAut=
h@ietf.org
https://www.ietf.org/mailman/l=
istinfo/oauth

  <=
/div>=20

    =

--Apple-Mail-14B1C5F1-F4AD-4183-8034-4DBE141D4104--

From wmills_92105@yahoo.com  Fri Feb 15 08:21:58 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A3921F87D2 for ; Fri, 15 Feb 2013 08:21:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.25
X-Spam-Level: 
X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.348,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNguVf6ukVRA for ; Fri, 15 Feb 2013 08:21:57 -0800 (PST)
Received: from nm18-vm1.bullet.mail.ne1.yahoo.com (nm18-vm1.bullet.mail.ne1.yahoo.com [98.138.91.64]) by ietfa.amsl.com (Postfix) with ESMTP id D04CF21F8467 for ; Fri, 15 Feb 2013 08:21:56 -0800 (PST)
Received: from [98.138.226.179] by nm18.bullet.mail.ne1.yahoo.com with NNFMP; 15 Feb 2013 16:21:56 -0000
Received: from [98.138.88.232] by tm14.bullet.mail.ne1.yahoo.com with NNFMP; 15 Feb 2013 16:21:56 -0000
Received: from [127.0.0.1] by omp1032.mail.ne1.yahoo.com with NNFMP; 15 Feb 2013 16:21:56 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 358203.440.bm@omp1032.mail.ne1.yahoo.com
Received: (qmail 73873 invoked by uid 60001); 15 Feb 2013 16:21:55 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360945315; bh=Pap3peOoLL4cxQP8AzL/9wsb/I3codcdif3gA6993kM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=oa1lmENhCD/M4nYeD7ZTSpOFUtPnAZNeo9sjB/LkiMYAL4Bqsf49Cn56OZC5p955P8g8lNngjhpyygBuiA+/xVHWlDIpgD3kpCJO+lbABOLez/lmPVOj3cCtdHzRJcZ9PzYGPdVuzm/+HxwAAyi3aF2jRVM9lxciDuWH1AnHum0=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=bf+6G6biGxUu2u7n3lTJdoBeY03u1vn9nzsfRuE9R2qdEAR6692NPLJlWCkWNtp4SO53Dfs6XZp4kW29FxaRmmg4zHaJtawPj1oJGQjakGSeoMD/l9x07tJZprA8a0MXhijQgoQ8L/632f2M5NO0vZYx6DHEHX9W7u8xtuiEtdA=;
X-YMail-OSG: .TqT3KIVM1lPQ87TzWD6eT6QT_4CjW0P13jMrG2aLJ7nnQ4 0h3fSWZNx_Cnav.4JrpCmLMDdCpO5L6RJpBxL0VhJr55NOQbYWZr6twOtAVh HlFeNP9lr7ZWYNjx0t9lUntUlY0Wfz1JZ.e.0ZwFJNF68o561_LFx5b0xeye 9GzBgx5nbo0ogKvO.WrVBMn5wPPNw5GUNGn8OdZEnMjLAiyE8iEJRNrIyM4M dOj8l22NfvDGwssgzOhS_aNCPOCbcmSWeVhYCr4a1JkJaFd_OYKWiIuKGKcv SgRuXNPw.TwxXjLyzsZj21tgwNo0p5P6OVqfMNSarFpXOZQ8l4RCThPTE.at 9gpX2Ej7VxKRwhQ5evu.rSmzuNB0W5.1_JV.ARy2cp3beYL8R6L5iqU0ZZmd Y7TJCaEeeLGpjA4VWxABlOq7jjhtQboks9vVX_jQGrRGk_wnMv5KFLJmHtbl 0TymwC938E8Yn1mN6v7CPPQ0H9x9BYU4XMPk7dtX3fSNwNQA3tpmkXNe.Eze JhzqBr6F5oybx4gCVIBjokn_U1tn0aMJJpkvlqXBtFe0Ng6qUfmVDJMLgJ8t mrhpRCTvd_ulfBCTga1G4dGepaDLWhJVsFXhmvdry8FsrlwzI1cEFWAaz3ri n243q9DCzsUJozDZtNSyCkWR5KpDAa2Xf6t5NmTMHj4kjUPtebQKH0k2ZbAO GIAvldAd8NgnfD3ID5E4ko5xJw5Ef
Received: from [209.131.62.115] by web31811.mail.mud.yahoo.com via HTTP; Fri, 15 Feb 2013 08:21:55 PST
X-Rocket-MIMEInfo: 001.001, RXhhY3RseS4gwqBBbmQgaW4gdGhlIEZsaWNrciBjYXNlIHJlcGxheSBvZiB0aGUgc2FtZSBldmVudCBpcyBub3QgYSBwcm9ibGVtLiDCoFRoYW5rcyBmb3Iga2VlcGluZyBtZSBob25lc3QsIHdvcmsganVzdCBjcmFua2VkIHRoZSBkaWFsIHVwIHRvIDExLjUgc28gSSdtIGEgYml0IGRpc3RyYWN0ZWQuCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KIEZyb206IFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb20.ClRvOiBXaWxsaWFtIE1pbGxzIDx3bWlsbHNfOTIxMDVAeWFob28uY29tPiABMAEBAQE-
X-Mailer: YahooMailWebService/0.8.134.513
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net>  <511A7D27.8010209@mitre.org> <4E1F6AAD24975D4BA5B16804296739436744BD23@TK5EX14MBXC285.redmond.corp.microsoft.com> <1360891897.14004.YahooMailNeo@web31811.mail.mud.yahoo.com>  <1360912115.36543.YahooMailNeo@web31811.mail.mud.yahoo.com> <2A0F585F-2CEF-418D-9654-5084E6C9BD0D@lodderstedt.net> <1360944589.51724.YahooMailNeo@web31808.mail.mud.yahoo.com> <2DD050E1-DD8B-4788-B373-CDBED10C8048@oracle.com>
Message-ID: <1360945315.70386.YahooMailNeo@web31811.mail.mud.yahoo.com>
Date: Fri, 15 Feb 2013 08:21:55 -0800 (PST)
From: William Mills 
To: Phil Hunt 
In-Reply-To: <2DD050E1-DD8B-4788-B373-CDBED10C8048@oracle.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="764183289-1875840522-1360945315=:70386"
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Feb 2013 16:21:58 -0000

--764183289-1875840522-1360945315=:70386
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Exactly. =A0And in the Flickr case replay of the same event is not a proble=
m. =A0Thanks for keeping me honest, work just cranked the dial up to 11.5 s=
o I'm a bit distracted.=0A=0A=0A________________________________=0A From: P=
hil Hunt =0ATo: William Mills  =0ACc: Torsten Lodderstedt ; Mike Jones ; Justin Richer ; IETF oauth WG  =0ASent: Friday, February 15, 2013 8:19 AM=0ASubject: Re: [OA=
UTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February =
2013=0A =0A=0ABill=0A=0AYou aren't objecting to https in the as communicati=
ons correct? =A0It is the rs comms which is plain http where you want to pr=
otect the credential from theft. =A0=0A=0AEven replay is not the primary is=
sue here.=A0=0A=0APhil=0A=0ASent from my phone.=0A=0AOn 2013-02-15, at 8:09=
, William Mills  wrote:=0A=0A=0AI'll repeat the use=
 case for Flickr, which requires OAuth 1.0a type capabilites that OAuth 2 d=
oes not provide. =A0Simply stating "move to HTTPS" is not a viable response=
 here. =A0=0A>=0A>=0A>=0A>________________________________=0A> From: Torste=
n Lodderstedt =0A>To: William Mills  =0A>Cc: Mike Jones ; Justin Richer =
; Phil Hunt ; IETF oauth WG  =0A>Sent: Friday, February 15, 2013 7:22 AM=0A>Subject: Re: [OAU=
TH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2=
013=0A> =0A>=0A>Hi Bill,=0A>=0A>=0A>I think one needs to compare the costs/=
impact of HTTPS on one side and the implementation of integrity protection =
and replay detection on the other. We had this discussion several times.=0A=
>=0A>=0A>regards,=0A>Torsten.=0A>=0A>Am 15.02.2013 um 08:08 schrieb William=
 Mills :=0A>=0A>=0A>I fundamentally disagree with t=
hat too. =A0OAuth 2 is the *framework*, one which supports multiple token t=
ypes. =A0Bearer tokens were the first credential type defined.=0A>>=0A>>=0A=
>>OAuth 1.0a also requires HTTPS transport for authentication and getting t=
he token.=0A>>=0A>>=0A>>There are =A0real use cases for tokens usable over =
plain text with integrity protection.=0A>>=0A>>=0A>>-bill=0A>>=0A>>=0A>>=0A=
>>________________________________=0A>> From: Torsten Lodderstedt =0A>>To: William Mills  =0A>>Cc: Mi=
ke Jones ; Justin Richer ; =
Phil Hunt ; IETF oauth WG  =0A>>Sent:=
 Thursday, February 14, 2013 10:05 PM=0A>>Subject: Re: [OAUTH-WG] Minutes f=
rom the OAuth Design Team Conference Call - 11th February 2013=0A>> =0A>>=
=0A>>Hi Bill,=0A>>=0A>>=0A>>OAuth 2.0 took a different direction by relying=
 on HTTPS to provide the basic protection. So the need to have a token, whi=
ch can be used for service requests over plain HTTP is arguable. My underst=
anding of this activity was, the intend is to provide additional protection=
 on top of HTTPS.=0A>>=0A>>=0A>>regards,=0A>>Torsten.=0A>>=0A>>Am 15.02.201=
3 um 02:31 schrieb William Mills :=0A>>=0A>>=0A>>I =
disagree with "That was the impediment to OAuth 1.0 adoption that OAuth 2.0=
 solved in the first place.", unless "solving" means does not address the n=
eed for it at all.=0A>>>=0A>>>=0A>>>OAuth 2 does several good things, but i=
t still lacks a defined token type that is safe to user over plain text HTT=
P. =A01.0a solved that.=0A>>>=0A>>>=0A>>>=0A>>>____________________________=
____=0A>>> From: Mike Jones =0A>>>To: Justin R=
icher ; Phil Hunt  =0A>>>Cc: IETF =
oauth WG  =0A>>>Sent: Thursday, February 14, 2013 1:44 PM=
=0A>>>Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference=
 Call - 11th February 2013=0A>>> =0A>>>I'm in favor of reusing the JWT work=
 that this WG is also doing. :-)=0A>>>=0A>>>I'm pretty skeptical of us inve=
nting another custom scheme for signing HTTP headers.=A0 That was the imped=
iment to OAuth 1.0 adoption that OAuth 2.0 solved in the first place.=0A>>>=
=0A>>>=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 -- Mike=0A>>>=0A>>>-----Origi=
nal Message-----=0A>>>From: oauth-bounces@ietf.org [mailto:oauth-bounces@ie=
tf.org] On Behalf Of Justin Richer=0A>>>Sent: Tuesday, February 12, 2013 9:=
35 AM=0A>>>To: Phil Hunt=0A>>>Cc: IETF oauth WG=0A>>>Subject: Re: [OAUTH-WG=
] Minutes from the OAuth Design Team Conference Call - 11th February 2013=
=0A>>>=0A>>>That's my reading of it as well, Phil, thanks for providing the=
 clarification.=0A One motivator behind using a JSON-based token is to be a=
ble to=0A re-use some of the great work that the JOSE group is doing but ap=
ply it to an HTTP payload.=0A>>>=0A>>>What neither of us want is a token ty=
pe that requires stuffing all query, header, and other parameters *into* th=
e JSON object itself, which would be a more SOAPy approach.=0A>>>=0A>>>=A0 =
-- Justin=0A>>>=0A>>>On 02/12/2013 12:30 PM, Phil Hunt wrote:=0A>>>> Clarif=
ication.=A0 I think Justin and I were in agreement that we don't want to se=
e a format that requires JSON payloads.=A0 We are both interested in a JSON=
 token used in the authorization header that could be based on a computed s=
ignature of some combination of http headers and body if possible.=0A>>>>=
=0A>>>> Phil=0A>>>>=0A>>>> @independentid=0A>>>> www.independentid.com=0A>>=
>> phil.hunt@oracle.com=0A>>>>=0A>>>>=0A>>>>=0A>>>>=0A>>>>=0A>>>> On=0A 201=
3-02-12, at 1:10 AM, Hannes Tschofenig wrote:=0A>>>>=0A>>>>> Here are my no=
tes.=0A>>>>>=0A>>>>> Participants:=0A>>>>>=0A>>>>> * John Bradley=0A>>>>> *=
 Derek Atkins=0A>>>>> * Phil Hunt=0A>>>>> * Prateek Mishra=0A>>>>> * Hannes=
 Tschofenig=0A>>>>> * Mike Jones=0A>>>>> * Antonio Sanso=0A>>>>> * Justin R=
icher=0A>>>>>=0A>>>>> Notes:=0A>>>>>=0A>>>>> My slides are available here: =
=0A>>>>> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt=0A>>>>=
>=0A>>>>> Slide #2 summarizes earlier discussions during the conference cal=
ls.=0A>>>>>=0A>>>>> -- HTTP vs. JSON=0A>>>>>=0A>>>>> Phil noted that he doe=
s not like to use the MAC Token draft as a starting point because it does n=
ot re-use any of the work done in the JOSE working group and in particular =
all the libraries that are available today. He mentioned that earlier attem=
pts to write the MAC Token code lead to=0A problems for implementers.=0A>>>=
>>=0A>>>>> Justin responded that he does not agree with using JSON as a tra=
nsport mechanism since this would replicate a SOAP style.=0A>>>>>=0A>>>>> P=
hil noted that he wants to send JSON but the signature shall be computed ov=
er the HTTP header field.=0A>>>>>=0A>>>>> -- Flexibility for the keyed mess=
age digest computation=0A>>>>>=0A>>>>>=A0 From earlier discussion it was cl=
ear that the conference call participants wanted more flexibility regarding=
 the keyed message digest computation. For this purpose Hannes presented th=
e DKIM based approach, which allows selective header fields to be included =
in the digest. This is shown in slide #4.=0A>>>>>=0A>>>>> After some discus=
sion the conference call participants thought that this would meet their ne=
eds. Further investigations would still be useful to determine the degree o=
f failed HMAC calculations due to HTTP proxies modifying the=0A content.=0A=
>>>>>=0A>>>>> -- Key Distribution=0A>>>>>=0A>>>>> Hannes presented the open=
 issue regarding the choice of key =0A>>>>> distribution. Slides #6-#8 pres=
ent three techniques and Hannes asked =0A>>>>> for feedback regarding the p=
referred style. Justin and others didn't =0A>>>>> see the need to decide on=
 one mechanism - they wanted to keep the =0A>>>>> choice open. Derek indica=
ted that this will not be an acceptable =0A>>>>> approach. Since the resour=
ce server and the authorization server may, =0A>>>>> in the OAuth 2.0 frame=
work, be entities produced by different vendors =0A>>>>> there is an intero=
perability need. Justin responded that he disagrees =0A>>>>> and that the r=
esource server needs to understand the access token and =0A>>>>> referred t=
o the recent draft submission for the token introspection =0A>>>>> endpoint=
. Derek indicated that the resource server has to understand =0A>>>>>=0A th=
e content of the access token and the token introspection endpoint =0A>>>>>=
 just pushes the problem around: the resource server has to send the =0A>>>=
>> access token to the authorization server and then the resource server =
=0A>>>>> gets the result back (which he the=0A>>>n=0A>>>>=A0 =A0 a=0A>>>>> =
gain needs to understand) in order to make a meaningful authorization decis=
ion.=0A>>>>>=0A>>>>> Everyone agreed that the client must receive the sessi=
on key from the authorization server and that this approach has to be stand=
ardized. It was also agreed that this is a common approach among all three =
key distribution mechanisms.=0A>>>>>=0A>>>>> Hannes asked the participants =
to think about their preference.=0A>>>>>=0A>>>>> The questions regarding ke=
y naming and the indication for the intended resource server the client wan=
ts to talk to have been postponed.=0A>>>>>=0A>>>>> Ciao=0A>>>>>=0A Hannes=
=0A>>>>>=0A>>>>>=0A>>>>> _______________________________________________=0A=
>>>>> OAuth mailing list=0A>>>>> OAuth@ietf.org=0A>>>>> https://www.ietf.or=
g/mailman/listinfo/oauth=0A>>>> ___________________________________________=
____=0A>>>> OAuth mailing list=0A>>>> OAuth@ietf.org=0A>>>> https://www.iet=
f.org/mailman/listinfo/oauth=0A>>>=0A>>>=0A>>>_____________________________=
__________________=0A>>>OAuth mailing list=0A>>>OAuth@ietf.org=0A>>>https:/=
/www.ietf.org/mailman/listinfo/oauth=0A>>>_________________________________=
______________=0A>>>OAuth mailing list=0A>>>OAuth@ietf.org=0A>>>https://www=
.ietf.org/mailman/listinfo/oauth=0A>>>=0A>>>=0A>>>=0A>>____________________=
___________________________=0A>>>OAuth mailing list=0A>>>OAuth@ietf.org=0A>=
>>https://www.ietf.org/mailman/listinfo/oauth=0A>>>=0A>>=0A>>=0A>=0A>
--764183289-1875840522-1360945315=:70386
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Exactly.  And in the Flickr case replay of the same event is not a p=
roblem.  Thanks for keeping me honest, work just cranked the dial up t=
o 11.5 so I'm a bit distracted.

  From: =
Phil Hunt <phil.hunt@oracle.com>
 To: William Mills <wmills_92105@yahoo.com> 
Cc: Torsten Lodderstedt <tor=
sten@lodderstedt.net>; Mike Jones <Michael.Jones@microsoft.com>; J=
ustin Richer
 <jricher@mitre.org>; IETF oauth WG <oauth@ietf.org> 
 Sent: Friday, February 15, 2013=
 8:19 AM
 Subject: Re: =
[OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th Februa=
ry 2013

=0ABill<=
/div>
You aren't objecting to https in the as communicat=
ions correct?  It is the rs comms which is plain http where you want t=
o protect the credential from theft.  

Even r=
eplay is not the primary issue here. 

Phil
S=
ent from my phone.

On 2013-02-15, at 8:09, William Mill=
s <wmills_92105@yahoo.com> wrote:

I'll repeat the use case for Flickr, which requires OAuth 1.0a type capa=
bilites that OAuth 2 does not provide.  Simply stating "move to HTTPS"=
 is not a viable response here.

        <=
b>From: Torsten Lodderstedt &l=
t;torsten@lodderstedt.net=
>
 To: William Mills =
<wmills_92105@yahoo.com&=
gt; 
Cc: Mike Jones <=
Michael.Jones@micro=
soft.com>; Justin Richer <jricher@mitre.org>; Phil=0A Hunt <=
;phil.hunt@oracle.com>; IETF=
 oauth WG <oauth@ietf.org> 
 <=
span style=3D"font-weight:bold;">Sent: Friday, February 15, 2013=
 7:22 AM
 Subject: Re: [=
OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th Februar=
y 2013

=0AHi Bil=
l,

I think one needs to compare the costs/impact o=
f HTTPS on one side and the implementation of integrity protection and repl=
ay detection on the other. We had this discussion several times.
=

regards,
Torsten.

Am 15.02.2013 um 0=
8:08 schrieb William Mills <=
wmills_92105@yahoo.com>:

I fundamentally disagree with that too.  OAuth 2 =
is the *framework*, one which supports multiple token types.  Bearer t=
okens were the first credential type defined.

OAuth 1.0a also requires HTTPS transport for authenti=
cation and getting the token.

<=
/span>
There are  real use cases for =
tokens usable over plain text with integrity protection.

-bill<=
/span>

 =0A From: Torsten Lodderstedt <torsten@lodderstedt.net> To: William Mills <wmills_92105@yahoo.com> Cc: Mike Jones <Michael.Jones@microsoft.com=
>; Justin Richer <jricher@mitre=
.org>; Phil Hunt <phil.hu=
nt@oracle.com>; IETF=0A oauth WG <oau=
th@ietf.org> 
 Sent:<=
/b> Thursday, February 14, 2013 10:05 PM
 Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Tea=
m Conference Call - 11th February 2013

=0AHi Bill,

OAuth 2.0 took =
a different direction by relying on HTTPS to provide the basic protection. =
So the need to have a token, which can be used for service requests over pl=
ain HTTP is arguable. My understanding of this activity was, the intend is =
to provide additional protection on top of HTTPS.

=
regards,
Torsten.

Am 15.02.2013 um 02:31 schrieb Wi=
lliam Mills <wmills_92105@ya=
hoo.com>:

=
I disagree with "That was the impediment to=0A=
 OAuth 1.0 adoption that OAuth 2.0 solved in the first place.", unless "sol=
ving" means does not address the need for it at all.

OAuth 2 does=
 several=0A good things, but it still lacks a defined token type that is sa=
fe to user over plain text HTTP.  1.0a solved that.
<=
br>

  From: Mike Jones <Michael.Jones@microsoft.com>
 To: Justin Richer <jricher@mitre.org>; Phil Hunt <phil.hunt@oracle.com> 
<=
span style=3D"font-weight:bold;">Cc: IETF oauth WG <oauth@ietf.org> 
 Sent: Thursday, February 14, 2013 1:44 PM
 Subject: Re: [OAUTH-WG] Minutes from=
 the OAuth Design Team Conference Call - 11th February 2013
=0A  =

=0AI'm in favor of reusing the JWT work that this WG is also doi=
ng. :-)

I'm pretty skeptical of us inventing another custom scheme f=
or signing HTTP headers.  That was the impediment to OAuth 1.0 adoptio=
n that OAuth 2.0 solved in the first place.

     =
;           -- Mike

-----Ori=
ginal Message-----
From: oau=
th-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Tuesday, F=
ebruary 12, 2013 9:35 AM
To: Phil Hunt
Cc: IETF oauth WG
Subject: =
Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th Fe=
bruary 2013

That's my reading of it as well, Phil, thanks for provid=
ing the clarification.=0A One motivator behind using a JSON-based token is =
to be able to=0A re-use some of the great work that the JOSE group is doing=
 but apply it to an HTTP payload.

What neither of us want is a token=
 type that requires stuffing all query, header, and other parameters *into*=
 the JSON object itself, which would be a more SOAPy approach.

 =
; -- Justin

On 02/12/2013 12:30 PM, Phil Hunt wrote:
> Clarifi=
cation.  I think Justin and I were in agreement that we don't want to =
see a format that requires JSON payloads.  We are both interested in a=
 JSON token used in the authorization header that could be based on a compu=
ted signature of some combination of http headers and body if possible.
=
>
> Phil
>
> @independentid
> www.independenti=
d.com
> phil.hunt@oracle.com
>
&=
gt;
>
>
>
> On=0A 2013-02-12, at 1:10 AM, Hannes Ts=
chofenig wrote:
>
>> Here are my notes.
>>
>&=
gt; Participants:
>>
>> * John Bradley
>> * Dere=
k Atkins
>> * Phil Hunt
>> * Prateek Mishra
>> *=
 Hannes Tschofenig
>> * Mike Jones
>> * Antonio Sanso
=
>> * Justin Richer
>>
>> Notes:
>>
>=
> My slides are available here: 
>> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
&g=
t;>
>> Slide #2 summarizes earlier discussions during the confe=
rence calls.
>>
>> -- HTTP vs. JSON
>>
>&g=
t; Phil noted that he does not like to use the MAC Token draft as a startin=
g point because it does not re-use any of the work done in the JOSE working=
 group and in particular all the
 libraries that are available today. He mentioned that earlier attempts to =
write the MAC Token code lead to=0A problems for implementers.
>><=
br>>> Justin responded that he does not agree with using JSON as a tr=
ansport mechanism since this would replicate a SOAP style.
>>
&=
gt;> Phil noted that he wants to send JSON but the signature shall be co=
mputed over the HTTP header field.
>>
>> -- Flexibility f=
or the keyed message digest computation
>>
>>  From =
earlier discussion it was clear that the conference call participants wante=
d more flexibility regarding the keyed message digest computation. For this=
 purpose Hannes presented the DKIM based approach, which allows selective h=
eader fields to be included in the digest. This is shown in slide #4.
&g=
t;>
>> After some discussion the conference call participants t=
hought that this would meet their needs. Further investigations would still=
 be useful to determine the degree of failed HMAC calculations due to HTTP =
proxies modifying the=0A content.
>>
>> -- Key Distributi=
on
>>
>> Hannes presented the open issue regarding the ch=
oice of key 
>> distribution. Slides #6-#8 present three technique=
s and Hannes asked 
>> for feedback regarding the preferred style.=
 Justin and others didn't 
>> see the need to decide on one mechan=
ism - they wanted to keep the 
>> choice open. Derek indicated tha=
t this will not be an acceptable 
>> approach. Since the resource =
server and the authorization server may, 
>> in the OAuth 2.0 fram=
ework, be entities produced by different vendors 
>> there is an i=
nteroperability need. Justin responded that he disagrees 
>> and t=
hat the resource server needs to understand the access token and 
>&g=
t; referred to the recent draft submission for the token introspection 
=
>> endpoint. Derek indicated that the resource server has to understa=
nd 
>>=0A the content of the access token and the token introspect=
ion endpoint 
>> just pushes the problem around: the resource serv=
er has to send the 
>> access token to the authorization server an=
d then the resource server 
>> gets the result back (which he the<=
br> n
>    a
>> gain needs to understand) in order=
 to make a meaningful authorization decision.
>>
>> Every=
one agreed that the client must receive the session key from the authorizat=
ion server and that this approach has to be standardized. It was also agree=
d that this is a common approach among all three key distribution mechanism=
s.
>>
>> Hannes asked the participants to think about the=
ir preference.
>>
>> The questions regarding key naming a=
nd the indication for the intended resource server the client wants to talk=
 to have been postponed.
>>
>> Ciao
>>=0A Hannes=

>>
>>
>> ______________________________________=
_________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/m=
ailman/listinfo/oauth
> _________________________________________=
______
> OAuth mailing list
> OAuth=
@ietf.org
> https://www.ietf.org/mailman/listinfo=
/oauth

_______________________________________________
OA=
uth mailing list
OAuth@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/oauth
___________________________=
____________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinf=
o/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/=
mailman/listinfo/oauth

 =0A 

--764183289-1875840522-1360945315=:70386--

From sberyozkin@gmail.com  Fri Feb 15 08:25:40 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF8C21F888F for ; Fri, 15 Feb 2013 08:25:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.324
X-Spam-Level: 
X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=-1.276, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cx3-bfj5bMG4 for ; Fri, 15 Feb 2013 08:25:39 -0800 (PST)
Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 090AC21F8887 for ; Fri, 15 Feb 2013 08:25:34 -0800 (PST)
Received: by mail-we0-f179.google.com with SMTP id p43so1271676wea.10 for ; Fri, 15 Feb 2013 08:25:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=V1CSdCJNps3ynHx0DJ7941DfASEMO3RGnaXLKkOMc4Q=; b=jaXB3ulGX7dK+ZP15A/MVVNxXHN8O6xNG39HfO1s0BBgCelV+P5qreZRh1enZo3OJY CDCi9HXLdmY7zj8T1ZOgLHF6kXkKF2NtTPWMGLI0KiuWz5SoC1zysoM5shI+UhM/qojE CdxexaJka3VWw0mbSi7fxon6Vc/ZZP8fpNVAOTL0lnMPQUK8+Sq/+J2Jc2SBT3CPiLlA EWh5H+xGaZ9yCSgtQwa8TRcb/rtuo5d2L8X8gQRkVQwY1q4PnFXFw+o5LtGB5+qtrDo1 04TNgzwzuvuJLBpR7GRN4wzjH7IwDBbJO6j9EZYz4SdtQFfqa8bNYG1ZlLx2twdSiiAN P3Zg==
X-Received: by 10.180.94.69 with SMTP id da5mr7026254wib.30.1360945533910; Fri, 15 Feb 2013 08:25:33 -0800 (PST)
Received: from [10.36.226.5] ([217.173.99.61]) by mx.google.com with ESMTPS id bg5sm6253685wib.8.2013.02.15.08.25.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Feb 2013 08:25:33 -0800 (PST)
Message-ID: <511E617A.4000302@gmail.com>
Date: Fri, 15 Feb 2013 16:25:30 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: oauth@ietf.org
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net>  <511A7D27.8010209@mitre.org> <4E1F6AAD24975D4BA5B16804296739436744BD23@TK5EX14MBXC285.redmond.corp.microsoft.com> <1360891897.14004.YahooMailNeo@web31811.mail.mud.yahoo.com>  <1360912115.36543.YahooMailNeo@web31811.mail.mud.yahoo.com> <2A0F585F-2CEF-418D-9654-5084E6C9BD0D@lodderstedt.net> <1360944589.51724.YahooMailNeo@web31808.mail.mud.yahoo.com>
In-Reply-To: <1360944589.51724.YahooMailNeo@web31808.mail.mud.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Feb 2013 16:25:40 -0000

I wonder why it is proving so difficult to get a nearly completed MAC 
draft completed ?
Is it because:
1. JWT was first in OAuth2 and thus it wins ?
2. MAC is not 'capable' enough as JWT is ?
3. Not enough motivation for some vendors to push MAC ?

Example, in cases where not a product but a development framework is 
shipped (as with us for example), IMHO is it a big motivation to get MAC 
done for the reasons repeated many times. Or in case of migrating Flickr 
users to OAuth2.
I think I can see why no interest is there where nothing is really 
achieved if JWT is used from the get go, no particular need to get OAuth 
1.0 developers out there migrating to the particular products.

This is 3. Re 2, I think there was enough expressed to suggest that it 
can complement JWT nicely. So far I'm inclined to think it is 3. and 2. 
which stop it from being completed, with 3. 'contributing' indirectly 
but significantly,

Just my 2c
Thanks, Sergey

On 15/02/13 16:09, William Mills wrote:
> I'll repeat the use case for Flickr, which requires OAuth 1.0a type
> capabilites that OAuth 2 does not provide. Simply stating "move to
> HTTPS" is not a viable response here.
>
> ------------------------------------------------------------------------
> *From:* Torsten Lodderstedt 
> *To:* William Mills 
> *Cc:* Mike Jones ; Justin Richer
> ; Phil Hunt ; IETF oauth WG
> 
> *Sent:* Friday, February 15, 2013 7:22 AM
> *Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference
> Call - 11th February 2013
>
> Hi Bill,
>
> I think one needs to compare the costs/impact of HTTPS on one side and
> the implementation of integrity protection and replay detection on the
> other. We had this discussion several times.
>
> regards,
> Torsten.
>
> Am 15.02.2013 um 08:08 schrieb William Mills  >:
>
>> I fundamentally disagree with that too. OAuth 2 is the *framework*,
>> one which supports multiple token types. Bearer tokens were the first
>> credential type defined.
>>
>> OAuth 1.0a also requires HTTPS transport for authentication and
>> getting the token.
>>
>> There are real use cases for tokens usable over plain text with
>> integrity protection.
>>
>> -bill
>>
>> ------------------------------------------------------------------------
>> *From:* Torsten Lodderstedt > >
>> *To:* William Mills > >
>> *Cc:* Mike Jones > >; Justin Richer
>> >; Phil Hunt
>> >; IETF oauth WG
>> >
>> *Sent:* Thursday, February 14, 2013 10:05 PM
>> *Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team
>> Conference Call - 11th February 2013
>>
>> Hi Bill,
>>
>> OAuth 2.0 took a different direction by relying on HTTPS to provide
>> the basic protection. So the need to have a token, which can be used
>> for service requests over plain HTTP is arguable. My understanding of
>> this activity was, the intend is to provide additional protection on
>> top of HTTPS.
>>
>> regards,
>> Torsten.
>>
>> Am 15.02.2013 um 02:31 schrieb William Mills > >:
>>
>>> I disagree with "That was the impediment to OAuth 1.0 adoption that
>>> OAuth 2.0 solved in the first place.", unless "solving" means does
>>> not address the need for it at all.
>>>
>>> OAuth 2 does several good things, but it still lacks a defined token
>>> type that is safe to user over plain text HTTP. 1.0a solved that.
>>>
>>> ------------------------------------------------------------------------
>>> *From:* Mike Jones >> >
>>> *To:* Justin Richer >;
>>> Phil Hunt >
>>> *Cc:* IETF oauth WG >
>>> *Sent:* Thursday, February 14, 2013 1:44 PM
>>> *Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team
>>> Conference Call - 11th February 2013
>>>
>>> I'm in favor of reusing the JWT work that this WG is also doing. :-)
>>>
>>> I'm pretty skeptical of us inventing another custom scheme for
>>> signing HTTP headers. That was the impediment to OAuth 1.0 adoption
>>> that OAuth 2.0 solved in the first place.
>>>
>>> -- Mike
>>>
>>> -----Original Message-----
>>> From: oauth-bounces@ietf.org 
>>> [mailto:oauth-bounces@ietf.org ] On
>>> Behalf Of Justin Richer
>>> Sent: Tuesday, February 12, 2013 9:35 AM
>>> To: Phil Hunt
>>> Cc: IETF oauth WG
>>> Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference
>>> Call - 11th February 2013
>>>
>>> That's my reading of it as well, Phil, thanks for providing the
>>> clarification. One motivator behind using a JSON-based token is to be
>>> able to re-use some of the great work that the JOSE group is doing
>>> but apply it to an HTTP payload.
>>>
>>> What neither of us want is a token type that requires stuffing all
>>> query, header, and other parameters *into* the JSON object itself,
>>> which would be a more SOAPy approach.
>>>
>>> -- Justin
>>>
>>> On 02/12/2013 12:30 PM, Phil Hunt wrote:
>>> > Clarification. I think Justin and I were in agreement that we don't
>>> want to see a format that requires JSON payloads. We are both
>>> interested in a JSON token used in the authorization header that
>>> could be based on a computed signature of some combination of http
>>> headers and body if possible.
>>> >
>>> > Phil
>>> >
>>> > @independentid
>>> > www.independentid.com 
>>> > phil.hunt@oracle.com 
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On 2013-02-12, at 1:10 AM, Hannes Tschofenig wrote:
>>> >
>>> >> Here are my notes.
>>> >>
>>> >> Participants:
>>> >>
>>> >> * John Bradley
>>> >> * Derek Atkins
>>> >> * Phil Hunt
>>> >> * Prateek Mishra
>>> >> * Hannes Tschofenig
>>> >> * Mike Jones
>>> >> * Antonio Sanso
>>> >> * Justin Richer
>>> >>
>>> >> Notes:
>>> >>
>>> >> My slides are available here:
>>> >> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
>>> >>
>>> >> Slide #2 summarizes earlier discussions during the conference calls.
>>> >>
>>> >> -- HTTP vs. JSON
>>> >>
>>> >> Phil noted that he does not like to use the MAC Token draft as a
>>> starting point because it does not re-use any of the work done in the
>>> JOSE working group and in particular all the libraries that are
>>> available today. He mentioned that earlier attempts to write the MAC
>>> Token code lead to problems for implementers.
>>> >>
>>> >> Justin responded that he does not agree with using JSON as a
>>> transport mechanism since this would replicate a SOAP style.
>>> >>
>>> >> Phil noted that he wants to send JSON but the signature shall be
>>> computed over the HTTP header field.
>>> >>
>>> >> -- Flexibility for the keyed message digest computation
>>> >>
>>> >> From earlier discussion it was clear that the conference call
>>> participants wanted more flexibility regarding the keyed message
>>> digest computation. For this purpose Hannes presented the DKIM based
>>> approach, which allows selective header fields to be included in the
>>> digest. This is shown in slide #4.
>>> >>
>>> >> After some discussion the conference call participants thought
>>> that this would meet their needs. Further investigations would still
>>> be useful to determine the degree of failed HMAC calculations due to
>>> HTTP proxies modifying the content.
>>> >>
>>> >> -- Key Distribution
>>> >>
>>> >> Hannes presented the open issue regarding the choice of key
>>> >> distribution. Slides #6-#8 present three techniques and Hannes asked
>>> >> for feedback regarding the preferred style. Justin and others didn't
>>> >> see the need to decide on one mechanism - they wanted to keep the
>>> >> choice open. Derek indicated that this will not be an acceptable
>>> >> approach. Since the resource server and the authorization server may,
>>> >> in the OAuth 2.0 framework, be entities produced by different vendors
>>> >> there is an interoperability need. Justin responded that he disagrees
>>> >> and that the resource server needs to understand the access token and
>>> >> referred to the recent draft submission for the token introspection
>>> >> endpoint. Derek indicated that the resource server has to understand
>>> >> the content of the access token and the token introspection endpoint
>>> >> just pushes the problem around: the resource server has to send the
>>> >> access token to the authorization server and then the resource server
>>> >> gets the result back (which he the
>>> n
>>> > a
>>> >> gain needs to understand) in order to make a meaningful
>>> authorization decision.
>>> >>
>>> >> Everyone agreed that the client must receive the session key from
>>> the authorization server and that this approach has to be
>>> standardized. It was also agreed that this is a common approach among
>>> all three key distribution mechanisms.
>>> >>
>>> >> Hannes asked the participants to think about their preference.
>>> >>
>>> >> The questions regarding key naming and the indication for the
>>> intended resource server the client wants to talk to have been postponed.
>>> >>
>>> >> 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
>>>
>>>
>>> _______________________________________________
>>> 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

From twbray@google.com  Fri Feb 15 08:50:04 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA6D21F855F for ; Fri, 15 Feb 2013 08:50:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.81
X-Spam-Level: 
X-Spam-Status: No, score=-101.81 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bS1vAiLwgeba for ; Fri, 15 Feb 2013 08:50:00 -0800 (PST)
Received: from mail-ia0-x22f.google.com (mail-ia0-x22f.google.com [IPv6:2607:f8b0:4001:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7B021F8869 for ; Fri, 15 Feb 2013 08:50:00 -0800 (PST)
Received: by mail-ia0-f175.google.com with SMTP id r4so3412383iaj.20 for ; Fri, 15 Feb 2013 08:50:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=IDMxY+v9lchWnkOPV6gi3oh0D6LuYe0QeT2b2MLsXts=; b=W2FfYpUpHMr8+nYXEjqHoO2xxwqJue4inTBIQNTdS+yB9OVtwAuLXHhxZpLS7mRzRO sdtU0zjgVMiZrB9zxPEtcFoiw3NTu2sYHlNK6zLb0XtzML84IGktS+GV4yfD10fHQ3y9 z/PZ7qzQ8dFaIUBPkVJLO+WeEwEdqK/6m//dRe9Iz7lsaFqhzADpCpMRGwvD7v3+V/Ex pSyWukjfM20ICQcIZSUehI4/UE0QNVtnJwOSiT5sJEVBIEIUA/ODRwoSB2/9UmAO1Xeh 2lSxQWvpVd4zWtjG8MiIfYdVw9PBIR42204RSd8dUGUAigz482yIgxCwhUfwW+GGKD8s dTLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=IDMxY+v9lchWnkOPV6gi3oh0D6LuYe0QeT2b2MLsXts=; b=C0OS0g+h1qtfhVhJAPXrr/iL2yG3+oRDg+pqrED9eewqGlF1K+j8eqtSrJgErj2npM Cc1g8VCzA5CNfva5zGCBjtOFANloPmto/1P7rj+L3Wik1ZX2yOrG2JZl75fnHVVlRrB/ /ehwRl3RIVWObZ9pgn+dhEbOI0LL2z2c2xj6GSm2UY46dKggdqz0zEsKDjCJGZZZGLRz PsmrGz4MqsP1T+IvLiG4t789klw8Dnq9qDwkTA92wIxAZRPeJOVk+B62rJZOkddoDdhl 4vymEw4WZnod98iUwg5K8vNjIkMiWBzEgH4bTXYTLUalgQvNUOLJ7SmbMLldiohz0VOQ WPGA==
X-Received: by 10.50.196.234 with SMTP id ip10mr2297728igc.27.1360946989711; Fri, 15 Feb 2013 08:49:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.16.199 with HTTP; Fri, 15 Feb 2013 08:49:19 -0800 (PST)
In-Reply-To: <1360944589.51724.YahooMailNeo@web31808.mail.mud.yahoo.com>
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net>  <511A7D27.8010209@mitre.org> <4E1F6AAD24975D4BA5B16804296739436744BD23@TK5EX14MBXC285.redmond.corp.microsoft.com> <1360891897.14004.YahooMailNeo@web31811.mail.mud.yahoo.com>  <1360912115.36543.YahooMailNeo@web31811.mail.mud.yahoo.com> <2A0F585F-2CEF-418D-9654-5084E6C9BD0D@lodderstedt.net> <1360944589.51724.YahooMailNeo@web31808.mail.mud.yahoo.com>
From: Tim Bray 
Date: Fri, 15 Feb 2013 08:49:19 -0800
Message-ID: 
To: William Mills 
Content-Type: multipart/alternative; boundary=14dae9341213e1403c04d5c6294d
X-Gm-Message-State: ALoCoQm9mnvqCwvZmL2lydI/mpvNhOx1tPVtO0HQ9w2AgHzCZVPmxJfHfHYw8L/vvCxq2OiV6v24/u1+6sgmUqXYIFUfswrptS/krj5kGYQOV+Z1GYbLFSMtYuWlWAHgkZkH8yhw+O0QwR3zT9Okhcx+/OGFaASVsjQgrVv9x1g0ltiPhvjCafkuBS8r5IX3u5xCiOKlKAGE
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Feb 2013 16:50:04 -0000

--14dae9341213e1403c04d5c6294d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Not deeply acquainted with the Flickr scenario, but it occurs to me to ask:
If OAuth 1.0 is working well for them, why don=E2=80=99t they just keep usi=
ng it?
 I.e. if there=E2=80=99s already a good solution in place for people who re=
quire
secure authn/authz over insecure channels, why would we go the extra work
of duplicating that in OAuth 2 territory? -T

On Fri, Feb 15, 2013 at 8:09 AM, William Mills wrot=
e:

> I'll repeat the use case for Flickr, which requires OAuth 1.0a type
> capabilites that OAuth 2 does not provide.  Simply stating "move to HTTPS=
"
> is not a viable response here.
>
>   ------------------------------
> *From:* Torsten Lodderstedt 
> *To:* William Mills 
> *Cc:* Mike Jones ; Justin Richer <
> jricher@mitre.org>; Phil Hunt ; IETF oauth WG <
> oauth@ietf.org>
> *Sent:* Friday, February 15, 2013 7:22 AM
> *Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference
> Call - 11th February 2013
>
> Hi Bill,
>
> I think one needs to compare the costs/impact of HTTPS on one side and th=
e
> implementation of integrity protection and replay detection on the other.
> We had this discussion several times.
>
> regards,
> Torsten.
>
> Am 15.02.2013 um 08:08 schrieb William Mills :
>
> I fundamentally disagree with that too.  OAuth 2 is the *framework*, one
> which supports multiple token types.  Bearer tokens were the first
> credential type defined.
>
> OAuth 1.0a also requires HTTPS transport for authentication and getting
> the token.
>
> There are  real use cases for tokens usable over plain text with integrit=
y
> protection.
>
> -bill
>
>   ------------------------------
> *From:* Torsten Lodderstedt 
> *To:* William Mills 
> *Cc:* Mike Jones ; Justin Richer <
> jricher@mitre.org>; Phil Hunt ; IETF oauth WG <
> oauth@ietf.org>
> *Sent:* Thursday, February 14, 2013 10:05 PM
> *Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference
> Call - 11th February 2013
>
> Hi Bill,
>
> OAuth 2.0 took a different direction by relying on HTTPS to provide the
> basic protection. So the need to have a token, which can be used for
> service requests over plain HTTP is arguable. My understanding of this
> activity was, the intend is to provide additional protection on top of
> HTTPS.
>
> regards,
> Torsten.
>
> Am 15.02.2013 um 02:31 schrieb William Mills :
>
> I disagree with "That was the impediment to OAuth 1.0 adoption that OAuth
> 2.0 solved in the first place.", unless "solving" means does not address
> the need for it at all.
>
> OAuth 2 does several good things, but it still lacks a defined token type
> that is safe to user over plain text HTTP.  1.0a solved that.
>
>   ------------------------------
> *From:* Mike Jones 
> *To:* Justin Richer ; Phil Hunt 
> *Cc:* IETF oauth WG 
> *Sent:* Thursday, February 14, 2013 1:44 PM
> *Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference
> Call - 11th February 2013
>
> I'm in favor of reusing the JWT work that this WG is also doing. :-)
>
> I'm pretty skeptical of us inventing another custom scheme for signing
> HTTP headers.  That was the impediment to OAuth 1.0 adoption that OAuth 2=
.0
> solved in the first place.
>
>                 -- Mike
>
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of
> Justin Richer
> Sent: Tuesday, February 12, 2013 9:35 AM
> To: Phil Hunt
> Cc: IETF oauth WG
> Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Cal=
l
> - 11th February 2013
>
> That's my reading of it as well, Phil, thanks for providing the
> clarification. One motivator behind using a JSON-based token is to be abl=
e
> to re-use some of the great work that the JOSE group is doing but apply i=
t
> to an HTTP payload.
>
> What neither of us want is a token type that requires stuffing all query,
> header, and other parameters *into* the JSON object itself, which would b=
e
> a more SOAPy approach.
>
>   -- Justin
>
> On 02/12/2013 12:30 PM, Phil Hunt wrote:
> > Clarification.  I think Justin and I were in agreement that we don't
> want to see a format that requires JSON payloads.  We are both interested
> in a JSON token used in the authorization header that could be based on a
> computed signature of some combination of http headers and body if possib=
le.
> >
> > Phil
> >
> > @independentid
> > www.independentid.com
> > phil.hunt@oracle.com
> >
> >
> >
> >
> >
> > On 2013-02-12, at 1:10 AM, Hannes Tschofenig wrote:
> >
> >> Here are my notes.
> >>
> >> Participants:
> >>
> >> * John Bradley
> >> * Derek Atkins
> >> * Phil Hunt
> >> * Prateek Mishra
> >> * Hannes Tschofenig
> >> * Mike Jones
> >> * Antonio Sanso
> >> * Justin Richer
> >>
> >> Notes:
> >>
> >> My slides are available here:
> >> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
> >>
> >> Slide #2 summarizes earlier discussions during the conference calls.
> >>
> >> -- HTTP vs. JSON
> >>
> >> Phil noted that he does not like to use the MAC Token draft as a
> starting point because it does not re-use any of the work done in the JOS=
E
> working group and in particular all the libraries that are available toda=
y.
> He mentioned that earlier attempts to write the MAC Token code lead to
> problems for implementers.
> >>
> >> Justin responded that he does not agree with using JSON as a transport
> mechanism since this would replicate a SOAP style.
> >>
> >> Phil noted that he wants to send JSON but the signature shall be
> computed over the HTTP header field.
> >>
> >> -- Flexibility for the keyed message digest computation
> >>
> >>  From earlier discussion it was clear that the conference call
> participants wanted more flexibility regarding the keyed message digest
> computation. For this purpose Hannes presented the DKIM based approach,
> which allows selective header fields to be included in the digest. This i=
s
> shown in slide #4.
> >>
> >> After some discussion the conference call participants thought that
> this would meet their needs. Further investigations would still be useful
> to determine the degree of failed HMAC calculations due to HTTP proxies
> modifying the content.
> >>
> >> -- Key Distribution
> >>
> >> Hannes presented the open issue regarding the choice of key
> >> distribution. Slides #6-#8 present three techniques and Hannes asked
> >> for feedback regarding the preferred style. Justin and others didn't
> >> see the need to decide on one mechanism - they wanted to keep the
> >> choice open. Derek indicated that this will not be an acceptable
> >> approach. Since the resource server and the authorization server may,
> >> in the OAuth 2.0 framework, be entities produced by different vendors
> >> there is an interoperability need. Justin responded that he disagrees
> >> and that the resource server needs to understand the access token and
> >> referred to the recent draft submission for the token introspection
> >> endpoint. Derek indicated that the resource server has to understand
> >> the content of the access token and the token introspection endpoint
> >> just pushes the problem around: the resource server has to send the
> >> access token to the authorization server and then the resource server
> >> gets the result back (which he the
> n
> >    a
> >> gain needs to understand) in order to make a meaningful authorization
> decision.
> >>
> >> Everyone agreed that the client must receive the session key from the
> authorization server and that this approach has to be standardized. It wa=
s
> also agreed that this is a common approach among all three key distributi=
on
> mechanisms.
> >>
> >> Hannes asked the participants to think about their preference.
> >>
> >> The questions regarding key naming and the indication for the intended
> resource server the client wants to talk to have been postponed.
> >>
> >> 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
>
>
>  _______________________________________________
> 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
>
>

--14dae9341213e1403c04d5c6294d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Not deeply acquainted with the Flickr scenario, but it occurs to me to ask:=
 If OAuth 1.0 is working well for them, why don=E2=80=99t they just keep us=
ing it? =C2=A0I.e. if there=E2=80=99s already a good solution in place for =
people who require secure authn/authz over insecure channels, why would we =
go the extra work of duplicating that in OAuth 2 territory? -T

On Fri, Feb 15, 2013 at 8:09 AM, William Mil=
ls <wmills_92105@yahoo.com> wrote:

I'll repeat the use case for Flickr, whi=
ch requires OAuth 1.0a type capabilites that OAuth 2 does not provide. =C2=
=A0Simply stating "move to HTTPS" is not a viable response here. =
=C2=A0

  From: Torsten Lodderstedt <torsten@lodderstedt.net>
 To: William Mills <wmills_92105@yahoo.com> <=
br>

Cc: Mike Jones <Michael.Jones@mic=
rosoft.com>; Justin Richer <jricher@mitre.org>; Phil
 Hunt <phil.hu=
nt@oracle.com>; IETF oauth WG <oauth@ietf.org> 
 Sent: Friday, February 15, 2013 7:22 AM

 Subject: Re: [OAUTH-WG] Min=
utes from the OAuth Design Team Conference Call - 11th February 2013

Hi Bill,

I think one needs to compa=
re the costs/impact of HTTPS on one side and the implementation of integrit=
y protection and replay detection on the other. We had this discussion seve=
ral times.

regards,
Torsten.

Am 15.02.2013=
 um 08:08 schrieb William Mills <wmills_92105@yahoo.com>:

I =
fundamentally disagree with that too. =C2=A0OAuth 2 is the *framework*, one=
 which supports multiple token types. =C2=A0Bearer tokens were the first cr=
edential type defined.

OAuth 1.0a also requires HTTPS transport for authentication and getti=
ng the token.

There are =C2=A0real use cases for tokens usable =
over plain text with integrity protection.

-bill

   =20
 From: Torsten Lodderstedt &=
lt;torsten@lodderstedt.net>
 To: William Mills <wmills_92105@yahoo.com> 

Cc: Mike Jones <Mi=
chael.Jones@microsoft.com>; Justin Richer <jricher@mitre.org>=
; Phil Hunt <phil.hunt@oracle.com>; IETF
 oauth WG <oauth@ietf.org> 
 Sen=
t: Thursday, February 14, 2013 10:05 PM
 Subject: Re: [OAUTH-WG] Minutes from the OAuth D=
esign Team Conference Call - 11th February 2013

Hi Bill,

OAuth 2.0 took a different=
 direction by relying on HTTPS to provide the basic protection. So the need=
 to have a token, which can be used for service requests over plain HTTP is=
 arguable. My understanding of this activity was, the intend is to provide =
additional protection on top of HTTPS.

regards,
Torsten.

Am 15.02.2013=
 um 02:31 schrieb William Mills <wmills_92105@yahoo.com>:

I =
disagree with "That was the impediment=
 to
 OAuth 1.0 adoption that OAuth 2.0 solved in the first place.", unless=
 "solving" means does not address the need for it at all.<=
/div>

OAuth 2 does several
 good things, but it still lacks a defined token type that is safe to user =
over plain text HTTP. =C2=A01.0a solved that.

  =

  From: Mike Jones &l=
t;Michael.Jones@microsoft.com>

 To: Justin Richer <jricher@=
mitre.org>; Phil Hunt <phil.hunt@oracle.com> 

Cc: IETF oauth WG <oauth@ietf.o=
rg> 
 Sent: Thursd=
ay, February 14, 2013 1:44 PM

 Subject: Re: [OAUTH-WG] Min=
utes from the OAuth Design Team Conference Call - 11th February 2013

I'm in favor of reusing the JWT work that this WG is also doing. :-)
I'm pretty skeptical of us inventing another custom scheme for sig=
ning HTTP headers.=C2=A0 That was the impediment to OAuth 1.0 adoption that=
 OAuth 2.0 solved in the first place.

=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=
=C2=A0 -- Mike

-----Original Message-----
From: oauth-bounces@i=
etf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Riche=
r

Sent: Tuesday, February 12, 2013 9:35 AM
To: Phil Hunt
Cc: IETF oauth=
 WG
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conferenc=
e Call - 11th February 2013

That's my reading of it as well, Phi=
l, thanks for providing the clarification.
 One motivator behind using a JSON-based token is to be able to
 re-use some of the great work that the JOSE group is doing but apply it to=
 an HTTP payload.

What neither of us want is a token type that requi=
res stuffing all query, header, and other parameters *into* the JSON object=
 itself, which would be a more SOAPy approach.

=C2=A0 -- Justin

On 02/12/2013 12:30 PM, Phil Hunt wrote:
>=
; Clarification.=C2=A0 I think Justin and I were in agreement that we don&#=
39;t want to see a format that requires JSON payloads.=C2=A0 We are both in=
terested in a JSON token used in the authorization header that could be bas=
ed on a computed signature of some combination of http headers and body if =
possible.

>
> Phil
>
> @independentid
> www.independenti=
d.com
> phil.hunt@oracle.com

>
>
>
>
>
> On
 2013-02-12, at 1:10 AM, Hannes Tschofenig wrote:
>
>> Here =
are my notes.
>>
>> Participants:
>>
>>=
 * John Bradley
>> * Derek Atkins
>> * Phil Hunt

>> * Prateek Mishra
>> * Hannes Tschofenig
>> * Mik=
e Jones
>> * Antonio Sanso
>> * Justin Richer
>>=

>> Notes:
>>
>> My slides are available here: <=
br>

>> http://www.tschofenig.priv.at/OAuth2-Security-11Feb=
2013.ppt
>>
>> Slide #2 summarizes earlier discussion=
s during the conference calls.

>>
>> -- HTTP vs. JSON
>>
>> Phil noted th=
at he does not like to use the MAC Token draft as a starting point because =
it does not re-use any of the work done in the JOSE working group and in pa=
rticular all the libraries that are available today. He mentioned that earl=
ier attempts to write the MAC Token code lead to
 problems for implementers.
>>
>> Justin responded that h=
e does not agree with using JSON as a transport mechanism since this would =
replicate a SOAP style.
>>
>> Phil noted that he wants to=
 send JSON but the signature shall be computed over the HTTP header field.<=
br>

>>
>> -- Flexibility for the keyed message digest computatio=
n
>>
>>=C2=A0 From earlier discussion it was clear that t=
he conference call participants wanted more flexibility regarding the keyed=
 message digest computation. For this purpose Hannes presented the DKIM bas=
ed approach, which allows selective header fields to be included in the dig=
est. This is shown in slide #4.

>>
>> After some discussion the conference call participants=
 thought that this would meet their needs. Further investigations would sti=
ll be useful to determine the degree of failed HMAC calculations due to HTT=
P proxies modifying the
 content.
>>
>> -- Key Distribution
>>
>&g=
t; Hannes presented the open issue regarding the choice of key 
>>=
 distribution. Slides #6-#8 present three techniques and Hannes asked 

>> for feedback regarding the preferred style. Justin and others didn=
't 
>> see the need to decide on one mechanism - they wanted t=
o keep the 
>> choice open. Derek indicated that this will not be =
an acceptable 

>> approach. Since the resource server and the authorization server m=
ay, 
>> in the OAuth 2.0 framework, be entities produced by differ=
ent vendors 
>> there is an interoperability need. Justin responde=
d that he disagrees 

>> and that the resource server needs to understand the access token =
and 
>> referred to the recent draft submission for the token intr=
ospection 
>> endpoint. Derek indicated that the resource server h=
as to understand 

>>
 the content of the access token and the token introspection endpoint 
&=
gt;> just pushes the problem around: the resource server has to send the=

>> access token to the authorization server and then the resourc=
e server 

>> gets the result back (which he the
 n
>=C2=A0 =C2=A0 a>> gain needs to understand) in order to make a meaningful authoriza=
tion decision.
>>
>> Everyone agreed that the client must=
 receive the session key from the authorization server and that this approa=
ch has to be standardized. It was also agreed that this is a common approac=
h among all three key distribution mechanisms.

>>
>> Hannes asked the participants to think about their pre=
ference.
>>
>> The questions regarding key naming and the=
 indication for the intended resource server the client wants to talk to ha=
ve been postponed.

>>
>> Ciao
>>
 Hannes
>>
>>
>> _______________________________=
________________
>> OAuth mailing list
>> OAuth@ietf.org

>> https://www.ietf.org/mailman/listinfo/oauth> _______________________________________________
> OAuth mailing=
 list

> O=
Auth@ietf.org
> https://www.ietf.org/mailman/list=
info/oauth

_______________________________________________
OAuth mailing li=
st
=
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo=
/oauth

_______________________________________________
OAuth mailing list
OAuth@ie=
tf.org
https://www.ietf.org/mailman/listinfo/oauth

=
_______________________________________________
=
OAuth mailing list
OAuth@ietf.org

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

 =20

<=
br>_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

--14dae9341213e1403c04d5c6294d--

From wmills_92105@yahoo.com  Fri Feb 15 10:29:16 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B9D21F87DF for ; Fri, 15 Feb 2013 10:29:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.273
X-Spam-Level: 
X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=0.325,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWV3WnxwDwvk for ; Fri, 15 Feb 2013 10:29:15 -0800 (PST)
Received: from nm9-vm2.bullet.mail.ne1.yahoo.com (nm9-vm2.bullet.mail.ne1.yahoo.com [98.138.90.157]) by ietfa.amsl.com (Postfix) with ESMTP id EE3D721F8563 for ; Fri, 15 Feb 2013 10:29:14 -0800 (PST)
Received: from [98.138.226.179] by nm9.bullet.mail.ne1.yahoo.com with NNFMP; 15 Feb 2013 18:29:14 -0000
Received: from [98.138.89.198] by tm14.bullet.mail.ne1.yahoo.com with NNFMP; 15 Feb 2013 18:29:14 -0000
Received: from [127.0.0.1] by omp1056.mail.ne1.yahoo.com with NNFMP; 15 Feb 2013 18:29:14 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 449998.9493.bm@omp1056.mail.ne1.yahoo.com
Received: (qmail 69340 invoked by uid 60001); 15 Feb 2013 18:29:13 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360952953; bh=ve54Teb/nSt3o9+Q0MTrgKlLsSmzN9Kl0yrG7tO8liI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=HHFtrbvaq1cbjJfuK4PiFonZ/VKL5l26xs2KMak4yC8ZIAlbqJQ1PqSzQwj0WI8H8RWv4PdV/DcZuKIydk5VtanU3/4okJNzJO/OXAa9BaefwHdTGh5VQpiFeuv4Qa5z0Wqvvdi7FOeM7RMq1S0LKTHsXhJnhIkrXQKF7r3gicQ=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=k8ajYIJIOWLCblcRYgWM8+vQk+iHOO/8asjPYZrc6wTEaTDYYGzw/yVDs9jUJPeYp5BghkRLxCQiiPw4rh4dPj7MXTwcPyL3bMADkgoWgx1DP6hZzDBVKw50fe+Y1qvh4P+N+TM/waYP9vEGvV12bnlVxGcRFE0RkCyJPj5riNY=;
X-YMail-OSG: eu6iupkVM1n1qkj7XDpVRc2CfhLQxSwQrtj4EZguOnJEmhq 5UxdJBX1sGjk7amV5E7kUACTWbuVNciXNVEahH61lMoIzIOaqwHDs43LrsJF 1BmTt9k0XJxZVelefz4dRk5OugTbQjw02nSgifjo3.ITs6s2I7l6KOrm1ucX KGIKJmheK9PyJyEC2WELBukNtxly4GJU.N4TjmUjm1RhaFcOd0TKC7Nd5xFT O9P3WolFKrTuZ4ZU3flaPIXjRuT5uSoMOS59V.ntDK_DnIbEJd9sA41dsaJa D5QUz7u13iqGQXnZ2gVbhW6KFCnTzEv2pAbpmybcoqSbBxaPRpgo3K7i3y3D ZzCsK_SVzdGiHnT_nucn65DH5Jy.YelYH41TlDDSqocAVQFXm6fkGnhTDfz6 JdxwpKe6NPmRPXl2jZHt.fqJCZH9plmjx_H43_08rh.tY4Ooh3u0Gqi_ywOH V9p1BcEvCt73cp1JOBqLeRDB1uhyou72FLDTGNXnP9PkCzhGqW6tIdIneS1i d7qgHkKmVoopnTkkUHZjV17G75LbriGySlJEf2ScjnICQNaqU0iH4DSHBtbR yNyJh_hFx6lfgOm2wADhvkyqn4u_0eq4ev3RS68yMBPgs1IRkEVJC7q5uJav 5K72KN5MF.dO3JFcCTELGAEVEUAitjNYNauyYXutacZo5Puou0diefGPBs9s BVQhMtsx9yPrZydW.1gbVLlXSXYfrgkwtsFmmf3gzXfO6ios-
Received: from [209.131.62.145] by web31804.mail.mud.yahoo.com via HTTP; Fri, 15 Feb 2013 10:29:13 PST
X-Rocket-MIMEInfo: 001.001, QXQgdGhpcyBwb2ludCBJIGFtIG1vcmUgaW4gZmF2b3IgY29udmVydGluZyB0aGUgTUFDIHRva2VuIGZvcm1hdCB0byBKV1QgYW5kIGdldHRpbmcgdGhlIHNpZ25hdHVyZSBlbnZlbG9wZSBhZGRlZCB0aGF0IHdheS4gwqBJdCdzIHJlYWxseSBhIG1hdHRlciBvZiB0aW1lLgoKTUFDIHN0YWxsZWQgYmVjYXVzZSBmb2xrcyBzZWUgdGhlIEhPSyB0b2tlbnMgYXMgYSByZXBsYWNlbWVudC4gwqAKCkl0J3MgYWxzbyBiZWVuIGEgbWF0dGVyIG9mIEp1c3RpbiBhbmQgSSBoYXZpbmcgdGhlIHRpbWUgdG8gdGFrZSBpdCABMAEBAQE-
X-Mailer: YahooMailWebService/0.8.134.513
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net>  <511A7D27.8010209@mitre.org> <4E1F6AAD24975D4BA5B16804296739436744BD23@TK5EX14MBXC285.redmond.corp.microsoft.com> <1360891897.14004.YahooMailNeo@web31811.mail.mud.yahoo.com>  <1360912115.36543.YahooMailNeo@web31811.mail.mud.yahoo.com> <2A0F585F-2CEF-418D-9654-5084E6C9BD0D@lodderstedt.net> <1360944589.51724.YahooMailNeo@web31808.mail.mud.yahoo.com> <511E617A.4000302@gmail.com>
Message-ID: <1360952953.58617.YahooMailNeo@web31804.mail.mud.yahoo.com>
Date: Fri, 15 Feb 2013 10:29:13 -0800 (PST)
From: William Mills 
To: Sergey Beryozkin , "oauth@ietf.org" 
In-Reply-To: <511E617A.4000302@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="835683298-2140817601-1360952953=:58617"
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Feb 2013 18:29:17 -0000

--835683298-2140817601-1360952953=:58617
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

At this point I am more in favor converting the MAC token format to JWT and=
 getting the signature envelope added that way. =A0It's really a matter of =
time.=0A=0AMAC stalled because folks see the HOK tokens as a replacement. =
=A0=0A=0AIt's also been a matter of Justin and I having the time to take it=
 up again.=0A=0A=0A=0A________________________________=0A From: Sergey Bery=
ozkin =0ATo: oauth@ietf.org =0ASent: Friday, February=
 15, 2013 8:25 AM=0ASubject: Re: [OAUTH-WG] Minutes from the OAuth Design T=
eam Conference Call - 11th February 2013=0A =0AI wonder why it is proving s=
o difficult to get a nearly completed MAC =0Adraft completed ?=0AIs it beca=
use:=0A1. JWT was first in OAuth2 and thus it wins ?=0A2. MAC is not 'capab=
le' enough as JWT is ?=0A3. Not enough motivation for some vendors to push =
MAC ?=0A=0AExample, in cases where not a product but a development framewor=
k is =0Ashipped (as with us for example), IMHO is it a big motivation to ge=
t MAC =0Adone for the reasons repeated many times. Or in case of migrating =
Flickr =0Ausers to OAuth2.=0AI think I can see why no interest is there whe=
re nothing is really =0Aachieved if JWT is used from the get go, no particu=
lar need to get OAuth =0A1.0 developers out there migrating to the particul=
ar products.=0A=0AThis is 3. Re 2, I think there was enough expressed to su=
ggest that it =0Acan complement JWT nicely. So far I'm inclined to think it=
 is 3. and 2. =0Awhich stop it from being completed, with 3. 'contributing'=
 indirectly =0Abut significantly,=0A=0AJust my 2c=0AThanks, Sergey=0A=0A=0A=
On 15/02/13 16:09, William Mills wrote:=0A> I'll repeat the use case for Fl=
ickr, which requires OAuth 1.0a type=0A> capabilites that OAuth 2 does not =
provide. Simply stating "move to=0A> HTTPS" is not a viable response here.=
=0A>=0A> ------------------------------------------------------------------=
------=0A> *From:* Torsten Lodderstedt =0A> *To:* =
William Mills =0A> *Cc:* Mike Jones ; Justin Richer=0A> ; Phil Hunt ; IETF oauth WG=0A> =0A> *Sent:* Friday, Februa=
ry 15, 2013 7:22 AM=0A> *Subject:* Re: [OAUTH-WG] Minutes from the OAuth De=
sign Team Conference=0A> Call - 11th February 2013=0A>=0A> Hi Bill,=0A>=0A>=
 I think one needs to compare the costs/impact of HTTPS on one side and=0A>=
 the implementation of integrity protection and replay detection on the=0A>=
 other. We had this discussion several times.=0A>=0A> regards,=0A> Torsten.=
=0A>=0A> Am 15.02.2013 um 08:08 schrieb William Mills  >:=0A>=0A>> I fundamentally disagree =
with that too. OAuth 2 is the *framework*,=0A>> one which supports multiple=
 token types. Bearer tokens were the first=0A>> credential type defined.=0A=
>>=0A>> OAuth 1.0a also requires HTTPS transport for authentication and=0A>=
> getting the token.=0A>>=0A>> There are real use cases for tokens usable o=
ver plain text with=0A>> integrity protection.=0A>>=0A>> -bill=0A>>=0A>> --=
----------------------------------------------------------------------=0A>>=
 *From:* Torsten Lodderstedt > >=0A>> *To:* William Mills > >=0A>> *Cc:* Mike Jones > >; Justin Richer=0A>> >; Phil Hunt=0A>> >; IETF oauth WG=0A>> >=0A>> *Sent:* Thursday, February 14, 2013 10:05 PM=0A>>=
 *Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team=0A>> Conferen=
ce Call - 11th February 2013=0A>>=0A>> Hi Bill,=0A>>=0A>> OAuth 2.0 took a =
different direction by relying on HTTPS to provide=0A>> the basic protectio=
n. So the need to have a token, which can be used=0A>> for service requests=
 over plain HTTP is arguable. My understanding of=0A>> this activity was, t=
he intend is to provide additional protection on=0A>> top of HTTPS.=0A>>=0A=
>> regards,=0A>> Torsten.=0A>>=0A>> Am 15.02.2013 um 02:31 schrieb William =
Mills > >:=0A>>=
=0A>>> I disagree with "That was the impediment to OAuth 1.0 adoption that=
=0A>>> OAuth 2.0 solved in the first place.", unless "solving" means does=
=0A>>> not address the need for it at all.=0A>>>=0A>>> OAuth 2 does several=
 good things, but it still lacks a defined token=0A>>> type that is safe to=
 user over plain text HTTP. 1.0a solved that.=0A>>>=0A>>> -----------------=
-------------------------------------------------------=0A>>> *From:* Mike =
Jones >> >=0A>>> *To:* Justin Richer =
>;=0A>>> Phil Hunt >=0A>=
>> *Cc:* IETF oauth WG >=0A>>> *Sent=
:* Thursday, February 14, 2013 1:44 PM=0A>>> *Subject:* Re: [OAUTH-WG] Minu=
tes from the OAuth Design Team=0A>>> Conference Call - 11th February 2013=
=0A>>>=0A>>> I'm in favor of reusing the JWT work that this WG is also doin=
g. :-)=0A>>>=0A>>> I'm pretty skeptical of us inventing another custom sche=
me for=0A>>> signing HTTP headers. That was the impediment to OAuth 1.0 ado=
ption=0A>>> that OAuth 2.0 solved in the first place.=0A>>>=0A>>> -- Mike=
=0A>>>=0A>>> -----Original Message-----=0A>>> From: oauth-bounces@ietf.org =
=0A>>> [mailto:oauth-bounces@ietf.org ] On=0A>>> Behalf Of Justin Richer=0A>>> Sent: Tue=
sday, February 12, 2013 9:35 AM=0A>>> To: Phil Hunt=0A>>> Cc: IETF oauth WG=
=0A>>> Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conferenc=
e=0A>>> Call - 11th February 2013=0A>>>=0A>>> That's my reading of it as we=
ll, Phil, thanks for providing the=0A>>> clarification. One motivator behin=
d using a JSON-based token is to be=0A>>> able to re-use some of the great =
work that the JOSE group is doing=0A>>> but apply it to an HTTP payload.=0A=
>>>=0A>>> What neither of us want is a token type that requires stuffing al=
l=0A>>> query, header, and other parameters *into* the JSON object itself,=
=0A>>> which would be a more SOAPy approach.=0A>>>=0A>>> -- Justin=0A>>>=0A=
>>> On 02/12/2013 12:30 PM, Phil Hunt wrote:=0A>>> > Clarification. I think=
 Justin and I were in agreement that we don't=0A>>> want to see a format th=
at requires JSON payloads. We are both=0A>>> interested in a JSON token use=
d in the authorization header that=0A>>> could be based on a computed signa=
ture of some combination of http=0A>>> headers and body if possible.=0A>>> =
>=0A>>> > Phil=0A>>> >=0A>>> > @independentid=0A>>> > www.independentid.com=
 =0A>>> > phil.hunt@oracle.com =0A>>> >=0A>>> >=0A>>> >=0A>>> >=0A>>> >=0A>>> > On 2013-02=
-12, at 1:10 AM, Hannes Tschofenig wrote:=0A>>> >=0A>>> >> Here are my note=
s.=0A>>> >>=0A>>> >> Participants:=0A>>> >>=0A>>> >> * John Bradley=0A>>> >=
> * Derek Atkins=0A>>> >> * Phil Hunt=0A>>> >> * Prateek Mishra=0A>>> >> * =
Hannes Tschofenig=0A>>> >> * Mike Jones=0A>>> >> * Antonio Sanso=0A>>> >> *=
 Justin Richer=0A>>> >>=0A>>> >> Notes:=0A>>> >>=0A>>> >> My slides are ava=
ilable here:=0A>>> >> http://www.tschofenig.priv.at/OAuth2-Security-11Feb20=
13.ppt=0A>>> >>=0A>>> >> Slide #2 summarizes earlier discussions during the=
 conference calls.=0A>>> >>=0A>>> >> -- HTTP vs. JSON=0A>>> >>=0A>>> >> Phi=
l noted that he does not like to use the MAC Token draft as a=0A>>> startin=
g point because it does not re-use any of the work done in the=0A>>> JOSE w=
orking group and in particular all the libraries that are=0A>>> available t=
oday. He mentioned that earlier attempts to write the MAC=0A>>> Token code =
lead to problems for implementers.=0A>>> >>=0A>>> >> Justin responded that =
he does not agree with using JSON as a=0A>>> transport mechanism since this=
 would replicate a SOAP style.=0A>>> >>=0A>>> >> Phil noted that he wants t=
o send JSON but the signature shall be=0A>>> computed over the HTTP header =
field.=0A>>> >>=0A>>> >> -- Flexibility for the keyed message digest comput=
ation=0A>>> >>=0A>>> >> From earlier discussion it was clear that the confe=
rence call=0A>>> participants wanted more flexibility regarding the keyed m=
essage=0A>>> digest computation. For this purpose Hannes presented the DKIM=
 based=0A>>> approach, which allows selective header fields to be included =
in the=0A>>> digest. This is shown in slide #4.=0A>>> >>=0A>>> >> After som=
e discussion the conference call participants thought=0A>>> that this would=
 meet their needs. Further investigations would still=0A>>> be useful to de=
termine the degree of failed HMAC calculations due to=0A>>> HTTP proxies mo=
difying the content.=0A>>> >>=0A>>> >> -- Key Distribution=0A>>> >>=0A>>> >=
> Hannes presented the open issue regarding the choice of key=0A>>> >> dist=
ribution. Slides #6-#8 present three techniques and Hannes asked=0A>>> >> f=
or feedback regarding the preferred style. Justin and others didn't=0A>>> >=
> see the need to decide on one mechanism - they wanted to keep the=0A>>> >=
> choice open. Derek indicated that this will not be an acceptable=0A>>> >>=
 approach. Since the resource server and the authorization server may,=0A>>=
> >> in the OAuth 2.0 framework, be entities produced by different vendors=
=0A>>> >> there is an interoperability need. Justin responded that he disag=
rees=0A>>> >> and that the resource server needs to understand the access t=
oken and=0A>>> >> referred to the recent draft submission for the token int=
rospection=0A>>> >> endpoint. Derek indicated that the resource server has =
to understand=0A>>> >> the content of the access token and the token intros=
pection endpoint=0A>>> >> just pushes the problem around: the resource serv=
er has to send the=0A>>> >> access token to the authorization server and th=
en the resource server=0A>>> >> gets the result back (which he the=0A>>> n=
=0A>>> > a=0A>>> >> gain needs to understand) in order to make a meaningful=
=0A>>> authorization decision.=0A>>> >>=0A>>> >> Everyone agreed that the c=
lient must receive the session key from=0A>>> the authorization server and =
that this approach has to be=0A>>> standardized. It was also agreed that th=
is is a common approach among=0A>>> all three key distribution mechanisms.=
=0A>>> >>=0A>>> >> Hannes asked the participants to think about their prefe=
rence.=0A>>> >>=0A>>> >> The questions regarding key naming and the indicat=
ion for the=0A>>> intended resource server the client wants to talk to have=
 been postponed.=0A>>> >>=0A>>> >> Ciao=0A>>> >> Hannes=0A>>> >>=0A>>> >>=
=0A>>> >> _______________________________________________=0A>>> >> OAuth ma=
iling list=0A>>> >> OAuth@ietf.org =0A>>> >> https:/=
/www.ietf.org/mailman/listinfo/oauth=0A>>> > ______________________________=
_________________=0A>>> > OAuth mailing list=0A>>> > OAuth@ietf.org =0A>>> > https://www.ietf.org/mailman/listinfo/oauth=0A>>>=
=0A>>>=0A>>> _______________________________________________=0A>>> OAuth ma=
iling list=0A>>> OAuth@ietf.org =0A>>> https://www.i=
etf.org/mailman/listinfo/oauth=0A>>> ______________________________________=
_________=0A>>> OAuth mailing list=0A>>> OAuth@ietf.org =0A>>> https://www.ietf.org/mailman/listinfo/oauth=0A>>>=0A>>>=0A>>> __=
_____________________________________________=0A>>> OAuth mailing list=0A>>=
> OAuth@ietf.org =0A>>> https://www.ietf.org/mailman=
/listinfo/oauth=0A>>=0A>>=0A>=0A>=0A>=0A>=0A> _____________________________=
__________________=0A> OAuth mailing list=0A> OAuth@ietf.org=0A> https://ww=
w.ietf.org/mailman/listinfo/oauth=0A_______________________________________=
________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailm=
an/listinfo/oauth
--835683298-2140817601-1360952953=:58617
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

At this point I am more in favor converting the MAC token format to JWT a=
nd getting the signature envelope added that way.  It's really a matte=
r of time.

MAC stalled because folks see the HOK tokens as a repl=
acement.  

It's also been=
 a matter of Justin and I having the time to take it up again.=

  From:=
 Sergey Beryozkin <sberyozkin@gmail.com>
 To: oauth@ietf.org 
 Sent: Friday, February 15, 2013 8:25 AM
 Subject: Re: [OAUTH-WG] Minutes from t=
he OAuth Design Team Conference Call - 11th February 2013

=0AI wonder why it is proving so difficult to get a nearly completed =
MAC 
draft completed ?
Is it because:
1. JWT was first in OAuth2 a=
nd thus it wins ?
2. MAC is not 'capable' enough as JWT is ?
3. Not e=
nough motivation for some vendors to push MAC ?

Example, in cases wh=
ere not a product but a development framework is 
shipped (as with us fo=
r example), IMHO is it a big motivation to get MAC 
done for the reasons=
 repeated many times. Or in case of migrating Flickr 
users to OAuth2.I think I can see why no interest is there where nothing is really 
ac=
hieved if JWT is used from the get go, no particular need to get OAuth 
=
1.0 developers out there migrating to the particular products.

This =
is 3. Re 2, I think there was enough expressed to suggest that it 
can c=
omplement JWT nicely. So far I'm inclined to think it is 3. and 2. 
whic=
h stop it from being completed, with 3. 'contributing' indirectly 
but
 significantly,

Just my 2c
Thanks, Sergey

On 15/02/13 =
16:09, William Mills wrote:
> I'll repeat the use case for Flickr, wh=
ich requires OAuth 1.0a type
> capabilites that OAuth 2 does not prov=
ide. Simply stating "move to
> HTTPS" is not a viable response here.<=
br>>
> -----------------------------------------------------------=
-------------
> *From:* Torsten Lodderstedt <torsten@lo=
dderstedt.net>
> *To:* William Mills <wmills_92105=
@yahoo.com>
> *Cc:* Mike Jones <Michael.=
Jones@microsoft.com>; Justin Richer
> <jricher@mitre.org=
>;
 Phil Hunt <phil.hunt@oracle.com>; IETF oauth WG
> <=
;oauth@=
ietf.org>
> *Sent:* Friday, February 15, 2013 7:22 AM
> =
*Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference
=
> Call - 11th February 2013
>
> Hi Bill,
>
> I t=
hink one needs to compare the costs/impact of HTTPS on one side and
>=
 the implementation of integrity protection and replay detection on the
=
> other. We had this discussion several times.
>
> regards,<=
br>> Torsten.
>
> Am 15.02.2013 um 08:08 schrieb William Mil=
ls <wmills_92105@yahoo.com
> <mailto:wmills_92105@yahoo.com>>:=

>
>> I fundamentally disagree with that too. OAuth 2 is the=
 *framework*,
>> one which supports multiple token types. Bearer t=
okens were the first
>> credential type defined.
>>
&g=
t;> OAuth 1.0a also requires HTTPS transport for authentication and
&=
gt;> getting the token.
>>
>> There are real use cases=
 for tokens usable over plain text with
>> integrity protection.>>
>> -bill
>>
>> ----------------------=
--------------------------------------------------
>> *From:* Tors=
ten Lodderstedt <torsten@lodderstedt.net
>> <=
mailto:torsten@lodderstedt.net>>
>> *To:*
 William Mills <wmills_92105@yahoo.com
>> <mail=
to:wmills_92105@yahoo.com>>
>> *Cc:* Mike Jones=
 <Michael.Jones@microsoft.com
>> <mai=
lto:Michael.Jones@microsoft.com>>; Justin Rich=
er
>> <jricher@mitre.org <mailto:jricher@mitre.org>=
>; Phil Hunt
>> <phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>>; IETF oauth WG
>> <oauth@ietf.org<=
/a> <mailto:oauth@ietf.org>>
>> *Sent:* Thursday, February 1=
4, 2013 10:05 PM
>> *Subject:* Re: [OAUTH-WG] Minutes from the OAu=
th Design Team
>> Conference Call - 11th February 2013
>>=

>> Hi Bill,
>>
>> OAuth 2.0 took a different di=
rection by relying on HTTPS to provide
>> the basic protection. So=
 the need to have a token, which can be used
>> for service reques=
ts over plain HTTP is arguable. My understanding of
>> this activi=
ty was, the intend is to provide additional protection on
>> top o=
f HTTPS.
>>
>> regards,
>>
 Torsten.
>>
>> Am 15.02.2013 um 02:31 schrieb William Mi=
lls <wmills_92105@yahoo.com
>> <mailto:wmills_92105@yahoo.com>>:
>>
>>> I disagree=
 with "That was the impediment to OAuth 1.0 adoption that
>>> O=
Auth 2.0 solved in the first place.", unless "solving" means does
>&g=
t;> not address the need for it at all.
>>>
>>> =
OAuth 2 does several good things, but it still lacks a defined token
>=
;>> type that is safe to user over plain text HTTP. 1.0a solved that.=

>>>
>>> ------------------------------------------=
------------------------------
>>> *From:* Mike Jones <Michael.Jones@microsoft.com
>>> <mailto:Michael.Jones@microsoft.com=
>>
>>> *To:* Justin Richer <jricher@mitre.org &=
lt;mailto:jricher@mitre.org>>;
>>> Phil Hunt <=
phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>>>>> *Cc:* IETF oauth WG <oauth@ietf.org <mailto:oauth@ietf.org&g=
t;>
>>>
 *Sent:* Thursday, February 14, 2013 1:44 PM
>>> *Subject:* Re:=
 [OAUTH-WG] Minutes from the OAuth Design Team
>>> Conference C=
all - 11th February 2013
>>>
>>> I'm in favor of re=
using the JWT work that this WG is also doing. :-)
>>>
>&=
gt;> I'm pretty skeptical of us inventing another custom scheme for
&=
gt;>> signing HTTP headers. That was the impediment to OAuth 1.0 adop=
tion
>>> that OAuth 2.0 solved in the first place.
>>&=
gt;
>>> -- Mike
>>>
>>> -----Original M=
essage-----
>>> From: oauth-bounces@ietf.org <m=
ailto:oauth-bounces@ietf.org>
>>> [mailto:oauth-bounces@ietf.org <mail=
to:oauth-bounces@ietf.org>] On
>>> Behalf Of Ju=
stin Richer
>>> Sent: Tuesday, February 12, 2013 9:35 AM
>=
;>> To: Phil Hunt
>>> Cc: IETF oauth WG
>>> S=
ubject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference
>=
;>> Call - 11th February 2013
>>>
>>> That's =
my reading of it as well, Phil, thanks for providing the
>>> cl=
arification. One motivator behind using a JSON-based token is to be
>=
>> able to re-use some of the great work that the JOSE group is doing=

>>> but apply it to an HTTP payload.
>>>
>&g=
t;> What neither of us want is a token type that requires stuffing all>>> query, header, and other parameters *into* the JSON object
 itself,
>>> which would be a more SOAPy approach.
>>&=
gt;
>>> -- Justin
>>>
>>> On 02/12/2013=
 12:30 PM, Phil Hunt wrote:
>>> > Clarification. I think Jus=
tin and I were in agreement that we don't
>>> want to see a for=
mat that requires JSON payloads. We are both
>>> interested in =
a JSON token used in the authorization header that
>>> could be=
 based on a computed signature of some combination of http
>>> =
headers and body if possible.
>>> >
>>> > Phi=
l
>>> >
>>> > @independentid
>>> =
> www.independentid.com <http://www.independentid.com/>
>>> > =
phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
>>> >
>>> >>>> >
>>> >
>>> >
>>&g=
t; > On 2013-02-12, at 1:10 AM, Hannes Tschofenig wrote:
>>>=
 >
>>> >> Here are my notes.
>>> >><=
br>>>> >> Participants:
>>> >>
>>=
> >> * John Bradley
>>> >> * Derek Atkins
>=
;>> >> * Phil Hunt
>>> >> * Prateek Mishra>>> >> * Hannes Tschofenig
>>> >> * Mike =
Jones
>>> >> * Antonio Sanso
>>> >> * J=
ustin Richer
>>> >>
>>> >> Notes:
&g=
t;>> >>
>>> >> My slides are available here:<=
br>>>> >> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
>>> >>
>>> >> Slide #2 summarizes ear=
lier discussions during the conference calls.
>>> >>
&=
gt;>> >> -- HTTP vs. JSON
>>> >>
>>&=
gt; >> Phil noted that he does not like to use the MAC Token draft as=
 a
>>> starting point because it does not re-use any of the wor=
k done in the
>>> JOSE working group and in particular all the =
libraries that are
>>> available today. He mentioned that earli=
er attempts to write the MAC
>>> Token code lead to problems fo=
r implementers.
>>> >>
>>> >> Justin re=
sponded that he does not agree with using JSON as a
>>> transpo=
rt mechanism since this would replicate a SOAP style.
>>>
 >>
>>> >> Phil noted that he wants to send JSON bu=
t the signature shall be
>>> computed over the HTTP header fiel=
d.
>>> >>
>>> >> -- Flexibility for the=
 keyed message digest computation
>>> >>
>>> =
>> From earlier discussion it was clear that the conference call
&=
gt;>> participants wanted more flexibility regarding the keyed messag=
e
>>> digest computation. For this purpose Hannes presented the=
 DKIM based
>>> approach, which allows selective header fields =
to be included in the
>>> digest. This is shown in slide #4.>>> >>
>>> >> After some discussion the c=
onference call participants thought
>>> that this would meet th=
eir needs. Further investigations would still
>>> be useful to =
determine the degree of failed HMAC calculations due
 to
>>> HTTP proxies modifying the content.
>>> >=
;>
>>> >> -- Key Distribution
>>> >>=

>>> >> Hannes presented the open issue regarding the cho=
ice of key
>>> >> distribution. Slides #6-#8 present thre=
e techniques and Hannes asked
>>> >> for feedback regardi=
ng the preferred style. Justin and others didn't
>>> >> s=
ee the need to decide on one mechanism - they wanted to keep the
>>=
;> >> choice open. Derek indicated that this will not be an accept=
able
>>> >> approach. Since the resource server and the a=
uthorization server may,
>>> >> in the OAuth 2.0 framewor=
k, be entities produced by different vendors
>>> >> there=
 is an interoperability need. Justin responded that he disagrees
>>=
;> >> and that the resource server needs to understand the
 access token and
>>> >> referred to the recent draft sub=
mission for the token introspection
>>> >> endpoint. Dere=
k indicated that the resource server has to understand
>>> >=
> the content of the access token and the token introspection endpoint>>> >> just pushes the problem around: the resource server=
 has to send the
>>> >> access token to the authorization=
 server and then the resource server
>>> >> gets the resu=
lt back (which he the
>>> n
>>> > a
>>&=
gt; >> gain needs to understand) in order to make a meaningful
>=
;>> authorization decision.
>>> >>
>>> =
>> Everyone agreed that the client must receive the session key from<=
br>>>> the authorization server and that this approach has to be>>> standardized. It was also agreed that this is a
 common approach among
>>> all three key distribution mechanism=
s.
>>> >>
>>> >> Hannes asked the parti=
cipants to think about their preference.
>>> >>
>&g=
t;> >> The questions regarding key naming and the indication for t=
he
>>> intended resource server the client wants to talk to hav=
e been postponed.
>>> >>
>>> >> Ciao>>> >> Hannes
>>> >>
>>> >=
>
>>> >> _____________________________________________=
__
>>> >> OAuth mailing list
>>> >> OAuth@ietf=
.org <mailto:OAuth@ietf.org>
>>> >> https://www.ietf.org/mailman/listinfo/oauth
>&=
gt;> > _______________________________________________
>>>=
; > OAuth mailing list
>>> > OAuth@ietf.org <mailto:OAuth@ietf.o=
rg>
>>> > https://www.ietf.org/mailman/listinfo/oauth<=
/a>
>>>
>>>
>>> _______________________=
________________________
>>> OAuth mailing list
>>>=
 OAuth@=
ietf.org <mailto:OAuth@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/oauth
>&=
gt;> _______________________________________________
>>> OAu=
th mailing list
>>> OAuth@ietf.org <mailto:OAuth@ietf.org>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=
;
>>>
>>> _________________________________________=
______
>>> OAuth mailing list
>>> OAuth@ietf.org <m=
ailto:O=
Auth@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/oauth
>&=
gt;
>>
>
>
>
>
> ___________________=
____________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
_______________=
________________________________
OAuth mailing list
OAuth@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/oauth

--835683298-2140817601-1360952953=:58617--

From wmills_92105@yahoo.com  Fri Feb 15 12:50:45 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7134521F8614 for ; Fri, 15 Feb 2013 12:50:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.294
X-Spam-Level: 
X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=0.304,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOwsKXH7sYaW for ; Fri, 15 Feb 2013 12:50:43 -0800 (PST)
Received: from nm14-vm0.bullet.mail.bf1.yahoo.com (nm14-vm0.bullet.mail.bf1.yahoo.com [98.139.213.164]) by ietfa.amsl.com (Postfix) with SMTP id 6776221F85ED for ; Fri, 15 Feb 2013 12:50:43 -0800 (PST)
Received: from [98.139.215.142] by nm14.bullet.mail.bf1.yahoo.com with NNFMP; 15 Feb 2013 20:50:36 -0000
Received: from [98.139.212.205] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 15 Feb 2013 20:50:36 -0000
Received: from [127.0.0.1] by omp1014.mail.bf1.yahoo.com with NNFMP; 15 Feb 2013 20:50:36 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 425468.79360.bm@omp1014.mail.bf1.yahoo.com
Received: (qmail 44837 invoked by uid 60001); 15 Feb 2013 20:50:36 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360961435; bh=WEixqA4rerZbydylAyW56DOw3FOvgO+Ug6fFyDRcwo8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=lLeRONyKGvtrHnqsfgUiFZt4yDSyjLwiGeGaKxwSWmyjCEMwi6o9Fkr4OsU/CXTkFHakGpaBzRaj9vsoiJl4c/+6eFs3H3J1sja5iP//0JEE8TvA3sy0+h5U+LzKQvL11vg2uW8mH8357FSC7IK13x3rLHOBmZ4PplKOIk9ip5I=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=PR+Tyy2RZsOtQ4WeNKBB3VROzKRfM782e6hY7JYxW2wuw7SsqE7h6Bc4Kv+Ap9XKLfTXoTsPlbBekJl0gfomU0/I42WZD8uFoa8/o+C7+zn6AmKqSchINRp+ZsZpqggbh74BL749QII1wDkrd5C8VWxKtOGhqzE6ygSSuM3ywE0=;
X-YMail-OSG: rDOAlNYVM1mkT_ETVaQcWjaqHLO4xnpbu6lr6.2XDVZjFZj AM5eZWhJ97OlI.fpEwoZXSudOrBBZJin21seBLYnFSYjM08VW62j3mc7PKqy VcdvOC1lQnJGinxU9aDoUrd9nwrIcpjsMl_qLywXdpO88KZuf_rNbUIU0c07 kyxHv89fJueWU82yHhEkq4ZYtMxH4a3gD1RSvN.iXiDfiyrUIjDZA9nSJ4WF 0Mak3OMQpNikpSwBrfiYHrBM7wZSH4usgxZNu04ugOYtwqTJ5YGEhfb.hOZn IU.pMk0xe7pl5bk.bflwhlkuw5jpGrEEjNRNClXJeRlBVdVAloaCKuPtzQto P_b2zbYvf68FZ_C_bimoEIKOCCNpyavsrVdCF.9nRHpJ04cb8XklpPkSSaF8 uXH0l6pf3W7_0iHuzLh8qG09z5BHtBspG_sY_.waFlycPk9TXaguVMNyZb0N ndgzgv6oRYCAuCtrbxRTbhFreaAV_HMHfw97a7n2TqNsfzvlmBYcXl9.TUt. 8lboRqYbjv6jYNGQaFXMWNB9xaAKgNVSHiQ7FqpQsa2OCFtpB.i33alnT39M Sj_2UDYy_.oYCEHIRW4CdYSCtxLz6kKwZIDuPMwJedxmNd_xodgJ3JR._5a0 ZXcu7pgj6JhXV6ToQymF3IHdHo4WssRJhhRD4mNH4_T__CZkRGkx8A0gxDiw o2ZOWZuob.9T6gpmJNDZpCOo0ClFWwYViHBI2DoKhQ2.p.hvlNg--
Received: from [209.131.62.145] by web31801.mail.mud.yahoo.com via HTTP; Fri, 15 Feb 2013 12:50:34 PST
X-Rocket-MIMEInfo: 001.001, QmVjYXVzZSB3ZSdyZSBnb2lnbiB0byB3YW50IGEgc2luZ2xlIGltcGxlbWVudGF0aW9uLCBub3QgTi4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRnJvbTogVGltIEJyYXkgPHR3YnJheUBnb29nbGUuY29tPgpUbzogV2lsbGlhbSBNaWxscyA8d21pbGxzXzkyMTA1QHlhaG9vLmNvbT4gCkNjOiBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD47IElFVEYgb2F1dGggV0cgPG9hdXRoQGlldGYub3JnPiAKU2VudDogRnJpZGF5LCBGZWJydWFyeSAxNSwgMjAxMyABMAEBAQE-
X-Mailer: YahooMailWebService/0.8.134.513
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net>  <511A7D27.8010209@mitre.org> <4E1F6AAD24975D4BA5B16804296739436744BD23@TK5EX14MBXC285.redmond.corp.microsoft.com> <1360891897.14004.YahooMailNeo@web31811.mail.mud.yahoo.com>  <1360912115.36543.YahooMailNeo@web31811.mail.mud.yahoo.com> <2A0F585F-2CEF-418D-9654-5084E6C9BD0D@lodderstedt.net> <1360944589.51724.YahooMailNeo@web31808.mail.mud.yahoo.com> 
Message-ID: <1360961434.42688.YahooMailNeo@web31801.mail.mud.yahoo.com>
Date: Fri, 15 Feb 2013 12:50:34 -0800 (PST)
From: William Mills 
To: Tim Bray 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-368338466-484310537-1360961434=:42688"
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Feb 2013 20:50:45 -0000

---368338466-484310537-1360961434=:42688
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Because we're goign to want a single implementation, not N.=0A=0A=0A_______=
_________________________=0A From: Tim Bray =0ATo: Willi=
am Mills  =0ACc: Torsten Lodderstedt ; IETF oauth WG  =0ASent: Friday, February 15, 2=
013 8:49 AM=0ASubject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Co=
nference Call - 11th February 2013=0A =0A=0ANot deeply acquainted with the =
Flickr scenario, but it occurs to me to ask: If OAuth 1.0 is working well f=
or them, why don=E2=80=99t they just keep using it? =C2=A0I.e. if there=E2=
=80=99s already a good solution in place for people who require secure auth=
n/authz over insecure channels, why would we go the extra work of duplicati=
ng that in OAuth 2 territory? -T=0A=0A=0AOn Fri, Feb 15, 2013 at 8:09 AM, W=
illiam Mills  wrote:=0A=0AI'll repeat the use case =
for Flickr, which requires OAuth 1.0a type capabilites that OAuth 2 does no=
t provide. =C2=A0Simply stating "move to HTTPS" is not a viable response he=
re. =C2=A0=0A>=0A>=0A>=0A>________________________________=0A> From: Torste=
n Lodderstedt =0A>To: William Mills  =0A>Cc: Mike Jones ; Justin Richer =
; Phil Hunt ; IETF oauth WG  =0A>Sent: Friday, February 15, 2013 7:22 AM=0A>Subject: Re: [OAU=
TH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2=
013=0A> =0A>=0A>Hi Bill,=0A>=0A>=0A>I think one needs to compare the costs/=
impact of HTTPS on one side and the implementation of integrity protection =
and replay detection on the other. We had this discussion several times.=0A=
>=0A>=0A>regards,=0A>Torsten.=0A>=0A>Am 15.02.2013 um 08:08 schrieb William=
 Mills :=0A>=0A>=0A>I fundamentally disagree with t=
hat too. =C2=A0OAuth 2 is the *framework*, one which supports multiple toke=
n types. =C2=A0Bearer tokens were the first credential type defined.=0A>>=
=0A>>=0A>>OAuth 1.0a also requires HTTPS transport for authentication and g=
etting the token.=0A>>=0A>>=0A>>There are =C2=A0real use cases for tokens u=
sable over plain text with integrity protection.=0A>>=0A>>=0A>>-bill=0A>>=
=0A>>=0A>>=0A>>________________________________=0A>> From: Torsten Lodderst=
edt =0A>>To: William Mills  =0A>>Cc: Mike Jones ; Justin Richer ; Phil Hunt ; IETF oauth WG  =0A>>Sent: Thursday, February 14, 2013 10:05 PM=0A>>Subject: Re: [OAUTH-=
WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013=
=0A>> =0A>>=0A>>Hi Bill,=0A>>=0A>>=0A>>OAuth 2.0 took a different direction=
 by relying on HTTPS to provide the basic protection. So the need to have a=
 token, which can be used for service requests over plain HTTP is arguable.=
 My understanding of this activity was, the intend is to provide additional=
 protection on top of HTTPS.=0A>>=0A>>=0A>>regards,=0A>>Torsten.=0A>>=0A>>A=
m 15.02.2013 um 02:31 schrieb William Mills :=0A>>=
=0A>>=0A>>I disagree with "That was the impediment to OAuth 1.0 adoption th=
at OAuth 2.0 solved in the first place.", unless "solving" means does not a=
ddress the need for it at all.=0A>>>=0A>>>=0A>>>OAuth 2 does several good t=
hings, but it still lacks a defined token type that is safe to user over pl=
ain text HTTP. =C2=A01.0a solved that.=0A>>>=0A>>>=0A>>>=0A>>>_____________=
___________________=0A>>> From: Mike Jones =0A=
>>>To: Justin Richer ; Phil Hunt  =
=0A>>>Cc: IETF oauth WG  =0A>>>Sent: Thursday, February 14,=
 2013 1:44 PM=0A>>>Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Te=
am Conference Call - 11th February 2013=0A>>> =0A>>>I'm in favor of reusing=
 the JWT work that this WG is also doing. :-)=0A>>>=0A>>>I'm pretty skeptic=
al of us inventing another custom scheme for signing HTTP headers.=C2=A0 Th=
at was the impediment to OAuth 1.0 adoption that OAuth 2.0 solved in the fi=
rst place.=0A>>>=0A>>>=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=
=A0 =C2=A0=C2=A0=C2=A0 -- Mike=0A>>>=0A>>>-----Original Message-----=0A>>>F=
rom: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Ju=
stin Richer=0A>>>Sent: Tuesday, February 12, 2013 9:35 AM=0A>>>To: Phil Hun=
t=0A>>>Cc: IETF oauth WG=0A>>>Subject: Re: [OAUTH-WG] Minutes from the OAut=
h Design Team Conference Call - 11th February 2013=0A>>>=0A>>>That's my rea=
ding of it as well, Phil, thanks for providing the clarification.=0A One mo=
tivator behind using a JSON-based token is to be able to=0A re-use some of =
the great work that the JOSE group is doing but apply it to an HTTP payload=
.=0A>>>=0A>>>What neither of us want is a token type that requires stuffing=
 all query, header, and other parameters *into* the JSON object itself, whi=
ch would be a more SOAPy approach.=0A>>>=0A>>>=C2=A0 -- Justin=0A>>>=0A>>>O=
n 02/12/2013 12:30 PM, Phil Hunt wrote:=0A>>>> Clarification.=C2=A0 I think=
 Justin and I were in agreement that we don't want to see a format that req=
uires JSON payloads.=C2=A0 We are both interested in a JSON token used in t=
he authorization header that could be based on a computed signature of some=
 combination of http headers and body if possible.=0A>>>>=0A>>>> Phil=0A>>>=
>=0A>>>> @independentid=0A>>>> www.independentid.com=0A>>>> phil.hunt@oracl=
e.com=0A>>>>=0A>>>>=0A>>>>=0A>>>>=0A>>>>=0A>>>> On=0A 2013-02-12, at 1:10 A=
M, Hannes Tschofenig wrote:=0A>>>>=0A>>>>> Here are my notes.=0A>>>>>=0A>>>=
>> Participants:=0A>>>>>=0A>>>>> * John Bradley=0A>>>>> * Derek Atkins=0A>>=
>>> * Phil Hunt=0A>>>>> * Prateek Mishra=0A>>>>> * Hannes Tschofenig=0A>>>>=
> * Mike Jones=0A>>>>> * Antonio Sanso=0A>>>>> * Justin Richer=0A>>>>>=0A>>=
>>> Notes:=0A>>>>>=0A>>>>> My slides are available here: =0A>>>>> http://ww=
w.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt=0A>>>>>=0A>>>>> Slide #2=
 summarizes earlier discussions during the conference calls.=0A>>>>>=0A>>>>=
> -- HTTP vs. JSON=0A>>>>>=0A>>>>> Phil noted that he does not like to use =
the MAC Token draft as a starting point because it does not re-use any of t=
he work done in the JOSE working group and in particular all the libraries =
that are available today. He mentioned that earlier attempts to write the M=
AC Token code lead to=0A problems for implementers.=0A>>>>>=0A>>>>> Justin =
responded that he does not agree with using JSON as a transport mechanism s=
ince this would replicate a SOAP style.=0A>>>>>=0A>>>>> Phil noted that he =
wants to send JSON but the signature shall be computed over the HTTP header=
 field.=0A>>>>>=0A>>>>> -- Flexibility for the keyed message digest computa=
tion=0A>>>>>=0A>>>>>=C2=A0 From earlier discussion it was clear that the co=
nference call participants wanted more flexibility regarding the keyed mess=
age digest computation. For this purpose Hannes presented the DKIM based ap=
proach, which allows selective header fields to be included in the digest. =
This is shown in slide #4.=0A>>>>>=0A>>>>> After some discussion the confer=
ence call participants thought that this would meet their needs. Further in=
vestigations would still be useful to determine the degree of failed HMAC c=
alculations due to HTTP proxies modifying the=0A content.=0A>>>>>=0A>>>>> -=
- Key Distribution=0A>>>>>=0A>>>>> Hannes presented the open issue regardin=
g the choice of key =0A>>>>> distribution. Slides #6-#8 present three techn=
iques and Hannes asked =0A>>>>> for feedback regarding the preferred style.=
 Justin and others didn't =0A>>>>> see the need to decide on one mechanism =
- they wanted to keep the =0A>>>>> choice open. Derek indicated that this w=
ill not be an acceptable =0A>>>>> approach. Since the resource server and t=
he authorization server may, =0A>>>>> in the OAuth 2.0 framework, be entiti=
es produced by different vendors =0A>>>>> there is an interoperability need=
. Justin responded that he disagrees =0A>>>>> and that the resource server =
needs to understand the access token and =0A>>>>> referred to the recent dr=
aft submission for the token introspection =0A>>>>> endpoint. Derek indicat=
ed that the resource server has to understand =0A>>>>>=0A the content of th=
e access token and the token introspection endpoint =0A>>>>> just pushes th=
e problem around: the resource server has to send the =0A>>>>> access token=
 to the authorization server and then the resource server =0A>>>>> gets the=
 result back (which he the=0A>>>n=0A>>>>=C2=A0 =C2=A0 a=0A>>>>> gain needs =
to understand) in order to make a meaningful authorization decision.=0A>>>>=
>=0A>>>>> Everyone agreed that the client must receive the session key from=
 the authorization server and that this approach has to be standardized. It=
 was also agreed that this is a common approach among all three key distrib=
ution mechanisms.=0A>>>>>=0A>>>>> Hannes asked the participants to think ab=
out their preference.=0A>>>>>=0A>>>>> The questions regarding key naming an=
d the indication for the intended resource server the client wants to talk =
to have been postponed.=0A>>>>>=0A>>>>> Ciao=0A>>>>>=0A Hannes=0A>>>>>=0A>>=
>>>=0A>>>>> _______________________________________________=0A>>>>> OAuth m=
ailing list=0A>>>>> OAuth@ietf.org=0A>>>>> https://www.ietf.org/mailman/lis=
tinfo/oauth=0A>>>> _______________________________________________=0A>>>> O=
Auth mailing list=0A>>>> OAuth@ietf.org=0A>>>> https://www.ietf.org/mailman=
/listinfo/oauth=0A>>>=0A>>>=0A>>>__________________________________________=
_____=0A>>>OAuth mailing list=0A>>>OAuth@ietf.org=0A>>>https://www.ietf.org=
/mailman/listinfo/oauth=0A>>>______________________________________________=
_=0A>>>OAuth mailing list=0A>>>OAuth@ietf.org=0A>>>https://www.ietf.org/mai=
lman/listinfo/oauth=0A>>>=0A>>>=0A>>>=0A>>_________________________________=
______________=0A>>>OAuth mailing list=0A>>>OAuth@ietf.org=0A>>>https://www=
.ietf.org/mailman/listinfo/oauth=0A>>>=0A>>=0A>>=0A>=0A>=0A>_______________=
________________________________=0A>OAuth mailing list=0A>OAuth@ietf.org=0A=
>https://www.ietf.org/mailman/listinfo/oauth=0A>=0A>
---368338466-484310537-1360961434=:42688
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Because we're goign to want a single implementation, not N.<=
div>
    =

  From: Tim Bray <twbray@google.com>
 To: William Mills <wmills_921=
05@yahoo.com> 
Cc: T=
orsten Lodderstedt <torsten@lodderstedt.net>; IETF oauth WG <oauth=
@ietf.org> 
 Sent: F=
riday, February 15, 2013 8:49 AM
 Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Te=
am Conference Call - 11th February 2013

=0ANot deeply acquainted with the Flickr scenario, but it o=
ccurs to me to ask: If OAuth 1.0 is working well for them, why don=E2=80=99=
t they just keep using it?  I.e. if there=E2=80=99s already a good sol=
ution in place for people who require secure authn/authz over insecure chan=
nels, why would we go the extra work of duplicating that in OAuth 2 territo=
ry? -T
=0A=0A
On Fri, Feb 15,=
 2013 at 8:09 AM, William Mills <wmills_92105@yahoo.com> wrote:
=0A=0A
=0A=0A
    =0A=0A  
  From: Torsten Lodderstedt <torsten@lodderstedt.net>
 =
To: William Mills <wmills_92105@yahoo.com> 
=
=0A=0ACc: Mike Jones <Michael.Jones@microsoft=
.com>; Justin Richer <jricher@m=
itre.org>; Phil=0A Hunt <=
phil.hunt@oracle.com>; IETF oauth WG <oauth@ietf.org> 
 Sent: Friday, February 15, 2013 7:22 AM
=0A=0A Subject: Re: [OAUTH-WG] Minutes from the OAuth Des=
ign Team Conference Call - 11th February 2013

=0AHi Bill,

I think one needs to compare =
the costs/impact of HTTPS on one side and the implementation of integrity p=
rotection and replay detection on the other. We had this discussion several=
 times.
=0A=0A
regards,
Torsten.

Am 15.02.2013 um 08:08 schrieb William Mills <wmills_92105@yahoo.com>:

=0A=0A=
I =
fundamentally disagree with that too.  OAuth 2 is the *framework*, one=
 which supports multiple token types.  Bearer tokens were the first cr=
edential type defined.
=0A=0A
=0A=
=0AOAuth 1.0a also requires HTTPS transport for authentication and ge=
tting the token.
=0A=0A
There=
 are  real use cases for tokens usable over plain text with integrity =
protection.
=0A=0A
=0A=0A-bil=
l

   =0A=0A   
 =0A From: Torsten =
Lodderstedt <torsten@lodde=
rstedt.net>
 To: =
William Mills <wmills_92105@=
yahoo.com> 
=0A=0ACc:=
 Mike Jones <M=
ichael.Jones@microsoft.com>; Justin Richer <jricher@mitre.org>; Phil Hunt <phil.hunt@oracle.com>; IETF=0A oauth WG <oauth@ietf.org> 
 Sent: Thursday, February 14, 2013 10:05 PM
 <=
span style=3D"font-weight:bold;">Subject: Re: [OAUTH-WG] Minutes=
 from the OAuth Design Team Conference Call - 11th February 2013
=0A=0A =

=0AHi Bill,

OAut=
h 2.0 took a different direction by relying on HTTPS to provide the basic p=
rotection. So the need to have a token, which can be used for service reque=
sts over plain HTTP is arguable. My understanding of this activity was, the=
 intend is to provide additional protection on top of HTTPS.
=0A=0A
regards,
Torsten.

Am 15.02.2013 um=
 02:31 schrieb William Mills <wmills_92105@yahoo.com>:

=0A=0A
I disagree with "=
That was the impediment to=0A OAuth 1.0 ado=
ption that OAuth 2.0 solved in the first place.", unless "solving" means do=
es not address the need for it at all.
=0A=0A
=0A=0A=
OAuth 2 does several=0A good things, but it still lacks a defined token typ=
e that is safe to user over plain text HTTP.  1.0a solved that.=

  =0A=0A      =
From: Mike Jones <Michael.Jones@microsoft.com=
>
=0A=0A To: Just=
in Richer <jricher@mitre.org>; =
Phil Hunt <phil.hunt@oracle.com<=
/a>> 
=0A=0ACc: IETF =
oauth WG <oauth@ietf.org> 
 <=
span style=3D"font-weight:bold;">Sent: Thursday, February 14, 20=
13 1:44 PM
=0A=0A Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th=
 February 2013
=0A  

=0AI'm in favor of reusing the JWT=
 work that this WG is also doing. :-)

I'm pretty skeptical of us inv=
enting another custom scheme for signing HTTP headers.  That was the i=
mpediment to OAuth 1.0 adoption that OAuth 2.0 solved in the first place.=0A=0A
             =
   -- Mike

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behal=
f Of Justin Richer
=0A=0ASent: Tuesday, February 12, 2013 9:35 AM
To:=
 Phil Hunt
Cc: IETF oauth WG
Subject: Re: [OAUTH-WG] Minutes from the=
 OAuth Design Team Conference Call - 11th February 2013

That's my re=
ading of it as well, Phil, thanks for providing the clarification.=0A One m=
otivator behind using a JSON-based token is to be able to=0A re-use some of=
 the great work that the JOSE group is doing but apply it to an HTTP payloa=
d.

What neither of us want is a token type that requires stuffing al=
l query, header, and other parameters *into* the JSON object itself, which =
would be a more SOAPy approach.
=0A=0A
  -- Justin

On 02/=
12/2013 12:30 PM, Phil Hunt wrote:
> Clarification.  I think Jus=
tin and I were in agreement that we don't want to see a format that require=
s JSON payloads.  We are both interested in a JSON token used in the a=
uthorization header that could be based on a computed signature of some com=
bination of http headers and body if possible.
=0A=0A>
> Phil>
> @independentid
> www.independentid.com
> <=
a rel=3D"nofollow" ymailto=3D"mailto:phil.hunt@oracle.com" target=3D"_blank=
" href=3D"mailto:phil.hunt@oracle.com">phil.hunt@oracle.com
=0A=0A&g=
t;
>
>
>
>
> On=0A 2013-02-12, at 1:10 AM, Ha=
nnes Tschofenig wrote:
>
>> Here are my notes.
>>>> Participants:
>>
>> * John Bradley
>>=
 * Derek Atkins
>> * Phil Hunt
=0A=0A>> * Prateek Mishra<=
br>>> * Hannes Tschofenig
>> * Mike Jones
>> * Anto=
nio Sanso
>> * Justin Richer
>>
>> Notes:
>=
;>
>> My slides are available here: 
=0A=0A>> http://www.tschofenig.priv.at/OAuth2-Security-11F=
eb2013.ppt
>>
>> Slide #2 summarizes earlier discussi=
ons during the conference calls.
=0A=0A>>
>> -- HTTP vs. =
JSON
>>
>> Phil noted that he does not like to use the MA=
C Token draft as a starting point because it does not re-use any of the wor=
k done in the JOSE working group and in particular all the libraries that a=
re available today. He mentioned that earlier attempts to write the MAC Tok=
en code lead to=0A problems for implementers.
>>
>> Justi=
n responded that he does not agree with using JSON as a transport mechanism=
 since this would replicate a SOAP style.
>>
>> Phil note=
d that he wants to send JSON but the signature shall be computed over the H=
TTP header field.
=0A=0A>>
>> -- Flexibility for the keye=
d message digest computation
>>
>>  From earlier dis=
cussion it was clear that the conference call participants wanted more flex=
ibility regarding the keyed message digest computation. For this purpose Ha=
nnes presented the DKIM based approach, which allows selective header field=
s to be included in the digest. This is shown in slide #4.
=0A=0A>>=
;
>> After some discussion the conference call participants though=
t that this would meet their needs. Further investigations would still be u=
seful to determine the degree of failed HMAC calculations due to HTTP proxi=
es modifying the=0A content.
>>
>> -- Key Distribution>>
>> Hannes presented the open issue regarding the choice =
of key 
>> distribution. Slides #6-#8 present three techniques and=
 Hannes asked 
=0A=0A>> for feedback regarding the preferred style=
. Justin and others didn't 
>> see the need to decide on one mecha=
nism - they wanted to keep the 
>> choice open. Derek indicated th=
at this will not be an acceptable 
=0A=0A>> approach. Since the re=
source server and the authorization server may, 
>> in the OAuth 2=
.0 framework, be entities produced by different vendors 
>> there =
is an interoperability need. Justin responded that he disagrees 
=0A=0A&=
gt;> and that the resource server needs to understand the access token a=
nd 
>> referred to the recent draft submission for the token intro=
spection 
>> endpoint. Derek indicated that the resource server ha=
s to understand 
=0A=0A>>=0A the content of the access token and t=
he token introspection endpoint 
>> just pushes the problem around=
: the resource server has to send the 
>> access token to the auth=
orization server and then the resource server 
=0A=0A>> gets the r=
esult back (which he the
 n
>    a
>> gain need=
s to understand) in order to make a meaningful authorization decision.
&=
gt;>
>> Everyone agreed that the client must receive the sessio=
n key from the authorization server and that this approach has to be standa=
rdized. It was also agreed that this is a common approach among all three k=
ey distribution mechanisms.
=0A=0A>>
>> Hannes asked the =
participants to think about their preference.
>>
>> The q=
uestions regarding key naming and the indication for the intended resource =
server the client wants to talk to have been postponed.
=0A=0A>>>> Ciao
>>=0A Hannes
>>
>>
>> _=
______________________________________________
>> OAuth mailing li=
st
>> OAuth@ietf.org
=0A=0A>=
> https://www.ietf.org/mailman/listinfo/oauth
>=
; _______________________________________________
> OAuth mailing lis=
t
=0A=0A> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
=0A=0A
_______________________________________________
OAuth mailing list
=
OAuth@ietf.org
https://w=
ww.ietf.org/mailman/listinfo/oauth
=0A=0A___________________________=
____________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinf=
o/oauth
=0A=0A

___________________________________________=
____
OAuth mailing list
OAuth@ietf.org
=0A=0Ahttps://w=
ww.ietf.org/mailman/listinfo/oauth
<=
/div>

 =0A 

_________________________________________=
______
=0AOAuth mailing list
=0AOAuth@iet=
f.org
=0Ahttps://www.ietf.org/mailman/listinfo/oauth=

=0A

=0A

---368338466-484310537-1360961434=:42688--

From jricher@mitre.org  Fri Feb 15 12:55:51 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE88C21F844F for ; Fri, 15 Feb 2013 12:55:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.572
X-Spam-Level: 
X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.026,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6A7zaPO1iJb3 for ; Fri, 15 Feb 2013 12:55:48 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id AC61021E8039 for ; Fri, 15 Feb 2013 12:55:47 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 239C41F0FB6; Fri, 15 Feb 2013 15:55:47 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id F12471F033D; Fri, 15 Feb 2013 15:55:46 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 15 Feb 2013 15:55:46 -0500
Message-ID: <511EA0A3.7080000@mitre.org>
Date: Fri, 15 Feb 2013 15:54:59 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Tim Bray 
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net>  <511A7D27.8010209@mitre.org> <4E1F6AAD24975D4BA5B16804296739436744BD23@TK5EX14MBXC285.redmond.corp.microsoft.com> <1360891897.14004.YahooMailNeo@web31811.mail.mud.yahoo.com>  <1360912115.36543.YahooMailNeo@web31811.mail.mud.yahoo.com> <2A0F585F-2CEF-418D-9654-5084E6C9BD0D@lodderstedt.net> <1360944589.51724.YahooMailNeo@web31808.mail.mud.yahoo.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------010502060805030305000209"
X-Originating-IP: [129.83.31.58]
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Feb 2013 20:55:51 -0000

--------------010502060805030305000209
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

So that you can fetch and manage all your tokens using the same code 
paths as the OAuth2 services. The "get a token" part will be identical 
to Oauth2 Bearer (except for some details of what comes back from the 
token endpoint, of course), it's the "use a token" bit that really 
changes and is up in the air. You get to use scopes, and state, and 
refresh tokens, and all the other good stuff.

I've brought it up before, but I think it might be worthwhile, at least 
as an exercise, to define a method to get OAuth1-style tokens from an 
OAuth2 token endpoint. You'd defer to OAuth1 for how to use them with a 
protected resource.

  -- Justin

On 02/15/2013 11:49 AM, Tim Bray wrote:
> Not deeply acquainted with the Flickr scenario, but it occurs to me to 
> ask: If OAuth 1.0 is working well for them, why don't they just keep 
> using it?  I.e. if there's already a good solution in place for people 
> who require secure authn/authz over insecure channels, why would we go 
> the extra work of duplicating that in OAuth 2 territory? -T
>
> On Fri, Feb 15, 2013 at 8:09 AM, William Mills  > wrote:
>
>     I'll repeat the use case for Flickr, which requires OAuth 1.0a
>     type capabilites that OAuth 2 does not provide.  Simply stating
>     "move to HTTPS" is not a viable response here.
>
>     ------------------------------------------------------------------------
>     *From:* Torsten Lodderstedt      >
>     *To:* William Mills      >
>     *Cc:* Mike Jones      >; Justin Richer
>     >; Phil Hunt
>     >; IETF oauth
>     WG >
>     *Sent:* Friday, February 15, 2013 7:22 AM
>     *Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team
>     Conference Call - 11th February 2013
>
>     Hi Bill,
>
>     I think one needs to compare the costs/impact of HTTPS on one side
>     and the implementation of integrity protection and replay
>     detection on the other. We had this discussion several times.
>
>     regards,
>     Torsten.
>
>     Am 15.02.2013 um 08:08 schrieb William Mills
>     >:
>
>>     I fundamentally disagree with that too.  OAuth 2 is the
>>     *framework*, one which supports multiple token types.  Bearer
>>     tokens were the first credential type defined.
>>
>>     OAuth 1.0a also requires HTTPS transport for authentication and
>>     getting the token.
>>
>>     There are  real use cases for tokens usable over plain text with
>>     integrity protection.
>>
>>     -bill
>>
>>     ------------------------------------------------------------------------
>>     *From:* Torsten Lodderstedt >     >
>>     *To:* William Mills >     >
>>     *Cc:* Mike Jones >     >; Justin Richer
>>     >; Phil Hunt
>>     >; IETF oauth
>>     WG >
>>     *Sent:* Thursday, February 14, 2013 10:05 PM
>>     *Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team
>>     Conference Call - 11th February 2013
>>
>>     Hi Bill,
>>
>>     OAuth 2.0 took a different direction by relying on HTTPS to
>>     provide the basic protection. So the need to have a token, which
>>     can be used for service requests over plain HTTP is arguable. My
>>     understanding of this activity was, the intend is to provide
>>     additional protection on top of HTTPS.
>>
>>     regards,
>>     Torsten.
>>
>>     Am 15.02.2013 um 02:31 schrieb William Mills
>>     >:
>>
>>>     I disagree with "That was the impediment to OAuth 1.0 adoption
>>>     that OAuth 2.0 solved in the first place.", unless "solving"
>>>     means does not address the need for it at all.
>>>
>>>     OAuth 2 does several good things, but it still lacks a defined
>>>     token type that is safe to user over plain text HTTP.  1.0a
>>>     solved that.
>>>
>>>     ------------------------------------------------------------------------
>>>     *From:* Mike Jones >>     >
>>>     *To:* Justin Richer >>     >; Phil Hunt >>     >
>>>     *Cc:* IETF oauth WG >
>>>     *Sent:* Thursday, February 14, 2013 1:44 PM
>>>     *Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team
>>>     Conference Call - 11th February 2013
>>>
>>>     I'm in favor of reusing the JWT work that this WG is also doing. :-)
>>>
>>>     I'm pretty skeptical of us inventing another custom scheme for
>>>     signing HTTP headers.  That was the impediment to OAuth 1.0
>>>     adoption that OAuth 2.0 solved in the first place.
>>>
>>>                     -- Mike
>>>
>>>     -----Original Message-----
>>>     From: oauth-bounces@ietf.org 
>>>     [mailto:oauth-bounces@ietf.org ]
>>>     On Behalf Of Justin Richer
>>>     Sent: Tuesday, February 12, 2013 9:35 AM
>>>     To: Phil Hunt
>>>     Cc: IETF oauth WG
>>>     Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team
>>>     Conference Call - 11th February 2013
>>>
>>>     That's my reading of it as well, Phil, thanks for providing the
>>>     clarification. One motivator behind using a JSON-based token is
>>>     to be able to re-use some of the great work that the JOSE group
>>>     is doing but apply it to an HTTP payload.
>>>
>>>     What neither of us want is a token type that requires stuffing
>>>     all query, header, and other parameters *into* the JSON object
>>>     itself, which would be a more SOAPy approach.
>>>
>>>       -- Justin
>>>
>>>     On 02/12/2013 12:30 PM, Phil Hunt wrote:
>>>     > Clarification.  I think Justin and I were in agreement that we
>>>     don't want to see a format that requires JSON payloads. We are
>>>     both interested in a JSON token used in the authorization header
>>>     that could be based on a computed signature of some combination
>>>     of http headers and body if possible.
>>>     >
>>>     > Phil
>>>     >
>>>     > @independentid
>>>     > www.independentid.com 
>>>     > phil.hunt@oracle.com 
>>>     >
>>>     >
>>>     >
>>>     >
>>>     >
>>>     > On 2013-02-12, at 1:10 AM, Hannes Tschofenig wrote:
>>>     >
>>>     >> Here are my notes.
>>>     >>
>>>     >> Participants:
>>>     >>
>>>     >> * John Bradley
>>>     >> * Derek Atkins
>>>     >> * Phil Hunt
>>>     >> * Prateek Mishra
>>>     >> * Hannes Tschofenig
>>>     >> * Mike Jones
>>>     >> * Antonio Sanso
>>>     >> * Justin Richer
>>>     >>
>>>     >> Notes:
>>>     >>
>>>     >> My slides are available here:
>>>     >> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
>>>     >>
>>>     >> Slide #2 summarizes earlier discussions during the conference
>>>     calls.
>>>     >>
>>>     >> -- HTTP vs. JSON
>>>     >>
>>>     >> Phil noted that he does not like to use the MAC Token draft
>>>     as a starting point because it does not re-use any of the work
>>>     done in the JOSE working group and in particular all the
>>>     libraries that are available today. He mentioned that earlier
>>>     attempts to write the MAC Token code lead to problems for
>>>     implementers.
>>>     >>
>>>     >> Justin responded that he does not agree with using JSON as a
>>>     transport mechanism since this would replicate a SOAP style.
>>>     >>
>>>     >> Phil noted that he wants to send JSON but the signature shall
>>>     be computed over the HTTP header field.
>>>     >>
>>>     >> -- Flexibility for the keyed message digest computation
>>>     >>
>>>     >>  From earlier discussion it was clear that the conference
>>>     call participants wanted more flexibility regarding the keyed
>>>     message digest computation. For this purpose Hannes presented
>>>     the DKIM based approach, which allows selective header fields to
>>>     be included in the digest. This is shown in slide #4.
>>>     >>
>>>     >> After some discussion the conference call participants
>>>     thought that this would meet their needs. Further investigations
>>>     would still be useful to determine the degree of failed HMAC
>>>     calculations due to HTTP proxies modifying the content.
>>>     >>
>>>     >> -- Key Distribution
>>>     >>
>>>     >> Hannes presented the open issue regarding the choice of key
>>>     >> distribution. Slides #6-#8 present three techniques and
>>>     Hannes asked
>>>     >> for feedback regarding the preferred style. Justin and others
>>>     didn't
>>>     >> see the need to decide on one mechanism - they wanted to keep
>>>     the
>>>     >> choice open. Derek indicated that this will not be an acceptable
>>>     >> approach. Since the resource server and the authorization
>>>     server may,
>>>     >> in the OAuth 2.0 framework, be entities produced by different
>>>     vendors
>>>     >> there is an interoperability need. Justin responded that he
>>>     disagrees
>>>     >> and that the resource server needs to understand the access
>>>     token and
>>>     >> referred to the recent draft submission for the token
>>>     introspection
>>>     >> endpoint. Derek indicated that the resource server has to
>>>     understand
>>>     >> the content of the access token and the token introspection
>>>     endpoint
>>>     >> just pushes the problem around: the resource server has to
>>>     send the
>>>     >> access token to the authorization server and then the
>>>     resource server
>>>     >> gets the result back (which he the
>>>     n
>>>     >    a
>>>     >> gain needs to understand) in order to make a meaningful
>>>     authorization decision.
>>>     >>
>>>     >> Everyone agreed that the client must receive the session key
>>>     from the authorization server and that this approach has to be
>>>     standardized. It was also agreed that this is a common approach
>>>     among all three key distribution mechanisms.
>>>     >>
>>>     >> Hannes asked the participants to think about their preference.
>>>     >>
>>>     >> The questions regarding key naming and the indication for the
>>>     intended resource server the client wants to talk to have been
>>>     postponed.
>>>     >>
>>>     >> 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
>>>
>>>
>>>     _______________________________________________
>>>     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

--------------010502060805030305000209
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

    So that you can fetch and manage all your tokens using the same code
    paths as the OAuth2 services. The "get a token" part will be
    identical to Oauth2 Bearer (except for some details of what comes
    back from the token endpoint, of course), it's the "use a token" bit
    that really changes and is up in the air. You get to use scopes, and
    state, and refresh tokens, and all the other good stuff.

    I've brought it up before, but I think it might be worthwhile, at
    least as an exercise, to define a method to get OAuth1-style tokens
    from an OAuth2 token endpoint. You'd defer to OAuth1 for how to use
    them with a protected resource.

     -- Justin

    On 02/15/2013 11:49 AM, Tim Bray wrote:

      Not deeply acquainted with the Flickr scenario, but it occurs to
      me to ask: If OAuth 1.0 is working well for them, why don’t they
      just keep using it?  I.e. if there’s already a good solution in
      place for people who require secure authn/authz over insecure
      channels, why would we go the extra work of duplicating that in
      OAuth 2 territory? -T

      On Fri, Feb 15, 2013 at 8:09 AM, William
        Mills <wmills_92105@yahoo.com>
        wrote:

              I'll repeat the use case for Flickr, which
                  requires OAuth 1.0a type capabilites that OAuth 2 does
                  not provide.  Simply stating "move to HTTPS" is not a
                  viable response here.  

 From:
                      Torsten Lodderstedt <torsten@lodderstedt.net>

                      To:
                      William Mills <wmills_92105@yahoo.com> 

                      Cc:
                      Mike Jones <Michael.Jones@microsoft.com>;
                      Justin Richer <jricher@mitre.org>;
                      Phil Hunt <phil.hunt@oracle.com>;
                      IETF oauth WG <oauth@ietf.org>

                      Sent:
                      Friday, February 15, 2013 7:22 AM

                      Subject:
                      Re: [OAUTH-WG] Minutes from the OAuth Design Team
                      Conference Call - 11th February 2013

                      Hi Bill,

                      I think one needs to compare the costs/impact
                        of HTTPS on one side and the implementation of
                        integrity protection and replay detection on the
                        other. We had this discussion several times.

                      regards,
                      Torsten.

                        Am 15.02.2013 um 08:08 schrieb William Mills
                        <wmills_92105@yahoo.com>:

                            I fundamentally disagree with
                                that too.  OAuth 2 is the *framework*,
                                one which supports multiple token types.
                                 Bearer tokens were the first credential
                                type defined.

                              OAuth 1.0a also requires HTTPS
                                transport for authentication and getting
                                the token.

                            There
                                are  real use cases for tokens usable
                                over plain text with integrity
                                protection.

                              -bill

 From:
                                    Torsten Lodderstedt <torsten@lodderstedt.net>

                                    To:
                                    William Mills <wmills_92105@yahoo.com>

                                    Cc:
                                    Mike Jones <Michael.Jones@microsoft.com>;
                                    Justin Richer <jricher@mitre.org>;
                                    Phil Hunt <phil.hunt@oracle.com>;
                                    IETF oauth WG <oauth@ietf.org>

                                    Sent:
                                    Thursday, February 14, 2013 10:05 PM

                                    Subject:
                                    Re: [OAUTH-WG] Minutes from the
                                    OAuth Design Team Conference Call -
                                    11th February 2013

                                    Hi Bill,

                                    OAuth 2.0 took a different
                                      direction by relying on HTTPS to
                                      provide the basic protection. So
                                      the need to have a token, which
                                      can be used for service requests
                                      over plain HTTP is arguable. My
                                      understanding of this activity
                                      was, the intend is to provide
                                      additional protection on top of
                                      HTTPS.

                                    regards,
                                    Torsten.

                                      Am 15.02.2013 um 02:31 schrieb
                                      William Mills <wmills_92105@yahoo.com>:

                                          I disagree with "That
                                              was the impediment to
                                              OAuth 1.0 adoption that
                                              OAuth 2.0 solved in the
                                              first place.", unless
                                              "solving" means does not
                                              address the need for it at
                                              all.

                                            OAuth
                                              2 does several good
                                              things, but it still lacks
                                              a defined token type that
                                              is safe to user over plain
                                              text HTTP.  1.0a solved
                                              that.

 From: Mike Jones <Michael.Jones@microsoft.com>

                                                  To:
                                                  Justin Richer <jricher@mitre.org>;
                                                  Phil Hunt <phil.hunt@oracle.com>

                                                  Cc:
                                                  IETF oauth WG <oauth@ietf.org>

                                                  Sent:
                                                  Thursday, February 14,
                                                  2013 1:44 PM

                                                  Subject:
                                                  Re: [OAUTH-WG] Minutes
                                                  from the OAuth Design
                                                  Team Conference Call -
                                                  11th February 2013

                                              I'm in favor of reusing
                                              the JWT work that this WG
                                              is also doing. :-)

                                              I'm pretty skeptical of us
                                              inventing another custom
                                              scheme for signing HTTP
                                              headers.  That was the
                                              impediment to OAuth 1.0
                                              adoption that OAuth 2.0
                                              solved in the first place.

                                                              -- Mike

                                              -----Original Message-----

                                              From: oauth-bounces@ietf.org
                                              [mailto:oauth-bounces@ietf.org]
                                              On Behalf Of Justin Richer

                                              Sent: Tuesday, February
                                              12, 2013 9:35 AM

                                              To: Phil Hunt

                                              Cc: IETF oauth WG

                                              Subject: Re: [OAUTH-WG]
                                              Minutes from the OAuth
                                              Design Team Conference
                                              Call - 11th February 2013

                                              That's my reading of it as
                                              well, Phil, thanks for
                                              providing the
                                              clarification. One
                                              motivator behind using a
                                              JSON-based token is to be
                                              able to re-use some of the
                                              great work that the JOSE
                                              group is doing but apply
                                              it to an HTTP payload.

                                              What neither of us want is
                                              a token type that requires
                                              stuffing all query,
                                              header, and other
                                              parameters *into* the JSON
                                              object itself, which would
                                              be a more SOAPy approach.

                                                -- Justin

                                              On 02/12/2013 12:30 PM,
                                              Phil Hunt wrote:

                                              > Clarification.  I
                                              think Justin and I were in
                                              agreement that we don't
                                              want to see a format that
                                              requires JSON payloads. 
                                              We are both interested in
                                              a JSON token used in the
                                              authorization header that
                                              could be based on a
                                              computed signature of some
                                              combination of http
                                              headers and body if
                                              possible.

                                              >

                                              > Phil

                                              >

                                              > @independentid

                                              > www.independentid.com

                                              > phil.hunt@oracle.com

                                              >

                                              >

                                              >

                                              >

                                              >

                                              > On 2013-02-12, at
                                              1:10 AM, Hannes Tschofenig
                                              wrote:

                                              >

                                              >> Here are my
                                              notes.

                                              >>

                                              >> Participants:

                                              >>

                                              >> * John Bradley

                                              >> * Derek Atkins

                                              >> * Phil Hunt

                                              >> * Prateek Mishra

                                              >> * Hannes
                                              Tschofenig

                                              >> * Mike Jones

                                              >> * Antonio Sanso

                                              >> * Justin Richer

                                              >>

                                              >> Notes:

                                              >>

                                              >> My slides are
                                              available here: 

                                              >> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt

                                              >>

                                              >> Slide #2
                                              summarizes earlier
                                              discussions during the
                                              conference calls.

                                              >>

                                              >> -- HTTP vs. JSON

                                              >>

                                              >> Phil noted that
                                              he does not like to use
                                              the MAC Token draft as a
                                              starting point because it
                                              does not re-use any of the
                                              work done in the JOSE
                                              working group and in
                                              particular all the
                                              libraries that are
                                              available today. He
                                              mentioned that earlier
                                              attempts to write the MAC
                                              Token code lead to
                                              problems for implementers.

                                              >>

                                              >> Justin responded
                                              that he does not agree
                                              with using JSON as a
                                              transport mechanism since
                                              this would replicate a
                                              SOAP style.

                                              >>

                                              >> Phil noted that
                                              he wants to send JSON but
                                              the signature shall be
                                              computed over the HTTP
                                              header field.

                                              >>

                                              >> -- Flexibility
                                              for the keyed message
                                              digest computation

                                              >>

                                              >>  From earlier
                                              discussion it was clear
                                              that the conference call
                                              participants wanted more
                                              flexibility regarding the
                                              keyed message digest
                                              computation. For this
                                              purpose Hannes presented
                                              the DKIM based approach,
                                              which allows selective
                                              header fields to be
                                              included in the digest.
                                              This is shown in slide #4.

                                              >>

                                              >> After some
                                              discussion the conference
                                              call participants thought
                                              that this would meet their
                                              needs. Further
                                              investigations would still
                                              be useful to determine the
                                              degree of failed HMAC
                                              calculations due to HTTP
                                              proxies modifying the
                                              content.

                                              >>

                                              >> -- Key
                                              Distribution

                                              >>

                                              >> Hannes presented
                                              the open issue regarding
                                              the choice of key 

                                              >> distribution.
                                              Slides #6-#8 present three
                                              techniques and Hannes
                                              asked 

                                              >> for feedback
                                              regarding the preferred
                                              style. Justin and others
                                              didn't 

                                              >> see the need to
                                              decide on one mechanism -
                                              they wanted to keep the 

                                              >> choice open.
                                              Derek indicated that this
                                              will not be an acceptable

                                              >> approach. Since
                                              the resource server and
                                              the authorization server
                                              may, 

                                              >> in the OAuth 2.0
                                              framework, be entities
                                              produced by different
                                              vendors 

                                              >> there is an
                                              interoperability need.
                                              Justin responded that he
                                              disagrees 

                                              >> and that the
                                              resource server needs to
                                              understand the access
                                              token and 

                                              >> referred to the
                                              recent draft submission
                                              for the token
                                              introspection 

                                              >> endpoint. Derek
                                              indicated that the
                                              resource server has to
                                              understand 

                                              >> the content of
                                              the access token and the
                                              token introspection
                                              endpoint 

                                              >> just pushes the
                                              problem around: the
                                              resource server has to
                                              send the 

                                              >> access token to
                                              the authorization server
                                              and then the resource
                                              server 

                                              >> gets the result
                                              back (which he the

                                              n

                                              >    a

                                              >> gain needs to
                                              understand) in order to
                                              make a meaningful
                                              authorization decision.

                                              >>

                                              >> Everyone agreed
                                              that the client must
                                              receive the session key
                                              from the authorization
                                              server and that this
                                              approach has to be
                                              standardized. It was also
                                              agreed that this is a
                                              common approach among all
                                              three key distribution
                                              mechanisms.

                                              >>

                                              >> Hannes asked the
                                              participants to think
                                              about their preference.

                                              >>

                                              >> The questions
                                              regarding key naming and
                                              the indication for the
                                              intended resource server
                                              the client wants to talk
                                              to have been postponed.

                                              >>

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

                                      _______________________________________________

                                        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

--------------010502060805030305000209--

From wmills_92105@yahoo.com  Fri Feb 15 13:04:08 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A0121F868D for ; Fri, 15 Feb 2013 13:04:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.311
X-Spam-Level: 
X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[AWL=0.287,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DT8hzmq8l9+2 for ; Fri, 15 Feb 2013 13:04:06 -0800 (PST)
Received: from nm7-vm1.bullet.mail.gq1.yahoo.com (nm7-vm1.bullet.mail.gq1.yahoo.com [98.136.218.208]) by ietfa.amsl.com (Postfix) with SMTP id 4C1A221F8686 for ; Fri, 15 Feb 2013 13:04:04 -0800 (PST)
Received: from [98.137.12.57] by nm7.bullet.mail.gq1.yahoo.com with NNFMP; 15 Feb 2013 21:04:04 -0000
Received: from [98.137.12.52] by tm2.bullet.mail.gq1.yahoo.com with NNFMP; 15 Feb 2013 21:04:04 -0000
Received: from [127.0.0.1] by omp1067.mail.gq1.yahoo.com with NNFMP; 15 Feb 2013 21:04:04 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 90769.86499.bm@omp1067.mail.gq1.yahoo.com
Received: (qmail 19979 invoked by uid 60001); 15 Feb 2013 21:04:03 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360962243; bh=B+xHw19ra/ALJhNH+vFyHyLs7CrhpyBQWQ5+j0tWubo=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ZZ+OtjZ9nNKSWblQBWLtgDS0LWV6cGLKBZb/oT9ETgljbUVBKfPAwSMArxMa0BeFxUL5NtHsyqi7ZAblA7NFFNulxWm3kqCyxQmY2Sgy4nMjrECJCj/JuvB+rTQuve2nIQxU0hcDXD3FoB/G2hIbcMWnV8cSo42zGTeSeUe7dh8=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=m0VD5z7RlPzOlaAIUUrZt24gXVJRQw8TPW7bERESE1VfZT2Pnll9Y7S+E7G3HTFjYzpcm+j+lZWGmph3oIwKVr0/0WpOQGIziNThQx2TwVA9cjSZCuBq3d7val/EayIeiOt8oT3o6DQBhWqirjw2iazjqmjJSCLQxY0ZrJrcx4k=;
X-YMail-OSG: LT_EvGsVM1lGu1U3SDANOw30hvEEe6ZMnngvZzDpzkBpfLm _djnSmPPT2ltChap3RF59KFw3jEdSJ.qpunsB4P8Bz20OYPLxYt.npKSGfpT ULHPVHJPACISkC9Z2_acTFknRg9dp4kyhhn9tZCwWWLtBekT1KiNYltu288u AUTbMBFmc4q7xm22ZHwR.MpGkBXjI9FRasWBMzNgmA5cXQogsmUwzJKQOiDd uDkeLDAHOJrEo30FdJ_1jWp3BQA36klfgsvmJaWKEoIZ4cMAWytB6SBbklss J5oe2foPoRPg0ps8f38CqP1X0snww.lqOXjvQGpmyiph.T_bKCbHfZGlYjfy Wvg.q7pG2cg8isV4FtZP.Uhl3AIdrEw18PNBwyZNh_ow.kYmBA1IKL7TFnPi LBvcbIhRlb_nPNdHKZAv4dp3PTr3xny11AkwdTgW1.Z7ejlwVQzWElfai_aC ipR2JxmwWTR06ZFous3zdpZSedIk8A6iqxJ64GT9ulYigYHqtRPH5WO60C3E cZGmqdsFcnsHbFFvVEX.ENXEtUMcXHalL5ykMknZNqhHL0.rqv3HFER.JJMW sZ5PipiY8d2wZXsLFAmf0_PPNMnnE1bTPAnXcRnWXcofIAGAxDr_pIC5l5Y0 5FIpLk4JxzdPe2xsgeWnje44pfHN4WFxG0qlHH1AOQizA9jIQaw2kHzCskah R7S_H2WJ72.qzVvwS71k39474omxD
Received: from [209.131.62.145] by web31805.mail.mud.yahoo.com via HTTP; Fri, 15 Feb 2013 13:04:02 PST
X-Rocket-MIMEInfo: 001.001, PkkndmUgYnJvdWdodCBpdCB1cCBiZWZvcmUsIGJ1dCBJIHRoaW5rIGl0IG1pZ2h0IGJlIHdvcnRod2hpbGUsIGF0IGxlYXN0IGFzIGFuIGV4ZXJjaXNlLCB0byBkZWZpbmUgYSBtZXRob2QgdG8gZ2V0IE9BdXRoMS1zdHlsZSB0b2tlbnMgZnJvbSBhbiBPQXV0aDIgdG9rZW4gZW5kcG9pbnQuIFlvdSdkIGRlZmVyIHRvIE9BdXRoMSBmb3IgaG93IHRvIHVzZSB0aGVtID53aXRoIGEgcHJvdGVjdGVkIHJlc291cmNlLgoKCllFUyEKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRnJvbTogSnVzdGkBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.134.513
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net>  <511A7D27.8010209@mitre.org> <4E1F6AAD24975D4BA5B16804296739436744BD23@TK5EX14MBXC285.redmond.corp.microsoft.com> <1360891897.14004.YahooMailNeo@web31811.mail.mud.yahoo.com>  <1360912115.36543.YahooMailNeo@web31811.mail.mud.yahoo.com> <2A0F585F-2CEF-418D-9654-5084E6C9BD0D@lodderstedt.net> <1360944589.51724.YahooMailNeo@web31808.mail.mud.yahoo.com>  <511EA0A3.7080000@mitre.org>
Message-ID: <1360962242.18571.YahooMailNeo@web31805.mail.mud.yahoo.com>
Date: Fri, 15 Feb 2013 13:04:02 -0800 (PST)
From: William Mills 
To: Justin Richer , Tim Bray 
In-Reply-To: <511EA0A3.7080000@mitre.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-551393103-102741512-1360962242=:18571"
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Feb 2013 21:04:08 -0000

---551393103-102741512-1360962242=:18571
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

>I've brought it up before, but I think it might be worthwhile, at least as=
 an exercise, to define a method to get OAuth1-style tokens from an OAuth2 =
token endpoint. You'd defer to OAuth1 for how to use them >with a protected=
 resource.=0A=0A=0AYES!=0A=0A=0A________________________________=0A From: J=
ustin Richer =0ATo: Tim Bray  =0ACc: =
William Mills ; IETF oauth WG  =0AS=
ent: Friday, February 15, 2013 12:54 PM=0ASubject: Re: [OAUTH-WG] Minutes f=
rom the OAuth Design Team Conference Call - 11th February 2013=0A =0A=0ASo =
that you can fetch and manage all your tokens using the same code paths as =
the OAuth2 services. The "get a token" part will be identical to Oauth2 Bea=
rer (except for some details of what comes back from the token endpoint, of=
 course), it's the "use a token" bit that really changes and is up in the a=
ir. You get to use scopes, and state, and refresh tokens, and all the other=
 good stuff.=0A=0AI've brought it up before, but I think it might be worthw=
hile, at=0A    least as an exercise, to define a method to get OAuth1-style=
 tokens=0A    from an OAuth2 token endpoint. You'd defer to OAuth1 for how =
to use=0A    them with a protected resource.=0A=0A=C2=A0-- Justin=0A=0A=0AO=
n 02/15/2013 11:49 AM, Tim Bray wrote:=0A=0ANot deeply acquainted with the =
Flickr scenario, but it occurs to me to ask: If OAuth 1.0 is working well f=
or them, why don=E2=80=99t they just keep using it? =C2=A0I.e. if there=E2=
=80=99s already a good solution in place for people who require secure auth=
n/authz over insecure channels, why would we go the extra work of duplicati=
ng that in OAuth 2 territory? -T=0A>=0A>=0A>On Fri, Feb 15, 2013 at 8:09 AM=
, William Mills  wrote:=0A>=0A>I'll repeat the use =
case for Flickr, which requires OAuth 1.0a type capabilites that OAuth 2 do=
es not provide. =C2=A0Simply stating "move to HTTPS" is not a viable respon=
se here. =C2=A0=0A>>=0A>>=0A>>=0A>>________________________________=0A>> Fr=
om: Torsten Lodderstedt =0A>>To: William Mills  =0A>>Cc: Mike Jones ; Ju=
stin Richer ; Phil Hunt ; IETF oau=
th WG  =0A>>Sent: Friday, February 15, 2013 7:22 AM=0A>>Sub=
ject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 1=
1th February 2013=0A>> =0A>>=0A>>Hi Bill,=0A>>=0A>>=0A>>I think one needs t=
o compare the costs/impact of HTTPS on one side and the implementation of i=
ntegrity protection and replay detection on the other. We had this discussi=
on several times.=0A>>=0A>>=0A>>regards,=0A>>Torsten.=0A>>=0A>>Am 15.02.201=
3 um 08:08 schrieb William Mills=0A                        :=0A>>=0A>>=0A>>I fundamentally disagree with that too. =C2=A0OAuth=
 2 is the *framework*, one which supports multiple token types. =C2=A0Beare=
r tokens were the first credential type defined.=0A>>>=0A>>>=0A>>>OAuth 1.0=
a also requires HTTPS transport for authentication and getting the token.=
=0A>>>=0A>>>=0A>>>There are =C2=A0real use cases for tokens usable over pla=
in text with integrity protection.=0A>>>=0A>>>=0A>>>-bill=0A>>>=0A>>>=0A>>>=
=0A>>>________________________________=0A>>> From: Torsten Lodderstedt =0A>>>To: William Mills  =0A>>=
>Cc: Mike Jones ; Justin Richer ; Phil Hunt ; IETF oauth WG  =0A=
>>>Sent: Thursday, February 14, 2013 10:05 PM=0A>>>Subject: Re: [OAUTH-WG] =
Minutes from the OAuth Design Team Conference Call - 11th February 2013=0A>=
>> =0A>>>=0A>>>Hi Bill,=0A>>>=0A>>>=0A>>>OAuth 2.0 took a different directi=
on by relying on HTTPS to provide the basic protection. So the need to have=
 a token, which can be used for service requests over plain HTTP is arguabl=
e. My understanding of this activity was, the intend is to provide addition=
al protection on top of HTTPS.=0A>>>=0A>>>=0A>>>regards,=0A>>>Torsten.=0A>>=
>=0A>>>Am 15.02.2013 um 02:31 schrieb=0A                                   =
   William Mills :=0A>>>=0A>>>=0A>>>I disagree with=
 "That was the impediment to OAuth 1.0 adoption that OAuth 2.0 solved in th=
e first place.", unless "solving" means does not address the need for it at=
 all.=0A>>>>=0A>>>>=0A>>>>OAuth 2 does several good things, but it still la=
cks a defined token type that is safe to user over plain text HTTP. =C2=A01=
.0a solved that.=0A>>>>=0A>>>>=0A>>>>=0A>>>>_______________________________=
_=0A>>>> From: Mike Jones =0A>>>>To: Justin Ri=
cher ; Phil Hunt  =0A>>>>Cc: IETF =
oauth WG  =0A>>>>Sent: Thursday, February 14, 2013 1:44 PM=
=0A>>>>Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conferenc=
e Call - 11th February 2013=0A>>>> =0A>>>>I'm in favor of reusing=0A       =
                                       the JWT work that this WG=0A        =
                                      is also doing. :-)=0A>>>>=0A>>>>I'm p=
retty skeptical of us=0A                                              inven=
ting another custom=0A                                              scheme =
for signing HTTP=0A                                              headers.=
=C2=A0 That was the=0A                                              impedim=
ent to OAuth 1.0=0A                                              adoption t=
hat OAuth 2.0=0A                                              solved in the=
 first place.=0A>>>>=0A>>>>=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=
=A0=C2=A0 =C2=A0=C2=A0=C2=A0 -- Mike=0A>>>>=0A>>>>-----Original Message----=
-=0A>>>>From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Beh=
alf Of Justin Richer=0A>>>>Sent: Tuesday, February=0A                      =
                        12, 2013 9:35 AM=0A>>>>To: Phil Hunt=0A>>>>Cc: IETF=
 oauth WG=0A>>>>Subject: Re: [OAUTH-WG]=0A                                 =
             Minutes from the OAuth=0A                                     =
         Design Team Conference=0A                                         =
     Call - 11th February 2013=0A>>>>=0A>>>>That's my reading of it as=0A  =
                                            well, Phil, thanks for=0A      =
                                        providing the=0A                   =
                           clarification. One=0A                           =
                   motivator behind using a=0A                             =
                 JSON-based token is to be=0A                              =
                able to re-use some of the=0A                              =
                great work that the JOSE=0A                                =
              group is doing but apply=0A                                  =
            it to an HTTP payload.=0A>>>>=0A>>>>What neither of us want is=
=0A                                              a token type that requires=
=0A                                              stuffing all query,=0A    =
                                          header, and other=0A             =
                                 parameters *into* the JSON=0A             =
                                 object itself, which would=0A             =
                                 be a more SOAPy approach.=0A>>>>=0A>>>>=C2=
=A0 -- Justin=0A>>>>=0A>>>>On 02/12/2013 12:30 PM,=0A                      =
                        Phil Hunt wrote:=0A>>>>> Clarification.=C2=A0 I=0A =
                                             think Justin and I were in=0A =
                                             agreement that we don't=0A    =
                                          want to see a format that=0A     =
                                         requires JSON payloads.=C2=A0=0A  =
                                            We are both interested in=0A   =
                                           a JSON token used in the=0A     =
                                         authorization header that=0A      =
                                        could be based on a=0A             =
                                 computed signature of some=0A             =
                                 combination of http=0A                    =
                          headers and body if=0A                           =
                   possible.=0A>>>>>=0A>>>>> Phil=0A>>>>>=0A>>>>> @independ=
entid=0A>>>>> www.independentid.com=0A>>>>> phil.hunt@oracle.com=0A>>>>>=0A=
>>>>>=0A>>>>>=0A>>>>>=0A>>>>>=0A>>>>> On 2013-02-12, at=0A                 =
                             1:10 AM, Hannes Tschofenig=0A                 =
                             wrote:=0A>>>>>=0A>>>>>> Here are my=0A        =
                                      notes.=0A>>>>>>=0A>>>>>> Participants=
:=0A>>>>>>=0A>>>>>> * John Bradley=0A>>>>>> * Derek Atkins=0A>>>>>> * Phil =
Hunt=0A>>>>>> * Prateek Mishra=0A>>>>>> * Hannes=0A                        =
                      Tschofenig=0A>>>>>> * Mike Jones=0A>>>>>> * Antonio S=
anso=0A>>>>>> * Justin Richer=0A>>>>>>=0A>>>>>> Notes:=0A>>>>>>=0A>>>>>> My=
 slides are=0A                                              available here:=
 =0A>>>>>> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt=0A>>=
>>>>=0A>>>>>> Slide #2=0A                                              summ=
arizes earlier=0A                                              discussions =
during the=0A                                              conference calls=
.=0A>>>>>>=0A>>>>>> -- HTTP vs. JSON=0A>>>>>>=0A>>>>>> Phil noted that=0A  =
                                            he does not like to use=0A     =
                                         the MAC Token draft as a=0A       =
                                       starting point because it=0A        =
                                      does not re-use any of the=0A        =
                                      work done in the JOSE=0A             =
                                 working group and in=0A                   =
                           particular all the=0A                           =
                   libraries that are=0A                                   =
           available today. He=0A                                          =
    mentioned that earlier=0A                                              =
attempts to write the MAC=0A                                              T=
oken code lead to=0A                                              problems =
for implementers.=0A>>>>>>=0A>>>>>> Justin responded=0A                    =
                          that he does not agree=0A                        =
                      with using JSON as a=0A                              =
                transport mechanism since=0A                               =
               this would replicate a=0A                                   =
           SOAP style.=0A>>>>>>=0A>>>>>> Phil noted that=0A                =
                              he wants to send JSON but=0A                 =
                             the signature shall be=0A                     =
                         computed over the HTTP=0A                         =
                     header field.=0A>>>>>>=0A>>>>>> -- Flexibility=0A     =
                                         for the keyed message=0A          =
                                    digest computation=0A>>>>>>=0A>>>>>>=C2=
=A0 From earlier=0A                                              discussion=
 it was clear=0A                                              that the conf=
erence call=0A                                              participants wa=
nted more=0A                                              flexibility regar=
ding the=0A                                              keyed message dige=
st=0A                                              computation. For this=0A=
                                              purpose Hannes presented=0A  =
                                            the DKIM based approach,=0A    =
                                          which allows selective=0A        =
                                      header fields to be=0A               =
                               included in the digest.=0A                  =
                            This is shown in slide #4.=0A>>>>>>=0A>>>>>> Af=
ter some=0A                                              discussion the con=
ference=0A                                              call participants t=
hought=0A                                              that this would meet=
 their=0A                                              needs. Further=0A   =
                                           investigations would still=0A   =
                                           be useful to determine the=0A   =
                                           degree of failed HMAC=0A        =
                                      calculations due to HTTP=0A          =
                                    proxies modifying the=0A               =
                               content.=0A>>>>>>=0A>>>>>> -- Key=0A        =
                                      Distribution=0A>>>>>>=0A>>>>>> Hannes=
 presented=0A                                              the open issue r=
egarding=0A                                              the choice of key =
=0A>>>>>> distribution.=0A                                              Sli=
des #6-#8 present three=0A                                              tec=
hniques and Hannes=0A                                              asked =
=0A>>>>>> for feedback=0A                                              rega=
rding the preferred=0A                                              style. =
Justin and others=0A                                              didn't =
=0A>>>>>> see the need to=0A                                              d=
ecide on one mechanism -=0A                                              th=
ey wanted to keep the =0A>>>>>> choice open.=0A                            =
                  Derek indicated that this=0A                             =
                 will not be an acceptable =0A>>>>>> approach. Since=0A    =
                                          the resource server and=0A       =
                                       the authorization server=0A         =
                                     may, =0A>>>>>> in the OAuth 2.0=0A    =
                                          framework, be entities=0A        =
                                      produced by different=0A             =
                                 vendors =0A>>>>>> there is an=0A          =
                                    interoperability need.=0A              =
                                Justin responded that he=0A                =
                              disagrees =0A>>>>>> and that the=0A          =
                                    resource server needs to=0A            =
                                  understand the access=0A                 =
                             token and =0A>>>>>> referred to the=0A        =
                                      recent draft submission=0A           =
                                   for the token=0A                        =
                      introspection =0A>>>>>> endpoint. Derek=0A           =
                                   indicated that the=0A                   =
                           resource server has to=0A                       =
                       understand =0A>>>>>> the content of=0A              =
                                the access token and the=0A                =
                              token introspection=0A                       =
                       endpoint =0A>>>>>> just pushes the=0A               =
                               problem around: the=0A                      =
                        resource server has to=0A                          =
                    send the =0A>>>>>> access token to=0A                  =
                            the authorization server=0A                    =
                          and then the resource=0A                         =
                     server =0A>>>>>> gets the result=0A                   =
                           back (which he the=0A>>>>n=0A>>>>>=C2=A0 =C2=A0 =
a=0A>>>>>> gain needs to=0A                                              un=
derstand) in order to=0A                                              make =
a meaningful=0A                                              authorization =
decision.=0A>>>>>>=0A>>>>>> Everyone agreed=0A                             =
                 that the client must=0A                                   =
           receive the session key=0A                                      =
        from the authorization=0A                                          =
    server and that this=0A                                              ap=
proach has to be=0A                                              standardiz=
ed. It was also=0A                                              agreed that=
 this is a=0A                                              common approach =
among all=0A                                              three key distrib=
ution=0A                                              mechanisms.=0A>>>>>>=
=0A>>>>>> Hannes asked the=0A                                              =
participants to think=0A                                              about=
 their preference.=0A>>>>>>=0A>>>>>> The questions=0A                      =
                        regarding key naming and=0A                        =
                      the indication for the=0A                            =
                  intended resource server=0A                              =
                the client wants to talk=0A                                =
              to have been postponed.=0A>>>>>>=0A>>>>>> Ciao=0A>>>>>> Hanne=
s=0A>>>>>>=0A>>>>>>=0A>>>>>>=0A                                            =
  _______________________________________________=0A>>>>>> OAuth mailing=0A=
                                              list=0A>>>>>> OAuth@ietf.org=
=0A>>>>>> https://www.ietf.org/mailman/listinfo/oauth=0A>>>>>=0A           =
                                   ________________________________________=
_______=0A>>>>> OAuth mailing list=0A>>>>> OAuth@ietf.org=0A>>>>> https://w=
ww.ietf.org/mailman/listinfo/oauth=0A>>>>=0A>>>>=0A>>>>____________________=
___________________________=0A>>>>OAuth mailing list=0A>>>>OAuth@ietf.org=
=0A>>>>https://www.ietf.org/mailman/listinfo/oauth=0A>>>>__________________=
_____________________________=0A>>>>OAuth mailing list=0A>>>>OAuth@ietf.org=
=0A>>>>https://www.ietf.org/mailman/listinfo/oauth=0A>>>>=0A>>>>=0A>>>>=0A>=
>>_______________________________________________=0A>>>>OAuth mailing list=
=0A>>>>OAuth@ietf.org=0A>>>>https://www.ietf.org/mailman/listinfo/oauth=0A>=
>>>=0A>>>=0A>>>=0A>>=0A>>=0A>>_____________________________________________=
__=0A>>OAuth mailing list=0A>>OAuth@ietf.org=0A>>https://www.ietf.org/mailm=
an/listinfo/oauth=0A>>=0A>>=0A>=0A>=0A>=0A>________________________________=
_______________=0AOAuth mailing list OAuth@ietf.org https://www.ietf.org/ma=
ilman/listinfo/oauth 
---551393103-102741512-1360962242=:18571
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

>I've brought it up before, but I think it might be worthwhile, at leas=
t as an exercise, to define a method to get OAuth1-style tokens from an OAu=
th2 token endpoint. You'd defer to OAuth1 for how to use them >with a pr=
otected resource.

YES!=

        =
From: Justin Richer <jri=
cher@mitre.org>
 To:=
 Tim Bray <twbray@google.com> 
Cc: William Mills <wmills_92105@yahoo.com>; IETF oauth =
WG <oauth@ietf.org> 
 Sent:<=
/span> Friday, February 15, 2013 12:54 PM
 Subject: Re: [OAUTH-WG] Minutes from the OAuth Desi=
gn Team Conference Call - 11th February 2013

=0A  =0A=0A    =0A  =0A  =0A    So that you can fetc=
h and manage all your tokens using the same code=0A    paths as the OAuth2 =
services. The "get a token" part will be=0A    identical to Oauth2 Bearer (=
except for some details of what comes=0A    back from the token endpoint, o=
f course), it's the "use a token" bit=0A    that really changes and is up i=
n the air. You get to use scopes, and=0A    state, and refresh tokens, and =
all the other good stuff.
=0A    
=0A    I've brought it up before, b=
ut I think it might be worthwhile, at=0A    least as an exercise, to define=
 a method to get OAuth1-style tokens=0A    from an OAuth2 token endpoint. Y=
ou'd defer to OAuth1 for how to use=0A    them with a protected resource.=0A    
=0A     -- Justin
=0A    
=0A    On 02/15/2013 11:49 AM, Tim Bray wrote:
=0A    =
=0A    =0A      =0A      Not deeply acquain=
ted with the Flickr scenario, but it occurs to=0A      me to ask: If OAuth =
1.0 is working well for them, why don=E2=80=99t they=0A      just keep usin=
g it?  I.e. if there=E2=80=99s already a good solution in=0A      plac=
e for people who require secure authn/authz over insecure=0A      channels,=
 why would we go the extra work of duplicating that in=0A      OAuth 2 terr=
itory? -T
=0A      
=0A      O=
n Fri, Feb 15, 2013 at 8:09 AM, William=0A        Mills &=
lt;wmills_92105@yahoo.com&g=
t;=0A        wrote:
=0A        =0A          =0A            =0A    =
          I'll repeat the use case for Flickr, which=0A         =
         requires OAuth 1.0a type capabilites that OAuth 2 does=0A         =
         not provide.  Simply stating "move to HTTPS" is not a=0A     =
             viable response here.  
=0A              
=0A              
=0A              =0A                =0A           =
        =0A                      
 From:=0A       =
               Torsten Lodderstedt <torsten@lodderstedt.net>
=0A                      To:=0A                      Will=
iam Mills <wmills_92105@yaho=
o.com> 
=0A                      Cc:=0A                      Mike Jones <Michael.Jones@microsoft.com>=
;=0A                      Justin Richer <jricher@mitre.org>;=0A                      Phil Hunt <phil.hunt@oracle.com>;=0A         =
             IETF oauth WG <oauth@ietf.org>=0A                      
=0A                      Sent:=0A                      Friday, Feb=
ruary 15, 2013 7:22 AM
=0A                      Subject:=0A                      Re: [OAUTH-WG] Min=
utes from the OAuth Design Team=0A                      Conference Call - 1=
1th February 2013
=0A                     
=0A              =

=0A                  =0A                    =0A          =
            Hi Bill,
=0A                      
=0A       =

=0A                      I think one needs to com=
pare the costs/impact=0A                        of HTTPS on one side and th=
e implementation of=0A                        integrity protection and repl=
ay detection on the=0A                        other. We had this discussion=
 several times.
=0A                      
=0A                 =

=0A                      regards,=0A                 =
     Torsten.
=0A                      
=0A              =
          Am 15.02.2013 um 08:08 schrieb William Mills=0A                  =
      <wmills_92105@yahoo.co=
m>:
=0A                        
=0A                      =0A                      =0A                    =
    =0A                          =0A                            I fundamentally di=
sagree with=0A                                that too.  OAuth 2 is th=
e *framework*,=0A                                one which supports multipl=
e token types.=0A                                 Bearer tokens were t=
he first credential=0A                                type defined.<=
/div>=0A                            
=0A=
                              =0A                            <=
div style=3D"font-style:normal;font-size:16px;background-color:transparent;=
font-family:'Courier=0A                              New', courier, monaco,=
 monospace, sans-serif;">=0A                              OAuth 1.0a =
also requires HTTPS=0A                                transport for authent=
ication and getting=0A                                the token.=0A                            =0A             =

=0A                              =
=0A                            There=0A    =
                            are  real use cases for tokens usable=0A  =
                              over plain text with integrity=0A            =
                    protection.=0A                            =

=0A                              
=0A                            =0A        =
                      -bill=0A                          =

=0A                            =0A                        =
    =0A              =
                =0A                                 <=
font face=3D"Arial">=0A                                     =
From:=0A                   =
                 Torsten Lodderstedt <torsten@lodderstedt.net>
=0A                         =
           To:=0A          =
                          William Mills <wmills_92105@yahoo.com>=0A                             =

=0A                                    Cc:=0A                                    Mike Jones=
 <Michael.Jones@mi=
crosoft.com>;=0A                                    Justin Richer &l=
t;jricher@mitre.org>;=0A          =
                          Phil Hunt <phil.hunt@oracle.com>;=0A                                    IE=
TF oauth WG <oauth@ietf.org>=0A      =

=0A                                    Sent:=0A                     =
               Thursday, February 14, 2013 10:05 PM
=0A                 =
                   Subject:=
=0A                                    Re: [OAUTH-WG] Minutes from the=0A  =
                                  OAuth Design Team Conference Call -=0A   =
                                 11th February 2013
=0A                 =

=0A                                
=0A  =
                              =0A                                  =0A                                    Hi Bill,=0A            =

=0A                                    =0A                                    OAuth 2.0 took a different=
=0A                                      direction by relying on HTTPS to=
=0A                                      provide the basic protection. So=
=0A                                      the need to have a token, which=0A=
                                      can be used for service requests=0A  =
                                    over plain HTTP is arguable. My=0A     =
                                 understanding of this activity=0A         =
                             was, the intend is to provide=0A              =
                        additional protection on top of=0A                 =
                     HTTPS.
=0A                                    
=0A                                    =0A                     =
               regards,
=0A                                    Torsten.
=0A                                    
=0A       =
                               Am 15.02.2013 um 02:31 schrieb=0A           =
                           William Mills <wmills_92105@yahoo.com>:
=0A                       =

=0A                                    =0A        =
                            =0A                  =
                    =0A                                        =0A                                          I =
disagree with "That=0A            =
                                  was the impediment to=0A                 =
                             OAuth 1.0 adoption that=0A                    =
                          OAuth 2.0 solved in the=0A                       =
                       first place.", unless=0A                            =
                  "solving" means does not=0A                              =
                address the need for it at=0A                              =
                all.=0A                                       =
   =0A                                            
=0A                                            =
=0A                                          =0A                          =
                  OAuth=0A               =
                               2 does several good=0A                      =
                        things, but it still lacks=0A                      =
                        a defined token type that=0A                       =
                       is safe to user over plain=0A                       =
                       text HTTP.  1.0a solved=0A                     =
                         that.=0A                             =

=0A                                          =
=0A                                          =0A   =
                                         =0A                                               =0A                                                  
 From: Mike Jones &l=
t;Michael.Jones@micro=
soft.com>
=0A                                                  To:=0A                       =
                           Justin Richer <jricher@mitre.org>;=0A                                          =
        Phil Hunt <phil.hunt@ora=
cle.com>=0A                                                  
=0A=
                                                  Cc:=0A                                              =
    IETF oauth WG <oauth@ietf.org>=0A=

=0A                  =
                                Sent:<=
/span>=0A                                                  Thursday, Fe=
bruary 14,=0A                                                  2013 1:44 PM=

=0A                                                  Subject:=0A                                  =
                Re: [OAUTH-WG] Minutes=0A                                  =
                from the OAuth Design=0A                                   =
               Team Conference Call -=0A                                   =
               11th February 2013
=0A                                   =
              =0A                                             =

=0A                                              I'm in favor of reusi=
ng=0A                                              the JWT work that this W=
G=0A                                              is also doing. :-)
=0A=

=0A                      =
                        I'm pretty skeptical of us=0A                      =
                        inventing another custom=0A                        =
                      scheme for signing HTTP=0A                           =
                   headers.  That was the=0A                          =
                    impediment to OAuth 1.0=0A                             =
                 adoption that OAuth 2.0=0A                                =
              solved in the first place.
=0A                            =

=0A                                              &nbs=
p;               -- =
Mike
=0A                                              
=0A           =
                                   -----Original Message-----
=0A       =
                                       From: oauth-bounces@ietf.org=0A                                =
              [mailto:oauth-bou=
nces@ietf.org]=0A                                              On Behal=
f Of Justin Richer
=0A                                              Sent=
: Tuesday, February=0A                                              12, 201=
3 9:35 AM
=0A                                              To: Phil Hunt=

=0A                                              Cc: IETF oauth WG
=
=0A                                              Subject: Re: [OAUTH-WG]=0A=
                                              Minutes from the OAuth=0A    =
                                          Design Team Conference=0A        =
                                      Call - 11th February 2013
=0A     =

=0A                           =
                   That's my reading of it as=0A                           =
                   well, Phil, thanks for=0A                               =
               providing the=0A                                            =
  clarification. One=0A                                              motiva=
tor behind using a=0A                                              JSON-bas=
ed token is to be=0A                                              able to r=
e-use some of the=0A                                              great wor=
k that the JOSE=0A                                              group is do=
ing but apply=0A                                              it to an HTTP=
 payload.
=0A                                              
=0A      =
                                        What neither of us want is=0A      =
                                        a token type that requires=0A      =
                                        stuffing all query,=0A             =
                                 header, and other=0A                      =
                        parameters *into* the JSON=0A                      =
                        object itself, which would=0A                      =
                        be a more SOAPy approach.
=0A                   =

=0A                                         =
       -- Justin
=0A                                              <=
br>=0A                                              On 02/12/2013 12:30 PM,=
=0A                                              Phil Hunt wrote:
=0A   =
                                           > Clarification.  I=0A  =
                                            think Justin and I were in=0A  =
                                            agreement that we don't=0A     =
                                         want to see a format that=0A      =
                                        requires JSON payloads. =0A   =
                                           We are both interested in=0A    =
                                          a JSON token used in the=0A      =
                                        authorization header that=0A       =
                                       could be based on a=0A              =
                                computed signature of some=0A              =
                                combination of http=0A                     =
                         headers and body if=0A                            =
                  possible.
=0A                                         =
     >
=0A                                              > Phil
=
=0A                                              >
=0A               =
                               > @independentid
=0A                  =
                            > www.independentid.com
=0A        =
                                      > phil.hunt@oracle.com
=0A                                    =
          >
=0A                                              >
=
=0A                                              >
=0A               =
                               >
=0A                                 =
             >
=0A                                              > =
On 2013-02-12, at=0A                                              1:10 AM, =
Hannes Tschofenig=0A                                              wrote:=0A                                              >
=0A              =
                                >> Here are my=0A                    =
                          notes.
=0A                                    =
          >>
=0A                                              >=
> Participants:
=0A                                              >=
>
=0A                                              >> * John Br=
adley
=0A                                              >> * Derek =
Atkins
=0A                                              >> * Phil =
Hunt
=0A                                              >> * Prateek=
 Mishra
=0A                                              >> * Hann=
es=0A                                              Tschofenig
=0A       =
                                       >> * Mike Jones
=0A        =
                                      >> * Antonio Sanso
=0A      =
                                        >> * Justin Richer
=0A    =
                                          >>
=0A                  =
                            >> Notes:
=0A                         =
                     >>
=0A                                       =
       >> My slides are=0A                                           =
   available here: 
=0A                                              >=
;> http://www.tschofenig.priv.at/OAuth2-=
Security-11Feb2013.ppt
=0A                                          =
    >>
=0A                                              >> S=
lide #2=0A                                              summarizes earlier=
=0A                                              discussions during the=0A =
                                             conference calls.
=0A      =
                                        >>
=0A                    =
                          >> -- HTTP vs. JSON
=0A                 =
                             >>
=0A                               =
               >> Phil noted that=0A                                 =
             he does not like to use=0A                                    =
          the MAC Token draft as a=0A                                      =
        starting point because it=0A                                       =
       does not re-use any of the=0A                                       =
       work done in the JOSE=0A                                            =
  working group and in=0A                                              part=
icular all the=0A                                              libraries th=
at are=0A                                              available today. He=
=0A                                              mentioned that earlier=0A =
                                             attempts to write the MAC=0A  =
                                            Token code lead to=0A          =
                                    problems for implementers.
=0A      =
                                        >>
=0A                    =
                          >> Justin responded=0A                     =
                         that he does not agree=0A                         =
                     with using JSON as a=0A                               =
               transport mechanism since=0A                                =
              this would replicate a=0A                                    =
          SOAP style.
=0A                                              &=
gt;>
=0A                                              >> Phil n=
oted that=0A                                              he wants to send =
JSON but=0A                                              the signature shal=
l be=0A                                              computed over the HTTP=
=0A                                              header field.
=0A      =
                                        >>
=0A                    =
                          >> -- Flexibility=0A                       =
                       for the keyed message=0A                            =
                  digest computation
=0A                                =
              >>
=0A                                              =
>>  From earlier=0A                                             =
 discussion it was clear=0A                                              th=
at the conference call=0A                                              part=
icipants wanted more=0A                                              flexib=
ility regarding the=0A                                              keyed m=
essage digest=0A                                              computation. =
For this=0A                                              purpose Hannes pre=
sented=0A                                              the DKIM based appro=
ach,=0A                                              which allows selective=
=0A                                              header fields to be=0A    =
                                          included in the digest.=0A       =
                                       This is shown in slide #4.
=0A   =
                                           >>
=0A                 =
                             >> After some=0A                        =
                      discussion the conference=0A                         =
                     call participants thought=0A                          =
                    that this would meet their=0A                          =
                    needs. Further=0A                                      =
        investigations would still=0A                                      =
        be useful to determine the=0A                                      =
        degree of failed HMAC=0A                                           =
   calculations due to HTTP=0A                                             =
 proxies modifying the=0A                                              cont=
ent.
=0A                                              >>
=0A   =
                                           >> -- Key=0A              =
                                Distribution
=0A                        =
                      >>
=0A                                      =
        >> Hannes presented=0A                                       =
       the open issue regarding=0A                                         =
     the choice of key 
=0A                                             =
 >> distribution.=0A                                              Sli=
des #6-#8 present three=0A                                              tec=
hniques and Hannes=0A                                              asked =0A                                              >> for feedback=0A=
                                              regarding the preferred=0A   =
                                           style. Justin and others=0A     =
                                         didn't 
=0A                    =
                          >> see the need to=0A                      =
                        decide on one mechanism -=0A                       =
                       they wanted to keep the 
=0A                     =
                         >> choice open.=0A                          =
                    Derek indicated that this=0A                           =
                   will not be an acceptable=0A                            =

=0A                                              >=
> approach. Since=0A                                              the re=
source server and=0A                                              the autho=
rization server=0A                                              may, 
=
=0A                                              >> in the OAuth 2.0=
=0A                                              framework, be entities=0A =
                                             produced by different=0A      =
                                        vendors 
=0A                    =
                          >> there is an=0A                          =
                    interoperability need.=0A                              =
                Justin responded that he=0A                                =
              disagrees 
=0A                                            =
  >> and that the=0A                                              res=
ource server needs to=0A                                              under=
stand the access=0A                                              token and =

=0A                                              >> referred to t=
he=0A                                              recent draft submission=
=0A                                              for the token=0A          =
                                    introspection 
=0A                  =
                            >> endpoint. Derek=0A                    =
                          indicated that the=0A                            =
                  resource server has to=0A                                =
              understand 
=0A                                           =
   >> the content of=0A                                              =
the access token and the=0A                                              to=
ken introspection=0A                                              endpoint =

=0A                                              >> just pushes t=
he=0A                                              problem around: the=0A  =
                                            resource server has to=0A      =
                                        send the 
=0A                   =
                           >> access token to=0A                     =
                         the authorization server=0A                       =
                       and then the resource=0A                            =
                  server 
=0A                                           =
   >> gets the result=0A                                             =
 back (which he the
=0A                                              n=0A                                              >    a
=
=0A                                              >> gain needs to=0A =
                                             understand) in order to=0A    =
                                          make a meaningful=0A             =
                                 authorization decision.
=0A            =
                                  >>
=0A                          =
                    >> Everyone agreed=0A                            =
                  that the client must=0A                                  =
            receive the session key=0A                                     =
         from the authorization=0A                                         =
     server and that this=0A                                              a=
pproach has to be=0A                                              standardi=
zed. It was also=0A                                              agreed tha=
t this is a=0A                                              common approach=
 among all=0A                                              three key distri=
bution=0A                                              mechanisms.
=0A  =
                                            >>
=0A                =
                              >> Hannes asked the=0A                 =
                             participants to think=0A                      =
                        about their preference.
=0A                     =
                         >>
=0A                                   =
           >> The questions=0A                                       =
       regarding key naming and=0A                                         =
     the indication for the=0A                                             =
 intended resource server=0A                                              t=
he client wants to talk=0A                                              to =
have been postponed.
=0A                                              &g=
t;>
=0A                                              >> Ciao=0A                                              >> Hannes
=0A   =
                                           >>
=0A                 =
                             >>
=0A                               =
               >>=0A                                              ___=
____________________________________________
=0A                        =
                      >> OAuth mailing=0A                            =
                  list
=0A                                              =
>> OAuth@ietf.org
=0A             =
                                 >> https://www.ietf.=
org/mailman/listinfo/oauth
=0A                                      =
        >=0A                                              ______________=
_________________________________
=0A                                   =
           > OAuth mailing list
=0A                                  =
            > OAuth@ietf.org
=0A     =
                                         > https://www.i=
etf.org/mailman/listinfo/oauth
=0A                                  =

=0A                                              
=0A___=
____________________________________________
=0A                        =
                      OAuth mailing list
=0A                            =
                  OAuth@ietf.org
=0A    =
                                          https://www.ietf.=
org/mailman/listinfo/oauth
=0A______________________________________=
_________
=0A                                              OAuth mailing=
 list
=0A                                              OAuth@ietf.org
=0A                                       =
       https://www.ietf.org/mailman/listinfo/oauth
=
=0A                                              
=0A                   =

=0A                                         =

=0A                                          =0A            =
                            =0A                                      =
=0A                                    =0A              =
                      =0A                        =
              _______________________________________________
=0A                                        OAuth mailing list=

=0A                                        OAuth@ietf.org
=0A                              =
          https://www.ietf.org/mailman/listinfo/oauth=

=0A                                      =0A          =
                          =0A                                 =

=0A                                =0A                        =

=0A                                
=0A                     =

=0A                            =0A                    =

=0A                        
=0A                      =0A                    
=0A                  
=0A        =

=0A                  
=0A                
=0A        =

=0A            
=0A          
=0A          
=0A   =
       _______________________________________________
=0A          OAut=
h mailing list
=0A          OAuth@ietf.org
=0A          https://www.ietf.org/mailman/listinfo/oa=
uth
=0A          
=0A        
=0A      
=0A     =

=0A      
=0A      
=0A      
=0A      ________________________________=
_______________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/l=
istinfo/oauth=0A
=0A    =0A    
=0A  
=0A=0A<=
/div>

---551393103-102741512-1360962242=:18571--

From phil.hunt@oracle.com  Fri Feb 15 13:52:31 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D8821F8581 for ; Fri, 15 Feb 2013 13:52:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.635
X-Spam-Level: 
X-Spam-Status: No, score=-5.635 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8+CS0vtFekQ for ; Fri, 15 Feb 2013 13:52:29 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 533C621F857A for ; Fri, 15 Feb 2013 13:52:29 -0800 (PST)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1FLqQAm003307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 Feb 2013 21:52:27 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1FLqPYc004365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Feb 2013 21:52:26 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1FLqPt3013144; Fri, 15 Feb 2013 15:52:25 -0600
Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 15 Feb 2013 13:52:24 -0800
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net>  <511A7D27.8010209@mitre.org> <4E1F6AAD24975D4BA5B16804296739436744BD23@TK5EX14MBXC285.redmond.corp.microsoft.com> <1360891897.14004.YahooMailNeo@web31811.mail.mud.yahoo.com>  <1360912115.36543.YahooMailNeo@web31811.mail.mud.yahoo.com> <2A0F585F-2CEF-418D-9654-5084E6C9BD0D@lodderstedt.net> <1360944589.51724.YahooMailNeo@web31808.mail.mud.yahoo.com>  <511EA0A3.7080000@mitre.org> <1360962242.18571.YahooMailNeo@web31805.mail.mud.yahoo.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <1360962242.18571.YahooMailNeo@web31805.mail.mud.yahoo.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-2F9021E0-B6B0-475A-89C2-6C02AE340996
Content-Transfer-Encoding: 7bit
Message-Id: 
X-Mailer: iPhone Mail (10B142)
From: Phil Hunt 
Date: Fri, 15 Feb 2013 13:52:23 -0800
To: William Mills 
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Feb 2013 21:52:31 -0000

--Apple-Mail-2F9021E0-B6B0-475A-89C2-6C02AE340996
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Sorry. I have to disagree. The way 1.0 is written, it is not a shortcut to t=
urn it into a token for 2.=20

Phil

Sent from my phone.

On 2013-02-15, at 13:04, William Mills  wrote:

> >I've brought it up before, but I think it might be worthwhile, at least a=
s an exercise, to define a method to get OAuth1-style tokens from an OAuth2 t=
oken endpoint. You'd defer to OAuth1 for how to use them >with a protected r=
esource.
>=20
> YES!
>=20
> From: Justin Richer 
> To: Tim Bray =20
> Cc: William Mills ; IETF oauth WG =
=20
> Sent: Friday, February 15, 2013 12:54 PM
> Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call=
 - 11th February 2013
>=20
> So that you can fetch and manage all your tokens using the same code     p=
aths as the OAuth2 services. The "get a token" part will be identical to Oau=
th2 Bearer (except for some details of what comes back from the token endpoi=
nt, of course), it's the "use a token" bit that really changes and is up in t=
he air. You get to use scopes, and state, and refresh tokens, and all the ot=
her good stuff.
>=20
> I've brought it up before, but I think it might be worthwhile, at least as=
 an exercise, to define a method to get OAuth1-style tokens from an OAuth2 t=
oken endpoint. You'd defer to OAuth1 for how to use them with a protected re=
source.
>=20
>  -- Justin
>=20
> On 02/15/2013 11:49 AM, Tim Bray wrote:
>> Not deeply acquainted with the Flickr scenario, but it occurs to me to as=
k: If OAuth 1.0 is working well for them, why don=E2=80=99t they just keep u=
sing it?  I.e. if there=E2=80=99s already a good solution in place for peopl=
e who require secure authn/authz over insecure channels, why would we go the=
 extra work of duplicating that in OAuth 2 territory? -T
>>=20
>> On Fri, Feb 15, 2013 at 8:09 AM, William Mills  w=
rote:
>> I'll repeat the use case for Flickr, which requires OAuth 1.0a type capab=
ilites that OAuth 2 does not provide.  Simply stating "move to HTTPS" is not=
 a viable response here. =20
>>=20
>> From: Torsten Lodderstedt 
>> To: William Mills =20
>> Cc: Mike Jones ; Justin Richer ; Phil Hunt ; IETF oauth WG     =
                  =20
>> Sent: Friday, February 15, 2013 7:22 AM
>> Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Cal=
l - 11th February 2013
>>=20
>> Hi Bill,
>>=20
>> I think one needs to compare the costs/impact of HTTPS on one side and th=
e implementation of integrity protection and replay detection on the other. W=
e had this discussion several times.
>>=20
>> regards,
>> Torsten.
>>=20
>> Am 15.02.2013 um 08:08 schrieb William Mills                         :
>>=20
>>> I fundamentally disagree with that too.  OAuth 2 is the *framework*, one=
 which supports multiple token types.  Bearer tokens were the first credenti=
al type defined.
>>>=20
>>> OAuth 1.0a also requires HTTPS transport for authentication and getting t=
he token.
>>>=20
>>> There are  real use cases for tokens usable                             =
    over plain text with integrity protection.
>>>=20
>>> -bill
>>>=20
>>> From: Torsten Lodderstedt 
>>> To: William Mills =20
>>> Cc: Mike Jones ; Justin Richer ; Phil Hunt ; IETF oauth WG =20=

>>> Sent: Thursday, February 14, 2013 10:05 PM
>>> Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Ca=
ll - 11th February 2013
>>>=20
>>> Hi Bill,
>>>=20
>>> OAuth 2.0 took a different direction by relying on HTTPS to provide the b=
asic protection. So the need to have a token, which can be used for service r=
equests over plain HTTP is arguable. My understanding of this activity was, t=
he intend is to provide                                       additional pro=
tection on top of HTTPS.
>>>=20
>>> regards,
>>> Torsten.
>>>=20
>>> Am 15.02.2013 um 02:31 schrieb William Mills :
>>>=20
>>>> I disagree with "That was the impediment to OAuth 1.0 adoption that OAu=
th 2.0 solved in the first place.", unless "solving" means does not address t=
he need for it at all.
>>>>=20
>>>> OAuth 2 does several good things, but it still lacks a defined token ty=
pe that is safe to user over plain text HTTP.  1.0a solved that.
>>>>=20
>>>> From: Mike Jones 
>>>> To: Justin Richer ; Phil Hunt =
=20
>>>> Cc: IETF oauth WG =20
>>>> Sent: Thursday, February 14, 2013 1:44 PM
>>>> Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference C=
all - 11th February 2013
>>>>=20
>>>> I'm in favor of reusing the JWT work that this WG is also doing. :-)
>>>>=20
>>>> I'm pretty skeptical of us inventing another custom scheme for signing H=
TTP headers.  That was the impediment to OAuth 1.0 adoption that OAuth 2.0 s=
olved in the first place.
>>>>=20
>>>>                 -- Mike
>>>>=20
>>>> -----Original Message-----
>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O=
f Justin Richer
>>>> Sent: Tuesday, February 12, 2013 9:35 AM
>>>> To: Phil Hunt
>>>> Cc: IETF oauth WG
>>>> Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference C=
all - 11th February 2013
>>>>=20
>>>> That's my reading of it as well, Phil, thanks for providing the clarifi=
cation. One motivator behind using a JSON-based token is to be able to re-us=
e some of the                                               great work that t=
he JOSE group is doing but apply it to an HTTP payload.
>>>>=20
>>>> What neither of us want is a token type that requires stuffing all quer=
y, header, and other parameters *into* the JSON object itself, which would b=
e a more SOAPy approach.
>>>>=20
>>>>   -- Justin
>>>>=20
>>>> On 02/12/2013 12:30 PM, Phil Hunt wrote:
>>>> > Clarification.  I think Justin and I were in agreement that we don't w=
ant to see a format that requires JSON payloads.                            =
                    We are both interested in a JSON token used in the autho=
rization header that could be based on a computed signature of some combinat=
ion of http headers and body if possible.
>>>> >
>>>> > Phil
>>>> >
>>>> > @independentid
>>>> > www.independentid.com
>>>> > phil.hunt@oracle.com
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > On 2013-02-12, at 1:10 AM, Hannes Tschofenig wrote:
>>>> >
>>>> >> Here are my notes.
>>>> >>
>>>> >> Participants:
>>>> >>
>>>> >> * John Bradley
>>>> >> * Derek Atkins
>>>> >> * Phil Hunt
>>>> >> * Prateek Mishra
>>>> >> * Hannes Tschofenig
>>>> >> * Mike Jones
>>>> >> * Antonio Sanso
>>>> >> * Justin Richer
>>>> >>
>>>> >> Notes:
>>>> >>
>>>> >> My slides are available here:=20
>>>> >> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
>>>> >>
>>>> >> Slide #2 summarizes earlier discussions during the conference calls.=

>>>> >>
>>>> >> -- HTTP vs. JSON
>>>> >>
>>>> >> Phil noted that he does not like to use                             =
                  the MAC Token draft as a starting point because it does no=
t re-use any of the work done in the JOSE working group and in particular al=
l the libraries that are available today. He mentioned that earlier         =
                                      attempts to write the MAC Token code l=
ead to problems for implementers.
>>>> >>
>>>> >> Justin responded that he does not agree                             =
                  with using JSON as a transport mechanism since this would r=
eplicate a SOAP style.
>>>> >>
>>>> >> Phil noted that he wants to send JSON but the signature shall be com=
puted over the HTTP header field.
>>>> >>
>>>> >> -- Flexibility for the keyed message digest computation
>>>> >>
>>>> >>  =46rom earlier discussion it was clear that the conference call par=
ticipants wanted more flexibility regarding the keyed message digest computa=
tion. For this                                               purpose Hannes p=
resented the DKIM based approach, which allows selective header fields to be=
 included in the digest. This is shown in slide #4.
>>>> >>
>>>> >> After some discussion the conference call participants thought that t=
his would meet their needs. Further investigations would still be useful to d=
etermine the degree of failed HMAC calculations due to HTTP proxies modifyin=
g the content.
>>>> >>
>>>> >> -- Key Distribution
>>>> >>
>>>> >> Hannes presented the open issue regarding the choice of key=20
>>>> >> distribution. Slides #6-#8 present three techniques and Hannes asked=
=20
>>>> >> for feedback regarding the preferred style. Justin and others didn't=
=20
>>>> >> see the need to decide on one mechanism - they wanted to keep the=20=

>>>> >> choice open. Derek indicated that this                              =
                 will not be an acceptable=20
>>>> >> approach. Since the resource server and                             =
                  the authorization server may,=20
>>>> >> in the OAuth 2.0 framework, be entities                             =
                  produced by different vendors=20
>>>> >> there is an interoperability need. Justin responded that he disagree=
s=20
>>>> >> and that the resource server needs to understand the access token an=
d=20
>>>> >> referred to the recent draft submission                             =
                  for the token introspection=20
>>>> >> endpoint. Derek indicated that the resource server has to understand=
=20
>>>> >> the content of the access token and the                             =
                  token introspection endpoint=20
>>>> >> just pushes the problem around: the resource server has to send the=20=

>>>> >> access token to the authorization server and then the resource serve=
r=20
>>>> >> gets the result back (which he the
>>>> n
>>>> >    a
>>>> >> gain needs to understand) in order to make a meaningful authorizatio=
n decision.
>>>> >>
>>>> >> Everyone agreed that the client must receive the session key from th=
e authorization server and that this approach has to be standardized. It was=
 also agreed that this is a common approach among all three key distribution=
 mechanisms.
>>>> >>
>>>> >> Hannes asked the participants to think                              =
                 about their preference.
>>>> >>
>>>> >> The questions regarding key naming and                              =
                 the indication for the intended resource server the client w=
ants to talk to have been postponed.
>>>> >>
>>>> >> 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
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> 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
>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-2F9021E0-B6B0-475A-89C2-6C02AE340996
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Sorry. I have to disagree. The way 1.0=
 is written, it is not a shortcut to turn it into a token for 2. 
Phil
Sent from my phone.

On 2013-02=
-15, at 13:04, William Mills <w=
mills_92105@yahoo.com> wrote:

=
>I've b=
rought it up before, but I think it might be worthwhile, at least as an exer=
cise, to define a method to get OAuth1-style tokens from an OAuth2 token end=
point. You'd defer to OAuth1 for how to use them >with a protected resour=
ce.

YES!

  =
From: Justin Richer <jricher@mitre.org>
 To: Tim Bray <twbray@google.com> 
wmills_92105@yahoo.com>; IETF oauth WG <oauth@ietf.org> 
 S=
ent: Friday, February 15, 2013 12:54 PM
 Subject: Re: [OAUTH-WG] Minutes from the OAuth D=
esign Team Conference Call - 11th February 2013

 =20

   =20
 =20

    So that you can fetch and manage all your tokens using the same code
    paths as the OAuth2 services. The "get a token" part will be
    identical to Oauth2 Bearer (except for some details of what comes
    back from the token endpoint, of course), it's the "use a token" bit
    that really changes and is up in the air. You get to use scopes, and
    state, and refresh tokens, and all the other good stuff.

    I've brought it up before, but I think it might be worthwhile, at
    least as an exercise, to define a method to get OAuth1-style tokens
    from an OAuth2 token endpoint. You'd defer to OAuth1 for how to use
    them with a protected resource.

     -- Justin

    On 02/15/2013 11:49 AM, Tim B=
ray wrote:

     =20
      Not deeply acquainted with the Flickr scenario, but it occurs to
      me to ask: If OAuth 1.0 is working well for them, why don=E2=80=99t th=
ey
      just keep using it?  I.e. if there=E2=80=99s already a good solut=
ion in
      place for people who require secure authn/authz over insecure
      channels, why would we go the extra work of duplicating that in
      OAuth 2 territory? -T

      On Fri, Feb 15, 2013 at 8:09 AM=
, William
        Mills <wmills_92105@yahoo.com>
        wrote:

              I'll repeat the use case for Flickr, which
                  requires OAuth 1.0a type capabilites that OAuth 2 does
                  not provide.  Simply stating "move to HTTPS" is not a=

                  viable response here.  

 From:=

                      Torsten Lodderstedt <torsten@lodderstedt.net>

                      To:
                      William Mills <wmills_92105@yahoo.com> 

                      Cc:
                      Mike Jones <Michael.Jones@microsoft.com>;
                      Justin Richer <jri=
cher@mitre.org>;
                      Phil Hunt <p=
hil.hunt@oracle.com>;
                      IETF oauth WG <oauth@iet=
f.org>

                      Sent:
                      Friday, February 15, 2013 7:22 AM

                      Subject:
                      Re: [OAUTH-WG] Minutes from the OAuth Design Team
                      Conference Call - 11th February 2013

                      Hi Bill,

                      I think one needs to compare the costs/impact
                        of HTTPS on one side and the implementation of
                        integrity protection and replay detection on the
                        other. We had this discussion several times.

                      regards,
                      Torsten.

                        Am 15.02.2013 um 08:08 schrieb William Mills
                        <wmill=
s_92105@yahoo.com>:

                            I fundamentally disagree with
                                that too.  OAuth 2 is the *framework*,
                                one which supports multiple token types.
                                 Bearer tokens were the first credentia=
l
                                type defined.

                              OAuth 1.0a also requires HTTPS
                                transport for authentication and getting
                                the token.

                            There
                                are  real use cases for tokens usable
                                over plain text with integrity
                                protection.

                              -bill

 From:
                                    Torsten Lodderstedt <torsten@lodderstedt.net>

                                    To:=

                                    William Mills <wmills_92105@yahoo.com>

                                    Cc:=

                                    Mike Jones <Michael.Jones@microsoft.com>;
                                    Justin Richer <jricher@mitre.org>;
                                    Phil Hunt <phil.hunt@oracle.com>;
                                    IETF oauth WG <oauth@ietf.org>

                                    Sen=
t:
                                    Thursday, February 14, 2013 10:05 PM
=

                                    Sub=
ject:
                                    Re: [OAUTH-WG] Minutes from the
                                    OAuth Design Team Conference Call -
                                    11th February 2013

                                    Hi Bill,

                                    OAuth 2.0 took a different
                                      direction by relying on HTTPS to
                                      provide the basic protection. So
                                      the need to have a token, which
                                      can be used for service requests
                                      over plain HTTP is arguable. My
                                      understanding of this activity
                                      was, the intend is to provide
                                      additional protection on top of
                                      HTTPS.

                                    regards,
                                    Torsten.

                                      Am 15.02.2013 um 02:31 schrieb
                                      William Mills <wmills_92105@yahoo.com>:

                                          I disagree with "That
                                              was the impediment to
                                              OAuth 1.0 adoption that
                                              OAuth 2.0 solved in the
                                              first place.", unless
                                              "solving" means does not
                                              address the need for it at
                                              all.

                                            OAuth
                                              2 does several good
                                              things, but it still lacks
                                              a defined token type that
                                              is safe to user over plain
                                              text HTTP.  1.0a solved
                                              that.

 From: Mike Jones <Michael.Jones@microsoft.com>

                                                  To:
                                                  Justin Richer <jricher@mitre.org>;
                                                  Phil Hunt <phil.hunt@oracle.com>

                                                  Cc:
                                                  IETF oauth WG <oauth@ietf.org>

                                                  Sent:
                                                  Thursday, February 14,
                                                  2013 1:44 PM

                                                  Subject:
                                                  Re: [OAUTH-WG] Minutes
                                                  from the OAuth Design
                                                  Team Conference Call -
                                                  11th February 2013

                                              I'm in favor of reusing
                                              the JWT work that this WG
                                              is also doing. :-)

                                              I'm pretty skeptical of us
                                              inventing another custom
                                              scheme for signing HTTP
                                              headers.  That was the
                                              impediment to OAuth 1.0
                                              adoption that OAuth 2.0
                                              solved in the first place.
=

                                                    =
;          -- Mike

                                              -----Original Message-----
=

                                              From: oauth-bounces@ietf.org
                                              [mailto:oauth-bounces@ietf.org]
                                              On Behalf Of Justin Richer
=

                                              Sent: Tuesday, February
                                              12, 2013 9:35 AM

                                              To: Phil Hunt

                                              Cc: IETF oauth WG

                                              Subject: Re: [OAUTH-WG]
                                              Minutes from the OAuth
                                              Design Team Conference
                                              Call - 11th February 2013

                                              That's my reading of it as
                                              well, Phil, thanks for
                                              providing the
                                              clarification. One
                                              motivator behind using a
                                              JSON-based token is to be
                                              able to re-use some of the
                                              great work that the JOSE
                                              group is doing but apply
                                              it to an HTTP payload.

                                              What neither of us want is
                                              a token type that requires
                                              stuffing all query,
                                              header, and other
                                              parameters *into* the JSON
                                              object itself, which would
                                              be a more SOAPy approach.

                                                -- Justin

                                              On 02/12/2013 12:30 PM,
                                              Phil Hunt wrote:

                                              > Clarification.  I
                                              think Justin and I were in
                                              agreement that we don't
                                              want to see a format that
                                              requires JSON payloads. 
                                              We are both interested in
                                              a JSON token used in the
                                              authorization header that
                                              could be based on a
                                              computed signature of some
                                              combination of http
                                              headers and body if
                                              possible.

                                              >

                                              > Phil

                                              >

                                              > @independentid

                                              > www.independentid.com

                                              > phil.hunt@oracle.com

                                              >

                                              >

                                              >

                                              >

                                              >

                                              > On 2013-02-12, at
                                              1:10 AM, Hannes Tschofenig
                                              wrote:

                                              >

                                              >> Here are my
                                              notes.

                                              >>

                                              >> Participants:

                                              >>

                                              >> * John Bradley

                                              >> * Derek Atkins

                                              >> * Phil Hunt

                                              >> * Prateek Mishra

                                              >> * Hannes
                                              Tschofenig

                                              >> * Mike Jones

                                              >> * Antonio Sanso

                                              >> * Justin Richer

                                              >>

                                              >> Notes:

                                              >>

                                              >> My slides are
                                              available here: 

                                              >> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
                                              >>

                                              >> Slide #2
                                              summarizes earlier
                                              discussions during the
                                              conference calls.

                                              >>

                                              >> -- HTTP vs. JSON

                                              >>

                                              >> Phil noted that
                                              he does not like to use
                                              the MAC Token draft as a
                                              starting point because it
                                              does not re-use any of the
                                              work done in the JOSE
                                              working group and in
                                              particular all the
                                              libraries that are
                                              available today. He
                                              mentioned that earlier
                                              attempts to write the MAC
                                              Token code lead to
                                              problems for implementers.
=

                                              >>

                                              >> Justin responded
                                              that he does not agree
                                              with using JSON as a
                                              transport mechanism since
                                              this would replicate a
                                              SOAP style.

                                              >>

                                              >> Phil noted that
                                              he wants to send JSON but
                                              the signature shall be
                                              computed over the HTTP
                                              header field.

                                              >>

                                              >> -- Flexibility
                                              for the keyed message
                                              digest computation

                                              >>

                                              >>  =46rom earlier
                                              discussion it was clear
                                              that the conference call
                                              participants wanted more
                                              flexibility regarding the
                                              keyed message digest
                                              computation. For this
                                              purpose Hannes presented
                                              the DKIM based approach,
                                              which allows selective
                                              header fields to be
                                              included in the digest.
                                              This is shown in slide #4.
=

                                              >>

                                              >> After some
                                              discussion the conference
                                              call participants thought
                                              that this would meet their
                                              needs. Further
                                              investigations would still
                                              be useful to determine the
                                              degree of failed HMAC
                                              calculations due to HTTP
                                              proxies modifying the
                                              content.

                                              >>

                                              >> -- Key
                                              Distribution

                                              >>

                                              >> Hannes presented
                                              the open issue regarding
                                              the choice of key 

                                              >> distribution.
                                              Slides #6-#8 present three
                                              techniques and Hannes
                                              asked 

                                              >> for feedback
                                              regarding the preferred
                                              style. Justin and others
                                              didn't 

                                              >> see the need to
                                              decide on one mechanism -
                                              they wanted to keep the 

                                              >> choice open.
                                              Derek indicated that this
                                              will not be an acceptable

                                              >> approach. Since
                                              the resource server and
                                              the authorization server
                                              may, 

                                              >> in the OAuth 2.0
                                              framework, be entities
                                              produced by different
                                              vendors 

                                              >> there is an
                                              interoperability need.
                                              Justin responded that he
                                              disagrees 

                                              >> and that the
                                              resource server needs to
                                              understand the access
                                              token and 

                                              >> referred to the
                                              recent draft submission
                                              for the token
                                              introspection 

                                              >> endpoint. Derek
                                              indicated that the
                                              resource server has to
                                              understand 

                                              >> the content of
                                              the access token and the
                                              token introspection
                                              endpoint 

                                              >> just pushes the
                                              problem around: the
                                              resource server has to
                                              send the 

                                              >> access token to
                                              the authorization server
                                              and then the resource
                                              server 

                                              >> gets the result
                                              back (which he the

                                              n

                                              >    a

                                              >> gain needs to
                                              understand) in order to
                                              make a meaningful
                                              authorization decision.

                                              >>

                                              >> Everyone agreed
                                              that the client must
                                              receive the session key
                                              from the authorization
                                              server and that this
                                              approach has to be
                                              standardized. It was also
                                              agreed that this is a
                                              common approach among all
                                              three key distribution
                                              mechanisms.

                                              >>

                                              >> Hannes asked the
                                              participants to think
                                              about their preference.

                                              >>

                                              >> The questions
                                              regarding key naming and
                                              the indication for the
                                              intended resource server
                                              the client wants to talk
                                              to have been postponed.

                                              >>

                                              >> Ciao

                                              >> Hannes

                                              >>

                                              >>

                                              >>
                                              ______________________________=
_________________

                                              >> OAuth mailing
                                              list

                                              >> OAuth@ietf.org

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

                                              >
                                              ______________________________=
_________________

                                              > OAuth mailing list

                                              > OAuth@ietf.org

                                              > https://ww=
w.ietf.org/mailman/listinfo/oauth

_______________________________________________

                                              OAuth mailing list

                                              OAu=
th@ietf.org

                                              https://www.iet=
f.org/mailman/listinfo/oauth

_______________________________________________

                                              OAuth mailing list

                                              OAu=
th@ietf.org

                                              https://www.iet=
f.org/mailman/listinfo/oauth

                                      ___________________________=
____________________

                                        OAuth mailing list

                                        OAu=
th@ietf.org

                                        https://www.iet=
f.org/mailman/listinfo/oauth

          _______________________________________________

          OAuth mailing list

          OAuth@ietf.org

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

      _______________________________________________
OAuth mailing list
OAu=
th@ietf.org
https://www.ietf.=
org/mailman/listinfo/oauth

    _______________________________________________
OAuth mailing list
OAu=
th@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
=
=

--Apple-Mail-2F9021E0-B6B0-475A-89C2-6C02AE340996--

From internet-drafts@ietf.org  Fri Feb 15 13:54:24 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3799F21F8589; Fri, 15 Feb 2013 13:54:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgIhUGXsZE46; Fri, 15 Feb 2013 13:54:23 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972D821E8034; Fri, 15 Feb 2013 13:54:23 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.40
Message-ID: <20130215215423.23019.50224.idtracker@ietfa.amsl.com>
Date: Fri, 15 Feb 2013 13:54:23 -0800
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Feb 2013 21:54:24 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Web Authorization Protocol Working Group =
of the IETF.

	Title           : OAuth Dynamic Client Registration Protocol
	Author(s)       : Justin Richer
                          John Bradley
                          Michael B. Jones
                          Maciej Machulak
	Filename        : draft-ietf-oauth-dyn-reg-06.txt
	Pages           : 21
	Date            : 2013-02-15

Abstract:
   This specification defines an endpoint and protocol for dynamic
   registration of OAuth Clients at an Authorization Server.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-06

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

From jricher@mitre.org  Fri Feb 15 13:57:41 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8898E21E8043 for ; Fri, 15 Feb 2013 13:57:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.572
X-Spam-Level: 
X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.026,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xVPusEIwVLi for ; Fri, 15 Feb 2013 13:57:39 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7601021F85B8 for ; Fri, 15 Feb 2013 13:57:39 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E25DA1F0709; Fri, 15 Feb 2013 16:57:38 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id AB6E21F02D3; Fri, 15 Feb 2013 16:57:38 -0500 (EST)
Received: from IMCMBX01.MITRE.ORG ([169.254.1.25]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0318.004; Fri, 15 Feb 2013 16:57:37 -0500
From: "Richer, Justin P." 
To: Phil Hunt 
Thread-Topic: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
Thread-Index: AQHOCUdbkfNDf0E+QESmDzChh9il6ph55eFggACTxoCAAEyKAIAAEZyAgACKBACAAA00gIAACwmA///zXjyAAGFPgIAAAXaA
Date: Fri, 15 Feb 2013 21:57:37 +0000
Message-ID: 
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net>  <511A7D27.8010209@mitre.org> <4E1F6AAD24975D4BA5B16804296739436744BD23@TK5EX14MBXC285.redmond.corp.microsoft.com> <1360891897.14004.YahooMailNeo@web31811.mail.mud.yahoo.com>  <1360912115.36543.YahooMailNeo@web31811.mail.mud.yahoo.com> <2A0F585F-2CEF-418D-9654-5084E6C9BD0D@lodderstedt.net> <1360944589.51724.YahooMailNeo@web31808.mail.mud.yahoo.com>  <511EA0A3.7080000@mitre.org> <1360962242.18571.YahooMailNeo@web31805.mail.mud.yahoo.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.15.65]
Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E06894B15IMCMBX01MITREOR_"
MIME-Version: 1.0
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Feb 2013 21:57:41 -0000

--_000_B33BFB58CCC8BE4998958016839DE27E06894B15IMCMBX01MITREOR_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

It's a pretty good shortcut to not have to deal with request tokens, to be =
able to use scopes, to have access to client assertions and other methods o=
f client auth, and not have to do signing when talking to the AS. It's no s=
hortcut when talking to the RS, that's for sure.

 -- Justin

On Feb 15, 2013, at 4:52 PM, Phil Hunt > wrote:

Sorry. I have to disagree. The way 1.0 is written, it is not a shortcut to =
turn it into a token for 2.

Phil

Sent from my phone.

On 2013-02-15, at 13:04, William Mills > wrote:

>I've brought it up before, but I think it might be worthwhile, at least as=
 an exercise, to define a method to get OAuth1-style tokens from an OAuth2 =
token endpoint. You'd defer to OAuth1 for how to use them >with a protected=
 resource.

YES!

________________________________
From: Justin Richer >
To: Tim Bray >
Cc: William Mills >; =
IETF oauth WG >
Sent: Friday, February 15, 2013 12:54 PM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call =
- 11th February 2013

So that you can fetch and manage all your tokens using the same code paths =
as the OAuth2 services. The "get a token" part will be identical to Oauth2 =
Bearer (except for some details of what comes back from the token endpoint,=
 of course), it's the "use a token" bit that really changes and is up in th=
e air. You get to use scopes, and state, and refresh tokens, and all the ot=
her good stuff.

I've brought it up before, but I think it might be worthwhile, at least as =
an exercise, to define a method to get OAuth1-style tokens from an OAuth2 t=
oken endpoint. You'd defer to OAuth1 for how to use them with a protected r=
esource.

 -- Justin

On 02/15/2013 11:49 AM, Tim Bray wrote:
Not deeply acquainted with the Flickr scenario, but it occurs to me to ask:=
 If OAuth 1.0 is working well for them, why don=92t they just keep using it=
?  I.e. if there=92s already a good solution in place for people who requir=
e secure authn/authz over insecure channels, why would we go the extra work=
 of duplicating that in OAuth 2 territory? -T

On Fri, Feb 15, 2013 at 8:09 AM, William Mills > wrote:
I'll repeat the use case for Flickr, which requires OAuth 1.0a type capabil=
ites that OAuth 2 does not provide.  Simply stating "move to HTTPS" is not =
a viable response here.

________________________________
From: Torsten Lodderstedt >
To: William Mills >
Cc: Mike Jones >; Justin Richer >; Phil Hu=
nt >; IETF oauth WG >
Sent: Friday, February 15, 2013 7:22 AM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call =
- 11th February 2013

Hi Bill,

I think one needs to compare the costs/impact of HTTPS on one side and the =
implementation of integrity protection and replay detection on the other. W=
e had this discussion several times.

regards,
Torsten.

Am 15.02.2013 um 08:08 schrieb William Mills >:

I fundamentally disagree with that too.  OAuth 2 is the *framework*, one wh=
ich supports multiple token types.  Bearer tokens were the first credential=
 type defined.

OAuth 1.0a also requires HTTPS transport for authentication and getting the=
 token.

There are  real use cases for tokens usable over plain text with integrity =
protection.

-bill

________________________________
From: Torsten Lodderstedt >
To: William Mills >
Cc: Mike Jones >; Justin Richer >; Phil Hu=
nt >; IETF oauth WG >
Sent: Thursday, February 14, 2013 10:05 PM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call =
- 11th February 2013

Hi Bill,

OAuth 2.0 took a different direction by relying on HTTPS to provide the bas=
ic protection. So the need to have a token, which can be used for service r=
equests over plain HTTP is arguable. My understanding of this activity was,=
 the intend is to provide additional protection on top of HTTPS.

regards,
Torsten.

Am 15.02.2013 um 02:31 schrieb William Mills >:

I disagree with "That was the impediment to OAuth 1.0 adoption that OAuth 2=
.0 solved in the first place.", unless "solving" means does not address the=
 need for it at all.

OAuth 2 does several good things, but it still lacks a defined token type t=
hat is safe to user over plain text HTTP.  1.0a solved that.

________________________________
From: Mike Jones >
To: Justin Richer >; Phil Hunt =
>
Cc: IETF oauth WG >
Sent: Thursday, February 14, 2013 1:44 PM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call =
- 11th February 2013

I'm in favor of reusing the JWT work that this WG is also doing. :-)

I'm pretty skeptical of us inventing another custom scheme for signing HTTP=
 headers.  That was the impediment to OAuth 1.0 adoption that OAuth 2.0 sol=
ved in the first place.

                -- Mike

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Justin Richer
Sent: Tuesday, February 12, 2013 9:35 AM
To: Phil Hunt
Cc: IETF oauth WG
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call =
- 11th February 2013

That's my reading of it as well, Phil, thanks for providing the clarificati=
on. One motivator behind using a JSON-based token is to be able to re-use s=
ome of the great work that the JOSE group is doing but apply it to an HTTP =
payload.

What neither of us want is a token type that requires stuffing all query, h=
eader, and other parameters *into* the JSON object itself, which would be a=
 more SOAPy approach.

  -- Justin

On 02/12/2013 12:30 PM, Phil Hunt wrote:
> Clarification.  I think Justin and I were in agreement that we don't want=
 to see a format that requires JSON payloads.  We are both interested in a =
JSON token used in the authorization header that could be based on a comput=
ed signature of some combination of http headers and body if possible.
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>
>
>
>
> On 2013-02-12, at 1:10 AM, Hannes Tschofenig wrote:
>
>> Here are my notes.
>>
>> Participants:
>>
>> * John Bradley
>> * Derek Atkins
>> * Phil Hunt
>> * Prateek Mishra
>> * Hannes Tschofenig
>> * Mike Jones
>> * Antonio Sanso
>> * Justin Richer
>>
>> Notes:
>>
>> My slides are available here:
>> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
>>
>> Slide #2 summarizes earlier discussions during the conference calls.
>>
>> -- HTTP vs. JSON
>>
>> Phil noted that he does not like to use the MAC Token draft as a startin=
g point because it does not re-use any of the work done in the JOSE working=
 group and in particular all the libraries that are available today. He men=
tioned that earlier attempts to write the MAC Token code lead to problems f=
or implementers.
>>
>> Justin responded that he does not agree with using JSON as a transport m=
echanism since this would replicate a SOAP style.
>>
>> Phil noted that he wants to send JSON but the signature shall be compute=
d over the HTTP header field.
>>
>> -- Flexibility for the keyed message digest computation
>>
>>  From earlier discussion it was clear that the conference call participa=
nts wanted more flexibility regarding the keyed message digest computation.=
 For this purpose Hannes presented the DKIM based approach, which allows se=
lective header fields to be included in the digest. This is shown in slide =
#4.
>>
>> After some discussion the conference call participants thought that this=
 would meet their needs. Further investigations would still be useful to de=
termine the degree of failed HMAC calculations due to HTTP proxies modifyin=
g the content.
>>
>> -- Key Distribution
>>
>> Hannes presented the open issue regarding the choice of key
>> distribution. Slides #6-#8 present three techniques and Hannes asked
>> for feedback regarding the preferred style. Justin and others didn't
>> see the need to decide on one mechanism - they wanted to keep the
>> choice open. Derek indicated that this will not be an acceptable
>> approach. Since the resource server and the authorization server may,
>> in the OAuth 2.0 framework, be entities produced by different vendors
>> there is an interoperability need. Justin responded that he disagrees
>> and that the resource server needs to understand the access token and
>> referred to the recent draft submission for the token introspection
>> endpoint. Derek indicated that the resource server has to understand
>> the content of the access token and the token introspection endpoint
>> just pushes the problem around: the resource server has to send the
>> access token to the authorization server and then the resource server
>> gets the result back (which he the
n
>    a
>> gain needs to understand) in order to make a meaningful authorization de=
cision.
>>
>> Everyone agreed that the client must receive the session key from the au=
thorization server and that this approach has to be standardized. It was al=
so agreed that this is a common approach among all three key distribution m=
echanisms.
>>
>> Hannes asked the participants to think about their preference.
>>
>> The questions regarding key naming and the indication for the intended r=
esource server the client wants to talk to have been postponed.
>>
>> 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

_______________________________________________
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

--_000_B33BFB58CCC8BE4998958016839DE27E06894B15IMCMBX01MITREOR_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <684CB53426101046A1ACED8721CA0731@imc.mitre.org>
Content-Transfer-Encoding: quoted-printable

It's a pretty good shortcut to not have to deal with request tokens, to be =
able to use scopes, to have access to client assertions and other methods o=
f client auth, and not have to do signing when talking to the AS. It's no s=
hortcut when talking to the RS,
 that's for sure.

 -- Justin

On Feb 15, 2013, at 4:52 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Sorry. I have to disagree. The way 1.0 is written, it is not a shortcu=
t to turn it into a token for 2. 

Phil

Sent from my phone.

On 2013-02-15, at 13:04, William Mills <wmills_92105@yahoo.com> wrote:

>I've brought it up before, but I think it might be worthwhile=
, at least as an exercise, to define a method to get OAuth1-style tokens fr=
om an OAuth2 token endpoint. You'd defer
 to OAuth1 for how to use them >with a protected resource.

From: Justin Richer <jricher@mitre.org>

To: Tim Bray <twbray@google.com>

Cc: William Mills <wmills_92105@yahoo.com>; IETF =
oauth WG <oauth@ietf.org>

Sent: Friday, February 15,=
 2013 12:54 PM

Subject: Re: [OAUTH-WG] Mi=
nutes from the OAuth Design Team Conference Call - 11th February 2013

So that you can fetch and manage all your tokens using the same code p=
aths as the OAuth2 services. The "get a token" part will be ident=
ical to Oauth2 Bearer (except for some details of what comes back from the =
token endpoint, of course), it's the "use
 a token" bit that really changes and is up in the air. You get to use=
 scopes, and state, and refresh tokens, and all the other good stuff.

I've brought it up before, but I think it might be worthwhile, at least as =
an exercise, to define a method to get OAuth1-style tokens from an OAuth2 t=
oken endpoint. You'd defer to OAuth1 for how to use them with a protected r=
esource.

 -- Justin

On 02/15/2013 11:49 AM, Tim Bray=
 wrote:

Not deeply acquainted with the Flickr scenario, b=
ut it occurs to me to ask: If OAuth 1.0 is working well for them, why don=
=92t they just keep using it?  I.e. if there=92s already a good soluti=
on in place for people who require secure authn/authz
 over insecure channels, why would we go the extra work of duplicating that=
 in OAuth 2 territory? -T

On Fri, Feb 15, 2013 at 8:09 AM, Wil=
liam Mills
<wmills_92=
105@yahoo.com> wrote:

I'll repeat the use case for Flickr, which requires OAuth 1.0a t=
ype capabilites that OAuth 2 does not provide.  Simply stating "m=
ove to HTTPS" is not a viable response here.  

From: Torsten Lodderstedt &=
lt;torsten@lodderstedt.net>

To: William Mills <wmills_92105@yahoo.com>

Cc: Mike Jones <Michael.Jones@microsoft.com=
>; Justin Richer <jricher@mitre=
.org>;
 Phil Hunt <phil.hunt@oracle.com=
>; IETF oauth WG <oauth@ietf.org&=
gt;

Sent: Friday, February 15, =
2013 7:22 AM

Subject: Re: [OAUTH-WG] Min=
utes from the OAuth Design Team Conference Call - 11th February 2013

Hi Bill,

I think one needs to compare the costs/impact of HTTPS on one side and=
 the implementation of integrity protection and replay detection on the oth=
er. We had this discussion several times.

regards,
Torsten.

Am 15.02.2013 um 08:08 schrieb William Mills <wmills_92105@yahoo.com>:

I fundamentally disagree with that too.  OAuth 2 is the *fr=
amework*, one which supports multiple token types.  Bearer tokens were=
 the first credential type defined.

From: Torsten Lodderstedt &=
lt;torsten@lodderstedt.net>

To: William Mills <wmills_92105@yahoo.com>

Cc: Mike Jones <Michael.Jones@microsoft.com=
>; Justin Richer <jricher@mitre=
.org>;
 Phil Hunt <phil.hunt@oracle.com=
>; IETF oauth WG <oauth@ietf.org&=
gt;

Sent: Thursday, February 14=
, 2013 10:05 PM

Subject: Re: [OAUTH-WG] Min=
utes from the OAuth Design Team Conference Call - 11th February 2013

Hi Bill,

OAuth 2.0 took a different direction by relying on HTTPS to provide th=
e basic protection. So the need to have a token, which can be used for serv=
ice requests over plain HTTP is arguable. My understanding of this activity=
 was, the intend is to provide additional
 protection on top of HTTPS.

regards,
Torsten.

Am 15.02.2013 um 02:31 schrieb William Mills <wmills_92105@yahoo.com>:

I disagree with "That was the impediment to OAuth 1.0 adoption
 that OAuth 2.0 solved in the first place.", unless "solving"=
; means does not address the need for it at all.

OAuth 2 does several good things, but it still lacks a defined toke=
n type that
 is safe to user over plain text HTTP.  1.0a solved that.

From: Mike Jones <Michael.Jones@microsoft.com=
>

To: Justin Richer <jricher@mitre.org>; Phil Hunt <phil.hunt@oracle.com>

Cc: IETF oauth WG <oauth@ietf.org>

Sent: Thursday, February 14=
, 2013 1:44 PM

Subject: Re: [OAUTH-WG] Min=
utes from the OAuth Design Team Conference Call - 11th February 2013

I'm in favor of reusing the JWT work that this WG is also doing. :-)

I'm pretty skeptical of us inventing another custom scheme for signing HTTP=
 headers.  That was the impediment to OAuth 1.0 adoption that OAuth 2.=
0 solved in the first place.

               =
 -- Mike

-----Original Message-----

From: 
oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer

Sent: Tuesday, February 12, 2013 9:35 AM

To: Phil Hunt

Cc: IETF oauth WG

Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call =
- 11th February 2013

That's my reading of it as well, Phil, thanks for providing the clarificati=
on. One motivator behind using a JSON-based token is to be able to re-use s=
ome of the great work that the JOSE group is doing but apply it to an HTTP =
payload.

What neither of us want is a token type that requires stuffing all query, h=
eader, and other parameters *into* the JSON object itself, which would be a=
 more SOAPy approach.

  -- Justin

On 02/12/2013 12:30 PM, Phil Hunt wrote:

> Clarification.  I think Justin and I were in agreement that we do=
n't want to see a format that requires JSON payloads.  We are both int=
erested in a JSON token used in the authorization header that could be base=
d on a computed signature of some combination
 of http headers and body if possible.

>

> Phil

>

> @independentid

> www.independentid.com

> 
phil.hunt@oracle.com

>

>

>

>

>

> On 2013-02-12, at 1:10 AM, Hannes Tschofenig wrote:

>

>> Here are my notes.

>>

>> Participants:

>>

>> * John Bradley

>> * Derek Atkins

>> * Phil Hunt

>> * Prateek Mishra

>> * Hannes Tschofenig

>> * Mike Jones

>> * Antonio Sanso

>> * Justin Richer

>>

>> Notes:

>>

>> My slides are available here: 

>> 
http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt

>>

>> Slide #2 summarizes earlier discussions during the conference call=
s.

>>

>> -- HTTP vs. JSON

>>

>> Phil noted that he does not like to use the MAC Token draft as a s=
tarting point because it does not re-use any of the work done in the JOSE w=
orking group and in particular all the libraries that are available today. =
He mentioned that earlier attempts to
 write the MAC Token code lead to problems for implementers.

>>

>> Justin responded that he does not agree with using JSON as a trans=
port mechanism since this would replicate a SOAP style.

>>

>> Phil noted that he wants to send JSON but the signature shall be c=
omputed over the HTTP header field.

>>

>> -- Flexibility for the keyed message digest computation

>>

>>  From earlier discussion it was clear that the conference cal=
l participants wanted more flexibility regarding the keyed message digest c=
omputation. For this purpose Hannes presented the DKIM based approach, whic=
h allows selective header fields to be included
 in the digest. This is shown in slide #4.

>>

>> After some discussion the conference call participants thought tha=
t this would meet their needs. Further investigations would still be useful=
 to determine the degree of failed HMAC calculations due to HTTP proxies mo=
difying the content.

>>

>> -- Key Distribution

>>

>> Hannes presented the open issue regarding the choice of key 

>> distribution. Slides #6-#8 present three techniques and Hannes ask=
ed 

>> for feedback regarding the preferred style. Justin and others didn=
't 

>> see the need to decide on one mechanism - they wanted to keep the =

>> choice open. Derek indicated that this will not be an acceptable <=
br>
>> approach. Since the resource server and the authorization server m=
ay, 

>> in the OAuth 2.0 framework, be entities produced by different vend=
ors 

>> there is an interoperability need. Justin responded that he disagr=
ees 

>> and that the resource server needs to understand the access token =
and 

>> referred to the recent draft submission for the token introspectio=
n 

>> endpoint. Derek indicated that the resource server has to understa=
nd 

>> the content of the access token and the token introspection endpoi=
nt 

>> just pushes the problem around: the resource server has to send th=
e 

>> access token to the authorization server and then the resource ser=
ver 

>> gets the result back (which he the

n

>    a

>> gain needs to understand) in order to make a meaningful authorizat=
ion decision.

>>

>> Everyone agreed that the client must receive the session key from =
the authorization server and that this approach has to be standardized. It =
was also agreed that this is a common approach among all three key distribu=
tion mechanisms.

>>

>> Hannes asked the participants to think about their preference.

>>

>> The questions regarding key naming and the indication for the inte=
nded resource server the client wants to talk to have been postponed.

>>

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

_______________________________________________

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.iet=
f.org/mailman/listinfo/oauth

___________________________________________=
____

OAuth mailing list

OAuth@ietf.org

https://www.i=
etf.org/mailman/listinfo/oauth

--_000_B33BFB58CCC8BE4998958016839DE27E06894B15IMCMBX01MITREOR_--

From jricher@mitre.org  Fri Feb 15 14:00:31 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0940B21E803C; Fri, 15 Feb 2013 14:00:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.573
X-Spam-Level: 
X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhKY+iK7h5FU; Fri, 15 Feb 2013 14:00:30 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 434A521E8034; Fri, 15 Feb 2013 14:00:30 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 608261F070A; Fri, 15 Feb 2013 17:00:29 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id EA7E953111EA; Fri, 15 Feb 2013 17:00:28 -0500 (EST)
Received: from IMCMBX01.MITRE.ORG ([169.254.1.25]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0318.004; Fri, 15 Feb 2013 17:00:28 -0500
From: "Richer, Justin P." 
To: "internet-drafts@ietf.org" 
Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
Thread-Index: AQHOC8cHzYfMM+l930eNScmFnnKSo5h7y/2A
Date: Fri, 15 Feb 2013 22:00:27 +0000
Message-ID: 
References: <20130215215423.23019.50224.idtracker@ietfa.amsl.com>
In-Reply-To: <20130215215423.23019.50224.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.15.65]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8C5D61CC699F3741839821932792E7C8@imc.mitre.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" , "" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Feb 2013 22:00:31 -0000

Everyone, there's a new draft of DynReg up on the tracker. This draft tries=
 to codify the discussions so far from this week into something we can all =
read. There are still plenty of open discussion points and items up for deb=
ate. Please read through this latest draft and see what's changed and help =
assure that it properly captures the conversations. If you have any inputs =
for the marked [[ Editor's Note ]] sections, please send them to the list b=
y next Thursday to give me opportunity to get any necessary changes in by t=
he cutoff date of Monday the 22nd.

Thanks for all of your hard work everyone, I think this is *really* coming =
along now.

 -- Justin

On Feb 15, 2013, at 4:54 PM, internet-drafts@ietf.org wrote:

>=20
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
> This draft is a work item of the Web Authorization Protocol Working Group=
 of the IETF.
>=20
> 	Title           : OAuth Dynamic Client Registration Protocol
> 	Author(s)       : Justin Richer
>                          John Bradley
>                          Michael B. Jones
>                          Maciej Machulak
> 	Filename        : draft-ietf-oauth-dyn-reg-06.txt
> 	Pages           : 21
> 	Date            : 2013-02-15
>=20
> Abstract:
>   This specification defines an endpoint and protocol for dynamic
>   registration of OAuth Clients at an Authorization Server.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06
>=20
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-06
>=20
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From sberyozkin@gmail.com  Fri Feb 15 14:10:08 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D1521F84BB for ; Fri, 15 Feb 2013 14:10:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.386
X-Spam-Level: 
X-Spam-Status: No, score=-3.386 tagged_above=-999 required=5 tests=[AWL=0.213,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQ65pH2-2RX8 for ; Fri, 15 Feb 2013 14:10:06 -0800 (PST)
Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB3721F848B for ; Fri, 15 Feb 2013 14:10:06 -0800 (PST)
Received: by mail-wg0-f52.google.com with SMTP id 12so3094389wgh.31 for ; Fri, 15 Feb 2013 14:10:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hlJObRsrSbeR4oEzzPP3INAxEnzGzzstM16CQiQFmtw=; b=n7pJp85t5G8WiiqNzysIEWl3ucV7eSGGc7ipe2/gaM1PqkPIeDtg9OVRnsTzOmCr/6 k1SEXNJs2WSncMd0nt551gz4xWPBu0eZKrivkmfhJTj+z+K5UXpjDTIkLpsRpLky7YR3 zzPERY0Tlh82sK7AiPuJB8Rm3Lkd9NJWGFawz/Sj5mNC8kjD/hSGx+JQbtocTu95Fi/h EtW6ULx8PVJ/IELT4m1ONufNlk6PRHBl95yJT2IsPc/VJlatgtrCx33T3yRaKfR8eBnv gBmpFIpUpOCdh7olZmSZ0iIu/tHAt1LX0DD0qCkDEeDuviigfjO0kBHI4Y2dcfm32cBL XnDQ==
X-Received: by 10.180.102.164 with SMTP id fp4mr6913861wib.1.1360966205423; Fri, 15 Feb 2013 14:10:05 -0800 (PST)
Received: from [192.168.2.5] ([89.100.138.67]) by mx.google.com with ESMTPS id du2sm7307344wib.0.2013.02.15.14.10.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Feb 2013 14:10:04 -0800 (PST)
Message-ID: <511EB23A.8000307@gmail.com>
Date: Fri, 15 Feb 2013 22:10:02 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: William Mills 
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net>  <511A7D27.8010209@mitre.org> <4E1F6AAD24975D4BA5B16804296739436744BD23@TK5EX14MBXC285.redmond.corp.microsoft.com> <1360891897.14004.YahooMailNeo@web31811.mail.mud.yahoo.com>  <1360912115.36543.YahooMailNeo@web31811.mail.mud.yahoo.com> <2A0F585F-2CEF-418D-9654-5084E6C9BD0D@lodderstedt.net> <1360944589.51724.YahooMailNeo@web31808.mail.mud.yahoo.com> <511E617A.4000302@gmail.com> <1360952953.58617.YahooMailNeo@web31804.mail.mud.yahoo.com>
In-Reply-To: <1360952953.58617.YahooMailNeo@web31804.mail.mud.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Feb 2013 22:10:08 -0000

HI,
On 15/02/13 18:29, William Mills wrote:
> At this point I am more in favor converting the MAC token format to JWT
> and getting the signature envelope added that way. It's really a matter
> of time.
>
> MAC stalled because folks see the HOK tokens as a replacement.
>
> It's also been a matter of Justin and I having the time to take it up again.
>
Sure, thanks for the above info, as I've said before I'm ultimately fine 
with having MAC supported just in our implementation for example, and 
let those users who decide to use know that they actually write a 
compliant OAuth2 code - but not inter-operable unless some other stack 
does it too...Interoperability may not be highly important in some cases 
too, so...

Ultimately whatever the experts decide upon will be good I guess, the 
question will remain though if dropping MAC will help with avoiding 
having N- number of OAuth(s) variants - it appears the sentiment is 
quite strong in oAuth1 community toward this style MAC kind of replicates.

Thanks, Sergey

>
> ------------------------------------------------------------------------
> *From:* Sergey Beryozkin 
> *To:* oauth@ietf.org
> *Sent:* Friday, February 15, 2013 8:25 AM
> *Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference
> Call - 11th February 2013
>
> I wonder why it is proving so difficult to get a nearly completed MAC
> draft completed ?
> Is it because:
> 1. JWT was first in OAuth2 and thus it wins ?
> 2. MAC is not 'capable' enough as JWT is ?
> 3. Not enough motivation for some vendors to push MAC ?
>
> Example, in cases where not a product but a development framework is
> shipped (as with us for example), IMHO is it a big motivation to get MAC
> done for the reasons repeated many times. Or in case of migrating Flickr
> users to OAuth2.
> I think I can see why no interest is there where nothing is really
> achieved if JWT is used from the get go, no particular need to get OAuth
> 1.0 developers out there migrating to the particular products.
>
> This is 3. Re 2, I think there was enough expressed to suggest that it
> can complement JWT nicely. So far I'm inclined to think it is 3. and 2.
> which stop it from being completed, with 3. 'contributing' indirectly
> but significantly,
>
> Just my 2c
> Thanks, Sergey
>
>
> On 15/02/13 16:09, William Mills wrote:
>  > I'll repeat the use case for Flickr, which requires OAuth 1.0a type
>  > capabilites that OAuth 2 does not provide. Simply stating "move to
>  > HTTPS" is not a viable response here.
>  >
>  > ------------------------------------------------------------------------
>  > *From:* Torsten Lodderstedt  >
>  > *To:* William Mills  >
>  > *Cc:* Mike Jones  >; Justin Richer
>  > >; Phil Hunt
> >; IETF oauth WG
>  > >
>  > *Sent:* Friday, February 15, 2013 7:22 AM
>  > *Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference
>  > Call - 11th February 2013
>  >
>  > Hi Bill,
>  >
>  > I think one needs to compare the costs/impact of HTTPS on one side and
>  > the implementation of integrity protection and replay detection on the
>  > other. We had this discussion several times.
>  >
>  > regards,
>  > Torsten.
>  >
>  > Am 15.02.2013 um 08:08 schrieb William Mills  
>  > >>:
>  >
>  >> I fundamentally disagree with that too. OAuth 2 is the *framework*,
>  >> one which supports multiple token types. Bearer tokens were the first
>  >> credential type defined.
>  >>
>  >> OAuth 1.0a also requires HTTPS transport for authentication and
>  >> getting the token.
>  >>
>  >> There are real use cases for tokens usable over plain text with
>  >> integrity protection.
>  >>
>  >> -bill
>  >>
>  >> ------------------------------------------------------------------------
>  >> *From:* Torsten Lodderstedt  
>  >> >>
>  >> *To:* William Mills  
>  >> >>
>  >> *Cc:* Mike Jones  
>  >>  >>; Justin Richer
>  >> 
> >>; Phil Hunt
>  >> 
> >>; IETF oauth WG
>  >>   >>
>  >> *Sent:* Thursday, February 14, 2013 10:05 PM
>  >> *Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team
>  >> Conference Call - 11th February 2013
>  >>
>  >> Hi Bill,
>  >>
>  >> OAuth 2.0 took a different direction by relying on HTTPS to provide
>  >> the basic protection. So the need to have a token, which can be used
>  >> for service requests over plain HTTP is arguable. My understanding of
>  >> this activity was, the intend is to provide additional protection on
>  >> top of HTTPS.
>  >>
>  >> regards,
>  >> Torsten.
>  >>
>  >> Am 15.02.2013 um 02:31 schrieb William Mills  
>  >> >>:
>  >>
>  >>> I disagree with "That was the impediment to OAuth 1.0 adoption that
>  >>> OAuth 2.0 solved in the first place.", unless "solving" means does
>  >>> not address the need for it at all.
>  >>>
>  >>> OAuth 2 does several good things, but it still lacks a defined token
>  >>> type that is safe to user over plain text HTTP. 1.0a solved that.
>  >>>
>  >>>
> ------------------------------------------------------------------------
>  >>> *From:* Mike Jones  
>  >>>  >>
>  >>> *To:* Justin Richer 
> >>;
>  >>> Phil Hunt 
> >>
>  >>> *Cc:* IETF oauth WG 
> >>
>  >>> *Sent:* Thursday, February 14, 2013 1:44 PM
>  >>> *Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team
>  >>> Conference Call - 11th February 2013
>  >>>
>  >>> I'm in favor of reusing the JWT work that this WG is also doing. :-)
>  >>>
>  >>> I'm pretty skeptical of us inventing another custom scheme for
>  >>> signing HTTP headers. That was the impediment to OAuth 1.0 adoption
>  >>> that OAuth 2.0 solved in the first place.
>  >>>
>  >>> -- Mike
>  >>>
>  >>> -----Original Message-----
>  >>> From: oauth-bounces@ietf.org 
> >
>  >>> [mailto:oauth-bounces@ietf.org 
> >] On
>  >>> Behalf Of Justin Richer
>  >>> Sent: Tuesday, February 12, 2013 9:35 AM
>  >>> To: Phil Hunt
>  >>> Cc: IETF oauth WG
>  >>> Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference
>  >>> Call - 11th February 2013
>  >>>
>  >>> That's my reading of it as well, Phil, thanks for providing the
>  >>> clarification. One motivator behind using a JSON-based token is to be
>  >>> able to re-use some of the great work that the JOSE group is doing
>  >>> but apply it to an HTTP payload.
>  >>>
>  >>> What neither of us want is a token type that requires stuffing all
>  >>> query, header, and other parameters *into* the JSON object itself,
>  >>> which would be a more SOAPy approach.
>  >>>
>  >>> -- Justin
>  >>>
>  >>> On 02/12/2013 12:30 PM, Phil Hunt wrote:
>  >>> > Clarification. I think Justin and I were in agreement that we don't
>  >>> want to see a format that requires JSON payloads. We are both
>  >>> interested in a JSON token used in the authorization header that
>  >>> could be based on a computed signature of some combination of http
>  >>> headers and body if possible.
>  >>> >
>  >>> > Phil
>  >>> >
>  >>> > @independentid
>  >>> > www.independentid.com 
>  >>> > phil.hunt@oracle.com 
> >
>  >>> >
>  >>> >
>  >>> >
>  >>> >
>  >>> >
>  >>> > On 2013-02-12, at 1:10 AM, Hannes Tschofenig wrote:
>  >>> >
>  >>> >> Here are my notes.
>  >>> >>
>  >>> >> Participants:
>  >>> >>
>  >>> >> * John Bradley
>  >>> >> * Derek Atkins
>  >>> >> * Phil Hunt
>  >>> >> * Prateek Mishra
>  >>> >> * Hannes Tschofenig
>  >>> >> * Mike Jones
>  >>> >> * Antonio Sanso
>  >>> >> * Justin Richer
>  >>> >>
>  >>> >> Notes:
>  >>> >>
>  >>> >> My slides are available here:
>  >>> >> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
>  >>> >>
>  >>> >> Slide #2 summarizes earlier discussions during the conference calls.
>  >>> >>
>  >>> >> -- HTTP vs. JSON
>  >>> >>
>  >>> >> Phil noted that he does not like to use the MAC Token draft as a
>  >>> starting point because it does not re-use any of the work done in the
>  >>> JOSE working group and in particular all the libraries that are
>  >>> available today. He mentioned that earlier attempts to write the MAC
>  >>> Token code lead to problems for implementers.
>  >>> >>
>  >>> >> Justin responded that he does not agree with using JSON as a
>  >>> transport mechanism since this would replicate a SOAP style.
>  >>> >>
>  >>> >> Phil noted that he wants to send JSON but the signature shall be
>  >>> computed over the HTTP header field.
>  >>> >>
>  >>> >> -- Flexibility for the keyed message digest computation
>  >>> >>
>  >>> >> From earlier discussion it was clear that the conference call
>  >>> participants wanted more flexibility regarding the keyed message
>  >>> digest computation. For this purpose Hannes presented the DKIM based
>  >>> approach, which allows selective header fields to be included in the
>  >>> digest. This is shown in slide #4.
>  >>> >>
>  >>> >> After some discussion the conference call participants thought
>  >>> that this would meet their needs. Further investigations would still
>  >>> be useful to determine the degree of failed HMAC calculations due to
>  >>> HTTP proxies modifying the content.
>  >>> >>
>  >>> >> -- Key Distribution
>  >>> >>
>  >>> >> Hannes presented the open issue regarding the choice of key
>  >>> >> distribution. Slides #6-#8 present three techniques and Hannes asked
>  >>> >> for feedback regarding the preferred style. Justin and others didn't
>  >>> >> see the need to decide on one mechanism - they wanted to keep the
>  >>> >> choice open. Derek indicated that this will not be an acceptable
>  >>> >> approach. Since the resource server and the authorization server
> may,
>  >>> >> in the OAuth 2.0 framework, be entities produced by different
> vendors
>  >>> >> there is an interoperability need. Justin responded that he
> disagrees
>  >>> >> and that the resource server needs to understand the access
> token and
>  >>> >> referred to the recent draft submission for the token introspection
>  >>> >> endpoint. Derek indicated that the resource server has to understand
>  >>> >> the content of the access token and the token introspection endpoint
>  >>> >> just pushes the problem around: the resource server has to send the
>  >>> >> access token to the authorization server and then the resource
> server
>  >>> >> gets the result back (which he the
>  >>> n
>  >>> > a
>  >>> >> gain needs to understand) in order to make a meaningful
>  >>> authorization decision.
>  >>> >>
>  >>> >> Everyone agreed that the client must receive the session key from
>  >>> the authorization server and that this approach has to be
>  >>> standardized. It was also agreed that this is a common approach among
>  >>> all three key distribution mechanisms.
>  >>> >>
>  >>> >> Hannes asked the participants to think about their preference.
>  >>> >>
>  >>> >> The questions regarding key naming and the indication for the
>  >>> intended resource server the client wants to talk to have been
> postponed.
>  >>> >>
>  >>> >> 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
>  >>>
>  >>>
>  >>> _______________________________________________
>  >>> 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
>
>

From Michael.Jones@microsoft.com  Fri Feb 15 14:15:47 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A3221E804B; Fri, 15 Feb 2013 14:15:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.585
X-Spam-Level: 
X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0Zx+4-VTdPg; Fri, 15 Feb 2013 14:15:47 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.25]) by ietfa.amsl.com (Postfix) with ESMTP id 319E521E8045; Fri, 15 Feb 2013 14:15:47 -0800 (PST)
Received: from BY2FFO11FD016.protection.gbl (10.1.15.201) by BY2FFO11HUB024.protection.gbl (10.1.14.138) with Microsoft SMTP Server (TLS) id 15.0.620.12; Fri, 15 Feb 2013 22:15:43 +0000
Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD016.mail.protection.outlook.com (10.1.14.148) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Fri, 15 Feb 2013 22:15:43 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.96]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Fri, 15 Feb 2013 22:15:12 +0000
From: Mike Jones 
To: "Richer, Justin P." , "internet-drafts@ietf.org" 
Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
Thread-Index: AQHOC8cMkbohP5vU0EO7eTLi/U/hMJh7eCuAgAAEDkA=
Date: Fri, 15 Feb 2013 22:15:11 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943674642E2@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <20130215215423.23019.50224.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.70]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464002)(51704002)(377424002)(377454001)(52604002)(69224001)(24454001)(65554002)(44976002)(74662001)(15202345001)(74502001)(76482001)(31966008)(33656001)(5343655001)(56816002)(20776003)(47446002)(66066001)(54316002)(56776001)(49866001)(47736001)(50466001)(47976001)(16406001)(59766001)(77982001)(79102001)(50986001)(65816001)(80022001)(51856001)(55846006)(4396001)(46102001)(23726001)(46406002)(63696002)(53806001)(54356001)(47776003); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB024; H:TK5EX14MLTC104.redmond.corp.microsoft.com; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07584EDBCD
Cc: "" , "" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Feb 2013 22:15:48 -0000

+1

Thanks for doing this, Justin!

				-- Mike

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of R=
icher, Justin P.
Sent: Friday, February 15, 2013 2:00 PM
To: internet-drafts@ietf.org
Cc: ; 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

Everyone, there's a new draft of DynReg up on the tracker. This draft tries=
 to codify the discussions so far from this week into something we can all =
read. There are still plenty of open discussion points and items up for deb=
ate. Please read through this latest draft and see what's changed and help =
assure that it properly captures the conversations. If you have any inputs =
for the marked [[ Editor's Note ]] sections, please send them to the list b=
y next Thursday to give me opportunity to get any necessary changes in by t=
he cutoff date of Monday the 22nd.

Thanks for all of your hard work everyone, I think this is *really* coming =
along now.

 -- Justin

On Feb 15, 2013, at 4:54 PM, internet-drafts@ietf.org wrote:

>=20
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
> This draft is a work item of the Web Authorization Protocol Working Group=
 of the IETF.
>=20
> 	Title           : OAuth Dynamic Client Registration Protocol
> 	Author(s)       : Justin Richer
>                          John Bradley
>                          Michael B. Jones
>                          Maciej Machulak
> 	Filename        : draft-ietf-oauth-dyn-reg-06.txt
> 	Pages           : 21
> 	Date            : 2013-02-15
>=20
> Abstract:
>   This specification defines an endpoint and protocol for dynamic
>   registration of OAuth Clients at an Authorization Server.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06
>=20
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-06
>=20
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> 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

From donald.coffin@reminetworks.com  Fri Feb 15 18:03:41 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F181821F85E7 for ; Fri, 15 Feb 2013 18:03:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.199
X-Spam-Level: 
X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=1.400,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jg7lXblxxu6x for ; Fri, 15 Feb 2013 18:03:39 -0800 (PST)
Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 4D1CB21F8573 for ; Fri, 15 Feb 2013 18:03:39 -0800 (PST)
Received: (qmail 10308 invoked by uid 0); 16 Feb 2013 02:03:14 -0000
Received: from unknown (HELO host125.hostmonster.com) (74.220.207.125) by oproxy12.bluehost.com with SMTP; 16 Feb 2013 02:03:14 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default;  h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=s/ywkdlWX64xedV52sBJv1lNJgTcrYILCSmnuD25XFU=;  b=F6QyZO8AHsnCsFhKEyMQbGlfQ9sYGiKHFty+BjEFr6+Cpo1Ww6LAN6lOcU8cHtecxVUO7agIK2SaKA2A6xg5g5x8JAzEYez6ohiH7J1dVyGsR0v46Mk4FOjl1z6glXcQ;
Received: from [68.4.207.246] (port=6775 helo=HPPavilionElite) by host125.hostmonster.com with esmtpa (Exim 4.80) (envelope-from ) id 1U6X7S-0008Ey-Gp; Fri, 15 Feb 2013 19:03:14 -0700
From: "Donald F Coffin" 
To: , 
References: <20130215215423.23019.50224.idtracker@ietfa.amsl.com>
In-Reply-To: <20130215215423.23019.50224.idtracker@ietfa.amsl.com>
Date: Fri, 15 Feb 2013 18:01:09 -0800
Message-ID: <00b601ce0be9$7d4fa460$77eeed20$@reminetworks.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJR1evIYzX2Fhgoge99d7m6DWb3sZd0JhXA
Content-Language: en-us
X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.4.207.246 authed with donald.coffin@reminetworks.com}
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Feb 2013 02:03:41 -0000

Justin,

Section 5.1 of RFC6749 "OAuth 2.0 Authorization Framework" states:

	"The authorization server MUST include the HTTP "Cache-Control"
  	 response header field [RFC2616] with a value of "no-store" in any
   	response containing tokens, credentials, or other sensitive
   	information, as well as the "Pragma" response header field [RFC2616]
   	with a value of "no-cache"."

I've noticed several of the response examples in the current and =
previous versions of "draft-ietf-oauth-dyn-reg-xx.txt" fail to include =
the required "Pragma: "no-cache" directive.  I assume this is an =
oversight and am merely pointing out that it needs to be included.

Best regards,
Don
Donald F. Coffin
Founder/CTO

REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA  92688-3836

Phone:      (949) 636-8571
Email:       donald.coffin@reminetworks.com

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20
Sent: Friday, February 15, 2013 1:54 PM
To: i-d-announce@ietf.org
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
 This draft is a work item of the Web Authorization Protocol Working =
Group of the IETF.

	Title           : OAuth Dynamic Client Registration Protocol
	Author(s)       : Justin Richer
                          John Bradley
                          Michael B. Jones
                          Maciej Machulak
	Filename        : draft-ietf-oauth-dyn-reg-06.txt
	Pages           : 21
	Date            : 2013-02-15

Abstract:
   This specification defines an endpoint and protocol for dynamic
   registration of OAuth Clients at an Authorization Server.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-06

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

From wmills_92105@yahoo.com  Fri Feb 15 22:02:55 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1BE21F841F for ; Fri, 15 Feb 2013 22:02:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.165
X-Spam-Level: 
X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.433,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9Nk70G26Ilg for ; Fri, 15 Feb 2013 22:02:53 -0800 (PST)
Received: from nm1.bullet.mail.bf1.yahoo.com (nm1.bullet.mail.bf1.yahoo.com [98.139.212.160]) by ietfa.amsl.com (Postfix) with SMTP id EDDBE21F85C0 for ; Fri, 15 Feb 2013 22:02:51 -0800 (PST)
Received: from [98.139.212.146] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 16 Feb 2013 06:02:51 -0000
Received: from [98.139.212.222] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 16 Feb 2013 06:02:51 -0000
Received: from [127.0.0.1] by omp1031.mail.bf1.yahoo.com with NNFMP; 16 Feb 2013 06:02:51 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 252469.81335.bm@omp1031.mail.bf1.yahoo.com
Received: (qmail 62018 invoked by uid 60001); 16 Feb 2013 06:02:50 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360994570; bh=CXgW/glPOppt36mqlXKI0FNDhjpnv1kq8HiszxkfwXo=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ujXPVwFVYj5D+9Ph9+qv9qDlPfbN01kpA3HIFaDB+8J2NrqlvFJ556Ujw71E5NexySDGAlKq6X3KjgOpyeb+B6eENMJ58LptqUq9EmPSxEes84hhxxM+nKI/8uD8YRzFpClB46buf6iP3ZTJB6FtMb/An2R3mPW3k+KulcwOcls=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=LzJFm2MszDSVbots/srVrFfObGIC/y+f2VubeapxGJRDeeIckxnv+v4jOUpY8cpVJhtldEd4iB1zo4T6EAuL2IMtWP1PKFhJG87g+M2tVcYrtyb2L+ZgTC83fbdgUO47eVSqFLlW3+yX9GqtAvD4755oR3OVTFIu/OAdKg0Ev+w=;
X-YMail-OSG: KgpTZCYVM1k9.aVbCS6kuYJCRK99OpjFoo4tGSXVBmQtZEf eQwVPCptZMuxGqkFfzL.D9JwSzk4.TijonYy4WRwFpbv4GxzzRu5VDQrUvKC KMoVnd7yl9xeYS07lCU8PlrlWDXU6Bqg3iTJHBhqnK0Vk5Shr9HAq0x.6leo FvAhkmHUG6nTiZTwLvBMdUAR3yOOLL0le6qAR.66Ddx4hf6.4.fgbLwCubb7 ieyI3.QmTaVmYNxmPJG8YGvVBg0BGLf6M0W9T9K2nQFwv0M0Q0AJOV5t47AK lI3_DRJeYzX31nFQq4fyhy3w8hrUC3FAfKAVDL0RwgWjQaS4bw_AgsXzk0S_ aAXaibNaYVWpfCtQPr4gbmsmpN3cxqxxc.niqK7xETfcHE96pu8y6As8VRQK lMujg5WBxaDAhOf.L7pace6O0AMu3Eqer_jSFzUA9NY2ZafXBS6_tjT4rHSv gLlhlm02GqOGRvo5E7ST.jj5wrAqe6or.S4nOd0q6nvZ3jfO6cPnQAWEvhd8 zvRRvgt6q5h1EqrT_1OdxLCE9UnBb.vovCazRH5AtMA6laMHrxndjGB1vfH8 3cxYGkRdkSw3NuXf1V9TaTZYdD9fdgOjAMa_6zMhuK6xyNMvpcmHHHzYbnj3 eSKHL_XDWiPB4yxRMUwerBWi8YyijpTDoOtP5XPzH.82bv0b33Wl7qSGPi.j QKsqzhtLfm7UlGI9dC8kUO1yKLmqQZso9pjKljN2JLoA1qqXyJA--
Received: from [99.31.212.42] by web31805.mail.mud.yahoo.com via HTTP; Fri, 15 Feb 2013 22:02:50 PST
X-Rocket-MIMEInfo: 001.001, QWxsIHRoZSBzYW1lIGNvbmNlcHRzL2luZm8gYXJlIGF2YWlsYWJsZSBpbiB0aGUgQVM6IGNsaWVudCBJRCwgY2xpZW50IGF1dGgsIGFuZCBjYW4gZGVsaXZlciBib3RoIHRva2VuIGFuZCBzZWNyZXQuIMKgV2hhdCdzIG1hZ2ljIG9uY2UgdGhlIGNsaWVudCBoYXMgdGhlIHRva2VuIHRoYXQncyBtaXNzaW5nPwoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBGcm9tOiBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPgpUbzogV2lsbGlhbSBNaWxscyA8d21pbGxzXzkyMTA1QHlhaG9vLmMBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.134.513
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net>  <511A7D27.8010209@mitre.org> <4E1F6AAD24975D4BA5B16804296739436744BD23@TK5EX14MBXC285.redmond.corp.microsoft.com> <1360891897.14004.YahooMailNeo@web31811.mail.mud.yahoo.com>  <1360912115.36543.YahooMailNeo@web31811.mail.mud.yahoo.com> <2A0F585F-2CEF-418D-9654-5084E6C9BD0D@lodderstedt.net> <1360944589.51724.YahooMailNeo@web31808.mail.mud.yahoo.com>  <511EA0A3.7080000@mitre.org> <1360962242.18571.YahooMailNeo@web31805.mail.mud.yahoo.com> 
Message-ID: <1360994570.11377.YahooMailNeo@web31805.mail.mud.yahoo.com>
Date: Fri, 15 Feb 2013 22:02:50 -0800 (PST)
From: William Mills 
To: Phil Hunt 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-551393103-308099663-1360994570=:11377"
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Feb 2013 06:02:55 -0000

---551393103-308099663-1360994570=:11377
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

All the same concepts/info are available in the AS: client ID, client auth,=
 and can deliver both token and secret. =C2=A0What's magic once the client =
has the token that's missing?=0A=0A=0A________________________________=0A F=
rom: Phil Hunt =0ATo: William Mills  =0ACc: Justin Richer ; Tim Bray ; IETF oauth WG  =0ASent: Friday, February 15, 2013 1:52=
 PM=0ASubject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference=
 Call - 11th February 2013=0A =0A=0ASorry. I have to disagree. The way 1.0 =
is written, it is not a shortcut to turn it into a token for 2.=C2=A0=0A=0A=
Phil=0A=0ASent from my phone.=0A=0AOn 2013-02-15, at 13:04, William Mills <=
wmills_92105@yahoo.com> wrote:=0A=0A=0A>I've brought it up before, but I th=
ink it might be worthwhile, at least as an exercise, to define a method to =
get OAuth1-style tokens from an OAuth2 token endpoint. You'd defer to OAuth=
1 for how to use them >with a protected resource.=0A>=0A>=0A>=0A>YES!=0A>=
=0A>=0A>=0A>________________________________=0A> From: Justin Richer =0A>To: Tim Bray  =0A>Cc: William Mills ; IETF oauth WG  =0A>Sent: Friday, Feb=
ruary 15, 2013 12:54 PM=0A>Subject: Re: [OAUTH-WG] Minutes from the OAuth D=
esign Team Conference Call - 11th February 2013=0A> =0A>=0A>So that you can=
 fetch and manage all your tokens using the same code paths as the OAuth2 s=
ervices. The "get a token" part will be identical to Oauth2 Bearer (except =
for some details of what comes back from the token endpoint, of course), it=
's the "use a token" bit that really changes and is up in the air. You get =
to use scopes, and state, and refresh tokens, and all the other good stuff.=
=0A>=0A>I've brought it up before, but I think it might be worthwhile, at=
=0A    least as an exercise, to define a method to get OAuth1-style tokens=
=0A    from an OAuth2 token endpoint. You'd defer to OAuth1 for how to use=
=0A    them with a protected resource.=0A>=0A>=C2=A0-- Justin=0A>=0A>=0A>On=
 02/15/2013 11:49 AM, Tim Bray wrote:=0A>=0A>Not deeply acquainted with the=
 Flickr scenario, but it occurs to me to ask: If OAuth 1.0 is working well =
for them, why don=E2=80=99t they just keep using it? =C2=A0I.e. if there=E2=
=80=99s already a good solution in place for people who require secure auth=
n/authz over insecure channels, why would we go the extra work of duplicati=
ng that in OAuth 2 territory? -T=0A>>=0A>>=0A>>On Fri, Feb 15, 2013 at 8:09=
 AM, William Mills  wrote:=0A>>=0A>>I'll repeat the=
 use case for Flickr, which requires OAuth 1.0a type capabilites that OAuth=
 2 does not provide. =C2=A0Simply stating "move to HTTPS" is not a viable r=
esponse here. =C2=A0=0A>>>=0A>>>=0A>>>=0A>>>_______________________________=
_=0A>>> From: Torsten Lodderstedt =0A>>>To: Willia=
m Mills  =0A>>>Cc: Mike Jones ; Justin Richer ; Phil Hunt ; IETF oauth WG  =0A>>>Sent: Friday, February 15, 2013 7:=
22 AM=0A>>>Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Confe=
rence Call - 11th February 2013=0A>>> =0A>>>=0A>>>Hi Bill,=0A>>>=0A>>>=0A>>=
>I think one needs to compare the costs/impact of HTTPS on one side and the=
 implementation of integrity protection and replay detection on the other. =
We had this discussion several times.=0A>>>=0A>>>=0A>>>regards,=0A>>>Torste=
n.=0A>>>=0A>>>Am 15.02.2013 um 08:08 schrieb William Mills=0A              =
          :=0A>>>=0A>>>=0A>>>I fundamentally disagr=
ee with that too. =C2=A0OAuth 2 is the *framework*, one which supports mult=
iple token types. =C2=A0Bearer tokens were the first credential type define=
d.=0A>>>>=0A>>>>=0A>>>>OAuth 1.0a also requires HTTPS transport for authent=
ication and getting the token.=0A>>>>=0A>>>>=0A>>>>There are =C2=A0real use=
 cases for tokens usable over plain text with integrity protection.=0A>>>>=
=0A>>>>=0A>>>>-bill=0A>>>>=0A>>>>=0A>>>>=0A>>>>____________________________=
____=0A>>>> From: Torsten Lodderstedt =0A>>>>To: W=
illiam Mills  =0A>>>>Cc: Mike Jones ; Justin Richer ; Phil Hunt ; IETF oauth WG  =0A>>>>Sent: Thursday, February 14=
, 2013 10:05 PM=0A>>>>Subject: Re: [OAUTH-WG] Minutes from the OAuth Design=
 Team Conference Call - 11th February 2013=0A>>>> =0A>>>>=0A>>>>Hi Bill,=0A=
>>>>=0A>>>>=0A>>>>OAuth 2.0 took a different direction by relying on HTTPS =
to provide the basic protection. So the need to have a token, which can be =
used for service requests over plain HTTP is arguable. My understanding of =
this activity was, the intend is to provide additional protection on top of=
 HTTPS.=0A>>>>=0A>>>>=0A>>>>regards,=0A>>>>Torsten.=0A>>>>=0A>>>>Am 15.02.2=
013 um 02:31 schrieb=0A                                      William Mills =
:=0A>>>>=0A>>>>=0A>>>>I disagree with "That was the=
 impediment to OAuth 1.0 adoption that OAuth 2.0 solved in the first place.=
", unless "solving" means does not address the need for it at all.=0A>>>>>=
=0A>>>>>=0A>>>>>OAuth 2 does several good things, but it still lacks a defi=
ned token type that is safe to user over plain text HTTP. =C2=A01.0a solved=
 that.=0A>>>>>=0A>>>>>=0A>>>>>=0A>>>>>________________________________=0A>>=
>>> From: Mike Jones =0A>>>>>To: Justin Richer=
 ; Phil Hunt  =0A>>>>>Cc: IETF oau=
th WG  =0A>>>>>Sent: Thursday, February 14, 2013 1:44 PM=0A=
>>>>>Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference =
Call - 11th February 2013=0A>>>>> =0A>>>>>I'm in favor of reusing=0A       =
                                       the JWT work that this WG=0A        =
                                      is also doing. :-)=0A>>>>>=0A>>>>>I'm=
 pretty skeptical of us=0A                                              inv=
enting another custom=0A                                              schem=
e for signing HTTP=0A                                              headers.=
=C2=A0 That was the=0A                                              impedim=
ent to OAuth 1.0=0A                                              adoption t=
hat OAuth 2.0=0A                                              solved in the=
 first place.=0A>>>>>=0A>>>>>=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=
=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 -- Mike=0A>>>>>=0A>>>>>-----Original Messag=
e-----=0A>>>>>From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] =
On Behalf Of Justin Richer=0A>>>>>Sent: Tuesday, February=0A               =
                               12, 2013 9:35 AM=0A>>>>>To: Phil Hunt=0A>>>>=
>Cc: IETF oauth WG=0A>>>>>Subject: Re: [OAUTH-WG]=0A                       =
                       Minutes from the OAuth=0A                           =
                   Design Team Conference=0A                               =
               Call - 11th February 2013=0A>>>>>=0A>>>>>That's my reading o=
f it as=0A                                              well, Phil, thanks =
for=0A                                              providing the=0A       =
                                       clarification. One=0A               =
                               motivator behind using a=0A                 =
                             JSON-based token is to be=0A                  =
                            able to re-use some of the=0A                  =
                            great work that the JOSE=0A                    =
                          group is doing but apply=0A                      =
                        it to an HTTP payload.=0A>>>>>=0A>>>>>What neither =
of us want is=0A                                              a token type =
that requires=0A                                              stuffing all =
query,=0A                                              header, and other=0A=
                                              parameters *into* the JSON=0A=
                                              object itself, which would=0A=
                                              be a more SOAPy approach.=0A>=
>>>>=0A>>>>>=C2=A0 -- Justin=0A>>>>>=0A>>>>>On 02/12/2013 12:30 PM,=0A     =
                                         Phil Hunt wrote:=0A>>>>>> Clarific=
ation.=C2=A0 I=0A                                              think Justin=
 and I were in=0A                                              agreement th=
at we don't=0A                                              want to see a f=
ormat that=0A                                              requires JSON pa=
yloads.=C2=A0=0A                                              We are both i=
nterested in=0A                                              a JSON token u=
sed in the=0A                                              authorization he=
ader that=0A                                              could be based on=
 a=0A                                              computed signature of so=
me=0A                                              combination of http=0A  =
                                            headers and body if=0A         =
                                     possible.=0A>>>>>>=0A>>>>>> Phil=0A>>>=
>>>=0A>>>>>> @independentid=0A>>>>>> www.independentid.com=0A>>>>>> phil.hu=
nt@oracle.com=0A>>>>>>=0A>>>>>>=0A>>>>>>=0A>>>>>>=0A>>>>>>=0A>>>>>> On 2013=
-02-12, at=0A                                              1:10 AM, Hannes =
Tschofenig=0A                                              wrote:=0A>>>>>>=
=0A>>>>>>> Here are my=0A                                              note=
s.=0A>>>>>>>=0A>>>>>>> Participants:=0A>>>>>>>=0A>>>>>>> * John Bradley=0A>=
>>>>>> * Derek Atkins=0A>>>>>>> * Phil Hunt=0A>>>>>>> * Prateek Mishra=0A>>=
>>>>> * Hannes=0A                                              Tschofenig=
=0A>>>>>>> * Mike Jones=0A>>>>>>> * Antonio Sanso=0A>>>>>>> * Justin Richer=
=0A>>>>>>>=0A>>>>>>> Notes:=0A>>>>>>>=0A>>>>>>> My slides are=0A           =
                                   available here: =0A>>>>>>> http://www.ts=
chofenig.priv.at/OAuth2-Security-11Feb2013.ppt=0A>>>>>>>=0A>>>>>>> Slide #2=
=0A                                              summarizes earlier=0A     =
                                         discussions during the=0A         =
                                     conference calls.=0A>>>>>>>=0A>>>>>>> =
-- HTTP vs. JSON=0A>>>>>>>=0A>>>>>>> Phil noted that=0A                    =
                          he does not like to use=0A                       =
                       the MAC Token draft as a=0A                         =
                     starting point because it=0A                          =
                    does not re-use any of the=0A                          =
                    work done in the JOSE=0A                               =
               working group and in=0A                                     =
         particular all the=0A                                             =
 libraries that are=0A                                              availab=
le today. He=0A                                              mentioned that=
 earlier=0A                                              attempts to write =
the MAC=0A                                              Token code lead to=
=0A                                              problems for implementers.=
=0A>>>>>>>=0A>>>>>>> Justin responded=0A                                   =
           that he does not agree=0A                                       =
       with using JSON as a=0A                                             =
 transport mechanism since=0A                                              =
this would replicate a=0A                                              SOAP=
 style.=0A>>>>>>>=0A>>>>>>> Phil noted that=0A                             =
                 he wants to send JSON but=0A                              =
                the signature shall be=0A                                  =
            computed over the HTTP=0A                                      =
        header field.=0A>>>>>>>=0A>>>>>>> -- Flexibility=0A                =
                              for the keyed message=0A                     =
                         digest computation=0A>>>>>>>=0A>>>>>>>=C2=A0 From =
earlier=0A                                              discussion it was c=
lear=0A                                              that the conference ca=
ll=0A                                              participants wanted more=
=0A                                              flexibility regarding the=
=0A                                              keyed message digest=0A   =
                                           computation. For this=0A        =
                                      purpose Hannes presented=0A          =
                                    the DKIM based approach,=0A            =
                                  which allows selective=0A                =
                              header fields to be=0A                       =
                       included in the digest.=0A                          =
                    This is shown in slide #4.=0A>>>>>>>=0A>>>>>>> After so=
me=0A                                              discussion the conferenc=
e=0A                                              call participants thought=
=0A                                              that this would meet their=
=0A                                              needs. Further=0A         =
                                     investigations would still=0A         =
                                     be useful to determine the=0A         =
                                     degree of failed HMAC=0A              =
                                calculations due to HTTP=0A                =
                              proxies modifying the=0A                     =
                         content.=0A>>>>>>>=0A>>>>>>> -- Key=0A            =
                                  Distribution=0A>>>>>>>=0A>>>>>>> Hannes p=
resented=0A                                              the open issue reg=
arding=0A                                              the choice of key =
=0A>>>>>>> distribution.=0A                                              Sl=
ides #6-#8 present three=0A                                              te=
chniques and Hannes=0A                                              asked =
=0A>>>>>>> for feedback=0A                                              reg=
arding the preferred=0A                                              style.=
 Justin and others=0A                                              didn't =
=0A>>>>>>> see the need to=0A                                              =
decide on one mechanism -=0A                                              t=
hey wanted to keep the =0A>>>>>>> choice open.=0A                          =
                    Derek indicated that this=0A                           =
                   will not be an acceptable =0A>>>>>>> approach. Since=0A =
                                             the resource server and=0A    =
                                          the authorization server=0A      =
                                        may, =0A>>>>>>> in the OAuth 2.0=0A=
                                              framework, be entities=0A    =
                                          produced by different=0A         =
                                     vendors =0A>>>>>>> there is an=0A     =
                                         interoperability need.=0A         =
                                     Justin responded that he=0A           =
                                   disagrees =0A>>>>>>> and that the=0A    =
                                          resource server needs to=0A      =
                                        understand the access=0A           =
                                   token and =0A>>>>>>> referred to the=0A =
                                             recent draft submission=0A    =
                                          for the token=0A                 =
                             introspection =0A>>>>>>> endpoint. Derek=0A   =
                                           indicated that the=0A           =
                                   resource server has to=0A               =
                               understand =0A>>>>>>> the content of=0A     =
                                         the access token and the=0A       =
                                       token introspection=0A              =
                                endpoint =0A>>>>>>> just pushes the=0A     =
                                         problem around: the=0A            =
                                  resource server has to=0A                =
                              send the =0A>>>>>>> access token to=0A       =
                                       the authorization server=0A         =
                                     and then the resource=0A              =
                                server =0A>>>>>>> gets the result=0A       =
                                       back (which he the=0A>>>>>n=0A>>>>>>=
=C2=A0 =C2=A0 a=0A>>>>>>> gain needs to=0A                                 =
             understand) in order to=0A                                    =
          make a meaningful=0A                                             =
 authorization decision.=0A>>>>>>>=0A>>>>>>> Everyone agreed=0A            =
                                  that the client must=0A                  =
                            receive the session key=0A                     =
                         from the authorization=0A                         =
                     server and that this=0A                               =
               approach has to be=0A                                       =
       standardized. It was also=0A                                        =
      agreed that this is a=0A                                             =
 common approach among all=0A                                              =
three key distribution=0A                                              mech=
anisms.=0A>>>>>>>=0A>>>>>>> Hannes asked the=0A                            =
                  participants to think=0A                                 =
             about their preference.=0A>>>>>>>=0A>>>>>>> The questions=0A  =
                                            regarding key naming and=0A    =
                                          the indication for the=0A        =
                                      intended resource server=0A          =
                                    the client wants to talk=0A            =
                                  to have been postponed.=0A>>>>>>>=0A>>>>>=
>> Ciao=0A>>>>>>> Hannes=0A>>>>>>>=0A>>>>>>>=0A>>>>>>>=0A                  =
                            _______________________________________________=
=0A>>>>>>> OAuth mailing=0A                                              li=
st=0A>>>>>>> OAuth@ietf.org=0A>>>>>>> https://www.ietf.org/mailman/listinfo=
/oauth=0A>>>>>>=0A                                              ___________=
____________________________________=0A>>>>>> OAuth mailing list=0A>>>>>> O=
Auth@ietf.org=0A>>>>>> https://www.ietf.org/mailman/listinfo/oauth=0A>>>>>=
=0A>>>>>=0A>>>>>_______________________________________________=0A>>>>>OAut=
h mailing list=0A>>>>>OAuth@ietf.org=0A>>>>>https://www.ietf.org/mailman/li=
stinfo/oauth=0A>>>>>_______________________________________________=0A>>>>>=
OAuth mailing list=0A>>>>>OAuth@ietf.org=0A>>>>>https://www.ietf.org/mailma=
n/listinfo/oauth=0A>>>>>=0A>>>>>=0A>>>>>=0A>>>>____________________________=
___________________=0A>>>>>OAuth mailing list=0A>>>>>OAuth@ietf.org=0A>>>>>=
https://www.ietf.org/mailman/listinfo/oauth=0A>>>>>=0A>>>>=0A>>>>=0A>>>=0A>=
>>=0A>>>_______________________________________________=0A>>>OAuth mailing =
list=0A>>>OAuth@ietf.org=0A>>>https://www.ietf.org/mailman/listinfo/oauth=
=0A>>>=0A>>>=0A>>=0A>>=0A>>=0A>>___________________________________________=
____=0AOAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listi=
nfo/oauth =0A>=0A>=0A>=0A_______________________________________________=0A=
>OAuth mailing list=0A>OAuth@ietf.org=0A>https://www.ietf.org/mailman/listi=
nfo/oauth=0A>
---551393103-308099663-1360994570=:11377
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

All =
the same concepts/info are available in the AS: client ID, client auth, and=
 can deliver both token and secret.  What's magic once the client has =
the token that's missing?

   <=
div style=3D"font-family: 'times new roman', 'new york', times, serif; font=
-size: 12pt;">   
  From: Phil Hunt &l=
t;phil.hunt@oracle.com>
 To: William Mills <wmills_92105@yahoo.com> 
Cc: Justin Richer <jricher@mitre.org>=
; Tim Bray <twbray@google.com>; IETF oauth WG <oauth@ietf.org> =

 Sent: Friday, February 15, 2013 1:=
52 PM
 Subject: Re: [OA=
UTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February =
2013

Sorry. I hav=
e to disagree. The way 1.0 is written, it is not a shortcut to turn it into=
 a token for 2. 

Phil
Sent from my phone.

On 2013-02-15, at 13:04, William Mills <wmills_92105@yahoo.com> wrote:

=
>I've brought it=
 up before,
 but I think it might be worthwhile, at least as an exercise, to define a m=
ethod to get OAuth1-style tokens from an OAuth2 token endpoint. You'd defer=
 to OAuth1 for how to use them >with a protected resource.

YES!

  From: Justin Richer <=
jricher@mitre.org>
 To: Tim Bray <twbray@google.com=
> 
Cc: William Mills =
<wmills_92105@yahoo.com&=
gt;; IETF oauth WG <oauth@ietf.org> <=
br> Sent: Friday, February 15, 2013 12:=
54 PM
 Subject: Re: [OAU=
TH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2=
013

=0A  =0A=0A    =0A  =0A=
  =0A    So that you can fetch and manage all your tokens using the sa=
me code=0A    paths as the OAuth2 services. The "get a token" part will be=
=0A    identical to Oauth2 Bearer (except for some details of what comes=0A=
    back from the token endpoint, of course), it's the "use a token" bit=0A=
    that really changes and is up in the air. You get to use scopes, and=0A=
    state, and refresh tokens, and all the other good stuff.
=0A    
=
=0A    I've brought it up before, but I think it might be worthwhile, at=0A=
    least as an exercise, to define a method to get OAuth1-style tokens=0A =
   from an OAuth2 token endpoint. You'd defer to OAuth1 for how to use=0A  =
  them with a protected resource.
=0A    
=0A     -- Justin
=
=0A    
=0A    On 02/15/2013 =
11:49 AM, Tim Bray wrote:
=0A    
=0A    =
=0A      =0A      Not deeply acquainted with the Flickr scenario, but it oc=
curs to=0A      me to ask: If OAuth 1.0 is working well for them, why don=
=E2=80=99t they=0A      just keep using it?  I.e. if there=E2=80=99s a=
lready a good solution in=0A      place for people who require secure authn=
/authz over insecure=0A      channels, why would we go the extra work of du=
plicating that in=0A      OAuth 2 territory? -T
=0A      
=0A      On Fri, Feb 15, 2013 at 8:09 AM, Willi=
am=0A        Mills <wmills_92105@yahoo.com>=0A        wrote:
=0A    =
    =0A          =0A      =
      =0A              I'll repeat the =
use case for Flickr, which=0A                  requires OAuth 1.0a type cap=
abilites that OAuth 2 does=0A                  not provide.  Simply st=
ating "move to HTTPS" is not a=0A                  viable response here. &n=
bsp;
=0A              
=0A              =0A      =
        =0A                =0A                   =0A                      
 From:=0A                      Torsten Lodderstedt =
<torsten@lodderstedt.net=
>
=0A                      T=
o:=0A                      William Mills <wmills_92105@yahoo.com> 
=0A            =
          Cc:=0A           =
           Mike Jones <Michael.Jones@microsoft.com>;=0A                      Justin Ri=
cher <jricher@mitre.org>;=0A   =
                   Phil Hunt <ph=
il.hunt@oracle.com>;=0A                      IETF oauth WG <oauth@ietf.org>=0A                      
=
=0A                      Sent:<=
/b>=0A                      Friday, February 15, 2013 7:22 AM
=0A       =
               Subject:=0A =
                     Re: [OAUTH-WG] Minutes from the OAuth Design Team=0A  =
                    Conference Call - 11th February 2013
=0A            =

=0A                  
=0A                  =
=0A                    =0A                      Hi Bill,=0A=

=0A                      =0A          =
            I think one needs to compare the costs/impact=0A          =
              of HTTPS on one side and the implementation of=0A            =
            integrity protection and replay detection on the=0A            =
            other. We had this discussion several times.=0A          =

=0A                      =0A                    =
  regards,
=0A                      Torsten.=0A       =

=0A                        Am 15.02.2013 um 08:08 s=
chrieb William Mills=0A                        <wmills_92105@yahoo.com>:
=0A                 =

=0A                      
=0A                      =0A                        =0A                      =
    =0A                =
            I fundamentally disagree with=0A                    =
            that too.  OAuth 2 is the *framework*,=0A                 =
               one which supports multiple token types.=0A                 =
                Bearer tokens were the first credential=0A            =
                    type defined.=0A                          =

=0A                              
=0A                            =0A      =
                        OAuth 1.0a also requires HTTPS=0A            =
                    transport for authentication and getting=0A            =
                    the token.=0A                            <=
div style=3D"font-style:normal;font-size:16px;background-color:transparent;=
font-family:'Courier=0A                              New', courier, monaco,=
 monospace, sans-serif;">=0A                              
=0A    =

=0A                            There=0A                                are &nbs=
p;real use cases for tokens usable=0A                                over p=
lain text with integrity=0A                                protection.
=0A                            
=
=0A                              =0A                          =
  =0A                              -bill
=0A                            
=0A                      =

=0A                            =0A                              =0A            =
                     =0A             =

 From:=0A                                    Torsten Lodderstedt=
 <torsten@lodderstedt.net=
>
=0A                                    To:=0A                                    William M=
ills <wmills_92105@yahoo.com=
>=0A                                    
=0A                     =
               Cc:=0A      =
                              Mike Jones <Michael.Jones@microsoft.com>;=0A            =
                        Justin Richer <jricher@mitre.org>;=0A                                    Phil Hunt=
 <phil.hunt@oracle.com>;=
=0A                                    IETF oauth WG <oauth@ietf.org>=0A                                    
=
=0A                                    Sent:=0A                                    Thursday, February =
14, 2013 10:05 PM
=0A                                    Subject:=0A                              =
      Re: [OAUTH-WG] Minutes from the=0A                                   =
 OAuth Design Team Conference Call -=0A                                    =
11th February 2013
=0A                                   =
=0A                                
=0A                                <=
div>=0A                                  =0A                          =
          Hi Bill,
=0A                                    =0A                                    =0A                         =
           OAuth 2.0 took a different=0A                              =
        direction by relying on HTTPS to=0A                                =
      provide the basic protection. So=0A                                  =
    the need to have a token, which=0A                                     =
 can be used for service requests=0A                                      o=
ver plain HTTP is arguable. My=0A                                      unde=
rstanding of this activity=0A                                      was, the=
 intend is to provide=0A                                      additional pr=
otection on top of=0A                                      HTTPS.=0A =

=0A                            =

=0A                                    regards,=0A=
                                    Torsten.=0A                 =

=0A                                      Am 15.=
02.2013 um 02:31 schrieb=0A                                      William Mi=
lls <wmills_92105@yahoo.com<=
/a>>:
=0A                                      
=0A               =

=0A                                    =0A                                      =0A         =
                               =0A                 =
                         I disagree with "That=0A                                              was=
 the impediment to=0A                                              OAuth 1.=
0 adoption that=0A                                              OAuth 2.0 s=
olved in the=0A                                              first place.",=
 unless=0A                                              "solving" means doe=
s not=0A                                              address the need for =
it at=0A                                              all.=0A =
                                         =0A                              =

=0A                    =
                        =0A                                   =
       =0A                                            OAuth=0A                                              2 does =
several good=0A                                              things, but it=
 still lacks=0A                                              a defined toke=
n type that=0A                                              is safe to user=
 over plain=0A                                              text HTTP. &nbs=
p;1.0a solved=0A                                              that.<=
/div>=0A                                          
=0A             =
                             =0A                                     =
     =0A                                           =
 =0A                                      =
         =0A                         =

 From: Mike Jones <Michael.Jones@microsoft.com>
=0A                   =
                               To:=0A                                                  Justin Richer &=
lt;jricher@mitre.org>;=0A         =
                                         Phil Hunt <phil.hunt@oracle.com>=0A                        =

=0A                                          =
        Cc:=0A             =
                                     IETF oauth WG <oauth@ietf.org>=0A                                          =

=0A                                                  Sent:=0A                             =
                     Thursday, February 14,=0A                             =
                     2013 1:44 PM
=0A                                   =
               Subject:=0A =
                                                 Re: [OAUTH-WG] Minutes=0A =
                                                 from the OAuth Design=0A  =
                                                Team Conference Call -=0A  =
                                                11th February 2013
=0A  =
                                               =0A            =

=0A                                  =
            I'm in favor of reusing=0A                                     =
         the JWT work that this WG=0A                                      =
        is also doing. :-)
=0A                                          =

=0A                                              I'm pretty skeptic=
al of us=0A                                              inventing another =
custom=0A                                              scheme for signing H=
TTP=0A                                              headers.  That was=
 the=0A                                              impediment to OAuth 1.=
0=0A                                              adoption that OAuth 2.0=
=0A                                              solved in the first place.=

=0A                                              
=0A               =
                                        =
       -- Mike
=0A                             =

=0A                                              -----=
Original Message-----
=0A                                              F=
rom: oauth-bounces@ietf.org=0A                                              [mailto:oauth-bounces@ietf.org]=0A                 =
                             On Behalf Of Justin Richer
=0A             =
                                 Sent: Tuesday, February=0A                =
                              12, 2013 9:35 AM
=0A                      =
                        To: Phil Hunt
=0A                               =
               Cc: IETF oauth WG
=0A                                    =
          Subject: Re: [OAUTH-WG]=0A                                       =
       Minutes from the OAuth=0A                                           =
   Design Team Conference=0A                                              C=
all - 11th February 2013
=0A                                            =

=0A                                              That's my reading of=
 it as=0A                                              well, Phil, thanks f=
or=0A                                              providing the=0A        =
                                      clarification. One=0A                =
                              motivator behind using a=0A                  =
                            JSON-based token is to be=0A                   =
                           able to re-use some of the=0A                   =
                           great work that the JOSE=0A                     =
                         group is doing but apply=0A                       =
                       it to an HTTP payload.
=0A                       =

=0A                                             =
 What neither of us want is=0A                                             =
 a token type that requires=0A                                             =
 stuffing all query,=0A                                              header=
, and other=0A                                              parameters *int=
o* the JSON=0A                                              object itself, =
which would=0A                                              be a more SOAPy=
 approach.
=0A                                              
=0A     =
                                           -- Justin
=0A           =

=0A                                 =
             On 02/12/2013 12:30 PM,=0A                                    =
          Phil Hunt wrote:
=0A                                          =
    > Clarification.  I=0A                                         =
     think Justin and I were in=0A                                         =
     agreement that we don't=0A                                            =
  want to see a format that=0A                                             =
 requires JSON payloads. =0A                                          =
    We are both interested in=0A                                           =
   a JSON token used in the=0A                                             =
 authorization header that=0A                                              =
could be based on a=0A                                              compute=
d signature of some=0A                                              combina=
tion of http=0A                                              headers and bo=
dy if=0A                                              possible.
=0A     =
                                         >
=0A                       =
                       > Phil
=0A                                    =
          >
=0A                                              > @in=
dependentid
=0A                                              > www.=
independentid.com
=0A                                              &=
gt; phil.hunt@oracle.com
=0A=
                                              >
=0A                  =
                            >
=0A                                    =
          >
=0A                                              >
=
=0A                                              >
=0A               =
                               > On 2013-02-12, at=0A                   =
                           1:10 AM, Hannes Tschofenig=0A                   =
                           wrote:
=0A                                   =
           >
=0A                                              >>=
; Here are my=0A                                              notes.
=0A=
                                              >>
=0A              =
                                >> Participants:
=0A              =
                                >>
=0A                            =
                  >> * John Bradley
=0A                           =
                   >> * Derek Atkins
=0A                          =
                    >> * Phil Hunt
=0A                            =
                  >> * Prateek Mishra
=0A                         =
                     >> * Hannes=0A                                  =
            Tschofenig
=0A                                              =
>> * Mike Jones
=0A                                              &=
gt;> * Antonio Sanso
=0A                                             =
 >> * Justin Richer
=0A                                           =
   >>
=0A                                              >> No=
tes:
=0A                                              >>
=0A   =
                                           >> My slides are=0A       =
                                       available here: 
=0A             =
                                 >> h=
ttp://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
=0A      =
                                        >>
=0A                    =
                          >> Slide #2=0A                             =
                 summarizes earlier=0A                                     =
         discussions during the=0A                                         =
     conference calls.
=0A                                              =
>>
=0A                                              >> -- HT=
TP vs. JSON
=0A                                              >>=0A                                              >> Phil noted that=
=0A                                              he does not like to use=0A=
                                              the MAC Token draft as a=0A  =
                                            starting point because it=0A   =
                                           does not re-use any of the=0A   =
                                           work done in the JOSE=0A        =
                                      working group and in=0A              =
                                particular all the=0A                      =
                        libraries that are=0A                              =
                available today. He=0A                                     =
         mentioned that earlier=0A                                         =
     attempts to write the MAC=0A                                          =
    Token code lead to=0A                                              prob=
lems for implementers.
=0A                                              =
>>
=0A                                              >> Justi=
n responded=0A                                              that he does no=
t agree=0A                                              with using JSON as =
a=0A                                              transport mechanism since=
=0A                                              this would replicate a=0A =
                                             SOAP style.
=0A            =
                                  >>
=0A                          =
                    >> Phil noted that=0A                            =
                  he wants to send JSON but=0A                             =
                 the signature shall be=0A                                 =
             computed over the HTTP=0A                                     =
         header field.
=0A                                              =
>>
=0A                                              >> -- Fl=
exibility=0A                                              for the keyed mes=
sage=0A                                              digest computation
=
=0A                                              >>
=0A           =
                                   >>  From earlier=0A          =
                                    discussion it was clear=0A             =
                                 that the conference call=0A               =
                               participants wanted more=0A                 =
                             flexibility regarding the=0A                  =
                            keyed message digest=0A                        =
                      computation. For this=0A                             =
                 purpose Hannes presented=0A                               =
               the DKIM based approach,=0A                                 =
             which allows selective=0A                                     =
         header fields to be=0A                                            =
  included in the digest.=0A                                              T=
his is shown in slide #4.
=0A                                           =
   >>
=0A                                              >> Af=
ter some=0A                                              discussion the con=
ference=0A                                              call participants t=
hought=0A                                              that this would meet=
 their=0A                                              needs. Further=0A   =
                                           investigations would still=0A   =
                                           be useful to determine the=0A   =
                                           degree of failed HMAC=0A        =
                                      calculations due to HTTP=0A          =
                                    proxies modifying the=0A               =
                               content.
=0A                             =
                 >>
=0A                                           =
   >> -- Key=0A                                              Distribu=
tion
=0A                                              >>
=0A   =
                                           >> Hannes presented=0A    =
                                          the open issue regarding=0A      =
                                        the choice of key 
=0A          =
                                    >> distribution.=0A              =
                                Slides #6-#8 present three=0A              =
                                techniques and Hannes=0A                   =
                           asked 
=0A                                   =
           >> for feedback=0A                                        =
      regarding the preferred=0A                                           =
   style. Justin and others=0A                                             =
 didn't 
=0A                                              >> see t=
he need to=0A                                              decide on one me=
chanism -=0A                                              they wanted to ke=
ep the 
=0A                                              >> choice=
 open.=0A                                              Derek indicated that=
 this=0A                                              will not be an accept=
able=0A                                              
=0A               =
                               >> approach. Since=0A                 =
                             the resource server and=0A                    =
                          the authorization server=0A                      =
                        may, 
=0A                                       =
       >> in the OAuth 2.0=0A                                        =
      framework, be entities=0A                                            =
  produced by different=0A                                              ven=
dors 
=0A                                              >> there is=
 an=0A                                              interoperability need.=
=0A                                              Justin responded that he=
=0A                                              disagrees 
=0A         =
                                     >> and that the=0A              =
                                resource server needs to=0A                =
                              understand the access=0A                     =
                         token and 
=0A                                 =
             >> referred to the=0A                                   =
           recent draft submission=0A                                      =
        for the token=0A                                              intro=
spection 
=0A                                              >> endp=
oint. Derek=0A                                              indicated that =
the=0A                                              resource server has to=
=0A                                              understand 
=0A        =
                                      >> the content of=0A           =
                                   the access token and the=0A             =
                                 token introspection=0A                    =
                          endpoint 
=0A                                 =
             >> just pushes the=0A                                   =
           problem around: the=0A                                          =
    resource server has to=0A                                              =
send the 
=0A                                              >> acce=
ss token to=0A                                              the authorizati=
on server=0A                                              and then the reso=
urce=0A                                              server 
=0A        =
                                      >> gets the result=0A          =
                                    back (which he the
=0A              =
                                n
=0A                                   =
           >    a
=0A                                      =
        >> gain needs to=0A                                          =
    understand) in order to=0A                                             =
 make a meaningful=0A                                              authoriz=
ation decision.
=0A                                              >>=
;
=0A                                              >> Everyone agr=
eed=0A                                              that the client must=0A=
                                              receive the session key=0A   =
                                           from the authorization=0A       =
                                       server and that this=0A             =
                                 approach has to be=0A                     =
                         standardized. It was also=0A                      =
                        agreed that this is a=0A                           =
                   common approach among all=0A                            =
                  three key distribution=0A                                =
              mechanisms.
=0A                                           =
   >>
=0A                                              >> Ha=
nnes asked the=0A                                              participants=
 to think=0A                                              about their prefe=
rence.
=0A                                              >>
=0A =
                                             >> The questions=0A     =
                                         regarding key naming and=0A       =
                                       the indication for the=0A           =
                                   intended resource server=0A             =
                                 the client wants to talk=0A               =
                               to have been postponed.
=0A              =
                                >>
=0A                            =
                  >> Ciao
=0A                                     =
         >> Hannes
=0A                                            =
  >>
=0A                                              >>
=
=0A                                              >>=0A               =
                               ____________________________________________=
___
=0A                                              >> OAuth mail=
ing=0A                                              list
=0A            =
                                  >> OAut=
h@ietf.org
=0A                                              >>=
 https://www.ietf.org/mailman/listinfo/oauth
=0A    =
                                          >=0A                          =
                    _______________________________________________
=0A =
                                             > OAuth mailing list
=0A=
                                              > OAuth@ietf.org
=0A                                              =
> https://www.ietf.org/mailman/listinfo/oauth
=0A=

=0A                      =

=0A____________________________________________=
___
=0A                                              OAuth mailing list<=
br>=0A                                              OAuth@ietf.org
=0A                                             =
 https://www.ietf.org/mailman/listinfo/oauth
=0A____=
___________________________________________
=0A                         =
                     OAuth mailing list
=0A                             =
                 OAuth@ietf.org
=0A     =
                                         https://www.ietf.o=
rg/mailman/listinfo/oauth
=0A                                       =

=0A                                              
=0A        =
                                    =0A                              =

=0A                                        =0A     =
                                 =0A                                 =

=0A                                    =0A                                      _________________=
______________________________
=0A                               =
         OAuth mailing list
=0A                            =
            OAuth@ietf.org
=
=0A                                        https://ww=
w.ietf.org/mailman/listinfo/oauth
=0A                        =

=0A                                    =0A=

=0A                                =
=0A                                
=0A                           =

=0A                              
=0A                        =

=0A                          
=0A                        =0A                      
=0A                    
=0A  =

=0A                  
=0A                  
=0A=

=0A              
=0A            
=0A      =
    =0A          
=0A          ___________________________________=
____________
=0A          OAuth mailing list
=0A          OAuth@ietf.org
=0A          https:/=
/www.ietf.org/mailman/listinfo/oauth
=0A          
=0A        =0A      =0A      
=0A      
=0A      
=0A      
=0A      _______________________________________________=0AOAuth mailing list=0AOAu=
th@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth=0A=0A    =0A    
=0A  =0A=0A

    <=
/blockquote>__________________________=
_____________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

---551393103-308099663-1360994570=:11377--

From phil.hunt@oracle.com  Fri Feb 15 23:22:33 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4041F21F8314 for ; Fri, 15 Feb 2013 23:22:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.596
X-Spam-Level: 
X-Spam-Status: No, score=-5.596 tagged_above=-999 required=5 tests=[AWL=-0.394, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0J4p1t8-6aOG for ; Fri, 15 Feb 2013 23:22:31 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id F085621F88E4 for ; Fri, 15 Feb 2013 23:22:30 -0800 (PST)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1G7MPNw026454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 16 Feb 2013 07:22:26 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1G7MPuX008988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Feb 2013 07:22:25 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1G7MOOv026995; Sat, 16 Feb 2013 01:22:24 -0600
Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 15 Feb 2013 23:22:23 -0800
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net>  <511A7D27.8010209@mitre.org> <4E1F6AAD24975D4BA5B16804296739436744BD23@TK5EX14MBXC285.redmond.corp.microsoft.com> <1360891897.14004.YahooMailNeo@web31811.mail.mud.yahoo.com>  <1360912115.36543.YahooMailNeo@web31811.mail.mud.yahoo.com> <2A0F585F-2CEF-418D-9654-5084E6C9BD0D@lodderstedt.net> <1360944589.51724.YahooMailNeo@web31808.mail.mud.yahoo.com>  <511EA0A3.7080000@mitre.org> <1360962242.18571.YahooMailNeo@web31805.mail.mud.yahoo.com>  <1360994570.11377.YahooMailNeo@web31805.mail.mud.yahoo.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <1360994570.11377.YahooMailNeo@web31805.mail.mud.yahoo.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-ADA71B80-EC28-4B76-89E1-E468BF4D4FA9
Content-Transfer-Encoding: 7bit
Message-Id: 
X-Mailer: iPhone Mail (10B142)
From: Phil Hunt 
Date: Fri, 15 Feb 2013 23:22:21 -0800
To: William Mills 
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Feb 2013 07:22:33 -0000

--Apple-Mail-ADA71B80-EC28-4B76-89E1-E468BF4D4FA9
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I don't see oauth1 tokens as a short cut because eran said the token in oaut=
h1 (which is inside the oauth1 spec) had many implementation problems by cli=
ent developers. Why go there and re-invent what jwt could do easily?

Do you need hok? Do you need replay protection? Do you need message signing?=
 Are asymmetric keys needed?  I get the impression the group is less interes=
ted in the last two.=20

There is also key distribution to resource server. I think we have client na=
iled but getting keys to resource server needs some discussion - especially i=
f the path is through the token itself. =20

I suppose we can move faster if we assume rs obtains keys in an unspecified m=
anner like what happened in oauth1.=20

Phil

Sent from my phone.

On 2013-02-15, at 22:02, William Mills  wrote:

> All the same concepts/info are available in the AS: client ID, client auth=
, and can deliver both token and secret.  What's magic once the client has t=
he token that's missing?
>=20
> From: Phil Hunt 
> To: William Mills =20
> Cc: Justin Richer ; Tim Bray ; IETF o=
auth WG =20
> Sent: Friday, February 15, 2013 1:52 PM
> Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call=
 - 11th February 2013
>=20
> Sorry. I have to disagree. The way 1.0 is written, it is not a shortcut to=
 turn it into a token for 2.=20
>=20
> Phil
>=20
> Sent from my phone.
>=20
> On 2013-02-15, at 13:04, William Mills  wrote:
>=20
>> >I've brought it up before, but I think it might be worthwhile, at least a=
s an exercise, to define a method to get OAuth1-style tokens from an OAuth2 t=
oken endpoint. You'd defer to OAuth1 for how to use them >with a protected r=
esource.
>>=20
>> YES!
>>=20
>> From: Justin Richer 
>> To: Tim Bray =20
>> Cc: William Mills ; IETF oauth WG =20
>> Sent: Friday, February 15, 2013 12:54 PM
>> Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Cal=
l - 11th February 2013
>>=20
>> So that you can fetch and manage all your tokens using the same code path=
s as the OAuth2 services. The "get a token" part will be identical to Oauth2=
 Bearer (except for some details of what comes back from the token endpoint,=
 of course), it's the "use a token" bit that really changes and is up in the=
 air. You get to use scopes, and state, and refresh tokens, and all the othe=
r good stuff.
>>=20
>> I've brought it up before, but I think it might be worthwhile, at least a=
s an exercise, to define a method to get OAuth1-style tokens from an OAuth2 t=
oken endpoint. You'd defer to OAuth1 for how to use them with a protected re=
source.
>>=20
>>  -- Justin
>>=20
>> On 02/15/2013 11:49 AM, Tim Bray wrote:
>>> Not deeply acquainted with the Flickr scenario, but it occurs to me to a=
sk: If OAuth 1.0 is working well for them, why don=E2=80=99t they just keep u=
sing it?  I.e. if there=E2=80=99s already a good solution in place for peopl=
e who require secure authn/authz over insecure channels, why would we go the=
 extra work of duplicating that in OAuth 2 territory? -T
>>>=20
>>> On Fri, Feb 15, 2013 at 8:09 AM, William Mills  w=
rote:
>>> I'll repeat the use case for Flickr, which requires OAuth 1.0a type capa=
bilites that OAuth 2 does not provide.  Simply stating "move to HTTPS" is no=
t a viable response here. =20
>>>=20
>>> From: Torsten Lodderstedt 
>>> To: William Mills =20
>>> Cc: Mike Jones ; Justin Richer ; Phil Hunt ; IETF oauth WG =20=

>>> Sent: Friday, February 15, 2013 7:22 AM
>>> Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Ca=
ll - 11th February 2013
>>>=20
>>> Hi Bill,
>>>=20
>>> I think one needs to compare the costs/impact of HTTPS on one side and t=
he implementation of integrity protection and replay detection on the other.=
 We had this discussion several times.
>>>=20
>>> regards,
>>> Torsten.
>>>=20
>>> Am 15.02.2013 um 08:08 schrieb William Mills :
>>>=20
>>>> I fundamentally disagree with that too.  OAuth 2 is the *framework*, on=
e which supports multiple token types.  Bearer tokens were the first credent=
ial type defined.
>>>>=20
>>>> OAuth 1.0a also requires HTTPS transport for authentication and getting=
 the token.
>>>>=20
>>>> There are  real use cases for tokens usable over plain text with integr=
ity                                 protection.
>>>>=20
>>>> -bill
>>>>=20
>>>> From: Torsten Lodderstedt 
>>>> To: William Mills =20
>>>> Cc: Mike Jones ;                          =
           Justin Richer ;                               =
      Phil Hunt ; IETF oauth WG =20
>>>> Sent: Thursday, February 14, 2013 10:05 PM
>>>> Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference C=
all - 11th February 2013
>>>>=20
>>>> Hi Bill,
>>>>=20
>>>> OAuth 2.0 took a different direction by relying on HTTPS to provide the=
 basic protection. So the need to have a token, which can be used for servic=
e requests over plain HTTP is arguable. My understanding of this activity wa=
s, the intend is to provide additional protection on top of HTTPS.
>>>>=20
>>>> regards,
>>>> Torsten.
>>>>=20
>>>> Am 15.02.2013 um 02:31 schrieb William Mills :
>>>>=20
>>>>> I disagree with "That was the impediment to OAuth 1.0 adoption that   =
                                            OAuth 2.0 solved in the         =
                                      first place.", unless "solving" means d=
oes not                                               address the need for i=
t at all.
>>>>>=20
>>>>> OAuth 2 does several good things, but it still lacks a defined token t=
ype that is safe to user over plain text HTTP.  1.0a solved that.
>>>>>=20
>>>>> From: Mike Jones 
>>>>> To: Justin Richer ; Phil Hunt =20
>>>>> Cc: IETF oauth WG =20
>>>>> Sent: Thursday, February 14, 2013 1:44 PM
>>>>> Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference C=
all - 11th February 2013
>>>>>=20
>>>>> I'm in favor of reusing                                               t=
he JWT work that this WG is also doing. :-)
>>>>>=20
>>>>> I'm pretty skeptical of us inventing another custom scheme for signing=
 HTTP headers.  That was the impediment to OAuth 1.0 adoption that OAuth 2.0=
 solved in the first place.
>>>>>=20
>>>>>                 -- Mike
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=
 Of Justin Richer
>>>>> Sent: Tuesday, February                                               1=
2, 2013 9:35 AM
>>>>> To: Phil Hunt
>>>>> Cc: IETF oauth WG
>>>>> Subject: Re: [OAUTH-WG]                                               M=
inutes from the OAuth Design Team Conference Call - 11th February 2013
>>>>>=20
>>>>> That's my reading of it as well, Phil, thanks for providing the clarif=
ication. One motivator behind using a                                       =
        JSON-based token is to be able to re-use some of the great work that=
 the JOSE group is doing but apply it to an HTTP payload.
>>>>>=20
>>>>> What neither of us want is a token type that requires stuffing all que=
ry, header, and other                                               paramete=
rs *into* the JSON object itself, which would be a more SOAPy approach.
>>>>>=20
>>>>>   -- Justin
>>>>>=20
>>>>> On 02/12/2013 12:30 PM,                                               P=
hil Hunt wrote:
>>>>> > Clarification.  I think Justin and I were in agreement that we don't=
 want to see a format that requires JSON payloads.  We are both interested i=
n a JSON token used in the authorization header that could be based on a    =
                                           computed signature of some combin=
ation of http                                               headers and body=
 if possible.
>>>>> >
>>>>> > Phil
>>>>> >
>>>>> > @independentid
>>>>> > www.independentid.com
>>>>> > phil.hunt@oracle.com
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > On 2013-02-12, at 1:10 AM, Hannes Tschofenig wrote:
>>>>> >
>>>>> >> Here are my notes.
>>>>> >>
>>>>> >> Participants:
>>>>> >>
>>>>> >> * John Bradley
>>>>> >> * Derek Atkins
>>>>> >> * Phil Hunt
>>>>> >> * Prateek Mishra
>>>>> >> * Hannes Tschofenig
>>>>> >> * Mike Jones
>>>>> >> * Antonio Sanso
>>>>> >> * Justin Richer
>>>>> >>
>>>>> >> Notes:
>>>>> >>
>>>>> >> My slides are available here:=20
>>>>> >> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
>>>>> >>
>>>>> >> Slide #2 summarizes earlier discussions during the conference calls=
.
>>>>> >>
>>>>> >> -- HTTP vs. JSON
>>>>> >>
>>>>> >> Phil noted that he does not like to use the MAC Token draft as a st=
arting point because it does not re-use any of the work done in the JOSE wor=
king group and in particular all the libraries that are available today. He m=
entioned that earlier attempts to write the MAC Token code lead to problems f=
or implementers.
>>>>> >>
>>>>> >> Justin responded that he does not agree with using JSON as a transp=
ort mechanism since this would replicate a SOAP style.
>>>>> >>
>>>>> >> Phil noted that he wants to send JSON but the signature shall be co=
mputed over the HTTP header field.
>>>>> >>
>>>>> >> -- Flexibility for the keyed message digest computation
>>>>> >>
>>>>> >>  =46rom earlier discussion it was clear                            =
                   that the conference call                                 =
              participants wanted more                                      =
         flexibility regarding the keyed message digest                     =
                          computation. For this purpose Hannes presented    =
                                           the DKIM based approach,         =
                                      which allows selective header fields t=
o be included in the digest.                                               T=
his is shown in slide #4.
>>>>> >>
>>>>> >> After some discussion the conference call participants thought that=
 this would meet their needs. Further investigations would still be useful t=
o determine the degree of failed HMAC calculations due to HTTP proxies modif=
ying the content.
>>>>> >>
>>>>> >> -- Key Distribution
>>>>> >>
>>>>> >> Hannes presented the open issue regarding the choice of key=20
>>>>> >> distribution. Slides #6-#8 present three techniques and Hannes aske=
d=20
>>>>> >> for feedback regarding the preferred                               =
                style. Justin and others                                    =
           didn't=20
>>>>> >> see the need to decide on one mechanism - they wanted to keep the=20=

>>>>> >> choice open. Derek indicated that this will not be an acceptable=20=

>>>>> >> approach. Since the resource server and the authorization server ma=
y,=20
>>>>> >> in the OAuth 2.0 framework, be entities produced by different vendo=
rs=20
>>>>> >> there is an interoperability need. Justin responded that he        =
                                       disagrees=20
>>>>> >> and that the resource server needs to understand the access token a=
nd=20
>>>>> >> referred to the recent draft submission                            =
                   for the token introspection=20
>>>>> >> endpoint. Derek indicated that the resource server has to understan=
d=20
>>>>> >> the content of the access token and the token introspection endpoin=
t=20
>>>>> >> just pushes the problem around: the resource server has to send the=
=20
>>>>> >> access token to the authorization server and then the resource serv=
er=20
>>>>> >> gets the result back (which he the
>>>>> n
>>>>> >    a
>>>>> >> gain needs to understand) in order to                              =
                 make a meaningful authorization decision.
>>>>> >>
>>>>> >> Everyone agreed that the client must receive the session key from t=
he authorization server and that this approach has to be standardized. It wa=
s also agreed that this is a common approach among all three key distributio=
n mechanisms.
>>>>> >>
>>>>> >> Hannes asked the participants to think about their preference.
>>>>> >>
>>>>> >> The questions regarding key naming and                             =
                  the indication for the intended resource server           =
                                    the client wants to talk                =
                               to have been postponed.
>>>>> >>
>>>>> >> 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
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> 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
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20

--Apple-Mail-ADA71B80-EC28-4B76-89E1-E468BF4D4FA9
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I don't see oauth1 tokens as a short c=
ut because eran said the token in oauth1 (which is inside the oauth1 spec) h=
ad many implementation problems by client developers. Why go there and re-in=
vent what jwt could do easily?

Do you need hok? Do you need replay pr=
otection? Do you need message signing? Are asymmetric keys needed?  I g=
et the impression the group is less interested in the last two. <=
div>
There is also key distribution to resource server. I thin=
k we have client nailed but getting keys to resource server needs some discu=
ssion - especially if the path is through the token itself.  

I suppose we can move faster if we assume rs obtains ke=
ys in an unspecified manner like what happened in oauth1. 
Phil
Sent from my phone.
On 2013-02-15, at 22:02, William Mills <wmills_92105@yahoo.com> wrote:

Al=
l the same concepts/info are available in the AS: client ID, client auth, an=
d can deliver both token and secret.  What's magic once the client has t=
he token that's missing?

  From: Phil Hunt <phil.hunt@oracle.com>
 To: William Mills <wmills_92105@yahoo.com> 
Cc: Justin Richer <jricher@mitre.org>; Tim Bray <twbray@google.com>; IETF oauth WG <oauth@ietf.org> 
 Sent: Friday, February 15, 2013 1:52 PM
 Subject: Re: [OAUTH-WG] Minutes fr=
om the OAuth Design Team Conference Call - 11th February 2013

Sorry. I have to disagree. The w=
ay 1.0 is written, it is not a shortcut to turn it into a token for 2. =

Phil
Sent from my phone.

On 2=
013-02-15, at 13:04, William Mills <wmills_92105@yahoo.com> wrote:

>I've brought it up before,
 but I think it might be worthwhile, at least as an exercise, to define a me=
thod to get OAuth1-style tokens from an OAuth2 token endpoint. You'd defer t=
o OAuth1 for how to use them >with a protected resource.

YES!

  From: Justin Richer <jricher@mitre.org>
 To: Tim Bray <t=
wbray@google.com> 
Cc:=
 William Mills <wmills_921=
05@yahoo.com>; IETF oauth WG <oauth@iet=
f.org> 
 Sent: Fri=
day, February 15, 2013 12:54 PM
 Sub=
ject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conferenc=
e Call - 11th February 2013

=

 =20

   =20
 =20

    So that you can fetch and manage all your tokens using the same code
    paths as the OAuth2 services. The "get a token" part will be
    identical to Oauth2 Bearer (except for some details of what comes
    back from the token endpoint, of course), it's the "use a token" bit
    that really changes and is up in the air. You get to use scopes, and
    state, and refresh tokens, and all the other good stuff.

    I've brought it up before, but I think it might be worthwhile, at
    least as an exercise, to define a method to get OAuth1-style tokens
    from an OAuth2 token endpoint. You'd defer to OAuth1 for how to use
    them with a protected resource.

     -- Justin

    On 02/15/2013 11:49 AM, Tim B=
ray wrote:

     =20
      Not deeply acquainted with the Flickr scenario, but it occurs to
      me to ask: If OAuth 1.0 is working well for them, why don=E2=80=99t th=
ey
      just keep using it?  I.e. if there=E2=80=99s already a good solut=
ion in
      place for people who require secure authn/authz over insecure
      channels, why would we go the extra work of duplicating that in
      OAuth 2 territory? -T

      On Fri, Feb 15, 2013 at 8:09 AM=
, William
        Mills <wmills_92105@yahoo.com>
        wrote:

              I'll repeat the use case for Flickr, which
                  requires OAuth 1.0a type capabilites that OAuth 2 does
                  not provide.  Simply stating "move to HTTPS" is not a=

                  viable response here.  

 From:=

                      Torsten Lodderstedt <torsten@lodderstedt.net>

                      To:
                      William Mills <wmills_92105@yahoo.com> 

                      Cc:
                      Mike Jones <Michael.Jones@microsoft.com>;
                      Justin Richer <jri=
cher@mitre.org>;
                      Phil Hunt <p=
hil.hunt@oracle.com>;
                      IETF oauth WG <oauth@iet=
f.org>

                      Sent:
                      Friday, February 15, 2013 7:22 AM

                      Subject:
                      Re: [OAUTH-WG] Minutes from the OAuth Design Team
                      Conference Call - 11th February 2013

                      Hi Bill,

                      I think one needs to compare the costs/impact
                        of HTTPS on one side and the implementation of
                        integrity protection and replay detection on the
                        other. We had this discussion several times.

                      regards,
                      Torsten.

                        Am 15.02.2013 um 08:08 schrieb William Mills
                        <wmill=
s_92105@yahoo.com>:

                            I fundamentally disagree with
                                that too.  OAuth 2 is the *framework*,
                                one which supports multiple token types.
                                 Bearer tokens were the first credentia=
l
                                type defined.

                              OAuth 1.0a also requires HTTPS
                                transport for authentication and getting
                                the token.

                            There
                                are  real use cases for tokens usable
                                over plain text with integrity
                                protection.

                              -bill

 From:
                                    Torsten Lodderstedt <torsten@lodderstedt.net>

                                    To:=

                                    William Mills <wmills_92105@yahoo.com>

                                    Cc:=

                                    Mike Jones <Michael.Jones@microsoft.com>;
                                    Justin Richer <jricher@mitre.org>;
                                    Phil Hunt <phil.hunt@oracle.com>;
                                    IETF oauth WG <oauth@ietf.org>

                                    Sen=
t:
                                    Thursday, February 14, 2013 10:05 PM
=

                                    Sub=
ject:
                                    Re: [OAUTH-WG] Minutes from the
                                    OAuth Design Team Conference Call -
                                    11th February 2013

                                    Hi Bill,

                                    OAuth 2.0 took a different
                                      direction by relying on HTTPS to
                                      provide the basic protection. So
                                      the need to have a token, which
                                      can be used for service requests
                                      over plain HTTP is arguable. My
                                      understanding of this activity
                                      was, the intend is to provide
                                      additional protection on top of
                                      HTTPS.

                                    regards,
                                    Torsten.

                                      Am 15.02.2013 um 02:31 schrieb
                                      William Mills <wmills_92105@yahoo.com>:

                                          I disagree with "That
                                              was the impediment to
                                              OAuth 1.0 adoption that
                                              OAuth 2.0 solved in the
                                              first place.", unless
                                              "solving" means does not
                                              address the need for it at
                                              all.

                                            OAuth
                                              2 does several good
                                              things, but it still lacks
                                              a defined token type that
                                              is safe to user over plain
                                              text HTTP.  1.0a solved
                                              that.

 From: Mike Jones <Michael.Jones@microsoft.com>

                                                  To:
                                                  Justin Richer <jricher@mitre.org>;
                                                  Phil Hunt <phil.hunt@oracle.com>

                                                  Cc:
                                                  IETF oauth WG <oauth@ietf.org>

                                                  Sent:
                                                  Thursday, February 14,
                                                  2013 1:44 PM

                                                  Subject:
                                                  Re: [OAUTH-WG] Minutes
                                                  from the OAuth Design
                                                  Team Conference Call -
                                                  11th February 2013

                                              I'm in favor of reusing
                                              the JWT work that this WG
                                              is also doing. :-)

                                              I'm pretty skeptical of us
                                              inventing another custom
                                              scheme for signing HTTP
                                              headers.  That was the
                                              impediment to OAuth 1.0
                                              adoption that OAuth 2.0
                                              solved in the first place.
=

                                                    =
;          -- Mike

                                              -----Original Message-----
=

                                              From: oauth-bounces@ietf.org
                                              [mailto:oauth-bounces@ietf.org]
                                              On Behalf Of Justin Richer
=

                                              Sent: Tuesday, February
                                              12, 2013 9:35 AM

                                              To: Phil Hunt

                                              Cc: IETF oauth WG

                                              Subject: Re: [OAUTH-WG]
                                              Minutes from the OAuth
                                              Design Team Conference
                                              Call - 11th February 2013

                                              That's my reading of it as
                                              well, Phil, thanks for
                                              providing the
                                              clarification. One
                                              motivator behind using a
                                              JSON-based token is to be
                                              able to re-use some of the
                                              great work that the JOSE
                                              group is doing but apply
                                              it to an HTTP payload.

                                              What neither of us want is
                                              a token type that requires
                                              stuffing all query,
                                              header, and other
                                              parameters *into* the JSON
                                              object itself, which would
                                              be a more SOAPy approach.

                                                -- Justin

                                              On 02/12/2013 12:30 PM,
                                              Phil Hunt wrote:

                                              > Clarification.  I
                                              think Justin and I were in
                                              agreement that we don't
                                              want to see a format that
                                              requires JSON payloads. 
                                              We are both interested in
                                              a JSON token used in the
                                              authorization header that
                                              could be based on a
                                              computed signature of some
                                              combination of http
                                              headers and body if
                                              possible.

                                              >

                                              > Phil

                                              >

                                              > @independentid

                                              > www.independentid.com

                                              > phil.hunt@oracle.com

                                              >

                                              >

                                              >

                                              >

                                              >

                                              > On 2013-02-12, at
                                              1:10 AM, Hannes Tschofenig
                                              wrote:

                                              >

                                              >> Here are my
                                              notes.

                                              >>

                                              >> Participants:

                                              >>

                                              >> * John Bradley

                                              >> * Derek Atkins

                                              >> * Phil Hunt

                                              >> * Prateek Mishra

                                              >> * Hannes
                                              Tschofenig

                                              >> * Mike Jones

                                              >> * Antonio Sanso

                                              >> * Justin Richer

                                              >>

                                              >> Notes:

                                              >>

                                              >> My slides are
                                              available here: 

                                              >> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
                                              >>

                                              >> Slide #2
                                              summarizes earlier
                                              discussions during the
                                              conference calls.

                                              >>

                                              >> -- HTTP vs. JSON

                                              >>

                                              >> Phil noted that
                                              he does not like to use
                                              the MAC Token draft as a
                                              starting point because it
                                              does not re-use any of the
                                              work done in the JOSE
                                              working group and in
                                              particular all the
                                              libraries that are
                                              available today. He
                                              mentioned that earlier
                                              attempts to write the MAC
                                              Token code lead to
                                              problems for implementers.
=

                                              >>

                                              >> Justin responded
                                              that he does not agree
                                              with using JSON as a
                                              transport mechanism since
                                              this would replicate a
                                              SOAP style.

                                              >>

                                              >> Phil noted that
                                              he wants to send JSON but
                                              the signature shall be
                                              computed over the HTTP
                                              header field.

                                              >>

                                              >> -- Flexibility
                                              for the keyed message
                                              digest computation

                                              >>

                                              >>  =46rom earlier
                                              discussion it was clear
                                              that the conference call
                                              participants wanted more
                                              flexibility regarding the
                                              keyed message digest
                                              computation. For this
                                              purpose Hannes presented
                                              the DKIM based approach,
                                              which allows selective
                                              header fields to be
                                              included in the digest.
                                              This is shown in slide #4.
=

                                              >>

                                              >> After some
                                              discussion the conference
                                              call participants thought
                                              that this would meet their
                                              needs. Further
                                              investigations would still
                                              be useful to determine the
                                              degree of failed HMAC
                                              calculations due to HTTP
                                              proxies modifying the
                                              content.

                                              >>

                                              >> -- Key
                                              Distribution

                                              >>

                                              >> Hannes presented
                                              the open issue regarding
                                              the choice of key 

                                              >> distribution.
                                              Slides #6-#8 present three
                                              techniques and Hannes
                                              asked 

                                              >> for feedback
                                              regarding the preferred
                                              style. Justin and others
                                              didn't 

                                              >> see the need to
                                              decide on one mechanism -
                                              they wanted to keep the 

                                              >> choice open.
                                              Derek indicated that this
                                              will not be an acceptable

                                              >> approach. Since
                                              the resource server and
                                              the authorization server
                                              may, 

                                              >> in the OAuth 2.0
                                              framework, be entities
                                              produced by different
                                              vendors 

                                              >> there is an
                                              interoperability need.
                                              Justin responded that he
                                              disagrees 

                                              >> and that the
                                              resource server needs to
                                              understand the access
                                              token and 

                                              >> referred to the
                                              recent draft submission
                                              for the token
                                              introspection 

                                              >> endpoint. Derek
                                              indicated that the
                                              resource server has to
                                              understand 

                                              >> the content of
                                              the access token and the
                                              token introspection
                                              endpoint 

                                              >> just pushes the
                                              problem around: the
                                              resource server has to
                                              send the 

                                              >> access token to
                                              the authorization server
                                              and then the resource
                                              server 

                                              >> gets the result
                                              back (which he the

                                              n

                                              >    a

                                              >> gain needs to
                                              understand) in order to
                                              make a meaningful
                                              authorization decision.

                                              >>

                                              >> Everyone agreed
                                              that the client must
                                              receive the session key
                                              from the authorization
                                              server and that this
                                              approach has to be
                                              standardized. It was also
                                              agreed that this is a
                                              common approach among all
                                              three key distribution
                                              mechanisms.

                                              >>

                                              >> Hannes asked the
                                              participants to think
                                              about their preference.

                                              >>

                                              >> The questions
                                              regarding key naming and
                                              the indication for the
                                              intended resource server
                                              the client wants to talk
                                              to have been postponed.

                                              >>

                                              >> Ciao

                                              >> Hannes

                                              >>

                                              >>

                                              >>
                                              ______________________________=
_________________

                                              >> OAuth mailing
                                              list

                                              >> OAuth@ietf.org

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

                                              >
                                              ______________________________=
_________________

                                              > OAuth mailing list

                                              > OAuth@ietf.org

                                              > https://ww=
w.ietf.org/mailman/listinfo/oauth

_______________________________________________

                                              OAuth mailing list

                                              OAu=
th@ietf.org

                                              https://www.iet=
f.org/mailman/listinfo/oauth

_______________________________________________

                                              OAuth mailing list

                                              OAu=
th@ietf.org

                                              https://www.iet=
f.org/mailman/listinfo/oauth

                                      ___________________________=
____________________

                                        OAuth mailing list

                                        OAu=
th@ietf.org

                                        https://www.iet=
f.org/mailman/listinfo/oauth

          _______________________________________________

          OAuth mailing list

          OAuth@ietf.org

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

      _______________________________________________
OAuth mailing list
OAu=
th@ietf.org
https://www.ietf.=
org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf=
.org
https://www.ietf.org/mailman/listinf=
o/oauth

   =

=

--Apple-Mail-ADA71B80-EC28-4B76-89E1-E468BF4D4FA9--

From zhou.sujing@zte.com.cn  Sat Feb 16 00:03:05 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E19C21F86CA; Sat, 16 Feb 2013 00:03:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.095
X-Spam-Level: 
X-Spam-Status: No, score=-98.095 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9gLgcF7qaCv; Sat, 16 Feb 2013 00:03:04 -0800 (PST)
Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 8757B21F8569; Sat, 16 Feb 2013 00:03:03 -0800 (PST)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 5D1FE18D3B; Sat, 16 Feb 2013 16:02:34 +0800 (CST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 1D9551F9929; Sat, 16 Feb 2013 16:00:09 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id r1G82cA3055373; Sat, 16 Feb 2013 16:02:38 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net>
To: Hannes Tschofenig 
MIME-Version: 1.0
X-KeepSent: 79A4CFF7:0B281747-48257B14:00269677; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: zhou.sujing@zte.com.cn
Date: Sat, 16 Feb 2013 16:02:20 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-02-16 16:02:17, Serialize complete at 2013-02-16 16:02:17
Content-Type: multipart/alternative; boundary="=_alternative 002C396D48257B14_="
X-MAIL: mse01.zte.com.cn r1G82cA3055373
Cc: IETF oauth WG , oauth-bounces@ietf.org
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Feb 2013 08:03:05 -0000

This is a multipart message in MIME format.
--=_alternative 002C396D48257B14_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

V2hvIGhhcyBhIHJhdGhlciBkZXRhaWxlZCBkZXNjcmlwdGlvbiBhYm91dCB0aGUgdGhyZWUga2V5
IGRpc3RyaWJ1dGlvbiANCm1hY2hhbmlzbXM/DQpQbGVhc2UgdGVsbCBtZSBpZiBJIGFtIHdyb25n
IGluIHVuZGVyc3RhbmRpbmcgdGhlbSBvbmx5IGZyb20gdGhlIHBwdCBhbmQgDQpwcmV2aW91c2Ug
bWFjIGFuZCBob3RrIGRvY3VtZW50Og0KDQoxLiBUaGUga2V5IGRpc3RyaWJ1dHVvbiBtZWFucyBB
UyBkaXN0cmlidXRpbmcgYSBzaG9ydC10ZXJtLWtleSAgdG8gY2xpZW50IA0KYW5kIFJTOw0KMi4g
QVMgYW5kIFJTIGhhcyBhbm90aGVyIHdheSBvZiBzaGFyaW5nIGEgbG9uZy10ZXJtLWtleSB3aGlj
aCBpcyBub3QgDQpjb3ZlcmVkIGJ5IHRoZSBkZXNpZ24gdGVhbTsNCjMuIENsaWVudC1BUyBhbmQg
Q2xpZW50LVJTICBtYXkgaGF2ZSB0aGVpciB3YXlzIG9mIGF1dGhlbnRpY2F0aW9uICBub3QgDQp1
c2luZyB0aGUgc2hvcnQtdGVybS1rZXk7DQo0LiBzaG9ydC10ZXJtLWtleSBpcyBvbmx5IHVzZWQg
Zm9yIHByb3RlY3RpbmcgYWNjZXNzIHRva2VuIGZyb20gYmVpbmcgDQpzdG9sZW4gb3IgYWJ1c2Vk
IGJ5IGVudGl0aWVzIG90aGVyIHRoYW4gdGhlIGNsaWVudChhcyBiZWFyIHRva2VuKTsNCiAgIHRo
ZW4gdGhlcmUgYXJlIDMgcG9zc2libGUgYXBwcm9hY2hlcyBmb3IgZ2VuZXJhdGluZyBhbiBhY2Nl
c3MgdG9rZW4gDQooc3VwcG9zZSBzaG9ydC10ZXJtLWtleSBpcyBpcnJlbGV2YW50IHdpdGggbG9u
Zy10ZXJtLWtleSk6DQogICAxKSBhY2Nlc3MgdG9rZW49RiguLi4sc2hvcnQtdGVybS1rZXkpIC8v
IG5vdCBzZWN1cmUsIGFuZCBlcXVpdmFsZW50IHRvIA0KdGhlIGNhc2UgdGhhdCBhY2Nlc3MgdG9r
ZW4gYmVpbmcgc2hvcnQtdGVybS1rZXkNCiAgIDIpIGFjY2VzcyB0b2tlbj1GKC4uLixsb25ndC10
ZXJtLWtleSkgLy9wYXNzLiBmb3Igbm8gc2hvcnQtdGVybS1rZXkgaXMgDQppbnZsb3ZlZCANCiAg
IDMpIGFjY2VzcyB0b2tlbj1GKC4uLixzaG9ydC10ZXJtLWtleSxsb25nLXRlcm0ta2V5KS8vIEkg
Z3Vlc3MgdGhpcyBjYXNlIA0KaXMgdGhlIGJhc2Ugb24gd2hpY2ggdGhlIGRlc2lnbiB0ZWFtIGlz
IGRpc2N1c3NpbmcgPw0KDQogQmFzZWQgb24gdGhlIGFib3ZlIHByZS1hc3N1bXB0aW9uLHRoZSBm
b2xsb3dpbmcgaXMgbXkgb3BpbmlvbiBvbiB0aGUgMyANCmtleSBkaXN0cmlidXRpb24gbWVjaGFu
aXNtczoNCmtleS10cmFuc3BvcnQ6IGluIHRoaXMgbWVhY2hhbmlzbSBzaG9ydC10ZXJtLWtleSBp
cyB0cmFuc3BvcnRlZCBmcm9tIEFTIHRvIA0KY2xpZW50LCB0aGVuIHRvIFJTLA0KICAgICAgICAg
ICAgICAgc2hvcnQtdGVybS1rZXkgY291bGQgYmUgdHJhbnNwb3J0ZWQgaW5zaWRlIG9yIG91dHNp
ZGUgb2YgDQphY2Nlc3MgdG9rZW4sIHdoaWNoIGlzIG5vIGJpZyBkaWZmZXJlbmNlLA0KICAgICAg
ICAgICAgICAgdGhlIHNlY3VyaXR5IG9mIHRoaXMgbWVjaGEgaXMgYWN0dWFsbHkgZ3VhcmFudGVl
ZCBieSANCmxvbmctdGVybS1rZXk7DQprZXktcmV0cmlldmFsOiBzaG9ydC10ZXJtLWtleSBpcyBv
YnRhaW5lZCBmcm9tIEFTICBieSBSUyBkaXJlY3RseSwgaXQgaXMgDQptb3JlIHNlY3VyZSwgYnV0
IG5lZWQgYW4gZXh0cmEgaW5mb3JtYXRpb24gZXhjaGFuZ2UgYmV0d2VlbiBSUyBhbmQgQVMgZWFj
aCANCnRpbWUgQ2xpZW50IGlzIHJlcXVlc3RpbmcgcmVzb3VyY2UgdG8gUlMuDQoNCmtleS1hZ3Jl
ZW1lbnQ6IHNob3J0LXRlcm0ta2V5IGNvdWxkIGJlIGRlcml2ZWQgZnJvbSBsb25nLXRlcm0ta2V5
IGFuZCBzb21lIA0Kb3RoZXIgaW5mb3JtYXRpb24gaW5jbHVkZWQgaW4gKG9yIGFjY29tcGFueWlu
ZykgYWNjZXNzIHRva2VuLA0KICAgICAgICAgICAgICAgdGhpcyBtZWNoYSBpcyBhY3R1YWxseSBu
b3QgZGlmZmVyZW50IGZyb20gY2FzZSAyKSBhYm92ZSwgDQp0aGF0IGlzIG5vIHNob3J0LXRlcm0t
a2V5IGlzIHJlcXVpcmVkIHRvIHNlbmQgYWN0dWFsbHkuIA0KIA0KDQoNCm9hdXRoLWJvdW5jZXNA
aWV0Zi5vcmcg0LTT2iAyMDEzLTAyLTEyIDE3OjEwOjI3Og0KDQo+IEhlcmUgYXJlIG15IG5vdGVz
LiANCj4gDQo+IFBhcnRpY2lwYW50czoNCj4gDQo+ICogSm9obiBCcmFkbGV5DQo+ICogRGVyZWsg
QXRraW5zDQo+ICogUGhpbCBIdW50DQo+ICogUHJhdGVlayBNaXNocmENCj4gKiBIYW5uZXMgVHNj
aG9mZW5pZw0KPiAqIE1pa2UgSm9uZXMNCj4gKiBBbnRvbmlvIFNhbnNvDQo+ICogSnVzdGluIFJp
Y2hlcg0KPiANCj4gTm90ZXM6IA0KPiANCj4gTXkgc2xpZGVzIGFyZSBhdmFpbGFibGUgaGVyZTog
aHR0cDovL3d3dy50c2Nob2ZlbmlnLnByaXYuYXQvT0F1dGgyLQ0KPiBTZWN1cml0eS0xMUZlYjIw
MTMucHB0DQo+IA0KPiBTbGlkZSAjMiBzdW1tYXJpemVzIGVhcmxpZXIgZGlzY3Vzc2lvbnMgZHVy
aW5nIHRoZSBjb25mZXJlbmNlIGNhbGxzLiANCj4gDQo+IC0tIEhUVFAgdnMuIEpTT04NCj4gDQo+
IFBoaWwgbm90ZWQgdGhhdCBoZSBkb2VzIG5vdCBsaWtlIHRvIHVzZSB0aGUgTUFDIFRva2VuIGRy
YWZ0IGFzIGEgDQo+IHN0YXJ0aW5nIHBvaW50IGJlY2F1c2UgaXQgZG9lcyBub3QgcmUtdXNlIGFu
eSBvZiB0aGUgd29yayBkb25lIGluIA0KPiB0aGUgSk9TRSB3b3JraW5nIGdyb3VwIGFuZCBpbiBw
YXJ0aWN1bGFyIGFsbCB0aGUgbGlicmFyaWVzIHRoYXQgYXJlIA0KPiBhdmFpbGFibGUgdG9kYXku
IEhlIG1lbnRpb25lZCB0aGF0IGVhcmxpZXIgYXR0ZW1wdHMgdG8gd3JpdGUgdGhlIE1BQw0KPiBU
b2tlbiBjb2RlIGxlYWQgdG8gcHJvYmxlbXMgZm9yIGltcGxlbWVudGVycy4gDQo+IA0KPiBKdXN0
aW4gcmVzcG9uZGVkIHRoYXQgaGUgZG9lcyBub3QgYWdyZWUgd2l0aCB1c2luZyBKU09OIGFzIGEg
DQo+IHRyYW5zcG9ydCBtZWNoYW5pc20gc2luY2UgdGhpcyB3b3VsZCByZXBsaWNhdGUgYSBTT0FQ
IHN0eWxlLiANCj4gDQo+IFBoaWwgbm90ZWQgdGhhdCBoZSB3YW50cyB0byBzZW5kIEpTT04gYnV0
IHRoZSBzaWduYXR1cmUgc2hhbGwgYmUgDQo+IGNvbXB1dGVkIG92ZXIgdGhlIEhUVFAgaGVhZGVy
IGZpZWxkLiANCj4gDQo+IC0tIEZsZXhpYmlsaXR5IGZvciB0aGUga2V5ZWQgbWVzc2FnZSBkaWdl
c3QgY29tcHV0YXRpb24NCj4gDQo+IEZyb20gZWFybGllciBkaXNjdXNzaW9uIGl0IHdhcyBjbGVh
ciB0aGF0IHRoZSBjb25mZXJlbmNlIGNhbGwgDQo+IHBhcnRpY2lwYW50cyB3YW50ZWQgbW9yZSBm
bGV4aWJpbGl0eSByZWdhcmRpbmcgdGhlIGtleWVkIG1lc3NhZ2UgDQo+IGRpZ2VzdCBjb21wdXRh
dGlvbi4gRm9yIHRoaXMgcHVycG9zZSBIYW5uZXMgcHJlc2VudGVkIHRoZSBES0lNIGJhc2VkDQo+
IGFwcHJvYWNoLCB3aGljaCBhbGxvd3Mgc2VsZWN0aXZlIGhlYWRlciBmaWVsZHMgdG8gYmUgaW5j
bHVkZWQgaW4gdGhlDQo+IGRpZ2VzdC4gVGhpcyBpcyBzaG93biBpbiBzbGlkZSAjNC4gDQo+IA0K
PiBBZnRlciBzb21lIGRpc2N1c3Npb24gdGhlIGNvbmZlcmVuY2UgY2FsbCBwYXJ0aWNpcGFudHMg
dGhvdWdodCB0aGF0IA0KPiB0aGlzIHdvdWxkIG1lZXQgdGhlaXIgbmVlZHMuIEZ1cnRoZXIgaW52
ZXN0aWdhdGlvbnMgd291bGQgc3RpbGwgYmUgDQo+IHVzZWZ1bCB0byBkZXRlcm1pbmUgdGhlIGRl
Z3JlZSBvZiBmYWlsZWQgSE1BQyBjYWxjdWxhdGlvbnMgZHVlIHRvIA0KPiBIVFRQIHByb3hpZXMg
bW9kaWZ5aW5nIHRoZSBjb250ZW50LiANCj4gDQo+IC0tIEtleSBEaXN0cmlidXRpb24NCj4gDQo+
IEhhbm5lcyBwcmVzZW50ZWQgdGhlIG9wZW4gaXNzdWUgcmVnYXJkaW5nIHRoZSBjaG9pY2Ugb2Yg
a2V5IA0KPiBkaXN0cmlidXRpb24uIFNsaWRlcyAjNi0jOCBwcmVzZW50IHRocmVlIHRlY2huaXF1
ZXMgYW5kIEhhbm5lcyBhc2tlZA0KPiBmb3IgZmVlZGJhY2sgcmVnYXJkaW5nIHRoZSBwcmVmZXJy
ZWQgc3R5bGUuIEp1c3RpbiBhbmQgb3RoZXJzIGRpZG4ndA0KPiBzZWUgdGhlIG5lZWQgdG8gZGVj
aWRlIG9uIG9uZSBtZWNoYW5pc20gLSB0aGV5IHdhbnRlZCB0byBrZWVwIHRoZSANCj4gY2hvaWNl
IG9wZW4uIERlcmVrIGluZGljYXRlZCB0aGF0IHRoaXMgd2lsbCBub3QgYmUgYW4gYWNjZXB0YWJs
ZSANCj4gYXBwcm9hY2guIFNpbmNlIHRoZSByZXNvdXJjZSBzZXJ2ZXIgYW5kIHRoZSBhdXRob3Jp
emF0aW9uIHNlcnZlciANCj4gbWF5LCBpbiB0aGUgT0F1dGggMi4wIGZyYW1ld29yaywgYmUgZW50
aXRpZXMgcHJvZHVjZWQgYnkgZGlmZmVyZW50IA0KPiB2ZW5kb3JzIHRoZXJlIGlzIGFuIGludGVy
b3BlcmFiaWxpdHkgbmVlZC4gSnVzdGluIHJlc3BvbmRlZCB0aGF0IGhlIA0KPiBkaXNhZ3JlZXMg
YW5kIHRoYXQgdGhlIHJlc291cmNlIHNlcnZlciBuZWVkcyB0byB1bmRlcnN0YW5kIHRoZSANCj4g
YWNjZXNzIHRva2VuIGFuZCByZWZlcnJlZCB0byB0aGUgcmVjZW50IGRyYWZ0IHN1Ym1pc3Npb24g
Zm9yIHRoZSANCj4gdG9rZW4gaW50cm9zcGVjdGlvbiBlbmRwb2ludC4gRGVyZWsgaW5kaWNhdGVk
IHRoYXQgdGhlIHJlc291cmNlIA0KPiBzZXJ2ZXIgaGFzIHRvIHVuZGVyc3RhbmQgdGhlIGNvbnRl
bnQgb2YgdGhlIGFjY2VzcyB0b2tlbiBhbmQgdGhlIA0KPiB0b2tlbiBpbnRyb3NwZWN0aW9uIGVu
ZHBvaW50IGp1c3QgcHVzaGVzIHRoZSBwcm9ibGVtIGFyb3VuZDogdGhlIA0KPiByZXNvdXJjZSBz
ZXJ2ZXIgaGFzIHRvIHNlbmQgdGhlIGFjY2VzcyB0b2tlbiB0byB0aGUgYXV0aG9yaXphdGlvbiAN
Cj4gc2VydmVyIGFuZCB0aGVuIHRoZSByZXNvdXJjZSBzZXJ2ZXIgZ2V0cyB0aGUgcmVzdWx0IGJh
Y2sgKHdoaWNoIGhlIHRoZW4gDQphDQo+ICBnYWluIG5lZWRzIHRvIHVuZGVyc3RhbmQpIGluIG9y
ZGVyIHRvIG1ha2UgYSBtZWFuaW5nZnVsIA0KPiBhdXRob3JpemF0aW9uIGRlY2lzaW9uLiANCj4g
DQo+IEV2ZXJ5b25lIGFncmVlZCB0aGF0IHRoZSBjbGllbnQgbXVzdCByZWNlaXZlIHRoZSBzZXNz
aW9uIGtleSBmcm9tIA0KPiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHRoYXQgdGhpcyBh
cHByb2FjaCBoYXMgdG8gYmUgDQo+IHN0YW5kYXJkaXplZC4gSXQgd2FzIGFsc28gYWdyZWVkIHRo
YXQgdGhpcyBpcyBhIGNvbW1vbiBhcHByb2FjaCANCj4gYW1vbmcgYWxsIHRocmVlIGtleSBkaXN0
cmlidXRpb24gbWVjaGFuaXNtcy4NCj4gDQo+IEhhbm5lcyBhc2tlZCB0aGUgcGFydGljaXBhbnRz
IHRvIHRoaW5rIGFib3V0IHRoZWlyIHByZWZlcmVuY2UuIA0KPiANCj4gVGhlIHF1ZXN0aW9ucyBy
ZWdhcmRpbmcga2V5IG5hbWluZyBhbmQgdGhlIGluZGljYXRpb24gZm9yIHRoZSANCj4gaW50ZW5k
ZWQgcmVzb3VyY2Ugc2VydmVyIHRoZSBjbGllbnQgd2FudHMgdG8gdGFsayB0byBoYXZlIGJlZW4g
DQpwb3N0cG9uZWQuIA0KPiANCj4gQ2lhbw0KPiBIYW5uZXMNCj4gDQo+IA0KPiBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPQXV0aCBtYWlsaW5nIGxp
c3QNCj4gT0F1dGhAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vYXV0aA0KDQo=
--=_alternative 002C396D48257B14_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPldobyBoYXMgYSByYXRoZXIgZGV0
YWlsZWQgZGVzY3JpcHRpb24NCmFib3V0IHRoZSB0aHJlZSBrZXkgZGlzdHJpYnV0aW9uIG1hY2hh
bmlzbXM/PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5QbGVhc2Ug
dGVsbCBtZSBpZiBJIGFtIHdyb25nIGluIHVuZGVyc3RhbmRpbmcNCnRoZW0gb25seSBmcm9tIHRo
ZSBwcHQgYW5kIHByZXZpb3VzZSBtYWMgYW5kIGhvdGsgZG9jdW1lbnQ6PC9mb250Pg0KPGJyPg0K
PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4xLiBUaGUga2V5IGRpc3RyaWJ1dHVv
biBtZWFucyBBUyBkaXN0cmlidXRpbmcNCmEgc2hvcnQtdGVybS1rZXkgJm5ic3A7dG8gY2xpZW50
IGFuZCBSUzs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjIuIEFT
IGFuZCBSUyBoYXMgYW5vdGhlciB3YXkgb2Ygc2hhcmluZw0KYSBsb25nLXRlcm0ta2V5IHdoaWNo
IGlzIG5vdCBjb3ZlcmVkIGJ5IHRoZSBkZXNpZ24gdGVhbTs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6
ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjMuIENsaWVudC1BUyBhbmQgQ2xpZW50LVJTICZuYnNwO21h
eQ0KaGF2ZSB0aGVpciB3YXlzIG9mIGF1dGhlbnRpY2F0aW9uICZuYnNwO25vdCB1c2luZyB0aGUg
c2hvcnQtdGVybS1rZXk7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm
Ij40LiBzaG9ydC10ZXJtLWtleSBpcyBvbmx5IHVzZWQgZm9yIHByb3RlY3RpbmcNCmFjY2VzcyB0
b2tlbiBmcm9tIGJlaW5nIHN0b2xlbiBvciBhYnVzZWQgYnkgZW50aXRpZXMgb3RoZXIgdGhhbiB0
aGUgY2xpZW50KGFzDQpiZWFyIHRva2VuKTs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9
InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDt0aGVuIHRoZXJlIGFyZSAzIHBvc3NpYmxlDQphcHBy
b2FjaGVzIGZvciBnZW5lcmF0aW5nIGFuIGFjY2VzcyB0b2tlbiAoc3VwcG9zZSBzaG9ydC10ZXJt
LWtleSBpcyBpcnJlbGV2YW50DQp3aXRoIGxvbmctdGVybS1rZXkpOjwvZm9udD4NCjxicj48Zm9u
dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOzEpIGFjY2VzcyB0b2tlbj1G
KC4uLixzaG9ydC10ZXJtLWtleSkNCi8vIG5vdCBzZWN1cmUsIGFuZCBlcXVpdmFsZW50IHRvIHRo
ZSBjYXNlIHRoYXQgYWNjZXNzIHRva2VuIGJlaW5nIHNob3J0LXRlcm0ta2V5PC9mb250Pg0KPGJy
Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7MikgYWNjZXNzIHRv
a2VuPUYoLi4uLGxvbmd0LXRlcm0ta2V5KQ0KLy9wYXNzLiBmb3Igbm8gc2hvcnQtdGVybS1rZXkg
aXMgaW52bG92ZWQgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4m
bmJzcDsgJm5ic3A7MykgYWNjZXNzIHRva2VuPUYoLi4uLHNob3J0LXRlcm0ta2V5LGxvbmctdGVy
bS1rZXkpLy8NCkkgZ3Vlc3MgdGhpcyBjYXNlIGlzIHRoZSBiYXNlIG9uIHdoaWNoIHRoZSBkZXNp
Z24gdGVhbSBpcyBkaXNjdXNzaW5nID88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh
Y2U9InNhbnMtc2VyaWYiPiZuYnNwO0Jhc2VkIG9uIHRoZSBhYm92ZSBwcmUtYXNzdW1wdGlvbix0
aGUNCmZvbGxvd2luZyBpcyBteSBvcGluaW9uIG9uIHRoZSAzIGtleSBkaXN0cmlidXRpb24gbWVj
aGFuaXNtczo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmtleS10
cmFuc3BvcnQ6IGluIHRoaXMgbWVhY2hhbmlzbSBzaG9ydC10ZXJtLWtleQ0KaXMgdHJhbnNwb3J0
ZWQgZnJvbSBBUyB0byBjbGllbnQsIHRoZW4gdG8gUlMsPC9mb250Pg0KPGJyPjxmb250IHNpemU9
MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOw0KJm5ic3A7ICZuYnNwO3Nob3J0LXRlcm0ta2V5IGNvdWxkIGJlIHRyYW5zcG9ydGVkIGlu
c2lkZSBvciBvdXRzaWRlIG9mIGFjY2Vzcw0KdG9rZW4sIHdoaWNoIGlzIG5vIGJpZyBkaWZmZXJl
bmNlLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDt0aGUgc2VjdXJp
dHkgb2YgdGhpcyBtZWNoYSBpcyBhY3R1YWxseSBndWFyYW50ZWVkIGJ5IGxvbmctdGVybS1rZXk7
PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5rZXktcmV0cmlldmFs
OiBzaG9ydC10ZXJtLWtleSBpcyBvYnRhaW5lZA0KZnJvbSBBUyAmbmJzcDtieSBSUyBkaXJlY3Rs
eSwgaXQgaXMgbW9yZSBzZWN1cmUsIGJ1dCBuZWVkIGFuIGV4dHJhIGluZm9ybWF0aW9uDQpleGNo
YW5nZSBiZXR3ZWVuIFJTIGFuZCBBUyBlYWNoIHRpbWUgQ2xpZW50IGlzIHJlcXVlc3RpbmcgcmVz
b3VyY2UgdG8gUlMuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl
cmlmIj5rZXktYWdyZWVtZW50OiBzaG9ydC10ZXJtLWtleSBjb3VsZA0KYmUgZGVyaXZlZCBmcm9t
IGxvbmctdGVybS1rZXkgYW5kIHNvbWUgb3RoZXIgaW5mb3JtYXRpb24gaW5jbHVkZWQgaW4gKG9y
DQphY2NvbXBhbnlpbmcpIGFjY2VzcyB0b2tlbiw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh
Y2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
DQombmJzcDsgJm5ic3A7dGhpcyBtZWNoYSBpcyBhY3R1YWxseSBub3QgZGlmZmVyZW50IGZyb20g
Y2FzZSAyKSBhYm92ZSwgdGhhdA0KaXMgbm8gc2hvcnQtdGVybS1rZXkgaXMgcmVxdWlyZWQgdG8g
c2VuZCBhY3R1YWxseS4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm
Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNw
OyA8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5vYXV0aC1ib3VuY2Vz
QGlldGYub3JnINC009ogMjAxMy0wMi0xMiAxNzoxMDoyNzo8YnI+DQo8YnI+DQomZ3Q7IEhlcmUg
YXJlIG15IG5vdGVzLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgUGFydGljaXBhbnRzOjxicj4NCiZn
dDsgPGJyPg0KJmd0OyAqIEpvaG4gQnJhZGxleTxicj4NCiZndDsgKiBEZXJlayBBdGtpbnM8YnI+
DQomZ3Q7ICogUGhpbCBIdW50PGJyPg0KJmd0OyAqIFByYXRlZWsgTWlzaHJhPGJyPg0KJmd0OyAq
IEhhbm5lcyBUc2Nob2ZlbmlnPGJyPg0KJmd0OyAqIE1pa2UgSm9uZXM8YnI+DQomZ3Q7ICogQW50
b25pbyBTYW5zbzxicj4NCiZndDsgKiBKdXN0aW4gUmljaGVyPGJyPg0KJmd0OyA8YnI+DQomZ3Q7
IE5vdGVzOiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgTXkgc2xpZGVzIGFyZSBhdmFpbGFibGUgaGVy
ZTogaHR0cDovL3d3dy50c2Nob2ZlbmlnLnByaXYuYXQvT0F1dGgyLTxicj4NCiZndDsgU2VjdXJp
dHktMTFGZWIyMDEzLnBwdDxicj4NCiZndDsgPGJyPg0KJmd0OyBTbGlkZSAjMiBzdW1tYXJpemVz
IGVhcmxpZXIgZGlzY3Vzc2lvbnMgZHVyaW5nIHRoZSBjb25mZXJlbmNlIGNhbGxzLg0KPGJyPg0K
Jmd0OyA8YnI+DQomZ3Q7IC0tIEhUVFAgdnMuIEpTT048YnI+DQomZ3Q7IDxicj4NCiZndDsgUGhp
bCBub3RlZCB0aGF0IGhlIGRvZXMgbm90IGxpa2UgdG8gdXNlIHRoZSBNQUMgVG9rZW4gZHJhZnQg
YXMgYSA8YnI+DQomZ3Q7IHN0YXJ0aW5nIHBvaW50IGJlY2F1c2UgaXQgZG9lcyBub3QgcmUtdXNl
IGFueSBvZiB0aGUgd29yayBkb25lIGluDQo8YnI+DQomZ3Q7IHRoZSBKT1NFIHdvcmtpbmcgZ3Jv
dXAgYW5kIGluIHBhcnRpY3VsYXIgYWxsIHRoZSBsaWJyYXJpZXMgdGhhdCBhcmUNCjxicj4NCiZn
dDsgYXZhaWxhYmxlIHRvZGF5LiBIZSBtZW50aW9uZWQgdGhhdCBlYXJsaWVyIGF0dGVtcHRzIHRv
IHdyaXRlIHRoZSBNQUM8YnI+DQomZ3Q7IFRva2VuIGNvZGUgbGVhZCB0byBwcm9ibGVtcyBmb3Ig
aW1wbGVtZW50ZXJzLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSnVzdGluIHJlc3BvbmRlZCB0aGF0
IGhlIGRvZXMgbm90IGFncmVlIHdpdGggdXNpbmcgSlNPTiBhcyBhIDxicj4NCiZndDsgdHJhbnNw
b3J0IG1lY2hhbmlzbSBzaW5jZSB0aGlzIHdvdWxkIHJlcGxpY2F0ZSBhIFNPQVAgc3R5bGUuIDxi
cj4NCiZndDsgPGJyPg0KJmd0OyBQaGlsIG5vdGVkIHRoYXQgaGUgd2FudHMgdG8gc2VuZCBKU09O
IGJ1dCB0aGUgc2lnbmF0dXJlIHNoYWxsIGJlIDxicj4NCiZndDsgY29tcHV0ZWQgb3ZlciB0aGUg
SFRUUCBoZWFkZXIgZmllbGQuIDxicj4NCiZndDsgPGJyPg0KJmd0OyAtLSBGbGV4aWJpbGl0eSBm
b3IgdGhlIGtleWVkIG1lc3NhZ2UgZGlnZXN0IGNvbXB1dGF0aW9uPGJyPg0KJmd0OyA8YnI+DQom
Z3Q7IEZyb20gZWFybGllciBkaXNjdXNzaW9uIGl0IHdhcyBjbGVhciB0aGF0IHRoZSBjb25mZXJl
bmNlIGNhbGwgPGJyPg0KJmd0OyBwYXJ0aWNpcGFudHMgd2FudGVkIG1vcmUgZmxleGliaWxpdHkg
cmVnYXJkaW5nIHRoZSBrZXllZCBtZXNzYWdlIDxicj4NCiZndDsgZGlnZXN0IGNvbXB1dGF0aW9u
LiBGb3IgdGhpcyBwdXJwb3NlIEhhbm5lcyBwcmVzZW50ZWQgdGhlIERLSU0gYmFzZWQ8YnI+DQom
Z3Q7IGFwcHJvYWNoLCB3aGljaCBhbGxvd3Mgc2VsZWN0aXZlIGhlYWRlciBmaWVsZHMgdG8gYmUg
aW5jbHVkZWQgaW4gdGhlPGJyPg0KJmd0OyBkaWdlc3QuIFRoaXMgaXMgc2hvd24gaW4gc2xpZGUg
IzQuIDxicj4NCiZndDsgPGJyPg0KJmd0OyBBZnRlciBzb21lIGRpc2N1c3Npb24gdGhlIGNvbmZl
cmVuY2UgY2FsbCBwYXJ0aWNpcGFudHMgdGhvdWdodCB0aGF0DQo8YnI+DQomZ3Q7IHRoaXMgd291
bGQgbWVldCB0aGVpciBuZWVkcy4gRnVydGhlciBpbnZlc3RpZ2F0aW9ucyB3b3VsZCBzdGlsbCBi
ZQ0KPGJyPg0KJmd0OyB1c2VmdWwgdG8gZGV0ZXJtaW5lIHRoZSBkZWdyZWUgb2YgZmFpbGVkIEhN
QUMgY2FsY3VsYXRpb25zIGR1ZSB0bw0KPGJyPg0KJmd0OyBIVFRQIHByb3hpZXMgbW9kaWZ5aW5n
IHRoZSBjb250ZW50LiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgLS0gS2V5IERpc3RyaWJ1dGlvbjxi
cj4NCiZndDsgPGJyPg0KJmd0OyBIYW5uZXMgcHJlc2VudGVkIHRoZSBvcGVuIGlzc3VlIHJlZ2Fy
ZGluZyB0aGUgY2hvaWNlIG9mIGtleSA8YnI+DQomZ3Q7IGRpc3RyaWJ1dGlvbi4gU2xpZGVzICM2
LSM4IHByZXNlbnQgdGhyZWUgdGVjaG5pcXVlcyBhbmQgSGFubmVzIGFza2VkPGJyPg0KJmd0OyBm
b3IgZmVlZGJhY2sgcmVnYXJkaW5nIHRoZSBwcmVmZXJyZWQgc3R5bGUuIEp1c3RpbiBhbmQgb3Ro
ZXJzIGRpZG4ndDxicj4NCiZndDsgc2VlIHRoZSBuZWVkIHRvIGRlY2lkZSBvbiBvbmUgbWVjaGFu
aXNtIC0gdGhleSB3YW50ZWQgdG8ga2VlcCB0aGUNCjxicj4NCiZndDsgY2hvaWNlIG9wZW4uIERl
cmVrIGluZGljYXRlZCB0aGF0IHRoaXMgd2lsbCBub3QgYmUgYW4gYWNjZXB0YWJsZSA8YnI+DQom
Z3Q7IGFwcHJvYWNoLiBTaW5jZSB0aGUgcmVzb3VyY2Ugc2VydmVyIGFuZCB0aGUgYXV0aG9yaXph
dGlvbiBzZXJ2ZXIgPGJyPg0KJmd0OyBtYXksIGluIHRoZSBPQXV0aCAyLjAgZnJhbWV3b3JrLCBi
ZSBlbnRpdGllcyBwcm9kdWNlZCBieSBkaWZmZXJlbnQNCjxicj4NCiZndDsgdmVuZG9ycyB0aGVy
ZSBpcyBhbiBpbnRlcm9wZXJhYmlsaXR5IG5lZWQuIEp1c3RpbiByZXNwb25kZWQgdGhhdCBoZQ0K
PGJyPg0KJmd0OyBkaXNhZ3JlZXMgYW5kIHRoYXQgdGhlIHJlc291cmNlIHNlcnZlciBuZWVkcyB0
byB1bmRlcnN0YW5kIHRoZSA8YnI+DQomZ3Q7IGFjY2VzcyB0b2tlbiBhbmQgcmVmZXJyZWQgdG8g
dGhlIHJlY2VudCBkcmFmdCBzdWJtaXNzaW9uIGZvciB0aGUgPGJyPg0KJmd0OyB0b2tlbiBpbnRy
b3NwZWN0aW9uIGVuZHBvaW50LiBEZXJlayBpbmRpY2F0ZWQgdGhhdCB0aGUgcmVzb3VyY2UgPGJy
Pg0KJmd0OyBzZXJ2ZXIgaGFzIHRvIHVuZGVyc3RhbmQgdGhlIGNvbnRlbnQgb2YgdGhlIGFjY2Vz
cyB0b2tlbiBhbmQgdGhlIDxicj4NCiZndDsgdG9rZW4gaW50cm9zcGVjdGlvbiBlbmRwb2ludCBq
dXN0IHB1c2hlcyB0aGUgcHJvYmxlbSBhcm91bmQ6IHRoZSA8YnI+DQomZ3Q7IHJlc291cmNlIHNl
cnZlciBoYXMgdG8gc2VuZCB0aGUgYWNjZXNzIHRva2VuIHRvIHRoZSBhdXRob3JpemF0aW9uDQo8
YnI+DQomZ3Q7IHNlcnZlciBhbmQgdGhlbiB0aGUgcmVzb3VyY2Ugc2VydmVyIGdldHMgdGhlIHJl
c3VsdCBiYWNrICh3aGljaCBoZQ0KdGhlbiBhPGJyPg0KJmd0OyAmbmJzcDtnYWluIG5lZWRzIHRv
IHVuZGVyc3RhbmQpIGluIG9yZGVyIHRvIG1ha2UgYSBtZWFuaW5nZnVsIDxicj4NCiZndDsgYXV0
aG9yaXphdGlvbiBkZWNpc2lvbi4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEV2ZXJ5b25lIGFncmVl
ZCB0aGF0IHRoZSBjbGllbnQgbXVzdCByZWNlaXZlIHRoZSBzZXNzaW9uIGtleSBmcm9tDQo8YnI+
DQomZ3Q7IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgdGhhdCB0aGlzIGFwcHJvYWNoIGhh
cyB0byBiZSA8YnI+DQomZ3Q7IHN0YW5kYXJkaXplZC4gSXQgd2FzIGFsc28gYWdyZWVkIHRoYXQg
dGhpcyBpcyBhIGNvbW1vbiBhcHByb2FjaCA8YnI+DQomZ3Q7IGFtb25nIGFsbCB0aHJlZSBrZXkg
ZGlzdHJpYnV0aW9uIG1lY2hhbmlzbXMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEhhbm5lcyBhc2tl
ZCB0aGUgcGFydGljaXBhbnRzIHRvIHRoaW5rIGFib3V0IHRoZWlyIHByZWZlcmVuY2UuIDxicj4N
CiZndDsgPGJyPg0KJmd0OyBUaGUgcXVlc3Rpb25zIHJlZ2FyZGluZyBrZXkgbmFtaW5nIGFuZCB0
aGUgaW5kaWNhdGlvbiBmb3IgdGhlIDxicj4NCiZndDsgaW50ZW5kZWQgcmVzb3VyY2Ugc2VydmVy
IHRoZSBjbGllbnQgd2FudHMgdG8gdGFsayB0byBoYXZlIGJlZW4gcG9zdHBvbmVkLg0KPGJyPg0K
Jmd0OyAmbmJzcDs8YnI+DQomZ3Q7IENpYW88YnI+DQomZ3Q7IEhhbm5lczxicj4NCiZndDsgPGJy
Pg0KJmd0OyA8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fPGJyPg0KJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IE9BdXRoQGll
dGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h
dXRoPGJyPg0KPC9mb250PjwvdHQ+DQo=
--=_alternative 002C396D48257B14_=--

From wmills_92105@yahoo.com  Sat Feb 16 09:57:33 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF35421F84E2 for ; Sat, 16 Feb 2013 09:57:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.327
X-Spam-Level: 
X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=0.271,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mllbQfXCZbb for ; Sat, 16 Feb 2013 09:57:30 -0800 (PST)
Received: from nm22-vm0.bullet.mail.bf1.yahoo.com (nm22-vm0.bullet.mail.bf1.yahoo.com [98.139.212.126]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE9821F8473 for ; Sat, 16 Feb 2013 09:57:30 -0800 (PST)
Received: from [98.139.215.140] by nm22.bullet.mail.bf1.yahoo.com with NNFMP; 16 Feb 2013 17:57:29 -0000
Received: from [98.139.212.219] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 16 Feb 2013 17:57:29 -0000
Received: from [127.0.0.1] by omp1028.mail.bf1.yahoo.com with NNFMP; 16 Feb 2013 17:57:29 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 348269.60814.bm@omp1028.mail.bf1.yahoo.com
Received: (qmail 16313 invoked by uid 60001); 16 Feb 2013 17:57:28 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1361037448; bh=l2DWkw+K+03UzlAylBNMUi5EURF89oU8XxG124tV9Wo=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=To3EHZL9/ij8RyBbic0BcT4e4dHT9eWLvofJSVo3USayQVaokj3YIh4Vd9KyoaCGv5Bl3NZqTX3yjkbKSlg8CZ8idYtJtKcaa0NLWbQdM4nNAIOVCpTrk6IjgvlV7YbbimeQifGGkPvsxIFdqCEhfcPv2zCF2EUSXn2uJwfGnRM=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=pRo0jRLd2yZSEgIUH8wh0n5/tV1ELQLZf+Ps2RFNJDixIN+pxcH7WmZnYtdrLMk0U6EXWlUdZSDOjWSPatCATW4Wn9y1/0Zgc0zylp+dQeqcRasQhpwfN5ivY0JXQxLTTumonAewwYudOIJZSGDZsy4oW39s4cBgWSJb2HUoDPw=;
X-YMail-OSG: C5k3XocVM1l..NAyKhCD9GhczBiDvfaDlOkKHbTFaMGZMf4 _Y.nWt_T6u4Swe6qgcfv2bI5qk4iaKQXyRs_TVab36qlkS8ri5OkwcAN.83c XP6ONoeydi4Bvxt7C6sF5Hkq2THLWqGhS0MPIKbUwNmwoEDWhJzFktshHGTf izIFZO3pwpxrxhiPiFsUH.JGnBcI.PRFzbJ5vAaTNn4Mfe8gTgMikkcn9hNo MOBkwL3_nGoOkAPqiFWNLRMdUAqK.JBoahUrMYAUQxVDSEFjaXzma95pb3Ih p8iF3vaKcwOlJh1M817VY3DtXFinjAbLsg6DECF9u545.u6LzRHVB9wKwMF0 f_J3I2SN15QVHLAvyt__Bg.9VRsTHOrwbyC58dGmcevsQzBsmy71jGb7GOT0 ip_pIGFZWkJ1_9SljvkP_d3FGgqOAjV8RiN9vIDR4FEAOgllfUdcwZJxUY7P XtOrhznWxH6TYZFAa0p_zjCsh8xQnEpxh9HDNJaCHPWugw0bnSCzMr_tV8rU XVyvYy2OsuAY.0mWno9n77SCckEfbRRcSxOwt6X4gZhlUvGbPk8AmFIWHIkk .U9v8gdqVqPdk2PqT6w23QEmJREamrHmtJBjUs6cTTjaVeFrRzn0c3Gs0FCZ otQRhJmaEa5VbhA6b5ddd7vQn3DMoDNHFiJ9DoVXVyskW8KB8BRuo..MqLwT oVwCZoFQq921r_EoiwUt4qxvCr68gSQ--
Received: from [209.131.62.115] by web31803.mail.mud.yahoo.com via HTTP; Sat, 16 Feb 2013 09:57:28 PST
X-Rocket-MIMEInfo: 001.001, VGhlIHJlYXNvbiB0byBzdXBwb3J0IDEuMGEgdG9rZW5zIGluIDIgaXMgc2ltcGx5IHRvIHByb3ZpZGUgYSBtaWdyYXRpb24gcGF0aCB3aGVuIGEgc2l0ZSBoYXMgMS4wYSBlbmRwb2ludCBpdCB3YW50cyB0byBzdXBwb3J0LgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBGcm9tOiBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPgpUbzogV2lsbGlhbSBNaWxscyA8d21pbGxzXzkyMTA1QHlhaG9vLmNvbT4gCkNjOiBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdHJlLm9yZz47IFRpbSABMAEBAQE-
X-Mailer: YahooMailWebService/0.8.134.513
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net>  <511A7D27.8010209@mitre.org> <4E1F6AAD24975D4BA5B16804296739436744BD23@TK5EX14MBXC285.redmond.corp.microsoft.com> <1360891897.14004.YahooMailNeo@web31811.mail.mud.yahoo.com>  <1360912115.36543.YahooMailNeo@web31811.mail.mud.yahoo.com> <2A0F585F-2CEF-418D-9654-5084E6C9BD0D@lodderstedt.net> <1360944589.51724.YahooMailNeo@web31808.mail.mud.yahoo.com>  <511EA0A3.7080000@mitre.org> <1360962242.18571.YahooMailNeo@web31805.mail.mud.yahoo.com>  <1360994570.11377.YahooMailNeo@web31805.mail.mud.yahoo.com> 
Message-ID: <1361037448.95269.YahooMailNeo@web31803.mail.mud.yahoo.com>
Date: Sat, 16 Feb 2013 09:57:28 -0800 (PST)
From: William Mills 
To: Phil Hunt 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="1502656925-1936149940-1361037448=:95269"
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Feb 2013 17:57:33 -0000

--1502656925-1936149940-1361037448=:95269
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

The reason to support 1.0a tokens in 2 is simply to provide a migration pat=
h when a site has 1.0a endpoint it wants to support.=0A=0A=0A______________=
__________________=0A From: Phil Hunt =0ATo: William =
Mills  =0ACc: Justin Richer ; Ti=
m Bray ; IETF oauth WG  =0ASent: Friday,=
 February 15, 2013 11:22 PM=0ASubject: Re: [OAUTH-WG] Minutes from the OAut=
h Design Team Conference Call - 11th February 2013=0A =0A=0AI don't see oau=
th1 tokens as a short cut because eran said the token in oauth1 (which is i=
nside the oauth1 spec) had many implementation problems by client developer=
s. Why go there and re-invent what jwt could do easily?=0A=0ADo you need ho=
k? Do you need replay protection? Do you need message signing? Are asymmetr=
ic keys needed? =C2=A0I get the impression the group is less interested in =
the last two.=C2=A0=0A=0AThere is also key distribution to resource server.=
 I think we have client nailed but getting keys to resource server needs so=
me discussion - especially if the path is through the token itself. =C2=A0=
=0A=0AI suppose we can move faster if we assume rs obtains=C2=A0keys in an =
unspecified manner like what happened in oauth1.=C2=A0=0A=0APhil=0A=0ASent =
from my phone.=0A=0AOn 2013-02-15, at 22:02, William Mills  wrote:=0A=0A=0AAll the same concepts/info are available in the AS:=
 client ID, client auth, and can deliver both token and secret. =C2=A0What'=
s magic once the client has the token that's missing?=0A>=0A>=0A>=0A>______=
__________________________=0A> From: Phil Hunt =0A>To=
: William Mills  =0A>Cc: Justin Richer ; Tim Bray ; IETF oauth WG  =0A>S=
ent: Friday, February 15, 2013 1:52 PM=0A>Subject: Re: [OAUTH-WG] Minutes f=
rom the OAuth Design Team Conference Call - 11th February 2013=0A> =0A>=0A>=
Sorry. I have to disagree. The way 1.0 is written, it is not a shortcut to =
turn it into a token for 2.=C2=A0=0A>=0A>Phil=0A>=0A>=0A>Sent from my phone=
.=0A>=0A>On 2013-02-15, at 13:04, William Mills  wr=
ote:=0A>=0A>=0A>>I've brought it up before, but I think it might be worthwh=
ile, at least as an exercise, to define a method to get OAuth1-style tokens=
 from an OAuth2 token endpoint. You'd defer to OAuth1 for how to use them >=
with a protected resource.=0A>>=0A>>=0A>>=0A>>YES!=0A>>=0A>>=0A>>=0A>>_____=
___________________________=0A>> From: Justin Richer =0A=
>>To: Tim Bray  =0A>>Cc: William Mills ; IETF oauth WG  =0A>>Sent: Friday, February 15, 201=
3 12:54 PM=0A>>Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team C=
onference Call - 11th February 2013=0A>> =0A>>=0A>>So that you can fetch an=
d manage all your tokens using the same code paths as the OAuth2 services. =
The "get a token" part will be identical to Oauth2 Bearer (except for some =
details of what comes back from the token endpoint, of course), it's the "u=
se a token" bit that really changes and is up in the air. You get to use sc=
opes, and state, and refresh tokens, and all the other good stuff.=0A>>=0A>=
>I've brought it up before, but I think it might be worthwhile, at=0A    le=
ast as an exercise, to define a method to get OAuth1-style tokens=0A    fro=
m an OAuth2 token endpoint. You'd defer to OAuth1 for how to use=0A    them=
 with a protected resource.=0A>>=0A>>=C2=A0-- Justin=0A>>=0A>>=0A>>On 02/15=
/2013 11:49 AM, Tim Bray wrote:=0A>>=0A>>Not deeply acquainted with the Fli=
ckr scenario, but it occurs to me to ask: If OAuth 1.0 is working well for =
them, why don=E2=80=99t they just keep using it? =C2=A0I.e. if there=E2=80=
=99s already a good solution in place for people who require secure authn/a=
uthz over insecure channels, why would we go the extra work of duplicating =
that in OAuth 2 territory? -T=0A>>>=0A>>>=0A>>>On Fri, Feb 15, 2013 at 8:09=
 AM, William Mills  wrote:=0A>>>=0A>>>I'll repeat t=
he use case for Flickr, which requires OAuth 1.0a type capabilites that OAu=
th 2 does not provide. =C2=A0Simply stating "move to HTTPS" is not a viable=
 response here. =C2=A0=0A>>>>=0A>>>>=0A>>>>=0A>>>>_________________________=
_______=0A>>>> From: Torsten Lodderstedt =0A>>>>To=
: William Mills  =0A>>>>Cc: Mike Jones ; Justin Richer ; Phil Hunt ; IETF oauth WG  =0A>>>>Sent: Friday, February 1=
5, 2013 7:22 AM=0A>>>>Subject: Re: [OAUTH-WG] Minutes from the OAuth Design=
 Team Conference Call - 11th February 2013=0A>>>> =0A>>>>=0A>>>>Hi Bill,=0A=
>>>>=0A>>>>=0A>>>>I think one needs to compare the costs/impact of HTTPS on=
 one side and the implementation of integrity protection and replay detecti=
on on the other. We had this discussion several times.=0A>>>>=0A>>>>=0A>>>>=
regards,=0A>>>>Torsten.=0A>>>>=0A>>>>Am 15.02.2013 um 08:08 schrieb William=
 Mills=0A                        :=0A>>>>=0A>>>>=0A=
>>>>I fundamentally disagree with that too. =C2=A0OAuth 2 is the *framework=
*, one which supports multiple token types. =C2=A0Bearer tokens were the fi=
rst credential type defined.=0A>>>>>=0A>>>>>=0A>>>>>OAuth 1.0a also require=
s HTTPS transport for authentication and getting the token.=0A>>>>>=0A>>>>>=
=0A>>>>>There are =C2=A0real use cases for tokens usable over plain text wi=
th integrity protection.=0A>>>>>=0A>>>>>=0A>>>>>-bill=0A>>>>>=0A>>>>>=0A>>>=
>>=0A>>>>>________________________________=0A>>>>> From: Torsten Loddersted=
t =0A>>>>>To: William Mills  =0A>>>>>Cc: Mike Jones ; Justin Richer ; Phil Hunt ; IETF oauth WG  =0A>>>>>Sent: Thursday, February 14, 2013 10:05 PM=0A>>>>>Subject: R=
e: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th Feb=
ruary 2013=0A>>>>> =0A>>>>>=0A>>>>>Hi Bill,=0A>>>>>=0A>>>>>=0A>>>>>OAuth 2.=
0 took a different direction by relying on HTTPS to provide the basic prote=
ction. So the need to have a token, which can be used for service requests =
over plain HTTP is arguable. My understanding of this activity was, the int=
end is to provide additional protection on top of HTTPS.=0A>>>>>=0A>>>>>=0A=
>>>>>regards,=0A>>>>>Torsten.=0A>>>>>=0A>>>>>Am 15.02.2013 um 02:31 schrieb=
=0A                                      William Mills :=0A>>>>>=0A>>>>>=0A>>>>>I disagree with "That was the impediment to OA=
uth 1.0 adoption that OAuth 2.0 solved in the first place.", unless "solvin=
g" means does not address the need for it at all.=0A>>>>>>=0A>>>>>>=0A>>>>>=
>OAuth 2 does several good things, but it still lacks a defined token type =
that is safe to user over plain text HTTP. =C2=A01.0a solved that.=0A>>>>>>=
=0A>>>>>>=0A>>>>>>=0A>>>>>>________________________________=0A>>>>>> From: =
Mike Jones =0A>>>>>>To: Justin Richer ; Phil Hunt  =0A>>>>>>Cc: IETF oauth WG  =0A>>>>>>Sent: Thursday, February 14, 2013 1:44 PM=0A>>>>>>S=
ubject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call -=
 11th February 2013=0A>>>>>> =0A>>>>>>I'm in favor of reusing=0A           =
                                   the JWT work that this WG=0A            =
                                  is also doing. :-)=0A>>>>>>=0A>>>>>>I'm p=
retty skeptical of us=0A                                              inven=
ting another custom=0A                                              scheme =
for signing HTTP=0A                                              headers.=
=C2=A0 That was the=0A                                              impedim=
ent to OAuth 1.0=0A                                              adoption t=
hat OAuth 2.0=0A                                              solved in the=
 first place.=0A>>>>>>=0A>>>>>>=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=
=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 -- Mike=0A>>>>>>=0A>>>>>>-----Original Mess=
age-----=0A>>>>>>From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.or=
g] On Behalf Of Justin Richer=0A>>>>>>Sent: Tuesday, February=0A           =
                                   12, 2013 9:35 AM=0A>>>>>>To: Phil Hunt=
=0A>>>>>>Cc: IETF oauth WG=0A>>>>>>Subject: Re: [OAUTH-WG]=0A              =
                                Minutes from the OAuth=0A                  =
                            Design Team Conference=0A                      =
                        Call - 11th February 2013=0A>>>>>>=0A>>>>>>That's m=
y reading of it as=0A                                              well, Ph=
il, thanks for=0A                                              providing th=
e=0A                                              clarification. One=0A    =
                                          motivator behind using a=0A      =
                                        JSON-based token is to be=0A       =
                                       able to re-use some of the=0A       =
                                       great work that the JOSE=0A         =
                                     group is doing but apply=0A           =
                                   it to an HTTP payload.=0A>>>>>>=0A>>>>>>=
What neither of us want is=0A                                              =
a token type that requires=0A                                              =
stuffing all query,=0A                                              header,=
 and other=0A                                              parameters *into=
* the JSON=0A                                              object itself, w=
hich would=0A                                              be a more SOAPy =
approach.=0A>>>>>>=0A>>>>>>=C2=A0 -- Justin=0A>>>>>>=0A>>>>>>On 02/12/2013 =
12:30 PM,=0A                                              Phil Hunt wrote:=
=0A>>>>>>> Clarification.=C2=A0 I=0A                                       =
       think Justin and I were in=0A                                       =
       agreement that we don't=0A                                          =
    want to see a format that=0A                                           =
   requires JSON payloads.=C2=A0=0A                                        =
      We are both interested in=0A                                         =
     a JSON token used in the=0A                                           =
   authorization header that=0A                                            =
  could be based on a=0A                                              compu=
ted signature of some=0A                                              combi=
nation of http=0A                                              headers and =
body if=0A                                              possible.=0A>>>>>>>=
=0A>>>>>>> Phil=0A>>>>>>>=0A>>>>>>> @independentid=0A>>>>>>> www.independen=
tid.com=0A>>>>>>> phil.hunt@oracle.com=0A>>>>>>>=0A>>>>>>>=0A>>>>>>>=0A>>>>=
>>>=0A>>>>>>>=0A>>>>>>> On 2013-02-12, at=0A                               =
               1:10 AM, Hannes Tschofenig=0A                               =
               wrote:=0A>>>>>>>=0A>>>>>>>> Here are my=0A                  =
                            notes.=0A>>>>>>>>=0A>>>>>>>> Participants:=0A>>=
>>>>>>=0A>>>>>>>> * John Bradley=0A>>>>>>>> * Derek Atkins=0A>>>>>>>> * Phi=
l Hunt=0A>>>>>>>> * Prateek Mishra=0A>>>>>>>> * Hannes=0A                  =
                            Tschofenig=0A>>>>>>>> * Mike Jones=0A>>>>>>>> *=
 Antonio Sanso=0A>>>>>>>> * Justin Richer=0A>>>>>>>>=0A>>>>>>>> Notes:=0A>>=
>>>>>>=0A>>>>>>>> My slides are=0A                                         =
     available here: =0A>>>>>>>> http://www.tschofenig.priv.at/OAuth2-Secur=
ity-11Feb2013.ppt=0A>>>>>>>>=0A>>>>>>>> Slide #2=0A                        =
                      summarizes earlier=0A                                =
              discussions during the=0A                                    =
          conference calls.=0A>>>>>>>>=0A>>>>>>>> -- HTTP vs. JSON=0A>>>>>>=
>>=0A>>>>>>>> Phil noted that=0A                                           =
   he does not like to use=0A                                              =
the MAC Token draft as a=0A                                              st=
arting point because it=0A                                              doe=
s not re-use any of the=0A                                              wor=
k done in the JOSE=0A                                              working =
group and in=0A                                              particular all=
 the=0A                                              libraries that are=0A =
                                             available today. He=0A        =
                                      mentioned that earlier=0A            =
                                  attempts to write the MAC=0A             =
                                 Token code lead to=0A                     =
                         problems for implementers.=0A>>>>>>>>=0A>>>>>>>> J=
ustin responded=0A                                              that he doe=
s not agree=0A                                              with using JSON=
 as a=0A                                              transport mechanism s=
ince=0A                                              this would replicate a=
=0A                                              SOAP style.=0A>>>>>>>>=0A>=
>>>>>>> Phil noted that=0A                                              he =
wants to send JSON but=0A                                              the =
signature shall be=0A                                              computed=
 over the HTTP=0A                                              header field=
.=0A>>>>>>>>=0A>>>>>>>> -- Flexibility=0A                                  =
            for the keyed message=0A                                       =
       digest computation=0A>>>>>>>>=0A>>>>>>>>=C2=A0 From earlier=0A      =
                                        discussion it was clear=0A         =
                                     that the conference call=0A           =
                                   participants wanted more=0A             =
                                 flexibility regarding the=0A              =
                                keyed message digest=0A                    =
                          computation. For this=0A                         =
                     purpose Hannes presented=0A                           =
                   the DKIM based approach,=0A                             =
                 which allows selective=0A                                 =
             header fields to be=0A                                        =
      included in the digest.=0A                                           =
   This is shown in slide #4.=0A>>>>>>>>=0A>>>>>>>> After some=0A          =
                                    discussion the conference=0A           =
                                   call participants thought=0A            =
                                  that this would meet their=0A            =
                                  needs. Further=0A                        =
                      investigations would still=0A                        =
                      be useful to determine the=0A                        =
                      degree of failed HMAC=0A                             =
                 calculations due to HTTP=0A                               =
               proxies modifying the=0A                                    =
          content.=0A>>>>>>>>=0A>>>>>>>> -- Key=0A                         =
                     Distribution=0A>>>>>>>>=0A>>>>>>>> Hannes presented=0A=
                                              the open issue regarding=0A  =
                                            the choice of key =0A>>>>>>>> d=
istribution.=0A                                              Slides #6-#8 p=
resent three=0A                                              techniques and=
 Hannes=0A                                              asked =0A>>>>>>>> f=
or feedback=0A                                              regarding the p=
referred=0A                                              style. Justin and =
others=0A                                              didn't =0A>>>>>>>> s=
ee the need to=0A                                              decide on on=
e mechanism -=0A                                              they wanted t=
o keep the =0A>>>>>>>> choice open.=0A                                     =
         Derek indicated that this=0A                                      =
        will not be an acceptable =0A>>>>>>>> approach. Since=0A           =
                                   the resource server and=0A              =
                                the authorization server=0A                =
                              may, =0A>>>>>>>> in the OAuth 2.0=0A         =
                                     framework, be entities=0A             =
                                 produced by different=0A                  =
                            vendors =0A>>>>>>>> there is an=0A             =
                                 interoperability need.=0A                 =
                             Justin responded that he=0A                   =
                           disagrees =0A>>>>>>>> and that the=0A           =
                                   resource server needs to=0A             =
                                 understand the access=0A                  =
                            token and =0A>>>>>>>> referred to the=0A       =
                                       recent draft submission=0A          =
                                    for the token=0A                       =
                       introspection =0A>>>>>>>> endpoint. Derek=0A        =
                                      indicated that the=0A                =
                              resource server has to=0A                    =
                          understand =0A>>>>>>>> the content of=0A         =
                                     the access token and the=0A           =
                                   token introspection=0A                  =
                            endpoint =0A>>>>>>>> just pushes the=0A        =
                                      problem around: the=0A               =
                               resource server has to=0A                   =
                           send the =0A>>>>>>>> access token to=0A         =
                                     the authorization server=0A           =
                                   and then the resource=0A                =
                              server =0A>>>>>>>> gets the result=0A        =
                                      back (which he the=0A>>>>>>n=0A>>>>>>=
>=C2=A0 =C2=A0 a=0A>>>>>>>> gain needs to=0A                               =
               understand) in order to=0A                                  =
            make a meaningful=0A                                           =
   authorization decision.=0A>>>>>>>>=0A>>>>>>>> Everyone agreed=0A        =
                                      that the client must=0A              =
                                receive the session key=0A                 =
                             from the authorization=0A                     =
                         server and that this=0A                           =
                   approach has to be=0A                                   =
           standardized. It was also=0A                                    =
          agreed that this is a=0A                                         =
     common approach among all=0A                                          =
    three key distribution=0A                                              =
mechanisms.=0A>>>>>>>>=0A>>>>>>>> Hannes asked the=0A                      =
                        participants to think=0A                           =
                   about their preference.=0A>>>>>>>>=0A>>>>>>>> The questi=
ons=0A                                              regarding key naming an=
d=0A                                              the indication for the=0A=
                                              intended resource server=0A  =
                                            the client wants to talk=0A    =
                                          to have been postponed.=0A>>>>>>>=
>=0A>>>>>>>> Ciao=0A>>>>>>>> Hannes=0A>>>>>>>>=0A>>>>>>>>=0A>>>>>>>>=0A    =
                                          _________________________________=
______________=0A>>>>>>>> OAuth mailing=0A                                 =
             list=0A>>>>>>>> OAuth@ietf.org=0A>>>>>>>> https://www.ietf.org=
/mailman/listinfo/oauth=0A>>>>>>>=0A                                       =
       _______________________________________________=0A>>>>>>> OAuth mail=
ing list=0A>>>>>>> OAuth@ietf.org=0A>>>>>>> https://www.ietf.org/mailman/li=
stinfo/oauth=0A>>>>>>=0A>>>>>>=0A>>>>>>____________________________________=
___________=0A>>>>>>OAuth mailing list=0A>>>>>>OAuth@ietf.org=0A>>>>>>https=
://www.ietf.org/mailman/listinfo/oauth=0A>>>>>>____________________________=
___________________=0A>>>>>>OAuth mailing list=0A>>>>>>OAuth@ietf.org=0A>>>=
>>>https://www.ietf.org/mailman/listinfo/oauth=0A>>>>>>=0A>>>>>>=0A>>>>>>=
=0A>>>>>_______________________________________________=0A>>>>>>OAuth maili=
ng list=0A>>>>>>OAuth@ietf.org=0A>>>>>>https://www.ietf.org/mailman/listinf=
o/oauth=0A>>>>>>=0A>>>>>=0A>>>>>=0A>>>>=0A>>>>=0A>>>>______________________=
_________________________=0A>>>>OAuth mailing list=0A>>>>OAuth@ietf.org=0A>=
>>>https://www.ietf.org/mailman/listinfo/oauth=0A>>>>=0A>>>>=0A>>>=0A>>>=0A=
>>>=0A>>>_______________________________________________=0AOAuth mailing li=
st OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =0A>>=0A>>=0A=
>>=0A>_______________________________________________=0A>>OAuth mailing lis=
t=0A>>OAuth@ietf.org=0A>>https://www.ietf.org/mailman/listinfo/oauth=0A>>=
=0A>=0A>
--1502656925-1936149940-1361037448=:95269
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

The reason to support 1.0a tokens in 2 is simply to provide a migration p=
ath when a site has 1.0a endpoint it wants to support.

  From: Phil Hunt <phil.hunt@oracle.com>
 To: William Mills <wmills_92105@=
yahoo.com> 
Cc: Just=
in Richer <jricher@mitre.org>; Tim Bray <twbray@google.com>; IE=
TF oauth WG <oauth@ietf.org> 
 Sent: Friday, February 15, 2013 11:22 PM
 Subject: Re: [OAUTH-WG] Minutes from =
the OAuth Design Team Conference Call - 11th February 2013

I don't see oauth1 tokens as a sh=
ort cut because eran said the token in oauth1 (which is inside the oauth1 s=
pec) had many implementation problems by client developers. Why go there an=
d re-invent what jwt could do easily?

Do you need hok? Do you need r=
eplay protection? Do you need message signing? Are asymmetric keys needed? =
 I get the impression the group is less interested in the last two.&nb=
sp;

There is also key distribution to resource ser=
ver. I think we have client nailed but getting keys to resource server need=
s some discussion - especially if the path is through the token itself. &nb=
sp;

I suppose we can move faster if we assume
 rs obtains keys in an unspecified manner like what happened in oauth1=
. 

Phil
Sent from my phone=
.

On 2013-02-15, at 22:02, William Mills <wmills_92105@yahoo.com> wrote:
All the same concep=
ts/info are available in the AS: client ID, client auth, and can deliver bo=
th token and secret.  What's magic once the client has the token that'=
s missing?

    =

  From: Phil Hunt <phil.hunt@oracle.com>
 To: William Mills <wmills_92105@yahoo.com> 
Cc: Justin Richer <jricher@mitre.org>; Tim Bray <twbray@google.com>; IETF oauth WG <oauth@ietf.org> 
 Sent: Friday, February 15, 2013 1:5=
2 PM
 Subject: Re: [OAUT=
H-WG] Minutes from the OAuth Design Team Conference Call - 11th February 20=
13

Sorry. I have =
to disagree. The way 1.0 is written, it is not a shortcut to turn it into a=
 token for 2. 

Phil
Sent from my phone.

On 2013-02-15, at 13:04, William Mills <wmills_92105@yahoo.com> wrote:

>I've brought it u=
p before,=0A but I think it might be worthwhile, at least as an exercise, t=
o define a method to get OAuth1-style tokens from an OAuth2 token endpoint.=
 You'd defer to OAuth1 for how to use them >with a protected resource.
YES!

  From: Justin Richer <jricher@mitre.org>
 To: Tim Bray <twbray@go=
ogle.com> 
Cc: Wi=
lliam Mills <wmills_92105@ya=
hoo.com>; IETF oauth WG <oauth@ietf.o=
rg> 
 Sent: Friday, February 15, 2013 12:=
54 PM
 Subject: Re: [OAU=
TH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2=
013

=0A  =0A=0A    =0A  =0A=
  =0A    So that you can fetch and manage all your tokens using the sa=
me code=0A    paths as the OAuth2 services. The "get a token" part will be=
=0A    identical to Oauth2 Bearer (except for some details of what comes=0A=
    back from the token endpoint, of course), it's the "use a token" bit=0A=
    that really changes and is up in the air. You get to use scopes, and=0A=
    state, and refresh tokens, and all the other good stuff.
=0A    
=
=0A    I've brought it up before, but I think it might be worthwhile, at=0A=
    least as an exercise, to define a method to get OAuth1-style tokens=0A =
   from an OAuth2 token endpoint. You'd defer to OAuth1 for how to use=0A  =
  them with a protected resource.
=0A    
=0A     -- Justin
=
=0A    
=0A    On 02/15/2013 =
11:49 AM, Tim Bray wrote:
=0A    
=0A    =
=0A      =0A      Not deeply acquainted with the Flickr scenario, but it oc=
curs to=0A      me to ask: If OAuth 1.0 is working well for them, why don=
=E2=80=99t they=0A      just keep using it?  I.e. if there=E2=80=99s a=
lready a good solution in=0A      place for people who require secure authn=
/authz over insecure=0A      channels, why would we go the extra work of du=
plicating that in=0A      OAuth 2 territory? -T
=0A      
=0A      On Fri, Feb 15, 2013 at 8:09 AM, Willi=
am=0A        Mills <wmills_92105@yahoo.com>=0A        wrote:
=0A    =
    =0A          =0A      =
      =0A              I'll repeat the =
use case for Flickr, which=0A                  requires OAuth 1.0a type cap=
abilites that OAuth 2 does=0A                  not provide.  Simply st=
ating "move to HTTPS" is not a=0A                  viable response here. &n=
bsp;
=0A              
=0A              =0A      =
        =0A                =0A                   =0A                      
 From:=0A                      Torsten Lodderstedt =
<torsten@lodderstedt.net=
>
=0A                      T=
o:=0A                      William Mills <wmills_92105@yahoo.com> 
=0A            =
          Cc:=0A           =
           Mike Jones <Michael.Jones@microsoft.com>;=0A                      Justin Ri=
cher <jricher@mitre.org>;=0A   =
                   Phil Hunt <ph=
il.hunt@oracle.com>;=0A                      IETF oauth WG <oauth@ietf.org>=0A                      
=
=0A                      Sent:<=
/b>=0A                      Friday, February 15, 2013 7:22 AM
=0A       =
               Subject:=0A =
                     Re: [OAUTH-WG] Minutes from the OAuth Design Team=0A  =
                    Conference Call - 11th February 2013
=0A            =

=0A                  
=0A                  =
=0A                    =0A                      Hi Bill,=0A=

=0A                      =0A          =
            I think one needs to compare the costs/impact=0A          =
              of HTTPS on one side and the implementation of=0A            =
            integrity protection and replay detection on the=0A            =
            other. We had this discussion several times.=0A          =

=0A                      =0A                    =
  regards,
=0A                      Torsten.=0A       =

=0A                        Am 15.02.2013 um 08:08 s=
chrieb William Mills=0A                        <wmills_92105@yahoo.com>:
=0A                 =

=0A                      
=0A                      =0A                        =0A                      =
    =0A                =
            I fundamentally disagree with=0A                    =
            that too.  OAuth 2 is the *framework*,=0A                 =
               one which supports multiple token types.=0A                 =
                Bearer tokens were the first credential=0A            =
                    type defined.=0A                          =

=0A                              
=0A                            =0A      =
                        OAuth 1.0a also requires HTTPS=0A            =
                    transport for authentication and getting=0A            =
                    the token.=0A                            <=
div style=3D"font-style:normal;font-size:16px;background-color:transparent;=
font-family:'Courier=0A                              New', courier, monaco,=
 monospace, sans-serif;">=0A                              
=0A    =

=0A                            There=0A                                are &nbs=
p;real use cases for tokens usable=0A                                over p=
lain text with integrity=0A                                protection.
=0A                            
=
=0A                              =0A                          =
  =0A                              -bill
=0A                            
=0A                      =

=0A                            =0A                              =0A            =
                     =0A             =

 From:=0A                                    Torsten Lodderstedt=
 <torsten@lodderstedt.net=
>
=0A                                    To:=0A                                    William M=
ills <wmills_92105@yahoo.com=
>=0A                                    
=0A                     =
               Cc:=0A      =
                              Mike Jones <Michael.Jones@microsoft.com>;=0A            =
                        Justin Richer <jricher@mitre.org>;=0A                                    Phil Hunt=
 <phil.hunt@oracle.com>;=
=0A                                    IETF oauth WG <oauth@ietf.org>=0A                                    
=
=0A                                    Sent:=0A                                    Thursday, February =
14, 2013 10:05 PM
=0A                                    Subject:=0A                              =
      Re: [OAUTH-WG] Minutes from the=0A                                   =
 OAuth Design Team Conference Call -=0A                                    =
11th February 2013
=0A                                   =
=0A                                
=0A                                <=
div>=0A                                  =0A                          =
          Hi Bill,
=0A                                    =0A                                    =0A                         =
           OAuth 2.0 took a different=0A                              =
        direction by relying on HTTPS to=0A                                =
      provide the basic protection. So=0A                                  =
    the need to have a token, which=0A                                     =
 can be used for service requests=0A                                      o=
ver plain HTTP is arguable. My=0A                                      unde=
rstanding of this activity=0A                                      was, the=
 intend is to provide=0A                                      additional pr=
otection on top of=0A                                      HTTPS.=0A =

=0A                            =

=0A                                    regards,=0A=
                                    Torsten.=0A                 =

=0A                                      Am 15.=
02.2013 um 02:31 schrieb=0A                                      William Mi=
lls <wmills_92105@yahoo.com<=
/a>>:
=0A                                      
=0A               =

=0A                                    =0A                                      =0A         =
                               =0A                 =
                         I disagree with "That=0A                                              was=
 the impediment to=0A                                              OAuth 1.=
0 adoption that=0A                                              OAuth 2.0 s=
olved in the=0A                                              first place.",=
 unless=0A                                              "solving" means doe=
s not=0A                                              address the need for =
it at=0A                                              all.=0A =
                                         =0A                              =

=0A                    =
                        =0A                                   =
       =0A                                            OAuth=0A                                              2 does =
several good=0A                                              things, but it=
 still lacks=0A                                              a defined toke=
n type that=0A                                              is safe to user=
 over plain=0A                                              text HTTP. &nbs=
p;1.0a solved=0A                                              that.<=
/div>=0A                                          
=0A             =
                             =0A                                     =
     =0A                                           =
 =0A                                      =
         =0A                         =

 From: Mike Jones <Michael.Jones@microsoft.com>
=0A                   =
                               To:=0A                                                  Justin Richer &=
lt;jricher@mitre.org>;=0A         =
                                         Phil Hunt <phil.hunt@oracle.com>=0A                        =

=0A                                          =
        Cc:=0A             =
                                     IETF oauth WG <oauth@ietf.org>=0A                                          =

=0A                                                  Sent:=0A                             =
                     Thursday, February 14,=0A                             =
                     2013 1:44 PM
=0A                                   =
               Subject:=0A =
                                                 Re: [OAUTH-WG] Minutes=0A =
                                                 from the OAuth Design=0A  =
                                                Team Conference Call -=0A  =
                                                11th February 2013
=0A  =
                                               =0A            =

=0A                                  =
            I'm in favor of reusing=0A                                     =
         the JWT work that this WG=0A                                      =
        is also doing. :-)
=0A                                          =

=0A                                              I'm pretty skeptic=
al of us=0A                                              inventing another =
custom=0A                                              scheme for signing H=
TTP=0A                                              headers.  That was=
 the=0A                                              impediment to OAuth 1.=
0=0A                                              adoption that OAuth 2.0=
=0A                                              solved in the first place.=

=0A                                              
=0A               =
                                        =
       -- Mike
=0A                             =

=0A                                              -----=
Original Message-----
=0A                                              F=
rom: oauth-bounces@ietf.org=0A                                              [mailto:oauth-bounces@ietf.org]=0A                 =
                             On Behalf Of Justin Richer
=0A             =
                                 Sent: Tuesday, February=0A                =
                              12, 2013 9:35 AM
=0A                      =
                        To: Phil Hunt
=0A                               =
               Cc: IETF oauth WG
=0A                                    =
          Subject: Re: [OAUTH-WG]=0A                                       =
       Minutes from the OAuth=0A                                           =
   Design Team Conference=0A                                              C=
all - 11th February 2013
=0A                                            =

=0A                                              That's my reading of=
 it as=0A                                              well, Phil, thanks f=
or=0A                                              providing the=0A        =
                                      clarification. One=0A                =
                              motivator behind using a=0A                  =
                            JSON-based token is to be=0A                   =
                           able to re-use some of the=0A                   =
                           great work that the JOSE=0A                     =
                         group is doing but apply=0A                       =
                       it to an HTTP payload.
=0A                       =

=0A                                             =
 What neither of us want is=0A                                             =
 a token type that requires=0A                                             =
 stuffing all query,=0A                                              header=
, and other=0A                                              parameters *int=
o* the JSON=0A                                              object itself, =
which would=0A                                              be a more SOAPy=
 approach.
=0A                                              
=0A     =
                                           -- Justin
=0A           =

=0A                                 =
             On 02/12/2013 12:30 PM,=0A                                    =
          Phil Hunt wrote:
=0A                                          =
    > Clarification.  I=0A                                         =
     think Justin and I were in=0A                                         =
     agreement that we don't=0A                                            =
  want to see a format that=0A                                             =
 requires JSON payloads. =0A                                          =
    We are both interested in=0A                                           =
   a JSON token used in the=0A                                             =
 authorization header that=0A                                              =
could be based on a=0A                                              compute=
d signature of some=0A                                              combina=
tion of http=0A                                              headers and bo=
dy if=0A                                              possible.
=0A     =
                                         >
=0A                       =
                       > Phil
=0A                                    =
          >
=0A                                              > @in=
dependentid
=0A                                              > www.=
independentid.com
=0A                                              &=
gt; phil.hunt@oracle.com
=0A=
                                              >
=0A                  =
                            >
=0A                                    =
          >
=0A                                              >
=
=0A                                              >
=0A               =
                               > On 2013-02-12, at=0A                   =
                           1:10 AM, Hannes Tschofenig=0A                   =
                           wrote:
=0A                                   =
           >
=0A                                              >>=
; Here are my=0A                                              notes.
=0A=
                                              >>
=0A              =
                                >> Participants:
=0A              =
                                >>
=0A                            =
                  >> * John Bradley
=0A                           =
                   >> * Derek Atkins
=0A                          =
                    >> * Phil Hunt
=0A                            =
                  >> * Prateek Mishra
=0A                         =
                     >> * Hannes=0A                                  =
            Tschofenig
=0A                                              =
>> * Mike Jones
=0A                                              &=
gt;> * Antonio Sanso
=0A                                             =
 >> * Justin Richer
=0A                                           =
   >>
=0A                                              >> No=
tes:
=0A                                              >>
=0A   =
                                           >> My slides are=0A       =
                                       available here: 
=0A             =
                                 >> h=
ttp://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
=0A      =
                                        >>
=0A                    =
                          >> Slide #2=0A                             =
                 summarizes earlier=0A                                     =
         discussions during the=0A                                         =
     conference calls.
=0A                                              =
>>
=0A                                              >> -- HT=
TP vs. JSON
=0A                                              >>=0A                                              >> Phil noted that=
=0A                                              he does not like to use=0A=
                                              the MAC Token draft as a=0A  =
                                            starting point because it=0A   =
                                           does not re-use any of the=0A   =
                                           work done in the JOSE=0A        =
                                      working group and in=0A              =
                                particular all the=0A                      =
                        libraries that are=0A                              =
                available today. He=0A                                     =
         mentioned that earlier=0A                                         =
     attempts to write the MAC=0A                                          =
    Token code lead to=0A                                              prob=
lems for implementers.
=0A                                              =
>>
=0A                                              >> Justi=
n responded=0A                                              that he does no=
t agree=0A                                              with using JSON as =
a=0A                                              transport mechanism since=
=0A                                              this would replicate a=0A =
                                             SOAP style.
=0A            =
                                  >>
=0A                          =
                    >> Phil noted that=0A                            =
                  he wants to send JSON but=0A                             =
                 the signature shall be=0A                                 =
             computed over the HTTP=0A                                     =
         header field.
=0A                                              =
>>
=0A                                              >> -- Fl=
exibility=0A                                              for the keyed mes=
sage=0A                                              digest computation
=
=0A                                              >>
=0A           =
                                   >>  From earlier=0A          =
                                    discussion it was clear=0A             =
                                 that the conference call=0A               =
                               participants wanted more=0A                 =
                             flexibility regarding the=0A                  =
                            keyed message digest=0A                        =
                      computation. For this=0A                             =
                 purpose Hannes presented=0A                               =
               the DKIM based approach,=0A                                 =
             which allows selective=0A                                     =
         header fields to be=0A                                            =
  included in the digest.=0A                                              T=
his is shown in slide #4.
=0A                                           =
   >>
=0A                                              >> Af=
ter some=0A                                              discussion the con=
ference=0A                                              call participants t=
hought=0A                                              that this would meet=
 their=0A                                              needs. Further=0A   =
                                           investigations would still=0A   =
                                           be useful to determine the=0A   =
                                           degree of failed HMAC=0A        =
                                      calculations due to HTTP=0A          =
                                    proxies modifying the=0A               =
                               content.
=0A                             =
                 >>
=0A                                           =
   >> -- Key=0A                                              Distribu=
tion
=0A                                              >>
=0A   =
                                           >> Hannes presented=0A    =
                                          the open issue regarding=0A      =
                                        the choice of key 
=0A          =
                                    >> distribution.=0A              =
                                Slides #6-#8 present three=0A              =
                                techniques and Hannes=0A                   =
                           asked 
=0A                                   =
           >> for feedback=0A                                        =
      regarding the preferred=0A                                           =
   style. Justin and others=0A                                             =
 didn't 
=0A                                              >> see t=
he need to=0A                                              decide on one me=
chanism -=0A                                              they wanted to ke=
ep the 
=0A                                              >> choice=
 open.=0A                                              Derek indicated that=
 this=0A                                              will not be an accept=
able=0A                                              
=0A               =
                               >> approach. Since=0A                 =
                             the resource server and=0A                    =
                          the authorization server=0A                      =
                        may, 
=0A                                       =
       >> in the OAuth 2.0=0A                                        =
      framework, be entities=0A                                            =
  produced by different=0A                                              ven=
dors 
=0A                                              >> there is=
 an=0A                                              interoperability need.=
=0A                                              Justin responded that he=
=0A                                              disagrees 
=0A         =
                                     >> and that the=0A              =
                                resource server needs to=0A                =
                              understand the access=0A                     =
                         token and 
=0A                                 =
             >> referred to the=0A                                   =
           recent draft submission=0A                                      =
        for the token=0A                                              intro=
spection 
=0A                                              >> endp=
oint. Derek=0A                                              indicated that =
the=0A                                              resource server has to=
=0A                                              understand 
=0A        =
                                      >> the content of=0A           =
                                   the access token and the=0A             =
                                 token introspection=0A                    =
                          endpoint 
=0A                                 =
             >> just pushes the=0A                                   =
           problem around: the=0A                                          =
    resource server has to=0A                                              =
send the 
=0A                                              >> acce=
ss token to=0A                                              the authorizati=
on server=0A                                              and then the reso=
urce=0A                                              server 
=0A        =
                                      >> gets the result=0A          =
                                    back (which he the
=0A              =
                                n
=0A                                   =
           >    a
=0A                                      =
        >> gain needs to=0A                                          =
    understand) in order to=0A                                             =
 make a meaningful=0A                                              authoriz=
ation decision.
=0A                                              >>=
;
=0A                                              >> Everyone agr=
eed=0A                                              that the client must=0A=
                                              receive the session key=0A   =
                                           from the authorization=0A       =
                                       server and that this=0A             =
                                 approach has to be=0A                     =
                         standardized. It was also=0A                      =
                        agreed that this is a=0A                           =
                   common approach among all=0A                            =
                  three key distribution=0A                                =
              mechanisms.
=0A                                           =
   >>
=0A                                              >> Ha=
nnes asked the=0A                                              participants=
 to think=0A                                              about their prefe=
rence.
=0A                                              >>
=0A =
                                             >> The questions=0A     =
                                         regarding key naming and=0A       =
                                       the indication for the=0A           =
                                   intended resource server=0A             =
                                 the client wants to talk=0A               =
                               to have been postponed.
=0A              =
                                >>
=0A                            =
                  >> Ciao
=0A                                     =
         >> Hannes
=0A                                            =
  >>
=0A                                              >>
=
=0A                                              >>=0A               =
                               ____________________________________________=
___
=0A                                              >> OAuth mail=
ing=0A                                              list
=0A            =
                                  >> OAut=
h@ietf.org
=0A                                              >>=
 https://www.ietf.org/mailman/listinfo/oauth
=0A    =
                                          >=0A                          =
                    _______________________________________________
=0A =
                                             > OAuth mailing list
=0A=
                                              > OAuth@ietf.org
=0A                                              =
> https://www.ietf.org/mailman/listinfo/oauth
=0A=

=0A                      =

=0A____________________________________________=
___
=0A                                              OAuth mailing list<=
br>=0A                                              OAuth@ietf.org
=0A                                             =
 https://www.ietf.org/mailman/listinfo/oauth
=0A____=
___________________________________________
=0A                         =
                     OAuth mailing list
=0A                             =
                 OAuth@ietf.org
=0A     =
                                         https://www.ietf.o=
rg/mailman/listinfo/oauth
=0A                                       =

=0A                                              
=0A        =
                                    =0A                              =

=0A                                        =0A     =
                                 =0A                                 =

=0A                                    =0A                                      _________________=
______________________________
=0A                               =
         OAuth mailing list
=0A                            =
            OAuth@ietf.org
=
=0A                                        https://ww=
w.ietf.org/mailman/listinfo/oauth
=0A                        =

=0A                                    =0A=

=0A                                =
=0A                                
=0A                           =

=0A                              
=0A                        =

=0A                          
=0A                        =0A                      
=0A                    
=0A  =

=0A                  
=0A                  
=0A=

=0A              
=0A            
=0A      =

=0A          
=0A          ___________________________________=
____________
=0A          OAuth mailing list
=0A          OAuth@ietf.org
=0A          https:/=
/www.ietf.org/mailman/listinfo/oauth
=0A          
=0A        =0A      
=0A      
=0A      
=0A      
=0A      
=0A      _______________________________________________=0AOAuth mailing list=0AOAu=
th@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth=0A=0A    =0A    
=0A  
=0A=0A

<=
/blockquote>__________________________=
_____________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--1502656925-1936149940-1361037448=:95269--

From sakimura@gmail.com  Sat Feb 16 21:53:40 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32DF21F894C for ; Sat, 16 Feb 2013 21:53:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.809
X-Spam-Level: 
X-Spam-Status: No, score=-2.809 tagged_above=-999 required=5 tests=[AWL=0.190,  BAYES_00=-2.599, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSAvnVaSWckX for ; Sat, 16 Feb 2013 21:53:39 -0800 (PST)
Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7AC21F8899 for ; Sat, 16 Feb 2013 21:53:39 -0800 (PST)
Received: by mail-qa0-f46.google.com with SMTP id o13so862369qaj.12 for ; Sat, 16 Feb 2013 21:53:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=7woLvcFs7JphiCD+XykyQMd0oAmJsY5765o4C5OggYk=; b=x6pN9x9CLspUWgxbaHrOcVZvwpScRoPi1B4CjpLjYx/gREtnNu7lG7BWR7owRzgX33 R+6DwxFioxjlC8O19WdFB0Lnp9u6SoqMJFXf7gUfFykIpJmLX0vvZXS6nI86OKx6rUH3 9HsWPgfA8r/2W0xk/6W+0x7XqCaqi/jG9nKNHcXjlWGHuPLSJa9RlI7M6HnKwKhCm1RY I6EPw9/liNaHL8IZYpY5QKCqFv8E+XXPun/HcfsjAhvg8zIIr2gk3/Gz5dCqsbPWJNEk c+HB7BKymx+X1S47i71hqOWjs4hppvpWMz6uGDT57afNXLql3z8UNA/g9jFOuNkXFzqc esWA==
MIME-Version: 1.0
X-Received: by 10.49.12.138 with SMTP id y10mr3124846qeb.64.1361080418797; Sat, 16 Feb 2013 21:53:38 -0800 (PST)
Received: by 10.49.106.161 with HTTP; Sat, 16 Feb 2013 21:53:38 -0800 (PST)
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367443619@TK5EX14MBXC285.redmond.corp.microsoft.com>
References: <51195F3F.7000704@mitre.org> <4E1F6AAD24975D4BA5B16804296739436743E371@TK5EX14MBXC285.redmond.corp.microsoft.com> <7FB7A108-EA9E-429A-BD86-7E09EA206748@ve7jtb.com> <511A51D6.9040604@mitre.org> <9FC3A5CD-B4EC-4CA2-8082-FAC65C499B3B@ve7jtb.com> <4E1F6AAD24975D4BA5B168042967394367443619@TK5EX14MBXC285.redmond.corp.microsoft.com>
Date: Sun, 17 Feb 2013 14:53:38 +0900
Message-ID: 
From: Nat Sakimura 
To: Mike Jones 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: Client secret rotation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Feb 2013 05:53:40 -0000

Sounds reasonable.

# just started to catch up with the emails of past 6 days...

2013/2/13 Mike Jones :
> +1
>
> ________________________________
> From: John Bradley
> Sent: 2/12/2013 8:20 AM
> To: Justin Richer
> Cc: Mike Jones; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Registration: Client secret rotation
>
> Yes, that agrees with my thoughts on it.
>
> John B.
> On 2013-02-12, at 11:29 AM, Justin Richer  wrote:
>
>> This is actually the approach that I favor now as well -- let the server
>> do the secret rotation if it wants to, and have the client be prepared to
>> receive a new client_secret or registration_access_token on any read or
>> update request.
>>
>> This would necessitate changing the returned values, essentially
>> collapsing the returns from the read/update and rotate actions into one
>> structure that's closer to the one returned from initial registration. This
>> has the added benefit of parallelizing the responses for these three
>> actions, which I like as well.
>>
>> -- Justin
>>
>> On 02/11/2013 08:42 PM, John Bradley wrote:
>>> OAuth doesn't say anything about client secrets other than they are
>>> provisioned in a magic realm outside the OAuth spec (Getting in the mood for
>>> the next IETF).
>>>
>>> Rotating client secrets was something I made up for connect because it
>>> seemed like a good idea at the time given that someone breaking in to the
>>> registration endpoint could take over a connection.
>>>
>>> We later separated the authentication to the token endpoint from the
>>> registration endpoint,in what I think was a good move.
>>>
>>> It is sort of up to the authorization server to make decisions about
>>> rotating client secrets, I expect that in the real world a client would try
>>> access ing the token endpoint and get back a invalid_client error response
>>> and then heck it's registration to see if the client_secret has changed.
>>>
>>> I suppose that a client could request rotating its secret if it thinks it
>>> has been compromised,  however the compromiser is more likely to quickly
>>> change the secret to lock out the legitimate clients before the good one
>>> notices.    I think the client wanting to rotate is enough of a edge case
>>> that it could deal with it out of band.
>>>
>>> Letting the server rotate the client secret according to what ever policy
>>> it decides is best is probably safest.
>>>
>>> We didn't have anything for rotating the access token.  I suspect that
>>> rotating it under the clients control is going to create as many problems as
>>> it solves.
>>>
>>> If you want to rotate it,  make it a refresh token that is issues and use
>>> OAuth to provide access tokens from the token endpoint.   Creating a new
>>> endpoint to duplicate existing OAuth functionality is overkill.
>>>
>>> John B.
>>> On 2013-02-11, at 10:18 PM, Mike Jones 
>>> wrote:
>>>
>>>> The rotate_secret operation was added to OpenID Connect Registration as
>>>> a workaround to the fact that registration updates used to be authenticated
>>>> using the client secret, so it seemed overly dangerous to have an update
>>>> operation potentially return an updated secret and have the secret be lost
>>>> due to communication problems - leaving the client stranded.  Since then,
>>>> registration was changed to use a bearer token to authenticate update
>>>> operations, and so this failure mode can't occur anymore.  It was an
>>>> omission not to have deleted the unneeded operation then.
>>>>
>>>> It's been deleted from OpenID Connect Registration and should likewise
>>>> be deleted from OAuth registration, since it is unneeded.  If a new client
>>>> secret is needed, there's nothing stopping the registration server from
>>>> returning it in the result of an update operation.
>>>>
>>>>                              -- Mike
>>>>
>>>> -----Original Message-----
>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>>>> Of Justin Richer
>>>> Sent: Monday, February 11, 2013 1:15 PM
>>>> To: oauth@ietf.org
>>>> Subject: [OAUTH-WG] Registration: Client secret rotation
>>>>
>>>> Draft -05 of OAuth Dynamic Client Registration [1] defines a means of
>>>> the client requesting a new client_secret (if applicable) and a new
>>>> registration_access_token. Client secrets MAY expire after some period of
>>>> time, and this method allows for a refresh of that secret. Draft -00 defined
>>>> no such operation, drafts -01 through -04 defined this operation in terms of
>>>> the operation=rotate_secret parameter, and draft -05 defines it through a
>>>> secondary endpoint, the Client Secret Rotation Endpoint.
>>>> This raises several questions:
>>>>
>>>>  - Should the client be allowed to request rotation of its secret?
>>>>  - Would a client ever take this action of its own accord?
>>>>  - Can a server rotate the secret of the client without the client
>>>> asking? (This seems to be an obvious "yes")
>>>>
>>>> Alternatives that keep this functionality include defining the
>>>> rotate_secret operation in terms of an HTTP verb, a query parameter, or
>>>> separate endpoint. Alternatively, we could drop the rotate_secret operation
>>>> all together. If we do this, we have to decide if the client secret can
>>>> still expire. If it can, then we need a way for the client to get this new
>>>> secret through a means that doesn't require it to request a change in
>>>> secret, such as sending it back as part of the client READ operation (see
>>>> other thread on RESTful verbs).
>>>>
>>>>  -- Justin
>>>>
>>>>
>>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>>>> _______________________________________________
>>>> 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
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

From sakimura@gmail.com  Sat Feb 16 21:55:41 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F8221F894C for ; Sat, 16 Feb 2013 21:55:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.128
X-Spam-Level: 
X-Spam-Status: No, score=-3.128 tagged_above=-999 required=5 tests=[AWL=0.471,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 839-uT7MZBzN for ; Sat, 16 Feb 2013 21:55:40 -0800 (PST)
Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5513821F8899 for ; Sat, 16 Feb 2013 21:55:40 -0800 (PST)
Received: by mail-qa0-f45.google.com with SMTP id g10so866721qah.11 for ; Sat, 16 Feb 2013 21:55:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=4rdECwMHvbvjA5UEKT8rMaJQPL4KRVSyDWlgPC5yTwM=; b=ST1CoXEt2P6Rkrf3CAyXEUi25KlV09SGA/GNuq7FaSQhPl4ixaxn2AFFZS11ycHuhj X9rfN4DLWfORfaGC0z0bEDzH9BrLU/siikYMCIwM3lSNvq5KzD1eEphEFRyzZI1Lsbns 2isqcsGogkoYQmmMdR0X3ldTwqkVUXf/3sVT1mogHuARe8BO2qYY/4pVDEmAkLTGZ93Y PpDHl12M3nAYu9mgmeC0q2ocAU/aVvu1sFoXeztPtgAzy4a7NEtM/6gD1kkbl7l7xJsG sVPzxxHRVRbcrPcWDhL8BbolJMDAQi7swiLLbfF6UqrhWJD+LZYcOU/Enfzd6xALM5Tf SIAg==
MIME-Version: 1.0
X-Received: by 10.224.185.148 with SMTP id co20mr3924562qab.94.1361080539790;  Sat, 16 Feb 2013 21:55:39 -0800 (PST)
Received: by 10.49.106.161 with HTTP; Sat, 16 Feb 2013 21:55:39 -0800 (PST)
In-Reply-To: 
References: <51195F39.3040809@mitre.org> <4E1F6AAD24975D4BA5B16804296739436743E3DD@TK5EX14MBXC285.redmond.corp.microsoft.com>  <511A586B.9060606@mitre.org> 
Date: Sun, 17 Feb 2013 14:55:39 +0900
Message-ID: 
From: Nat Sakimura 
To: Torsten Lodderstedt 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: Endpoint Definition (& operation parameter)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Feb 2013 05:55:41 -0000

+1

2013/2/13 Torsten Lodderstedt :
>
> Am 12.02.2013 um 15:57 schrieb Justin Richer :
>
>>
>> I think that's a very important difference.
>
> I fully agree.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

From sakimura@gmail.com  Sat Feb 16 22:04:06 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EABD821F8972 for ; Sat, 16 Feb 2013 22:04:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.171
X-Spam-Level: 
X-Spam-Status: No, score=-3.171 tagged_above=-999 required=5 tests=[AWL=0.428,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqjNv6NlSHL5 for ; Sat, 16 Feb 2013 22:04:05 -0800 (PST)
Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 00A8B21F894C for ; Sat, 16 Feb 2013 22:04:04 -0800 (PST)
Received: by mail-qc0-f179.google.com with SMTP id b40so1680586qcq.24 for ; Sat, 16 Feb 2013 22:04:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=M+ecvyeyXPxM8RbfdbUxjwzGV5L37idNWHa6gPAfpJA=; b=cD7ZRzRm18ZTz8ASOlGw+XHvPmPdYOBI4BeO5Pfz5FYbUWCA1pa6pKFK8/QmttB7Lf 1vG073yn8qNJUFJNEQnEgDzN/9PAlVUK/FVHJp3EmROSkrfktdK7i++BN4DYPjqcoAsw OPbaU9YhLoHLV4vI7ljHSG96e07wNe8wRxnL/nmb8MEFyPWojMtFs+98FlgUmj8fIiwi T2jT0V/P4Fe34MyO1sYZbUJ2qqt4ix3HiXTTfDkh60DbU1rrub64hzJcrMBGHfhbDx1W Od7Hn8qkpf4SN3NEgxcUlHliN3D89pVglg1/41H6uldjt8eTdUuu8DLUg8G4lNzrTm6s /LzA==
MIME-Version: 1.0
X-Received: by 10.224.185.148 with SMTP id co20mr3930007qab.94.1361081044498;  Sat, 16 Feb 2013 22:04:04 -0800 (PST)
Received: by 10.49.106.161 with HTTP; Sat, 16 Feb 2013 22:04:04 -0800 (PST)
In-Reply-To: 
References: <51195F36.6040705@mitre.org> <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com> <511BAA8B.8030309@mitre.org>  <-4554688250617930935@unknownmsgid>   <4687F290-4855-49DE-892F-F9694BB211D4@ve7jtb.com> <511CF2C9.9040604@mitre.org> 
Date: Sun, 17 Feb 2013 15:04:04 +0900
Message-ID: 
From: Nat Sakimura 
To: John Bradley 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Feb 2013 06:04:06 -0000

> When sending an update, a client MUST send all metadata fields returned
> from the server in its initial registration or previous read or update
> call, including its client_id. A server MAY replace any missing or
> invalid fields with default values, or it MAY return an error as
> described in the Error Response section. A server MUST return all
> provisioned fields in its response. A server MUST NOT change the
> client_id field. A server MAY change the client_secret and/or
> refresh_access_token fields.

Say the client registered some value. Sometime later, the server
changed a value due to some policy or security reasons etc. The client
when UPDATES with the previously registered value, what is going to
happen to the changed value?

>> DELETE to be used correctly is I think going to delete the client_id and all associated tokens and cause a ripple effect in removing grants associated with that client_id.
>
> This is how I would interpret it as well. It's de-provisioning the
> client, not resetting it.

For DELETE, I can think of an attack such that

1. Register as a client.
2. Send spam links to random users.
3. When user "authorizes", suck the user data such as contacts out.
4. DELETE the registration and disappear.

To prevent something like this, it should probably be something more
akin to "suspend" rather than completely de-provisioning.

From Michael.Jones@microsoft.com  Sat Feb 16 22:12:03 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D6C21F89D5 for ; Sat, 16 Feb 2013 22:12:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.586
X-Spam-Level: 
X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9t00WtlrtQ6G for ; Sat, 16 Feb 2013 22:12:02 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.31]) by ietfa.amsl.com (Postfix) with ESMTP id 37E2F21F894C for ; Sat, 16 Feb 2013 22:12:02 -0800 (PST)
Received: from BY2FFO11FD014.protection.gbl (10.1.15.200) by BY2FFO11HUB026.protection.gbl (10.1.14.112) with Microsoft SMTP Server (TLS) id 15.0.620.12; Sun, 17 Feb 2013 06:11:53 +0000
Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD014.mail.protection.outlook.com (10.1.14.76) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Sun, 17 Feb 2013 06:11:52 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.96]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Sun, 17 Feb 2013 06:11:51 +0000
From: Mike Jones 
To: Nat Sakimura , John Bradley 
Thread-Topic: [OAUTH-WG] Registration: RESTful client lifecycle management
Thread-Index: AQHOCJzxVGwYODuh3UmktcEEXHrfK5h1dc0AgAJusICAAAKVAIAAOFkAgAAd2QCAAHj+gIAAsSiAgAAEXoCAAAQAAIAEKCsAgAABe7A=
Date: Sun, 17 Feb 2013 06:11:50 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943674691FB@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <51195F36.6040705@mitre.org> <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com> <511BAA8B.8030309@mitre.org>  <-4554688250617930935@unknownmsgid>   <4687F290-4855-49DE-892F-F9694BB211D4@ve7jtb.com> <511CF2C9.9040604@mitre.org>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.35]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464002)(55885001)(377454001)(189002)(199002)(51704002)(23726001)(46406002)(55846006)(20776003)(31966008)(44976002)(79102001)(54356001)(74662001)(46102001)(47446002)(47776003)(74502001)(16406001)(53806001)(63696002)(66066001)(77982001)(59766001)(51856001)(80022001)(65816001)(50986001)(33656001)(54316002)(47736001)(47976001)(76482001)(56816002)(5343655001)(4396001)(50466001)(56776001)(49866001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB026; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07607ED19A
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Feb 2013 06:12:03 -0000

I agree.  If we have it at all, DELETE should be a declaration by the Clien=
t that requests by it should no longer be honored.  It should be up to the =
Server whether to implement this as suspension or deletion.  At most, I bel=
ieve it should be an optional operation, which MAY be supported.

				-- Mike

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of N=
at Sakimura
Sent: Saturday, February 16, 2013 10:04 PM
To: John Bradley
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management

> When sending an update, a client MUST send all metadata fields=20
> returned from the server in its initial registration or previous read=20
> or update call, including its client_id. A server MAY replace any=20
> missing or invalid fields with default values, or it MAY return an=20
> error as described in the Error Response section. A server MUST return=20
> all provisioned fields in its response. A server MUST NOT change the=20
> client_id field. A server MAY change the client_secret and/or=20
> refresh_access_token fields.

Say the client registered some value. Sometime later, the server changed a =
value due to some policy or security reasons etc. The client when UPDATES w=
ith the previously registered value, what is going to happen to the changed=
 value?

>> DELETE to be used correctly is I think going to delete the client_id and=
 all associated tokens and cause a ripple effect in removing grants associa=
ted with that client_id.
>
> This is how I would interpret it as well. It's de-provisioning the=20
> client, not resetting it.

For DELETE, I can think of an attack such that

1. Register as a client.
2. Send spam links to random users.
3. When user "authorizes", suck the user data such as contacts out.
4. DELETE the registration and disappear.

To prevent something like this, it should probably be something more akin t=
o "suspend" rather than completely de-provisioning.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

From torsten@lodderstedt.net  Sun Feb 17 02:54:45 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1361D21F8845; Sun, 17 Feb 2013 02:54:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.487
X-Spam-Level: 
X-Spam-Status: No, score=-1.487 tagged_above=-999 required=5 tests=[AWL=0.762,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pi9KijUFUVqP; Sun, 17 Feb 2013 02:54:44 -0800 (PST)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.36]) by ietfa.amsl.com (Postfix) with ESMTP id E607E21F87D5; Sun, 17 Feb 2013 02:54:43 -0800 (PST)
Received: from [79.253.38.170] (helo=[192.168.71.42]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1U71tJ-0001r1-Cg; Sun, 17 Feb 2013 11:54:41 +0100
Message-ID: <5120B6EE.60801@lodderstedt.net>
Date: Sun, 17 Feb 2013 11:54:38 +0100
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: "Richer, Justin P." 
References: <20130215215423.23019.50224.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: "internet-drafts@ietf.org" , "" , "" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Feb 2013 10:54:45 -0000

Hi Justin,

the new revision seems to catch the state of discussion and is 
consistent. Thank's for bringing this topic forward.

On your editor's not in section 4.2.: In my opinion, the 404 due to a 
none-existing resource should precede the 403. I would suggest to point 
out your thoughts on the access token. But as with any HTTP request, 
there could be other ways to authenticate to this endpoint. I therefore 
would not connect both aspects to much.

section 4.3

"This request MUST include all fields described in Client Metadata
    (Section 2) as returned to the Client from a previous register, read,
    or update operation."

Just to make sure I got it. Any data element omitted in this request is 
deleted/reset by the AS?

section 5.1

Something seems to be missing at

"The response contains the following fields:

    , as well as a Client Secret if this client is a confidential client."

regards,
Torsten.

Am 15.02.2013 23:00, schrieb Richer, Justin P.:
> Everyone, there's a new draft of DynReg up on the tracker. This draft tries to codify the discussions so far from this week into something we can all read. There are still plenty of open discussion points and items up for debate. Please read through this latest draft and see what's changed and help assure that it properly captures the conversations. If you have any inputs for the marked [[ Editor's Note ]] sections, please send them to the list by next Thursday to give me opportunity to get any necessary changes in by the cutoff date of Monday the 22nd.
>
> Thanks for all of your hard work everyone, I think this is *really* coming along now.
>
>   -- Justin
>
> On Feb 15, 2013, at 4:54 PM, internet-drafts@ietf.org wrote:
>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Web Authorization Protocol Working Group of the IETF.
>>
>> 	Title           : OAuth Dynamic Client Registration Protocol
>> 	Author(s)       : Justin Richer
>>                           John Bradley
>>                           Michael B. Jones
>>                           Maciej Machulak
>> 	Filename        : draft-ietf-oauth-dyn-reg-06.txt
>> 	Pages           : 21
>> 	Date            : 2013-02-15
>>
>> Abstract:
>>    This specification defines an endpoint and protocol for dynamic
>>    registration of OAuth Clients at an Authorization Server.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-06
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> 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

From torsten@lodderstedt.net  Sun Feb 17 03:04:02 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F9321F87B1 for ; Sun, 17 Feb 2013 03:04:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.572
X-Spam-Level: 
X-Spam-Status: No, score=-1.572 tagged_above=-999 required=5 tests=[AWL=0.677,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ih6V711lrpk for ; Sun, 17 Feb 2013 03:04:01 -0800 (PST)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.97]) by ietfa.amsl.com (Postfix) with ESMTP id 7E23B21F86D5 for ; Sun, 17 Feb 2013 03:04:01 -0800 (PST)
Received: from [79.253.38.170] (helo=[192.168.71.42]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1U722K-0006pp-4E; Sun, 17 Feb 2013 12:04:00 +0100
Message-ID: <5120B91D.90609@lodderstedt.net>
Date: Sun, 17 Feb 2013 12:03:57 +0100
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Sergey Beryozkin 
References: <20130213221326.3987.20729.idtracker@ietfa.amsl.com> <511C1155.6050709@lodderstedt.net> <511CBD2B.3080000@gmail.com>
In-Reply-To: <511CBD2B.3080000@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-05.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Feb 2013 11:04:02 -0000

Hi Sergey,

Am 14.02.2013 11:32, schrieb Sergey Beryozkin:
>> - an attempt to revoke an invalid token is now handled like a successful
>> revocation request (status code 200)
> Does it create some precedent, meaning that while people suggest using 
> 4xx statuses to indicate different sort of failures in this case 200 
> is returned, to eliminate a potential security attack. I mean, should 
> it become the recommended practice ?
>
> For example, in the discussion about DELETE, should it be 204 that is 
> returned all the time ?
>
> Sergey 

good point. In this particular case, we decided to go with 200 merely 
because the "error" indicates a state the client anyway wanted to 
achieve for the particular token. I dont know whether this can be 
generalized.

regards,
Torsten.

From sberyozkin@gmail.com  Sun Feb 17 09:31:43 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E4A21F8AF4 for ; Sun, 17 Feb 2013 09:31:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.599
X-Spam-Level: 
X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZ0pCAXeMwdp for ; Sun, 17 Feb 2013 09:31:41 -0800 (PST)
Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 6477521F8AD0 for ; Sun, 17 Feb 2013 09:31:41 -0800 (PST)
Received: by mail-wg0-f46.google.com with SMTP id fg15so3937189wgb.25 for ; Sun, 17 Feb 2013 09:31:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=+M6L1+o+7QQkrZ2wxjdeJH1QkBjyv7FA0rl0S4QwFx8=; b=FbdLQeVcNvuWffDlDXHAffTqdq/AFQh+HNKe/mNX4XUrNcb/ij0klU7DZCbjnGUrmJ 7T78sQLetRF3Vw2UVfPsEWKy3V8vIJDEqq/ya1ViNso+9VtC0y6SLVs96n3mmXOAhVTw jcG+95bIUA7njg8wOC0E3NJyDnar9JQn87IoCWnCGlCbvZ+eLtBtBT/qkB7tn5mjVDlD 2E5+Ft4f2foEpihYf5tuK7Nr6ZnZbM+XMtF/YjbKFrrPyOX3/+w6K9FEovnupegvoM7K FFh7i/zwGSiWPlUtDjsZi5GfJZjDcns/3TdUFiecpfPDP7mjTi+xwMaxZrsCgeOJfQX3 qnWA==
X-Received: by 10.194.77.129 with SMTP id s1mr14638820wjw.17.1361122300197; Sun, 17 Feb 2013 09:31:40 -0800 (PST)
Received: from [192.168.2.5] ([79.97.76.201]) by mx.google.com with ESMTPS id ex1sm17038752wib.7.2013.02.17.09.31.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Feb 2013 09:31:39 -0800 (PST)
Message-ID: <512113F5.4050909@gmail.com>
Date: Sun, 17 Feb 2013 17:31:33 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: oauth@ietf.org
References: <0573984A-8C11-4960-9BC6-F44D4B664C19@gmx.net>  <511A7D27.8010209@mitre.org> <4E1F6AAD24975D4BA5B16804296739436744BD23@TK5EX14MBXC285.redmond.corp.microsoft.com> <1360891897.14004.YahooMailNeo@web31811.mail.mud.yahoo.com>  <1360912115.36543.YahooMailNeo@web31811.mail.mud.yahoo.com> <2A0F585F-2CEF-418D-9654-5084E6C9BD0D@lodderstedt.net> <1360944589.51724.YahooMailNeo@web31808.mail.mud.yahoo.com>  <511EA0A3.7080000@mitre.org> <1360962242.18571.YahooMailNeo@web31805.mail.mud.yahoo.com>  <1360994570.11377.YahooMailNeo@web31805.mail.mud.yahoo.com>  <1361037448.95269.YahooMailNeo@web31803.mail.mud.yahoo.com>
In-Reply-To: <1361037448.95269.YahooMailNeo@web31803.mail.mud.yahoo.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Feb 2013 17:31:43 -0000

Hi,
On 16/02/13 17:57, William Mills wrote:
> The reason to support 1.0a tokens in 2 is simply to provide a migration
> path when a site has 1.0a endpoint it wants to support.
>

I really like the idea of having a migration path, which is very 
important to have, but IMHO this approach won't work. Appears to me that 
having a MAC completed (whenever feasible of course) will work better, 
it will be a statement of intent/invitation...

Cheers, Sergey

> ------------------------------------------------------------------------
> *From:* Phil Hunt 
> *To:* William Mills 
> *Cc:* Justin Richer ; Tim Bray ;
> IETF oauth WG 
> *Sent:* Friday, February 15, 2013 11:22 PM
> *Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference
> Call - 11th February 2013
>
> I don't see oauth1 tokens as a short cut because eran said the token in
> oauth1 (which is inside the oauth1 spec) had many implementation
> problems by client developers. Why go there and re-invent what jwt could
> do easily?
>
> Do you need hok? Do you need replay protection? Do you need message
> signing? Are asymmetric keys needed? I get the impression the group is
> less interested in the last two.
>
> There is also key distribution to resource server. I think we have
> client nailed but getting keys to resource server needs some discussion
> - especially if the path is through the token itself.
>
> I suppose we can move faster if we assume rs obtains keys in an
> unspecified manner like what happened in oauth1.
>
> Phil
>
> Sent from my phone.
>
> On 2013-02-15, at 22:02, William Mills  > wrote:
>
>> All the same concepts/info are available in the AS: client ID, client
>> auth, and can deliver both token and secret. What's magic once the
>> client has the token that's missing?
>>
>> ------------------------------------------------------------------------
>> *From:* Phil Hunt >
>> *To:* William Mills > >
>> *Cc:* Justin Richer >;
>> Tim Bray >; IETF oauth WG
>> >
>> *Sent:* Friday, February 15, 2013 1:52 PM
>> *Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team
>> Conference Call - 11th February 2013
>>
>> Sorry. I have to disagree. The way 1.0 is written, it is not a
>> shortcut to turn it into a token for 2.
>>
>> Phil
>>
>> Sent from my phone.
>>
>> On 2013-02-15, at 13:04, William Mills > > wrote:
>>
>>> >I've brought it up before, but I think it might be worthwhile, at
>>> least as an exercise, to define a method to get OAuth1-style tokens
>>> from an OAuth2 token endpoint. You'd defer to OAuth1 for how to use
>>> them >with a protected resource.
>>>
>>> YES!
>>>
>>> ------------------------------------------------------------------------
>>> *From:* Justin Richer >
>>> *To:* Tim Bray >
>>> *Cc:* William Mills >> >; IETF oauth WG >> >
>>> *Sent:* Friday, February 15, 2013 12:54 PM
>>> *Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team
>>> Conference Call - 11th February 2013
>>>
>>> So that you can fetch and manage all your tokens using the same code
>>> paths as the OAuth2 services. The "get a token" part will be
>>> identical to Oauth2 Bearer (except for some details of what comes
>>> back from the token endpoint, of course), it's the "use a token" bit
>>> that really changes and is up in the air. You get to use scopes, and
>>> state, and refresh tokens, and all the other good stuff.
>>>
>>> I've brought it up before, but I think it might be worthwhile, at
>>> least as an exercise, to define a method to get OAuth1-style tokens
>>> from an OAuth2 token endpoint. You'd defer to OAuth1 for how to use
>>> them with a protected resource.
>>>
>>> -- Justin
>>>
>>> On 02/15/2013 11:49 AM, Tim Bray wrote:
>>>> Not deeply acquainted with the Flickr scenario, but it occurs to me
>>>> to ask: If OAuth 1.0 is working well for them, why don�t they just
>>>> keep using it? I.e. if there�s already a good solution in place for
>>>> people who require secure authn/authz over insecure channels, why
>>>> would we go the extra work of duplicating that in OAuth 2 territory? -T
>>>>
>>>> On Fri, Feb 15, 2013 at 8:09 AM, William Mills
>>>> > wrote:
>>>>
>>>>     I'll repeat the use case for Flickr, which requires OAuth 1.0a
>>>>     type capabilites that OAuth 2 does not provide. Simply stating
>>>>     "move to HTTPS" is not a viable response here.
>>>>
>>>>     ------------------------------------------------------------------------
>>>>     *From:* Torsten Lodderstedt >>>     >
>>>>     *To:* William Mills >>>     >
>>>>     *Cc:* Mike Jones >>>     >; Justin Richer
>>>>     >; Phil Hunt
>>>>     >; IETF oauth
>>>>     WG >
>>>>     *Sent:* Friday, February 15, 2013 7:22 AM
>>>>     *Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team
>>>>     Conference Call - 11th February 2013
>>>>
>>>>     Hi Bill,
>>>>
>>>>     I think one needs to compare the costs/impact of HTTPS on one
>>>>     side and the implementation of integrity protection and replay
>>>>     detection on the other. We had this discussion several times.
>>>>
>>>>     regards,
>>>>     Torsten.
>>>>
>>>>     Am 15.02.2013 um 08:08 schrieb William Mills
>>>>     >:
>>>>
>>>>>     I fundamentally disagree with that too. OAuth 2 is the
>>>>>     *framework*, one which supports multiple token types. Bearer
>>>>>     tokens were the first credential type defined.
>>>>>
>>>>>     OAuth 1.0a also requires HTTPS transport for authentication and
>>>>>     getting the token.
>>>>>
>>>>>     There are real use cases for tokens usable over plain text with
>>>>>     integrity protection.
>>>>>
>>>>>     -bill
>>>>>
>>>>>     ------------------------------------------------------------------------
>>>>>     *From:* Torsten Lodderstedt >>>>     >
>>>>>     *To:* William Mills >>>>     >
>>>>>     *Cc:* Mike Jones >>>>     >; Justin Richer
>>>>>     >; Phil Hunt
>>>>>     >; IETF
>>>>>     oauth WG >
>>>>>     *Sent:* Thursday, February 14, 2013 10:05 PM
>>>>>     *Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team
>>>>>     Conference Call - 11th February 2013
>>>>>
>>>>>     Hi Bill,
>>>>>
>>>>>     OAuth 2.0 took a different direction by relying on HTTPS to
>>>>>     provide the basic protection. So the need to have a token,
>>>>>     which can be used for service requests over plain HTTP is
>>>>>     arguable. My understanding of this activity was, the intend is
>>>>>     to provide additional protection on top of HTTPS.
>>>>>
>>>>>     regards,
>>>>>     Torsten.
>>>>>
>>>>>     Am 15.02.2013 um 02:31 schrieb William Mills
>>>>>     >:
>>>>>
>>>>>>     I disagree with "That was the impediment to OAuth 1.0 adoption
>>>>>>     that OAuth 2.0 solved in the first place.", unless "solving"
>>>>>>     means does not address the need for it at all.
>>>>>>
>>>>>>     OAuth 2 does several good things, but it still lacks a defined
>>>>>>     token type that is safe to user over plain text HTTP. 1.0a
>>>>>>     solved that.
>>>>>>
>>>>>>     ------------------------------------------------------------------------
>>>>>>     *From:* Mike Jones >>>>>     >
>>>>>>     *To:* Justin Richer >>>>>     >; Phil Hunt >>>>>     >
>>>>>>     *Cc:* IETF oauth WG >
>>>>>>     *Sent:* Thursday, February 14, 2013 1:44 PM
>>>>>>     *Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team
>>>>>>     Conference Call - 11th February 2013
>>>>>>
>>>>>>     I'm in favor of reusing the JWT work that this WG is also
>>>>>>     doing. :-)
>>>>>>
>>>>>>     I'm pretty skeptical of us inventing another custom scheme for
>>>>>>     signing HTTP headers. That was the impediment to OAuth 1.0
>>>>>>     adoption that OAuth 2.0 solved in the first place.
>>>>>>
>>>>>>     -- Mike
>>>>>>
>>>>>>     -----Original Message-----
>>>>>>     From: oauth-bounces@ietf.org 
>>>>>>     [mailto:oauth-bounces@ietf.org
>>>>>>     ] On Behalf Of Justin Richer
>>>>>>     Sent: Tuesday, February 12, 2013 9:35 AM
>>>>>>     To: Phil Hunt
>>>>>>     Cc: IETF oauth WG
>>>>>>     Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team
>>>>>>     Conference Call - 11th February 2013
>>>>>>
>>>>>>     That's my reading of it as well, Phil, thanks for providing
>>>>>>     the clarification. One motivator behind using a JSON-based
>>>>>>     token is to be able to re-use some of the great work that the
>>>>>>     JOSE group is doing but apply it to an HTTP payload.
>>>>>>
>>>>>>     What neither of us want is a token type that requires stuffing
>>>>>>     all query, header, and other parameters *into* the JSON object
>>>>>>     itself, which would be a more SOAPy approach.
>>>>>>
>>>>>>     -- Justin
>>>>>>
>>>>>>     On 02/12/2013 12:30 PM, Phil Hunt wrote:
>>>>>>     > Clarification. I think Justin and I were in agreement that
>>>>>>     we don't want to see a format that requires JSON payloads. We
>>>>>>     are both interested in a JSON token used in the authorization
>>>>>>     header that could be based on a computed signature of some
>>>>>>     combination of http headers and body if possible.
>>>>>>     >
>>>>>>     > Phil
>>>>>>     >
>>>>>>     > @independentid
>>>>>>     > www.independentid.com 
>>>>>>     > phil.hunt@oracle.com 
>>>>>>     >
>>>>>>     >
>>>>>>     >
>>>>>>     >
>>>>>>     >
>>>>>>     > On 2013-02-12, at 1:10 AM, Hannes Tschofenig wrote:
>>>>>>     >
>>>>>>     >> Here are my notes.
>>>>>>     >>
>>>>>>     >> Participants:
>>>>>>     >>
>>>>>>     >> * John Bradley
>>>>>>     >> * Derek Atkins
>>>>>>     >> * Phil Hunt
>>>>>>     >> * Prateek Mishra
>>>>>>     >> * Hannes Tschofenig
>>>>>>     >> * Mike Jones
>>>>>>     >> * Antonio Sanso
>>>>>>     >> * Justin Richer
>>>>>>     >>
>>>>>>     >> Notes:
>>>>>>     >>
>>>>>>     >> My slides are available here:
>>>>>>     >> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
>>>>>>     >>
>>>>>>     >> Slide #2 summarizes earlier discussions during the
>>>>>>     conference calls.
>>>>>>     >>
>>>>>>     >> -- HTTP vs. JSON
>>>>>>     >>
>>>>>>     >> Phil noted that he does not like to use the MAC Token draft
>>>>>>     as a starting point because it does not re-use any of the work
>>>>>>     done in the JOSE working group and in particular all the
>>>>>>     libraries that are available today. He mentioned that earlier
>>>>>>     attempts to write the MAC Token code lead to problems for
>>>>>>     implementers.
>>>>>>     >>
>>>>>>     >> Justin responded that he does not agree with using JSON as
>>>>>>     a transport mechanism since this would replicate a SOAP style.
>>>>>>     >>
>>>>>>     >> Phil noted that he wants to send JSON but the signature
>>>>>>     shall be computed over the HTTP header field.
>>>>>>     >>
>>>>>>     >> -- Flexibility for the keyed message digest computation
>>>>>>     >>
>>>>>>     >> From earlier discussion it was clear that the conference
>>>>>>     call participants wanted more flexibility regarding the keyed
>>>>>>     message digest computation. For this purpose Hannes presented
>>>>>>     the DKIM based approach, which allows selective header fields
>>>>>>     to be included in the digest. This is shown in slide #4.
>>>>>>     >>
>>>>>>     >> After some discussion the conference call participants
>>>>>>     thought that this would meet their needs. Further
>>>>>>     investigations would still be useful to determine the degree
>>>>>>     of failed HMAC calculations due to HTTP proxies modifying the
>>>>>>     content.
>>>>>>     >>
>>>>>>     >> -- Key Distribution
>>>>>>     >>
>>>>>>     >> Hannes presented the open issue regarding the choice of key
>>>>>>     >> distribution. Slides #6-#8 present three techniques and
>>>>>>     Hannes asked
>>>>>>     >> for feedback regarding the preferred style. Justin and
>>>>>>     others didn't
>>>>>>     >> see the need to decide on one mechanism - they wanted to
>>>>>>     keep the
>>>>>>     >> choice open. Derek indicated that this will not be an
>>>>>>     acceptable
>>>>>>     >> approach. Since the resource server and the authorization
>>>>>>     server may,
>>>>>>     >> in the OAuth 2.0 framework, be entities produced by
>>>>>>     different vendors
>>>>>>     >> there is an interoperability need. Justin responded that he
>>>>>>     disagrees
>>>>>>     >> and that the resource server needs to understand the access
>>>>>>     token and
>>>>>>     >> referred to the recent draft submission for the token
>>>>>>     introspection
>>>>>>     >> endpoint. Derek indicated that the resource server has to
>>>>>>     understand
>>>>>>     >> the content of the access token and the token introspection
>>>>>>     endpoint
>>>>>>     >> just pushes the problem around: the resource server has to
>>>>>>     send the
>>>>>>     >> access token to the authorization server and then the
>>>>>>     resource server
>>>>>>     >> gets the result back (which he the
>>>>>>     n
>>>>>>     > a
>>>>>>     >> gain needs to understand) in order to make a meaningful
>>>>>>     authorization decision.
>>>>>>     >>
>>>>>>     >> Everyone agreed that the client must receive the session
>>>>>>     key from the authorization server and that this approach has
>>>>>>     to be standardized. It was also agreed that this is a common
>>>>>>     approach among all three key distribution mechanisms.
>>>>>>     >>
>>>>>>     >> Hannes asked the participants to think about their preference.
>>>>>>     >>
>>>>>>     >> The questions regarding key naming and the indication for
>>>>>>     the intended resource server the client wants to talk to have
>>>>>>     been postponed.
>>>>>>     >>
>>>>>>     >> 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
>>>>>>
>>>>>>
>>>>>>     _______________________________________________
>>>>>>     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
>>
>>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From stephen.farrell@cs.tcd.ie  Sun Feb 17 11:25:12 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB8821F84EB for ; Sun, 17 Feb 2013 11:25:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6s5D77WxVvd for ; Sun, 17 Feb 2013 11:25:12 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D7DA421F8B2E for ; Sun, 17 Feb 2013 11:25:02 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 47028BE49; Sun, 17 Feb 2013 19:24:41 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYAwTEfuoDey; Sun, 17 Feb 2013 19:24:41 +0000 (GMT)
Received: from [10.87.48.11] (unknown [86.44.73.97]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 11521BE3E; Sun, 17 Feb 2013 19:24:41 +0000 (GMT)
Message-ID: <51212E78.1050206@cs.tcd.ie>
Date: Sun, 17 Feb 2013 19:24:40 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: "oauth@ietf.org" 
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Barry Leiba , "oauth-chairs@tools.ietf.org" 
Subject: [OAUTH-WG] oauth assertions plan
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Feb 2013 19:25:12 -0000

Hi all,

The OAuth assertion document has received DISCUSSes as you can
see from the data tracker at [1].  I've been chatting with
the chairs and the ADs with those DISCUSSes in the last few
days.

The main concern is that these documents do not sufficiently
specify the functionality that is needed (MTI) in order
to develop an interoperable implementation. This concern is,
unfortunately, also applicable to the two assertion instance
documents, the JWT (draft-ietf-oauth-jwt-bearer) and the SAML
(draft-ietf-oauth-saml2-bearer) documents.

I've therefore decided to send the assertion document back to
the working group and to recommend to the group to resubmit
them for publication once these blocking DISCUSSes have been
addressed satisfactory. I think this will need some consideration
of both the assertions framework and the saml/jwt drafts. (Probably
submitting two or three of those at once makes better sense
anyway.)

To help resolve this we're planning to meet at lunch time on
the Monday of the IETF just before the oauth session. The goal
of that chat is to try to figure out what'll need doing to get
these documents ready, so that that plan can be presented as
a semi-worked out proposal at the oauth session later that day.
I'd like to have the document editors/authors, chairs and
discussing ADs there if possible. (I'll send details.) If
someone else really needs to be there, let me know but I think
starting with the smaller group will be more tractable. If
everyone thinks we need to just work it out at the WG session
that's fine and we can skip the lunchtime meeting, but I'd say
we're likely to end up in the same place but take longer.

However, if this can be sorted on the list beforehand that's
much better of course, so please do try to do that starting
now. (That is, let's not start by quibbling about process
and lunchtime meetings but by discussing the DISCUSSes:-)

Regards,
Stephen.

[1] http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ballot/.

From Michael.Jones@microsoft.com  Sun Feb 17 12:41:35 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 178ED21E8041 for ; Sun, 17 Feb 2013 12:41:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.586
X-Spam-Level: 
X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32xQWrJSe9vw for ; Sun, 17 Feb 2013 12:41:34 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8E421F8A79 for ; Sun, 17 Feb 2013 12:41:34 -0800 (PST)
Received: from BL2FFO11FD007.protection.gbl (10.173.161.202) by BL2FFO11HUB019.protection.gbl (10.173.160.111) with Microsoft SMTP Server (TLS) id 15.0.620.12; Sun, 17 Feb 2013 20:41:31 +0000
Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD007.mail.protection.outlook.com (10.173.161.3) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Sun, 17 Feb 2013 20:41:31 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.96]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Sun, 17 Feb 2013 20:41:29 +0000
From: Mike Jones 
To: Stephen Farrell , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] oauth assertions plan
Thread-Index: AQHODUSFJYuGTyHp/UK+QNplisn2A5h+fdTA
Date: Sun, 17 Feb 2013 20:41:29 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436746DC1C@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <51212E78.1050206@cs.tcd.ie>
In-Reply-To: <51212E78.1050206@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.35]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(13464002)(199002)(189002)(53754002)(65816001)(74662001)(74502001)(561944001)(76482001)(47446002)(23726001)(15202345001)(44976002)(46406002)(31966008)(16406001)(79102001)(5343655001)(66066001)(33656001)(46102001)(63696002)(80022001)(56776001)(56816002)(20776003)(47776003)(59766001)(54356001)(55846006)(77982001)(53806001)(47976001)(4396001)(47736001)(54316002)(51856001)(50466001)(50986001)(49866001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB019; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07607ED19A
Cc: "oauth-chairs@tools.ietf.org" , Barry Leiba 
Subject: Re: [OAUTH-WG] oauth assertions plan
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Feb 2013 20:41:35 -0000

I've been thinking about Barry's DISCUSS for a bit.  No one else has respon=
ded yet, so I guess I'll jump in and share my perspective.

As I see it, the OAuth Assertions spec, the SAML Assertion Profile, and the=
 JWT Assertion Profile are tools used for building applications - not appli=
cations themselves.  As such, there will and should be fields whose precise=
 syntax and interpretation is left up to the applications building built wi=
th them.  Applications can and should be interoperable.  Tools require prof=
iling to achieve interoperability.  This isn't a bug.  It's a feature, as i=
t means that the tool can be used in many different applications.

Let's consider the Audience field as an illustrative example.  For some app=
lications, the Audience field will be the Client ID of an OAuth Client.  Fo=
r some applications, the Audience field will be the URI of an endpoint that=
 the flow is redirected to.  For some applications, the Audience field will=
 be an abstract identifier associated with a group of participating parties=
, for instance, it might be a URN such as urn:incommon:federation-members. =
 All of these are valid uses of the Audience field.  If any of them were ma=
de mandatory values, it would break all the other applications, because tho=
se values aren't applicable or useful in the other applications.

I'll close with an analogy.  The UDP protocol is a tool.  The TCP protocol =
is a tool.  They were standardized as RFCs 768 and 793 without MTI port val=
ues or applications.  They could have required that TFTP and Telnet also be=
 implemented to ensure interoperable implementations of UDP and TCP, but th=
ey did not.  Just like the situation with the OAuth Assertions specs, this =
wasn't a bug - it was a feature.

I'd therefore request that you withdraw the DISCUSS on that basis, Barry.

I'd be glad to talk with you more about this either via e-mail or by phone.=
  I'm looking forward to a useful and productive discussion.

				Cheers,
				-- Mike

P.S.  RFC 768 is amazingly short!  Have a look at it again, if you haven't =
read it in a while.  Good things really can come in small packages!

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of S=
tephen Farrell
Sent: Sunday, February 17, 2013 11:25 AM
To: oauth@ietf.org
Cc: Barry Leiba; oauth-chairs@tools.ietf.org
Subject: [OAUTH-WG] oauth assertions plan

Hi all,

The OAuth assertion document has received DISCUSSes as you can see from the=
 data tracker at [1].  I've been chatting with the chairs and the ADs with =
those DISCUSSes in the last few days.

The main concern is that these documents do not sufficiently specify the fu=
nctionality that is needed (MTI) in order to develop an interoperable imple=
mentation. This concern is, unfortunately, also applicable to the two asser=
tion instance documents, the JWT (draft-ietf-oauth-jwt-bearer) and the SAML
(draft-ietf-oauth-saml2-bearer) documents.

I've therefore decided to send the assertion document back to the working g=
roup and to recommend to the group to resubmit them for publication once th=
ese blocking DISCUSSes have been addressed satisfactory. I think this will =
need some consideration of both the assertions framework and the saml/jwt d=
rafts. (Probably submitting two or three of those at once makes better sens=
e
anyway.)

To help resolve this we're planning to meet at lunch time on the Monday of =
the IETF just before the oauth session. The goal of that chat is to try to =
figure out what'll need doing to get these documents ready, so that that pl=
an can be presented as a semi-worked out proposal at the oauth session late=
r that day.
I'd like to have the document editors/authors, chairs and discussing ADs th=
ere if possible. (I'll send details.) If someone else really needs to be th=
ere, let me know but I think starting with the smaller group will be more t=
ractable. If everyone thinks we need to just work it out at the WG session =
that's fine and we can skip the lunchtime meeting, but I'd say we're likely=
 to end up in the same place but take longer.

However, if this can be sorted on the list beforehand that's much better of=
 course, so please do try to do that starting now. (That is, let's not star=
t by quibbling about process and lunchtime meetings but by discussing the D=
ISCUSSes:-)

Regards,
Stephen.

[1] http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ballot/.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

From stephen.farrell@cs.tcd.ie  Sun Feb 17 13:26:06 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7F221F8B2E for ; Sun, 17 Feb 2013 13:26:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIiwkK3vfT1b for ; Sun, 17 Feb 2013 13:26:05 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB4C21F896B for ; Sun, 17 Feb 2013 13:25:59 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E155CBE47; Sun, 17 Feb 2013 21:25:36 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhFFejNqykyg; Sun, 17 Feb 2013 21:25:34 +0000 (GMT)
Received: from [10.87.48.11] (unknown [86.44.73.97]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0033ABE3E; Sun, 17 Feb 2013 21:25:33 +0000 (GMT)
Message-ID: <51214AC5.3090807@cs.tcd.ie>
Date: Sun, 17 Feb 2013 21:25:25 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Mike Jones 
References: <51212E78.1050206@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DC1C@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436746DC1C@TK5EX14MBXC284.redmond.corp.microsoft.com>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "oauth-chairs@tools.ietf.org" , Barry Leiba , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] oauth assertions plan
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Feb 2013 21:26:06 -0000

Hi Mike,

On 02/17/2013 08:41 PM, Mike Jones wrote:
> I've been thinking about Barry's DISCUSS for a bit.  No one else has responded yet, so I guess I'll jump in and share my perspective.
> 
> As I see it, the OAuth Assertions spec, the SAML Assertion Profile, and the JWT Assertion Profile are tools used for building applications - not applications themselves.  As such, there will and should be fields whose precise syntax and interpretation is left up to the applications building built with them.  Applications can and should be interoperable.  Tools require profiling to achieve interoperability.  This isn't a bug.  It's a feature, as it means that the tool can be used in many different applications.

Declaring something a feature or bug may be in the eye of the
beholder. But the discuss is about interop and you don't address
that.

Please bear in mind that being able to interop (the goal here)
does not mean that field foo MUST have value type bar but that
implementations MUST have the code for handing value type bar.
I see no argument in your mail addressing that.

These specs might also be useful tools in a toolbox but that
is beside the point of this DISCUSSion.

> Let's consider the Audience field as an illustrative example.  For some applications, the Audience field will be the Client ID of an OAuth Client.  For some applications, the Audience field will be the URI of an endpoint that the flow is redirected to.  For some applications, the Audience field will be an abstract identifier associated with a group of participating parties, for instance, it might be a URN such as urn:incommon:federation-members.  All of these are valid uses of the Audience field.  If any of them were made mandatory values, it would break all the other applications, because those values aren't applicable or useful in the other applications.
> 
> I'll close with an analogy.  The UDP protocol is a tool.  The TCP protocol is a tool.  They were standardized as RFCs 768 and 793 without MTI port values or applications.  They could have required that TFTP and Telnet also be implemented to ensure interoperable implementations of UDP and TCP, but they did not.  Just like the situation with the OAuth Assertions specs, this wasn't a bug - it was a feature.

One cannot draw any conclusion from analogies and I don't
think they help this discussion.

> I'd therefore request that you withdraw the DISCUSS on that basis, Barry.

I'd be surprised, but Barry's able to speak for himself. I think
the WG need to address the topic of the discuss and not try to
say that interop isn't important. In this venue, it is.

> I'd be glad to talk with you more about this either via e-mail or by phone.  I'm looking forward to a useful and productive discussion.

Email discussion on this list is where this should mostly happen
I think now that the draft is back with the WG.

Cheers,
S.

> 				Cheers,
> 				-- Mike
> 
> P.S.  RFC 768 is amazingly short!  Have a look at it again, if you haven't read it in a while.  Good things really can come in small packages!
> 
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Stephen Farrell
> Sent: Sunday, February 17, 2013 11:25 AM
> To: oauth@ietf.org
> Cc: Barry Leiba; oauth-chairs@tools.ietf.org
> Subject: [OAUTH-WG] oauth assertions plan
> 
> 
> Hi all,
> 
> The OAuth assertion document has received DISCUSSes as you can see from the data tracker at [1].  I've been chatting with the chairs and the ADs with those DISCUSSes in the last few days.
> 
> The main concern is that these documents do not sufficiently specify the functionality that is needed (MTI) in order to develop an interoperable implementation. This concern is, unfortunately, also applicable to the two assertion instance documents, the JWT (draft-ietf-oauth-jwt-bearer) and the SAML
> (draft-ietf-oauth-saml2-bearer) documents.
> 
> I've therefore decided to send the assertion document back to the working group and to recommend to the group to resubmit them for publication once these blocking DISCUSSes have been addressed satisfactory. I think this will need some consideration of both the assertions framework and the saml/jwt drafts. (Probably submitting two or three of those at once makes better sense
> anyway.)
> 
> To help resolve this we're planning to meet at lunch time on the Monday of the IETF just before the oauth session. The goal of that chat is to try to figure out what'll need doing to get these documents ready, so that that plan can be presented as a semi-worked out proposal at the oauth session later that day.
> I'd like to have the document editors/authors, chairs and discussing ADs there if possible. (I'll send details.) If someone else really needs to be there, let me know but I think starting with the smaller group will be more tractable. If everyone thinks we need to just work it out at the WG session that's fine and we can skip the lunchtime meeting, but I'd say we're likely to end up in the same place but take longer.
> 
> However, if this can be sorted on the list beforehand that's much better of course, so please do try to do that starting now. (That is, let's not start by quibbling about process and lunchtime meetings but by discussing the DISCUSSes:-)
> 
> Regards,
> Stephen.
> 
> [1] http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ballot/.
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
> 

From Michael.Jones@microsoft.com  Sun Feb 17 13:56:53 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F23421F8B35 for ; Sun, 17 Feb 2013 13:56:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.586
X-Spam-Level: 
X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csduYuStAUq7 for ; Sun, 17 Feb 2013 13:56:52 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.28]) by ietfa.amsl.com (Postfix) with ESMTP id D076721F8B34 for ; Sun, 17 Feb 2013 13:56:51 -0800 (PST)
Received: from BL2FFO11FD015.protection.gbl (10.173.161.202) by BL2FFO11HUB021.protection.gbl (10.173.161.45) with Microsoft SMTP Server (TLS) id 15.0.620.12; Sun, 17 Feb 2013 21:56:44 +0000
Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD015.mail.protection.outlook.com (10.173.160.223) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Sun, 17 Feb 2013 21:56:43 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.96]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Sun, 17 Feb 2013 21:56:28 +0000
From: Mike Jones 
To: Stephen Farrell 
Thread-Topic: [OAUTH-WG] oauth assertions plan
Thread-Index: AQHODUSFJYuGTyHp/UK+QNplisn2A5h+fdTAgAASPICAAAGIAA==
Date: Sun, 17 Feb 2013 21:56:28 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436746DE40@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <51212E78.1050206@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DC1C@TK5EX14MBXC284.redmond.corp.microsoft.com> <51214AC5.3090807@cs.tcd.ie>
In-Reply-To: <51214AC5.3090807@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.35]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(53754002)(13464002)(51704002)(189002)(199002)(377454001)(24454001)(479174001)(561944001)(15202345001)(53806001)(33656001)(47446002)(54356001)(5343655001)(65816001)(74502001)(79102001)(16406001)(80022001)(66066001)(46406002)(59766001)(55846006)(77982001)(31966008)(23726001)(46102001)(54316002)(47776003)(56776001)(50466001)(63696002)(76482001)(49866001)(51856001)(44976002)(74662001)(20776003)(56816002)(47736001)(50986001)(4396001)(47976001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB021; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07607ED19A
Cc: "oauth-chairs@tools.ietf.org" , Barry Leiba , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] oauth assertions plan
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Feb 2013 21:56:53 -0000

Hi Stephen,

I disagree with you that I didn't discuss address interop in my note below.=
  I stated that applications built with these specifications can and should=
 be interoperable, but that profiling is (and should be) required to achiev=
e completely interoperable implementations of these specifications.

The contents of an assertion used for different applications will, of neces=
sity, have some differences between them, because they're specific to the n=
eeds of the application.  If we mandate an MTI profile that meets the needs=
 of one application of assertions, we will have rendered the specifications=
 less useful (or unusable) to other applications.  Otherwise (while you may=
 not find analogies useful), it's like declaring that TFTP be an MTI applic=
ation for all UDP implementations, in order to achieve interoperability.

I think it would be useful if we focused the discussion on the merits and d=
ownsides of specific possible changes to increase interop.  For instance, t=
he Audience field (by design) can contain different kinds of things when us=
ed by different applications.

Barry, are you proposing that we require that the Audience contain a specif=
ic data format tailored to a particular application of assertions?  If so, =
what format are you proposing, and for which application of assertions?  Li=
kewise, are you proposing that the Subject field contain a particular data =
format tailored to a particular application?  And also the Issuer field?

To be clear, the Subject, Issuer, and Audience fields are those that requir=
e profiling to achieve full interop.  Is there a concrete proposal that the=
 specs limit the values of those fields in a particular way?  (That would a=
chieve interop without profiling, but would severely limit the applicabilit=
y of the specs.)

Is there some third way that I'm missing?

				-- Mike
=20
-----Original Message-----
From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]=20
Sent: Sunday, February 17, 2013 1:25 PM
To: Mike Jones
Cc: oauth@ietf.org; Barry Leiba; oauth-chairs@tools.ietf.org
Subject: Re: [OAUTH-WG] oauth assertions plan

Hi Mike,

On 02/17/2013 08:41 PM, Mike Jones wrote:
> I've been thinking about Barry's DISCUSS for a bit.  No one else has resp=
onded yet, so I guess I'll jump in and share my perspective.
>=20
> As I see it, the OAuth Assertions spec, the SAML Assertion Profile, and t=
he JWT Assertion Profile are tools used for building applications - not app=
lications themselves.  As such, there will and should be fields whose preci=
se syntax and interpretation is left up to the applications building built =
with them.  Applications can and should be interoperable.  Tools require pr=
ofiling to achieve interoperability.  This isn't a bug.  It's a feature, as=
 it means that the tool can be used in many different applications.

Declaring something a feature or bug may be in the eye of the beholder. But=
 the discuss is about interop and you don't address that.

Please bear in mind that being able to interop (the goal here) does not mea=
n that field foo MUST have value type bar but that implementations MUST hav=
e the code for handing value type bar.
I see no argument in your mail addressing that.

These specs might also be useful tools in a toolbox but that is beside the =
point of this DISCUSSion.

> Let's consider the Audience field as an illustrative example.  For some a=
pplications, the Audience field will be the Client ID of an OAuth Client.  =
For some applications, the Audience field will be the URI of an endpoint th=
at the flow is redirected to.  For some applications, the Audience field wi=
ll be an abstract identifier associated with a group of participating parti=
es, for instance, it might be a URN such as urn:incommon:federation-members=
.  All of these are valid uses of the Audience field.  If any of them were =
made mandatory values, it would break all the other applications, because t=
hose values aren't applicable or useful in the other applications.
>=20
> I'll close with an analogy.  The UDP protocol is a tool.  The TCP protoco=
l is a tool.  They were standardized as RFCs 768 and 793 without MTI port v=
alues or applications.  They could have required that TFTP and Telnet also =
be implemented to ensure interoperable implementations of UDP and TCP, but =
they did not.  Just like the situation with the OAuth Assertions specs, thi=
s wasn't a bug - it was a feature.

One cannot draw any conclusion from analogies and I don't think they help t=
his discussion.

> I'd therefore request that you withdraw the DISCUSS on that basis, Barry.

I'd be surprised, but Barry's able to speak for himself. I think the WG nee=
d to address the topic of the discuss and not try to say that interop isn't=
 important. In this venue, it is.

> I'd be glad to talk with you more about this either via e-mail or by phon=
e.  I'm looking forward to a useful and productive discussion.

Email discussion on this list is where this should mostly happen I think no=
w that the draft is back with the WG.

Cheers,
S.

> 				Cheers,
> 				-- Mike
>=20
> P.S.  RFC 768 is amazingly short!  Have a look at it again, if you haven'=
t read it in a while.  Good things really can come in small packages!
>=20
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20
> Of Stephen Farrell
> Sent: Sunday, February 17, 2013 11:25 AM
> To: oauth@ietf.org
> Cc: Barry Leiba; oauth-chairs@tools.ietf.org
> Subject: [OAUTH-WG] oauth assertions plan
>=20
>=20
> Hi all,
>=20
> The OAuth assertion document has received DISCUSSes as you can see from t=
he data tracker at [1].  I've been chatting with the chairs and the ADs wit=
h those DISCUSSes in the last few days.
>=20
> The main concern is that these documents do not sufficiently specify=20
> the functionality that is needed (MTI) in order to develop an=20
> interoperable implementation. This concern is, unfortunately, also=20
> applicable to the two assertion instance documents, the JWT=20
> (draft-ietf-oauth-jwt-bearer) and the SAML
> (draft-ietf-oauth-saml2-bearer) documents.
>=20
> I've therefore decided to send the assertion document back to the=20
> working group and to recommend to the group to resubmit them for=20
> publication once these blocking DISCUSSes have been addressed=20
> satisfactory. I think this will need some consideration of both the=20
> assertions framework and the saml/jwt drafts. (Probably submitting two=20
> or three of those at once makes better sense
> anyway.)
>=20
> To help resolve this we're planning to meet at lunch time on the Monday o=
f the IETF just before the oauth session. The goal of that chat is to try t=
o figure out what'll need doing to get these documents ready, so that that =
plan can be presented as a semi-worked out proposal at the oauth session la=
ter that day.
> I'd like to have the document editors/authors, chairs and discussing ADs =
there if possible. (I'll send details.) If someone else really needs to be =
there, let me know but I think starting with the smaller group will be more=
 tractable. If everyone thinks we need to just work it out at the WG sessio=
n that's fine and we can skip the lunchtime meeting, but I'd say we're like=
ly to end up in the same place but take longer.
>=20
> However, if this can be sorted on the list beforehand that's much=20
> better of course, so please do try to do that starting now. (That is,=20
> let's not start by quibbling about process and lunchtime meetings but=20
> by discussing the DISCUSSes:-)
>=20
> Regards,
> Stephen.
>=20
> [1] http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ballot/.
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20

From stephen.farrell@cs.tcd.ie  Sun Feb 17 16:23:37 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240FE21F8AF4 for ; Sun, 17 Feb 2013 16:23:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMwYZymIkR9s for ; Sun, 17 Feb 2013 16:23:35 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1979E21F8B2B for ; Sun, 17 Feb 2013 16:23:35 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5C519BE47; Mon, 18 Feb 2013 00:23:13 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeU9fuV26L37; Mon, 18 Feb 2013 00:23:11 +0000 (GMT)
Received: from [10.87.48.11] (unknown [86.44.73.97]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7AA4BBE38; Mon, 18 Feb 2013 00:23:11 +0000 (GMT)
Message-ID: <5121746F.6050503@cs.tcd.ie>
Date: Mon, 18 Feb 2013 00:23:11 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Mike Jones 
References: <51212E78.1050206@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DC1C@TK5EX14MBXC284.redmond.corp.microsoft.com> <51214AC5.3090807@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DE40@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436746DE40@TK5EX14MBXC284.redmond.corp.microsoft.com>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "oauth-chairs@tools.ietf.org" , Barry Leiba , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] oauth assertions plan
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Feb 2013 00:23:37 -0000

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

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

To which I responded:

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

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

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

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

Cheers,
S.

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

From ve7jtb@ve7jtb.com  Sun Feb 17 17:20:48 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C6621F8A66 for ; Sun, 17 Feb 2013 17:20:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.398
X-Spam-Level: 
X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[AWL=0.201,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ab7iTBMnDsA for ; Sun, 17 Feb 2013 17:20:47 -0800 (PST)
Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) by ietfa.amsl.com (Postfix) with ESMTP id D457821F8A4A for ; Sun, 17 Feb 2013 17:20:43 -0800 (PST)
Received: by mail-qc0-f174.google.com with SMTP id z24so1873172qcq.19 for ; Sun, 17 Feb 2013 17:20:43 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=IQAu6DXU6xRTe1Zhgo4u5YfhbBdtI3gxOIHTAOs2bgk=; b=IIit8VZsv1YqSa2D86mNVnvaqafqFKZqHRhQPRIghWpk8tenXcGPZOsvrKu5Xq0d4q cnYSLUZ3jdInnAW90fGfInEBXyDTvRSuN4mSCba0/HgYbI1nzLWDEV246P5WAaixkJxP Swi5fkP/o2CCiOYVa22yz/vPETYHiayHw2pFqsnjvnxdf+1crskwQXjHZEr+SaAld2VD Lm4AE1lofR0WvFvPnl53iaXqlHaNNOOQ0yV67QZ2FizK87MTA6HESAFEnLq/myLpvHqx 9gpQYdUQ3jMayohYBKxBIgrWGRvXrw9qlBftHpj6Z5TU5YczwSLonapyb7bjDPH21gsl 8Chw==
X-Received: by 10.229.204.167 with SMTP id fm39mr848854qcb.97.1361150442925; Sun, 17 Feb 2013 17:20:42 -0800 (PST)
Received: from [192.168.1.213] (190-20-56-120.baf.movistar.cl. [190.20.56.120]) by mx.google.com with ESMTPS id 8sm23665905qed.6.2013.02.17.17.20.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Feb 2013 17:20:41 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_F15234AF-249A-45E5-9829-B5BCFA04BD4E"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436746DE40@TK5EX14MBXC284.redmond.corp.microsoft.com>
Date: Sun, 17 Feb 2013 22:19:43 -0300
Message-Id: <4796A10C-1DAD-4173-B2E3-F514F3A06FAC@ve7jtb.com>
References: <51212E78.1050206@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DC1C@TK5EX14MBXC284.redmond.corp.microsoft.com> <51214AC5.3090807@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DE40@TK5EX14MBXC284.redmond.corp.microsoft.com>
To: Mike Jones 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQnf1IPECQs74DflnkHggU60lZol9Gw5aZoH/MIxBklw/MQ5v2vlwWgWTKzoeN1k/zTfpAA0
Cc: "oauth-chairs@tools.ietf.org" , Barry Leiba , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] oauth assertions plan
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Feb 2013 01:20:48 -0000

--Apple-Mail=_F15234AF-249A-45E5-9829-B5BCFA04BD4E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I largely agree with Mike, that assertions are going to be used in a =
number of places that have different naming conventions.

Is what Barry looking for a specific profile for how it would be used =
with the token endpoint to authenticate a OAuth confidential client to a =
token endpoint in the OAuth Code flow?

I can see having specifics for particular protocols using assertions for =
them to accede interop.  The debate on that is if that should be in the =
assertions spec , the JWT assertions spec, the SAML assertions spec or =
some other document.

Unless we get down to some specifics I feed we will talk this in =
circles.

In Connect we did profile it for the code flow use-case.   To do that =
interoperable algorithms and some other things needed to be specified.  =20=

It may be useful to look at several ways people intend to use these =
profiles to add perspective to the discussion.

John B.

On 2013-02-17, at 6:56 PM, Mike Jones  =
wrote:

> Hi Stephen,
>=20
> I disagree with you that I didn't discuss address interop in my note =
below.  I stated that applications built with these specifications can =
and should be interoperable, but that profiling is (and should be) =
required to achieve completely interoperable implementations of these =
specifications.
>=20
> The contents of an assertion used for different applications will, of =
necessity, have some differences between them, because they're specific =
to the needs of the application.  If we mandate an MTI profile that =
meets the needs of one application of assertions, we will have rendered =
the specifications less useful (or unusable) to other applications.  =
Otherwise (while you may not find analogies useful), it's like declaring =
that TFTP be an MTI application for all UDP implementations, in order to =
achieve interoperability.
>=20
> I think it would be useful if we focused the discussion on the merits =
and downsides of specific possible changes to increase interop.  For =
instance, the Audience field (by design) can contain different kinds of =
things when used by different applications.
>=20
> Barry, are you proposing that we require that the Audience contain a =
specific data format tailored to a particular application of assertions? =
 If so, what format are you proposing, and for which application of =
assertions?  Likewise, are you proposing that the Subject field contain =
a particular data format tailored to a particular application?  And also =
the Issuer field?
>=20
> To be clear, the Subject, Issuer, and Audience fields are those that =
require profiling to achieve full interop.  Is there a concrete proposal =
that the specs limit the values of those fields in a particular way?  =
(That would achieve interop without profiling, but would severely limit =
the applicability of the specs.)
>=20
> Is there some third way that I'm missing?
>=20
> 				-- Mike
>=20
> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]=20
> Sent: Sunday, February 17, 2013 1:25 PM
> To: Mike Jones
> Cc: oauth@ietf.org; Barry Leiba; oauth-chairs@tools.ietf.org
> Subject: Re: [OAUTH-WG] oauth assertions plan
>=20
>=20
> Hi Mike,
>=20
> On 02/17/2013 08:41 PM, Mike Jones wrote:
>> I've been thinking about Barry's DISCUSS for a bit.  No one else has =
responded yet, so I guess I'll jump in and share my perspective.
>>=20
>> As I see it, the OAuth Assertions spec, the SAML Assertion Profile, =
and the JWT Assertion Profile are tools used for building applications - =
not applications themselves.  As such, there will and should be fields =
whose precise syntax and interpretation is left up to the applications =
building built with them.  Applications can and should be interoperable. =
 Tools require profiling to achieve interoperability.  This isn't a bug. =
 It's a feature, as it means that the tool can be used in many different =
applications.
>=20
> Declaring something a feature or bug may be in the eye of the =
beholder. But the discuss is about interop and you don't address that.
>=20
> Please bear in mind that being able to interop (the goal here) does =
not mean that field foo MUST have value type bar but that =
implementations MUST have the code for handing value type bar.
> I see no argument in your mail addressing that.
>=20
> These specs might also be useful tools in a toolbox but that is beside =
the point of this DISCUSSion.
>=20
>> Let's consider the Audience field as an illustrative example.  For =
some applications, the Audience field will be the Client ID of an OAuth =
Client.  For some applications, the Audience field will be the URI of an =
endpoint that the flow is redirected to.  For some applications, the =
Audience field will be an abstract identifier associated with a group of =
participating parties, for instance, it might be a URN such as =
urn:incommon:federation-members.  All of these are valid uses of the =
Audience field.  If any of them were made mandatory values, it would =
break all the other applications, because those values aren't applicable =
or useful in the other applications.
>>=20
>> I'll close with an analogy.  The UDP protocol is a tool.  The TCP =
protocol is a tool.  They were standardized as RFCs 768 and 793 without =
MTI port values or applications.  They could have required that TFTP and =
Telnet also be implemented to ensure interoperable implementations of =
UDP and TCP, but they did not.  Just like the situation with the OAuth =
Assertions specs, this wasn't a bug - it was a feature.
>=20
> One cannot draw any conclusion from analogies and I don't think they =
help this discussion.
>=20
>> I'd therefore request that you withdraw the DISCUSS on that basis, =
Barry.
>=20
> I'd be surprised, but Barry's able to speak for himself. I think the =
WG need to address the topic of the discuss and not try to say that =
interop isn't important. In this venue, it is.
>=20
>> I'd be glad to talk with you more about this either via e-mail or by =
phone.  I'm looking forward to a useful and productive discussion.
>=20
> Email discussion on this list is where this should mostly happen I =
think now that the draft is back with the WG.
>=20
> Cheers,
> S.
>=20
>=20
>> 				Cheers,
>> 				-- Mike
>>=20
>> P.S.  RFC 768 is amazingly short!  Have a look at it again, if you =
haven't read it in a while.  Good things really can come in small =
packages!
>>=20
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf=20
>> Of Stephen Farrell
>> Sent: Sunday, February 17, 2013 11:25 AM
>> To: oauth@ietf.org
>> Cc: Barry Leiba; oauth-chairs@tools.ietf.org
>> Subject: [OAUTH-WG] oauth assertions plan
>>=20
>>=20
>> Hi all,
>>=20
>> The OAuth assertion document has received DISCUSSes as you can see =
from the data tracker at [1].  I've been chatting with the chairs and =
the ADs with those DISCUSSes in the last few days.
>>=20
>> The main concern is that these documents do not sufficiently specify=20=

>> the functionality that is needed (MTI) in order to develop an=20
>> interoperable implementation. This concern is, unfortunately, also=20
>> applicable to the two assertion instance documents, the JWT=20
>> (draft-ietf-oauth-jwt-bearer) and the SAML
>> (draft-ietf-oauth-saml2-bearer) documents.
>>=20
>> I've therefore decided to send the assertion document back to the=20
>> working group and to recommend to the group to resubmit them for=20
>> publication once these blocking DISCUSSes have been addressed=20
>> satisfactory. I think this will need some consideration of both the=20=

>> assertions framework and the saml/jwt drafts. (Probably submitting =
two=20
>> or three of those at once makes better sense
>> anyway.)
>>=20
>> To help resolve this we're planning to meet at lunch time on the =
Monday of the IETF just before the oauth session. The goal of that chat =
is to try to figure out what'll need doing to get these documents ready, =
so that that plan can be presented as a semi-worked out proposal at the =
oauth session later that day.
>> I'd like to have the document editors/authors, chairs and discussing =
ADs there if possible. (I'll send details.) If someone else really needs =
to be there, let me know but I think starting with the smaller group =
will be more tractable. If everyone thinks we need to just work it out =
at the WG session that's fine and we can skip the lunchtime meeting, but =
I'd say we're likely to end up in the same place but take longer.
>>=20
>> However, if this can be sorted on the list beforehand that's much=20
>> better of course, so please do try to do that starting now. (That is,=20=

>> let's not start by quibbling about process and lunchtime meetings but=20=

>> by discussing the DISCUSSes:-)
>>=20
>> Regards,
>> Stephen.
>>=20
>> [1] =
http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ballot/.
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail=_F15234AF-249A-45E5-9829-B5BCFA04BD4E
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMjE4MDEyMDEwWjAjBgkqhkiG9w0BCQQxFgQUzykEGnxs
cxLdJHf06Lo79L5VxZwwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAmrSNye+4vk25fxGGGz3s6xbyCKwwbDIoa7JlLVuC
hlFJLMXtG61X/9FSmc+SvFVEItVsHMnJK91qKtdFfbLv8DI6n05SpmesikZvX3iI+7O63jtQNWWC
jaW3qkdiwCN31U9rmSpJOREgg3Ft5H4SzsGyR4ZCKYhYCzpGRMziXxogmekULkjflPDY2Lp9Crxv
WQybwb8LTsqXr78HXnYaRDB9AvJC+7QSsSLm9jTLRCIn3JqNNQE7T6gfl4SFphQUDXZvyQNe8G43
t344KGP+QG6QTihmvlDplA4Jat0PXAd4PW/gGAWEZfo0zhAb9/jxImfHLGs2Fw5AhWlty3mokQAA
AAAAAA==

--Apple-Mail=_F15234AF-249A-45E5-9829-B5BCFA04BD4E--

From barryleiba@gmail.com  Sun Feb 17 21:38:28 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCE621F88AE for ; Sun, 17 Feb 2013 21:38:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.637
X-Spam-Level: 
X-Spam-Status: No, score=-102.637 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qj2ODf3885Hm for ; Sun, 17 Feb 2013 21:38:28 -0800 (PST)
Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by ietfa.amsl.com (Postfix) with ESMTP id 33EFC21F89A6 for ; Sun, 17 Feb 2013 21:38:27 -0800 (PST)
Received: by mail-lb0-f179.google.com with SMTP id j14so4025830lbo.38 for ; Sun, 17 Feb 2013 21:38:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ei83U4Kk0IT+TJZUh4Kbh27DMRBciNvVbWFaj+DxGwA=; b=zXTbrcoJbS2hBiVNa+hKsDGDtsUa8wZaQ7rc60SxreS15BP14fUYHcuxXZH3fVreR+ jHBOJ2rHcQY2xqc7vkxO+6+k8Hv8UEUOqH6oMJLylculOqkegM2QUbB0IlJ18Hdu1xIS ZrH7ZjuuSUjghzmN2HKApqiKm/Gk5rnC/EaNPR3y55aAu21YJu0thuAOL6e7qCrQAEuV 8AAKfY+Q9Ya3zeZqbKNQpvlPBNzReZiZ8ECTg8xPeSzpBcjXUGaiarlgxiwNRGVsS8+y qkxSnv54kifsXhyh6dYN38IG3jV9n+6m7EQb7zR/arIlw0bNkkf4B6/Ww5mdoXiSV0z2 mA7g==
MIME-Version: 1.0
X-Received: by 10.152.123.194 with SMTP id mc2mr9530966lab.7.1361165905952; Sun, 17 Feb 2013 21:38:25 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.112.76.98 with HTTP; Sun, 17 Feb 2013 21:38:25 -0800 (PST)
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436746DE40@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <51212E78.1050206@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DC1C@TK5EX14MBXC284.redmond.corp.microsoft.com> <51214AC5.3090807@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DE40@TK5EX14MBXC284.redmond.corp.microsoft.com>
Date: Mon, 18 Feb 2013 00:38:25 -0500
X-Google-Sender-Auth: RdDRwaAnSsoOjuwGjhMwXTZEBE4
Message-ID: 
From: Barry Leiba 
To: Mike Jones 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] oauth assertions plan
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Feb 2013 05:38:28 -0000

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

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

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

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

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

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

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

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

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

For your specific questions:

> Barry, are you proposing that we require that the Audience contain a specific data
> format tailored to a particular application of assertions?  If so, what format are you
> proposing, and for which application of assertions?  Likewise, are you proposing
> that the Subject field contain a particular data format tailored to a particular
> application?  And also the Issuer field?

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

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

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

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

Can you do that here?  Please explain how.

Barry

From stephen.farrell@cs.tcd.ie  Mon Feb 18 01:44:27 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFFA21F87D5 for ; Mon, 18 Feb 2013 01:44:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPWTrfIdpN6m for ; Mon, 18 Feb 2013 01:44:26 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A043E21F87D3 for ; Mon, 18 Feb 2013 01:44:26 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 781E8BE51; Mon, 18 Feb 2013 09:44:03 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKEOiyd3NqSX; Mon, 18 Feb 2013 09:44:03 +0000 (GMT)
Received: from [IPv6:2001:770:10:203:70b4:a884:3fa8:8567] (unknown [IPv6:2001:770:10:203:70b4:a884:3fa8:8567]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4C3EDBE4D; Mon, 18 Feb 2013 09:44:03 +0000 (GMT)
Message-ID: <5121F7E3.4080900@cs.tcd.ie>
Date: Mon, 18 Feb 2013 09:44:03 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Barry Leiba 
References: <51212E78.1050206@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DC1C@TK5EX14MBXC284.redmond.corp.microsoft.com> <51214AC5.3090807@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DE40@TK5EX14MBXC284.redmond.corp.microsoft.com> 
In-Reply-To: 
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] oauth assertions plan
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Feb 2013 09:44:27 -0000

Hi Barry,

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

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

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

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

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

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

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

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

S.

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

From jricher@mitre.org  Mon Feb 18 06:23:15 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2865421F8946 for ; Mon, 18 Feb 2013 06:23:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.573
X-Spam-Level: 
X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldg-Haefn7ux for ; Mon, 18 Feb 2013 06:23:13 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 93B9521F8929 for ; Mon, 18 Feb 2013 06:23:13 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 13F6A5310B3D; Mon, 18 Feb 2013 09:23:13 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id D8C195310B37; Mon, 18 Feb 2013 09:23:12 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 18 Feb 2013 09:23:12 -0500
Message-ID: <5122391E.9030500@mitre.org>
Date: Mon, 18 Feb 2013 09:22:22 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Mike Jones 
References: <51195F36.6040705@mitre.org> <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com> <511BAA8B.8030309@mitre.org>  <-4554688250617930935@unknownmsgid>   <4687F290-4855-49DE-892F-F9694BB211D4@ve7jtb.com> <511CF2C9.9040604@mitre.org>   <4E1F6AAD24975D4BA5B1680429673943674691FB@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943674691FB@TK5EX14MBXC284.redmond.corp.microsoft.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Feb 2013 14:23:15 -0000

Nat's attack vector presumes lack of logging on the server side, where 
doing a "delete" means that you can no longer see anything about who did 
what. You could make the same argument if you have a system where users 
can register themselves and delete their accounts at will -- someone 
creates a fly-by-night account, does bad things, deletes the account. If 
the site doesn't have detailed logs in both of these cases, yes, they'll 
be in the dark about the bad things that happened when the 
account/client was active. It's a valuable security consideration, but I 
don't think that it's enough to say that delete is no longer a valid 
operation.

I think it's up to the server what "delete" means under the hood, but 
the important bit for the protocol is that as far as the client is 
concerned, that client_id is dead now. I don't think it's worthwhile to 
specify it as a "suspend" operation, because to me "suspend" implies an 
ability to "unsuspend", and I really don't think we want to get into the 
complicated zombie OAuth client business. But whether on the server side 
"delete" translates to "delete everything from the database immediately 
and burn all records of it" or instead "set a flag on that client and 
all of its outstanding grants so that it can't be used but 
administrators can still poke it with a stick" is completely up to the 
implementation and its security considerations.

That said, I think it would make sense to at least describe this 
potential problem in the security considerations, and note that the 
client MUST NOT use the client_id again.

  -- Justin

On 02/17/2013 01:11 AM, Mike Jones wrote:
> I agree.  If we have it at all, DELETE should be a declaration by the Client that requests by it should no longer be honored.  It should be up to the Server whether to implement this as suspension or deletion.  At most, I believe it should be an optional operation, which MAY be supported.
>
> 				-- Mike
>
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura
> Sent: Saturday, February 16, 2013 10:04 PM
> To: John Bradley
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
>
>> When sending an update, a client MUST send all metadata fields
>> returned from the server in its initial registration or previous read
>> or update call, including its client_id. A server MAY replace any
>> missing or invalid fields with default values, or it MAY return an
>> error as described in the Error Response section. A server MUST return
>> all provisioned fields in its response. A server MUST NOT change the
>> client_id field. A server MAY change the client_secret and/or
>> refresh_access_token fields.
> Say the client registered some value. Sometime later, the server changed a value due to some policy or security reasons etc. The client when UPDATES with the previously registered value, what is going to happen to the changed value?
>
>>> DELETE to be used correctly is I think going to delete the client_id and all associated tokens and cause a ripple effect in removing grants associated with that client_id.
>> This is how I would interpret it as well. It's de-provisioning the
>> client, not resetting it.
> For DELETE, I can think of an attack such that
>
> 1. Register as a client.
> 2. Send spam links to random users.
> 3. When user "authorizes", suck the user data such as contacts out.
> 4. DELETE the registration and disappear.
>
> To prevent something like this, it should probably be something more akin to "suspend" rather than completely de-provisioning.
> _______________________________________________
> 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

From jricher@mitre.org  Mon Feb 18 06:25:21 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E633C21F8929 for ; Mon, 18 Feb 2013 06:25:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.574
X-Spam-Level: 
X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPCStwRvgg-N for ; Mon, 18 Feb 2013 06:25:20 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 30EE621F87DF for ; Mon, 18 Feb 2013 06:25:20 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9F41E4350241; Mon, 18 Feb 2013 09:25:19 -0500 (EST)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7BCF61F0577; Mon, 18 Feb 2013 09:25:19 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 18 Feb 2013 09:25:19 -0500
Message-ID: <5122399D.5090403@mitre.org>
Date: Mon, 18 Feb 2013 09:24:29 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Donald F Coffin 
References: <20130215215423.23019.50224.idtracker@ietfa.amsl.com> <00b601ce0be9$7d4fa460$77eeed20$@reminetworks.com>
In-Reply-To: <00b601ce0be9$7d4fa460$77eeed20$@reminetworks.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.58]
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Feb 2013 14:25:21 -0000

The text in question refers to responses from the Token Endpoint, 
whereas this spec deals with a separate endpoint, the Client 
Registration Endpoint. Therefore, the text doesn't directly apply.

However, it's not bad advice to replicate that here since we are issuing 
a special-use access token along with the response.

  -- Justin

On 02/15/2013 09:01 PM, Donald F Coffin wrote:
> Justin,
>
> Section 5.1 of RFC6749 "OAuth 2.0 Authorization Framework" states:
>
> 	"The authorization server MUST include the HTTP "Cache-Control"
>    	 response header field [RFC2616] with a value of "no-store" in any
>     	response containing tokens, credentials, or other sensitive
>     	information, as well as the "Pragma" response header field [RFC2616]
>     	with a value of "no-cache"."
>
> I've noticed several of the response examples in the current and previous versions of "draft-ietf-oauth-dyn-reg-xx.txt" fail to include the required "Pragma: "no-cache" directive.  I assume this is an oversight and am merely pointing out that it needs to be included.
>
> Best regards,
> Don
> Donald F. Coffin
> Founder/CTO
>
> REMI Networks
> 22751 El Prado Suite 6216
> Rancho Santa Margarita, CA  92688-3836
>
> Phone:      (949) 636-8571
> Email:       donald.coffin@reminetworks.com
>
>
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: Friday, February 15, 2013 1:54 PM
> To: i-d-announce@ietf.org
> Cc: oauth@ietf.org
> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the Web Authorization Protocol Working Group of the IETF.
>
> 	Title           : OAuth Dynamic Client Registration Protocol
> 	Author(s)       : Justin Richer
>                            John Bradley
>                            Michael B. Jones
>                            Maciej Machulak
> 	Filename        : draft-ietf-oauth-dyn-reg-06.txt
> 	Pages           : 21
> 	Date            : 2013-02-15
>
> Abstract:
>     This specification defines an endpoint and protocol for dynamic
>     registration of OAuth Clients at an Authorization Server.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-06
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From jricher@mitre.org  Mon Feb 18 06:32:50 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5BF21F8763 for ; Mon, 18 Feb 2013 06:32:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.574
X-Spam-Level: 
X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AugikX3+PRz2 for ; Mon, 18 Feb 2013 06:32:46 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 48B0321F86A8 for ; Mon, 18 Feb 2013 06:32:44 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7F3601F0318; Mon, 18 Feb 2013 09:32:44 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 755891F1BD5; Mon, 18 Feb 2013 09:32:44 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 18 Feb 2013 09:32:44 -0500
Message-ID: <51223B5A.5050008@mitre.org>
Date: Mon, 18 Feb 2013 09:31:54 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Torsten Lodderstedt 
References: <20130215215423.23019.50224.idtracker@ietfa.amsl.com>  <5120B6EE.60801@lodderstedt.net>
In-Reply-To: <5120B6EE.60801@lodderstedt.net>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.58]
Cc: "" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Feb 2013 14:32:50 -0000

On 02/17/2013 05:54 AM, Torsten Lodderstedt wrote:
> Hi Justin,
>
> the new revision seems to catch the state of discussion and is 
> consistent. Thank's for bringing this topic forward.
>
> On your editor's not in section 4.2.: In my opinion, the 404 due to a 
> none-existing resource should precede the 403. I would suggest to 
> point out your thoughts on the access token. But as with any HTTP 
> request, there could be other ways to authenticate to this endpoint. I 
> therefore would not connect both aspects to much.
>

 From our own implementation, the code that processes the token would 
fire (and fail) long before the code that checks if the client is valid 
gets reached. So for us, checking if the client exists in the first 
place is difficult.

What if we just say it's a 403 if either the client or the token are 
invalid?

> section 4.3
>
> "This request MUST include all fields described in Client Metadata
>    (Section 2) as returned to the Client from a previous register, read,
>    or update operation."
>
> Just to make sure I got it. Any data element omitted in this request 
> is deleted/reset by the AS?

That's the intent. The AS is free to fill in or reject any fields the 
client omits, if it wants to.

>
> section 5.1
>
> Something seems to be missing at
>
> "The response contains the following fields:
>
>    , as well as a Client Secret if this client is a confidential client."
>

Vestigial formatting from shuffling sections around. Thanks for catching 
that!

  -- Justin

> regards,
> Torsten.
>
> Am 15.02.2013 23:00, schrieb Richer, Justin P.:
>> Everyone, there's a new draft of DynReg up on the tracker. This draft 
>> tries to codify the discussions so far from this week into something 
>> we can all read. There are still plenty of open discussion points and 
>> items up for debate. Please read through this latest draft and see 
>> what's changed and help assure that it properly captures the 
>> conversations. If you have any inputs for the marked [[ Editor's Note 
>> ]] sections, please send them to the list by next Thursday to give me 
>> opportunity to get any necessary changes in by the cutoff date of 
>> Monday the 22nd.
>>
>> Thanks for all of your hard work everyone, I think this is *really* 
>> coming along now.
>>
>>   -- Justin
>>
>> On Feb 15, 2013, at 4:54 PM, internet-drafts@ietf.org wrote:
>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts 
>>> directories.
>>> This draft is a work item of the Web Authorization Protocol Working 
>>> Group of the IETF.
>>>
>>>     Title           : OAuth Dynamic Client Registration Protocol
>>>     Author(s)       : Justin Richer
>>>                           John Bradley
>>>                           Michael B. Jones
>>>                           Maciej Machulak
>>>     Filename        : draft-ietf-oauth-dyn-reg-06.txt
>>>     Pages           : 21
>>>     Date            : 2013-02-15
>>>
>>> Abstract:
>>>    This specification defines an endpoint and protocol for dynamic
>>>    registration of OAuth Clients at an Authorization Server.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
>>>
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06
>>>
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-06
>>>
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> 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
>

From ve7jtb@ve7jtb.com  Mon Feb 18 07:18:34 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1096121F87F9 for ; Mon, 18 Feb 2013 07:18:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.104
X-Spam-Level: 
X-Spam-Status: No, score=-3.104 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfFauBp2f2j8 for ; Mon, 18 Feb 2013 07:18:32 -0800 (PST)
Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7E70A21F87C3 for ; Mon, 18 Feb 2013 07:18:31 -0800 (PST)
Received: by mail-qa0-f45.google.com with SMTP id g10so1322779qah.4 for ; Mon, 18 Feb 2013 07:18:31 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=sWk6e68fITM9/L1VT71HeB3cAoieW0wM3OS170iuQ1I=; b=nc2Rzcd7i+epePfG4ppP1q1X18hxlWxZ/dxQjIb3jXvpuvN1SF+jIBxfYFUcwAgTBe JAO2dVZJesNSRNso4GIKGLc4nvV3D6oz8I6GBPOTrfbWAwx8wKM9DY104RqlJ6npNQyz 8dQpFQ4tJ0eHi8yNb/bVKCYKjit7C7tmDTpUzw/aQIgTX4ckmEfBi0yvPX2/5bQWQT96 5Nohkz/0zUeSuq6+G4xE2i55Nd/S6lSymMNCUhwG+hWKiLc4KtDOiiIyfnIePhSUEyhx 0JXE1SvVVeFdaUKM0ovaZO0wh9R07aZ3VZcTdsS7jihHHef8ye+yP7nIG4GSv0fbCjVJ NgBQ==
X-Received: by 10.224.17.198 with SMTP id t6mr5824661qaa.84.1361200710897; Mon, 18 Feb 2013 07:18:30 -0800 (PST)
Received: from [192.168.1.213] (190-20-56-120.baf.movistar.cl. [190.20.56.120]) by mx.google.com with ESMTPS id ec9sm2521605qab.9.2013.02.18.07.18.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Feb 2013 07:18:28 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_5810A4CF-FD55-4169-944E-2AFECEEFFD23"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: 
Date: Mon, 18 Feb 2013 12:17:37 -0300
Message-Id: <37B4C89F-2864-4317-BF87-F562241C176D@ve7jtb.com>
References: <51212E78.1050206@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DC1C@TK5EX14MBXC284.redmond.corp.microsoft.com> <51214AC5.3090807@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DE40@TK5EX14MBXC284.redmond.corp.microsoft.com> 
To: Barry Leiba 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQk/+jsgBEn8KVV7OOy296yxU4fCXuwzKKflKQIKi+QvGPJIDI1FqIpGSlurNf5kowUojzOr
Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] oauth assertions plan
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Feb 2013 15:18:34 -0000

--Apple-Mail=_5810A4CF-FD55-4169-944E-2AFECEEFFD23
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_8D2010F5-AA6A-48C2-B9D0-1769BADCFDA8"

--Apple-Mail=_8D2010F5-AA6A-48C2-B9D0-1769BADCFDA8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Barry,

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

Perhaps you were speaking metaphorically though.

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

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

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

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

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

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

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

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

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

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

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

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

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

Regards
John B.

On 2013-02-18, at 2:38 AM, Barry Leiba  wrote:

> OK, I have some time to respond to this on a real computer.
>=20
> Let's look at the general mechanism that oauth provides, using one use =
case:
> A client asks an authorization server for authorization to do =
something.
> The authorization server responds with an authorization token, which
> the client is required to understand.
>=20
> We have talked about three kinds of tokens: bearer tokens, MAC tokens,
> and assertion tokens.
> How does a client know what kind of token it will get from a
> particular authorization server?
> How does a server that supports multiple token types know what kind of
> token it should give to a particular client?
>=20
> Now, suppose that the server decides to give back an assertion:
> How does the server know whether to give a SAML assertion or a JWT
> assertion?  How does the client know which it's going to get?
>=20
> And now you're saying that even if everyone knows they're going to get
> an assertion token, and specifically a JWT assertion, the semantics of
> particular fields in those tokens are undefined.  If you have
> different meanings ("different kinds of things", as you've said) for
> the Audience field, how is the server supposed to communicate which
> meaning *it* is using?  How is there any assurance that a client will
> understand it in the same way?
>=20
> These are the sorts of things I'm concerned about, and this is what I
> mean by saying that it's like a Ukrainian doll: you open the oauth
> doll and find the token doll; you open the token doll and find the
> assertions doll; you open the assertions doll and find the JWT doll;
> you open the JWT doll and find the Audience field doll... at what
> point do the dolls end and interoperablity begins?
>=20
> I understand that you want certain things to be handled differently by
> different applications, and I'm fine with that in principle.  But the
> other part of the principle is that I have to be able to write an
> application that interoperates with yours *purely by reading the
> specs*.
>=20
> If you do this by profiling, we need to get to a point where two
> things are true: (1) the profile chain has ended, and what's left is
> well defined, and (2) I have to be able to, *from the specs and the
> protocol alone*, determine what profile will be used.  I don't see how
> this protocol gives me any way to determine what to send or what to
> expect to receive.  And if an out-of-band understanding is required
> for that, that doesn't interoperate.
>=20
> Now, the way we usually handle the need for "different kinds of
> things" is to have different fields for each, or to have one field
> tagged so that it's self-defining (as URIs have a scheme that says
> what to do with them).  If the Audience field might look like this in
> one application:
>   urn:ietf:params:banana
> ...and like this in another
>   abra:cadabra
> ...where the first is understood to be a URI and the second is
> something else, then please explain how you and I can each write
> applications to that?
>=20
> For your specific questions:
>=20
>> Barry, are you proposing that we require that the Audience contain a =
specific data
>> format tailored to a particular application of assertions?  If so, =
what format are you
>> proposing, and for which application of assertions?  Likewise, are =
you proposing
>> that the Subject field contain a particular data format tailored to a =
particular
>> application?  And also the Issuer field?
>=20
> I am proposing that there must be a way for someone writing an
> application to know what to use in these fields that will work with
> your application (or will work with a server in the same way as your
> application does, or whatever) *without* having to go to the
> documentation of your application to figure it out.
>=20
> That's why I say that as I see it, it's not an issue of MTI.  I'm not
> saying that I want you to require that any particular thing be
> implemented.  I'm saying that both sides need to be able to know which
> variations *are* implemented.  How else do you get interoperability?
>=20
> Your TCP/ports example is a perfect one to show how this works: the
> assignments for port numbers are *exactly* to create the
> interoperability I'm talking about here.  TCP doesn't say anything
> about the protocol ("profile", perhaps) that's used over it.  But
> we've defined that port 110 is used for POP and 143 is used for IMAP
> and 25 is used for SMTP, and so on.  So I know that if my IMAP
> application wants to talk with your IMAP server, I can accomplish that
> by using port 143.  If you decide to run your IMAP server on port 142
> instead, or if you run your POP server on port 143, we will not
> interoperate.
>=20
> But all I need to know is (1) how to do IMAP, (2) how to do it over
> TCP, and (3) what port to use... and I can build an IMAP client that
> will work with any IMAP server that follows the same specs.
>=20
> Can you do that here?  Please explain how.
>=20
> Barry
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail=_8D2010F5-AA6A-48C2-B9D0-1769BADCFDA8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

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

token_endpoint_auth_signing_alg_values_supported =
 OPTIONAL.  JSON
      =
array containing a list of the JWS signing algorithms =
("alg"
      values) supported by the =
Token Endpoint for the "private_key_jwt"
 =
     and "client_secret_jwt" methods to encode the JWT [JWT]. =
 Servers
      SHOULD support =
"RS256".
      and =
"private_key_jwt", as described in Section 2.2.1 of =
OpenID
      Connect Messages 1.0 =
[OpenID.Messages].  Other Authentication
    =
  methods may be defined by extension.  If unspecified or =
omitted,
      the default is =
"client_secret_basic" HTTP Basic Authentication
    =
  Scheme as specified in Section 2.3.1 of OAuth 2.0 =
[RFC6749].

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

Are you saying that =
Assertions needs a low level mechanism to negotiate capabilities? =

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

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

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

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

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

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

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

Regards
John =
B.

On 2013-02-18, at 2:38 AM, Barry Leiba =
<barryleiba@computer.org> =
wrote:
OK, I have some time to respond to this on a real =
computer.

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

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

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

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

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

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

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

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

For your specific =
questions:

Barry, are you proposing =
that we require that the Audience contain a specific data
format =
tailored to a particular application of assertions?  If so, what =
format are you
proposing, and for which application of assertions? =
 Likewise, are you proposing
that the Subject field contain a =
particular data format tailored to a particular
application? =
 And also the Issuer field?

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

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

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

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

Can you do that here? =
 Please explain =
how.

Barry
_______________________________________________
OA=
uth mailing list
OAuth@ietf.org
https://www.ietf.org/=
mailman/listinfo/oauth

=

--Apple-Mail=_8D2010F5-AA6A-48C2-B9D0-1769BADCFDA8--

--Apple-Mail=_5810A4CF-FD55-4169-944E-2AFECEEFFD23
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMjE4MTUxNzU1WjAjBgkqhkiG9w0BCQQxFgQU3EP2/3BD
Qwmu3/E7fK0RlHifmcAwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAArmDE9NtAFCnggpAASUAopXVWQvyE/Y22OXpJYwd
0WSU9pL4+gYL2WzqtmhJsq2Z4NtKW01i4ufjNW3pbNOMwDxF2gMJyWuWbku/SKosqbR41GU2dyjI
/bTdX9QyJBOq8o/ytQeLS9iODtD85BbIW61aF34181n3KpXAswi5B3QnfOUWeVLYcQaoqb+7hPOM
MhkFFjig60mc1BuTKPychaSd0FfFDWFeQqOTRS1ceGbgjZK5R5U41Fg+N9EPLp7hAPY+K01tGxJq
Q/oFccFJ8JEoMJHdQ9oHudQMBvb51c2osTx4jlEbRkS+8o9dcKy04mBqW2l2eG2hLcOZhBAUbgAA
AAAAAA==

--Apple-Mail=_5810A4CF-FD55-4169-944E-2AFECEEFFD23--

From ve7jtb@ve7jtb.com  Mon Feb 18 07:27:28 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0A421F8958 for ; Mon, 18 Feb 2013 07:27:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.401
X-Spam-Level: 
X-Spam-Status: No, score=-3.401 tagged_above=-999 required=5 tests=[AWL=0.198,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gh7C2zACVvca for ; Mon, 18 Feb 2013 07:27:17 -0800 (PST)
Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA7121F87D4 for ; Mon, 18 Feb 2013 07:27:08 -0800 (PST)
Received: by mail-qe0-f48.google.com with SMTP id 3so2464829qea.7 for ; Mon, 18 Feb 2013 07:27:07 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=D7Fnq3zV/gZc1I5amVmVvTnc62vBYnEL7gmpVU2XCjg=; b=eZbFiYL1C+ROylP0Issf4drIIFRsrIxUBsHaPUKs0/ef3PnDZOuuCxTRbvZ4YSLiph h8l5AiHklLPGx7vtH4VFa+/kXtanlyPy9H/h8EjqdN1tZ4S7ysxrKcTwSaFn6z1DrCHN 3WV6vkL/BVmpBFT/bMSEd6FoCMTTpTw3Fw7HyZGZFHWGhKW5Tfca95weUGZu2O33WCiH mEREswrcLiobPlwLoVtcP36VNXYEeIK9XPJ6uZ0vlxoONbcd/Qv7IoKZJ8Ew28sULXfx O0yQUH7HtlD71Yce3nedsfabHZ2ySZhQOYrYfWtR6KjYSTWhLIXpV09xIMKcCY3t+6bv wcxg==
X-Received: by 10.224.221.81 with SMTP id ib17mr4805076qab.32.1361201227573; Mon, 18 Feb 2013 07:27:07 -0800 (PST)
Received: from [192.168.1.213] (190-20-56-120.baf.movistar.cl. [190.20.56.120]) by mx.google.com with ESMTPS id ei2sm25387554qab.3.2013.02.18.07.27.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Feb 2013 07:27:05 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_A680CF1F-3077-49E0-8ED2-29EE61D8F583"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <51223B5A.5050008@mitre.org>
Date: Mon, 18 Feb 2013 12:26:20 -0300
Message-Id: 
References: <20130215215423.23019.50224.idtracker@ietfa.amsl.com>  <5120B6EE.60801@lodderstedt.net> <51223B5A.5050008@mitre.org>
To: Justin Richer 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQlP93IiaMvPlVqKnGXg1G+/U+7NJclPPBzX4/zGTBIJoONGUhRmy3nKnbI1kMataRboWcrM
Cc: "" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Feb 2013 15:27:45 -0000

--Apple-Mail=_A680CF1F-3077-49E0-8ED2-29EE61D8F583
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

inline
On 2013-02-18, at 11:31 AM, Justin Richer  wrote:

>=20
> On 02/17/2013 05:54 AM, Torsten Lodderstedt wrote:
>> Hi Justin,
>>=20
>> the new revision seems to catch the state of discussion and is =
consistent. Thank's for bringing this topic forward.
>>=20
>> On your editor's not in section 4.2.: In my opinion, the 404 due to a =
none-existing resource should precede the 403. I would suggest to point =
out your thoughts on the access token. But as with any HTTP request, =
there could be other ways to authenticate to this endpoint. I therefore =
would not connect both aspects to much.
>>=20
>=20
> =46rom our own implementation, the code that processes the token would =
fire (and fail) long before the code that checks if the client is valid =
gets reached. So for us, checking if the client exists in the first =
place is difficult.
>=20
> What if we just say it's a 403 if either the client or the token are =
invalid?

This is the wording I put in the Connect version

When a read error condition occurs, the Client Registration Access =
Endpoint returns a HTTP 403 Forbidden status code. This indicates that =
the Access Token is invalid or the Client record requested is invalid or =
non-existent. Note that for security reasons, to inhibit brute force =
attacks, endpoints MUST NOT return 404 Not Found error codes.

=46rom a security point of view differentiating the two is bad as it =
helps an attacker find valid notes to brute force.  Ideally you want an =
attacker to spend time truing to break into resources that don't exist =
as well as ones that do.

John B.=

--Apple-Mail=_A680CF1F-3077-49E0-8ED2-29EE61D8F583
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMjE4MTUyNjI0WjAjBgkqhkiG9w0BCQQxFgQUSlu36ayk
jQH+0nur7jjxvsO694swgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEABtSAM+fm3OS6gd4EmaE5pZmOFAfHTnKHd5lp2PPI
NIhzj6oKg0huynkxblCKMXtR1svp9ORW92rw7zojvzmpFRFL0dKplt+sBBPHF+oIRY9JsbaOtW0o
lVN0uS+ARseZrUsJmEzzfEmS5YlWTdybbjWofG/jmM1g9RQY2UyGlcBCs3vLF9LCVtWlJ+Wt4t0O
4iTwAFy5nPLZQ/q2sWPGKe+YSIYZsqwKKJNXm3BOd3kwlUMke5IVnfI7uCM7rDPkrKowtVcXuIsM
KFM2ZEf7adGJHSGlHFFoQ3guh6fmP/saAW0IO8RbOPAbnmxv+CuLjK+O7hf/2DulOrEVZuXQuQAA
AAAAAA==

--Apple-Mail=_A680CF1F-3077-49E0-8ED2-29EE61D8F583--

From sal@idmachines.com  Mon Feb 18 08:02:33 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9712521F87F3 for ; Mon, 18 Feb 2013 08:02:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level: 
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+mpiawDoEBX for ; Mon, 18 Feb 2013 08:02:32 -0800 (PST)
Received: from atl4mhob04.myregisteredsite.com (atl4mhob04.myregisteredsite.com [209.17.115.42]) by ietfa.amsl.com (Postfix) with ESMTP id 567FC21F86F7 for ; Mon, 18 Feb 2013 08:02:32 -0800 (PST)
Received: from mailpod1.hostingplatform.com ([10.30.71.118]) by atl4mhob04.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r1IG2VLZ010246 for ; Mon, 18 Feb 2013 11:02:31 -0500
Received: (qmail 29280 invoked by uid 0); 18 Feb 2013 16:02:31 -0000
Received: from unknown (HELO salPC) (sal@idmachines.com@74.104.46.177) by 0 with ESMTPA; 18 Feb 2013 16:02:31 -0000
From: "Salvatore D'Agostino" 
To: , "'Justin Richer'" 
Date: Mon, 18 Feb 2013 11:02:30 -0500
Message-ID: <021401ce0df1$5b303b10$1190b130$@com>
X-Mailer: Microsoft Office Outlook 12.0
MIME-Version: 1.0
Thread-Index: Ac4N8VEivMZhpuPrQ9C0nAMQINM4Ug==
Content-Language: en-us
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_020C_01CE0DC7.684FB430"
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Feb 2013 16:02:33 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_020C_01CE0DC7.684FB430
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_020D_01CE0DC7.684FB430"

------=_NextPart_001_020D_01CE0DC7.684FB430
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

+1 to avoiding suspend 

"I don't think it's worthwhile to specify it as a "suspend" operation,
because to me "suspend" implies an ability to "unsuspend", and I really
don't think we want to get into the complicated zombie OAuth client
business."

Sal

Salvatore D'Agostino, CSCIP

IDmachines LLC |1264 Beacon Street, #5 | Brookline, MA  02446 | USA

http:\\www.idmachines.com   |
http:\\idmachines.blogspot.com   |
@idmachines

+1 617.201.4809 ph | +1 617.812.6495 fax

------=_NextPart_001_020D_01CE0DC7.684FB430
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

+1 to =
avoiding suspend 

“I =
don't think it's worthwhile to specify it as a "suspend" =
operation, because to me "suspend" implies an ability to =
"unsuspend", and I really don't think we want to get into the =
complicated zombie OAuth client business.”

Sal

Salvatore D'Agostino, =
CSCIP
IDmachines LLC |1264 Beacon Street, #5 | =
Brookline, MA  02446 | USA
http:\\www.idmachines.com | http:\\idmachines.blogspot.com | @idmachines
+1 617.201.4809 ph | +1 617.812.6495 =
fax

------=_NextPart_001_020D_01CE0DC7.684FB430--

------=_NextPart_000_020C_01CE0DC7.684FB430
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITIjCCBDYw
ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy
dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ
QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha
MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg
RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e
mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe
dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr
TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE
XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV
NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB
BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk
cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0
IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7
rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU
LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A
q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD
yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIEnTCC
A4WgAwIBAgIQND3pK6wnNP+PyzSU+8xwVDANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU
MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3
b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoX
DTIwMDUzMDEwNDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2Fs
dCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0
cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo
ZW50aWNhdGlvbiBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk
8n2rQTtiRjeuzcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTE
hb2FUTV5pE5okHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov
66yhs2qqty5nNYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8
goqOpA6l14lD/BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6h
hX71R2XL+E1XKHTSNP8wtu72YjAUjCzrAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6
xCZU7wO94CTLVBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIB
BjAPBgNVHRMBAf8EBTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNo
dHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYB
BQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3
DQEBBQUAA4IBAQABvJzjYyiw8zEBwt973WKgAZ0jMQ+cknNTUeofTPrWn8TKL2d+eDMPdBa5kYeR
9Yom+mRwANge+QsEYlCHk4HU2vUj2zS7hVa0cDRueIM3HoUcxREVkl+HF72sav3xwtHMiV+xfPA+
UfI183zsYJhrOivg79+zfYbrtRv1W+yifJgT1wBQudEtc94DeHThBYUxXsuauZ2UxrmUN3Vy3ET7
Z+jw+iUeUqfaJelH4KDHPKBOsQo2+3dIn++Xivu0/uOUFKiDvFwtP9JgcWDuwnGCDOmINuPaILSj
oGyqlku4gI51ykkH9jsUut/cBdmf2+Cy5k2geCbn5y1uf1/GHogVMIIFGjCCBAKgAwIBAgIQbRnq
pxlPajMi5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVU
MRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr
MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmly
c3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBaFw0yMDA1
MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw
DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09N
T0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU
4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHff
sReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kAB
W0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJk
JpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IB
SzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4
Y2QnwS/ioFu8ecV7MA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQK
MAgwBgYEVR0gADBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVRO
LVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRo
MGYwPQYIKwYBBQUHMAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVu
dF9DQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcN
AQEFBQADggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjB
MCjfy/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T
4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrUyTo8
H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lEuJB+ytF5
OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggUlMIIEDaADAgECAhAxNisl
hAwmPFmhraHt/QtWMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl
YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGlt
aXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt
YWlsIENBMB4XDTEyMTAyMjAwMDAwMFoXDTEzMTAyMjIzNTk1OVowIzEhMB8GCSqGSIb3DQEJARYS
c2FsQGlkbWFjaGluZXMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyMUItbfY
tMuC9vO6iN41DxtnlxM682Fr96jQQGvpQzUrj4tNMHUlad9Fge5rCHPryqG2bEATpf/fCunOsV9C
9D5+khqCpZlQzk6vdKxnHgv4tFv7KAv+6DxS9GCqgbNSLo1WSh16FnlwRAZT4jUd59GB5uHjxvEZ
E4eOAEKL+izQIEBzpMMDxDOS4J2wU3W88mCPLcuEESGKE5QUgRV2ARmyWMPdJhpFUpZGJv183zYf
JLLa6+mgd+cWbfPp3GUs+/xdpSd3gRY64XCsyPmygWC+zrw2XJW+bL1Ge+m5sUJ5DJSGE1XENdvj
2z6j0q56G1Q8SJrAY76XrTrNnGrMiwIDAQABo4IB4jCCAd4wHwYDVR0jBBgwFoAUehNOAHRbxnhj
ZCfBL+KgW7x5xXswHQYDVR0OBBYEFGSBNSyMTkmxv/++DoKmF05IEiYnMA4GA1UdDwEB/wQEAwIF
oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB
hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0
cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0cDovL2NybC5j
b21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy
bDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9D
T01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzAB
hhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHQYDVR0RBBYwFIESc2FsQGlkbWFjaGluZXMuY29t
MA0GCSqGSIb3DQEBBQUAA4IBAQA+jYBRYaQc2qf+SipdyHuI7A9W76ZCWAqCmeez66TNECSjbcvA
pw1HEKiehUGT4BiGSqTEBLnXM4pqsD5vUZLMiFnVAXhkgkNAOBZFq9G/bJSPW6pW9cNIjWifyAtn
wdqYXakYWQIuws08lYfGM/751/DXPioEuFSv0pqfCm/r9ashpU9+qMSmX4+nmS5VuUtRrVsyujq9
lQ0Jic737mkW6iVDIJzg4oE2ujL7l6dJBM5VdbCJns4y/R2iBn5JfIcO8ZACDuw/If558mBvhRzI
K5iBLkgqVKM6C/XTQ9Z+rc0YOaooiOn2CO4hILdhicFwr8M6V5cTBMltmrfOLqwyMYIEZTCCBGEC
AQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV
BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8g
Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDE2KyWEDCY8WaGtoe39
C1YwCQYFKw4DAhoFAKCCApEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx
DxcNMTMwMjE4MTYwMjE0WjAjBgkqhkiG9w0BCQQxFgQUZulLdxJOa85Uu2033WYo7lBIJegwgbcG
CSqGSIb3DQEJDzGBqTCBpjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsG
CWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZI
hvcNAwICASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEw
CgYIKoZIhvcNAgUwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT
EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB
IExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy
ZSBFbWFpbCBDQQIQMTYrJYQMJjxZoa2h7f0LVjCBuwYLKoZIhvcNAQkQAgsxgauggagwgZMxCzAJ
BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx
GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDE2KyWEDCY8WaGtoe39C1YwDQYJKoZIhvcN
AQEBBQAEggEAmI0+6i3qDRLQ1/DWT8tBkFu1a0FrXYMAjK6o1nCwrOepk7ott+i9gHy4rU4DGkyS
k55ws7VUY4DgLxe32jgI0yXboY9tSkI5/dvcwqnGYhmfN2C6i7sYVx3f14i65u61FZ18ZSCbrTsz
nO9NE3yDtk5/Leb7C48nor1MKRQxdSrwa1RldpLPLKYXjEu97AG1gV1kdQRhzcYCQNewD+uUQNyU
Fckg8bqX4ZkcnqVpI9zjtg0bCp/zQoDrzVqMmbKeP3c6uosAAFEOBBznNdZMCyGqOZbMn54S6gVe
NqQHxV1eIvUNkq80flXxhdJBqza7apAUle9UX1n8aARbZ431pQAAAAAAAA==

------=_NextPart_000_020C_01CE0DC7.684FB430--

From sberyozkin@gmail.com  Mon Feb 18 08:13:52 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7ED121F8BCE for ; Mon, 18 Feb 2013 08:13:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.417
X-Spam-Level: 
X-Spam-Status: No, score=-3.417 tagged_above=-999 required=5 tests=[AWL=0.182,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBl5ZZ1unPsl for ; Mon, 18 Feb 2013 08:13:52 -0800 (PST)
Received: from mail-ea0-f180.google.com (mail-ea0-f180.google.com [209.85.215.180]) by ietfa.amsl.com (Postfix) with ESMTP id F259121F8837 for ; Mon, 18 Feb 2013 08:13:51 -0800 (PST)
Received: by mail-ea0-f180.google.com with SMTP id c1so2376346eaa.11 for ; Mon, 18 Feb 2013 08:13:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=Qra4PsRdWabCW6ibN+0NGrMPWeiUPMaAcJHzZl1DzMo=; b=TB7EGEAOL6qgsF51La2sP47+vH5jnQXCDaAW4ubIh8utH9DcOHBct8nt7yGTwAj/MA h9ZHyrrYOXpeKqPMeF2IyqBtHjDWZsxWwfdO6BVBMN01dEXvJ404dnWL76dj1PZQGA+F TWb3M6wTAJ1+Oi7z4hPD/qm8NcOUHuL+M48uYOA/cIeYJ9WXTxoA3KGCu8rPlJWs1jAl /qun2QUUElZvdyvOl4/8YUwLp7CruohBQw9KHQLIFsqAd2taVoKIfwuEqVdRjKsfT8Qs OH7BhX03xfUPY1cItU/eI3lJ643/4mWcgUicXQzthUOvS5T8eOv2GrtPKy75aeSNpl9M u0Fg==
X-Received: by 10.14.0.73 with SMTP id 49mr46384668eea.21.1361204030835; Mon, 18 Feb 2013 08:13:50 -0800 (PST)
Received: from [10.36.226.5] ([217.173.99.61]) by mx.google.com with ESMTPS id r4sm54858839eeo.12.2013.02.18.08.13.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Feb 2013 08:13:49 -0800 (PST)
Message-ID: <5122533C.8020204@gmail.com>
Date: Mon, 18 Feb 2013 16:13:48 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: "" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [OAUTH-WG] Saml2 Bearer and base64url question
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Feb 2013 16:13:53 -0000

Hi,

RFC4648 [1] says:

"The pad character "=" is typically percent-encoded when used in an
  URI [9], but if the data length is known implicitly, this can be
  avoided by skipping the padding; see section 3.2."

while the SAML2 Bearer token draft says:

"The SAML Assertion XML data MUST be encoded using
    base64url, where the encoding adheres to the definition in Section 5
    of RFC4648 [RFC4648] and where the padding bits are set to zero.  To
    avoid the need for subsequent encoding steps (by "application/
    x-www-form-urlencoded" [W3C.REC-html401-19991224], for example), the
    base64url encoded data SHOULD NOT be line wrapped and pad characters
    ("=") SHOULD NOT be included."

I'd appreciate some clarifications on the above:
- SHOULD NOT implies that actually including the pad characters("=") is 
still going to work, right ? Why was it so important that the spec 
decided to mention it at all ?
- 'SHOULD NOT be included' implies the pad characters ("=") will be 
percent-encoded or not included at all ? If it is the latter, how will 
the decoder correctly read the assertion ?

Thanks, Sergey

[1] http://tools.ietf.org/html/rfc4648#section-5
[2] http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-15#section-2.1

From ve7jtb@ve7jtb.com  Mon Feb 18 08:55:34 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF05821F8C0C for ; Mon, 18 Feb 2013 08:55:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.407
X-Spam-Level: 
X-Spam-Status: No, score=-3.407 tagged_above=-999 required=5 tests=[AWL=0.192,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRAZ9R2gv7Tn for ; Mon, 18 Feb 2013 08:55:24 -0800 (PST)
Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) by ietfa.amsl.com (Postfix) with ESMTP id 39A7B21F8C4B for ; Mon, 18 Feb 2013 08:55:24 -0800 (PST)
Received: by mail-qa0-f43.google.com with SMTP id dx4so1375315qab.2 for ; Mon, 18 Feb 2013 08:55:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=sY/l2CEtLksNl+WXaIXhz8blAJOt9X5Q8ovPCiMg+8A=; b=LEPfDs7N8LunQ4pEAtf3SbVT081Dt7RuRgfGYmSUIroBVEgD5wpFWjUCB8HrvsXHgr 4d2VhXOAdq/6cT6z8DlI1se0TlVEvvztujN0oUJls7NDno54N/JHA5sw0QPEQQIttPHF 1RCFnzHxJaiwWJpr+vGdHpsaGQklyA5DoxOR/xPeme0DixWwge5Zi3nj8f1XnIbNiibI j8rmZyVoeMpMfZM3vP/d5bXwIqcr0446DHSRim6fpHirH9SdHsU8bV5d7iR8QHJ7VYzp VPs37qCLDMuExWeniuDaGDjb8F+KPqAsVOsySupYdIgUGZoS2n8jQXjPwZQPU58+Akt3 4F1Q==
X-Received: by 10.224.33.208 with SMTP id i16mr1091510qad.45.1361206523448; Mon, 18 Feb 2013 08:55:23 -0800 (PST)
Received: from [192.168.1.213] (190-20-56-120.baf.movistar.cl. [190.20.56.120]) by mx.google.com with ESMTPS id dt10sm25607741qab.0.2013.02.18.08.55.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Feb 2013 08:55:21 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_7A4C5FC5-8EAA-42A3-9E56-57BBE543B5DF"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <5122533C.8020204@gmail.com>
Date: Mon, 18 Feb 2013 13:54:49 -0300
Message-Id: 
References: <5122533C.8020204@gmail.com>
To: Sergey Beryozkin 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQkPsAFf/AWCx4UCxe1L9mSG5x85rsRvxZqq2mp1KI5pR0kAtKkY629JdwcMHQaJ/l4uIOd6
Cc: "" 
Subject: Re: [OAUTH-WG] Saml2 Bearer and base64url question
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Feb 2013 16:55:35 -0000

--Apple-Mail=_7A4C5FC5-8EAA-42A3-9E56-57BBE543B5DF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

A base64url decoder doesn't need the padding bytes in this case.  They =
are really only useful if you are concatenating outputs together.   The =
number of missing pads characters can be calculated from the number of =
base64url encoded octets to be decoded.

So the padding and any other line wraps SHOULD NOT be included.  If the =
recipient is known to have a problem with missing padding then they must =
be %encoded if the transport requires it.  =20

I will grant you that changing it to MUST NOT may be clearer to people.  =
I suspect that it is easier to fix broken decoders than try and =
accommodate them.

John B.

=20
On 2013-02-18, at 1:13 PM, Sergey Beryozkin  =
wrote:

> Hi,
>=20
> RFC4648 [1] says:
>=20
> "The pad character "=3D" is typically percent-encoded when used in an
> URI [9], but if the data length is known implicitly, this can be
> avoided by skipping the padding; see section 3.2."
>=20
> while the SAML2 Bearer token draft says:
>=20
> "The SAML Assertion XML data MUST be encoded using
>   base64url, where the encoding adheres to the definition in Section 5
>   of RFC4648 [RFC4648] and where the padding bits are set to zero.  To
>   avoid the need for subsequent encoding steps (by "application/
>   x-www-form-urlencoded" [W3C.REC-html401-19991224], for example), the
>   base64url encoded data SHOULD NOT be line wrapped and pad characters
>   ("=3D") SHOULD NOT be included."
>=20
> I'd appreciate some clarifications on the above:
> - SHOULD NOT implies that actually including the pad characters("=3D") =
is still going to work, right ? Why was it so important that the spec =
decided to mention it at all ?
> - 'SHOULD NOT be included' implies the pad characters ("=3D") will be =
percent-encoded or not included at all ? If it is the latter, how will =
the decoder correctly read the assertion ?
>=20
> Thanks, Sergey
>=20
>=20
> [1] http://tools.ietf.org/html/rfc4648#section-5
> [2] =
http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-15#section-2.1
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail=_7A4C5FC5-8EAA-42A3-9E56-57BBE543B5DF
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMjE4MTY1NDUyWjAjBgkqhkiG9w0BCQQxFgQUkwuEdBcy
Wr+svdx2mfv3MzJP0NEwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAkyZnR3e0RRu6I+Ttb9vAqQe4ZonxsWw41wjtpu+b
O7hK374uNDJmeB587RXmhldPGXjGFKEvfjQxnp5smGx6FGVRJjS513zG+LufPCUbM5WOa5uiI+59
YpXkZReeUwWiO6RIqwgEYwolTE8GrBOS3coE+I/ZhnBoUMKy6ETF3DdPot9ag2yxB0x+EabbViGA
BatkCQUtTb1WVFXv3ovVfhQJQh5RTkpX+JSzq2jEhfp4RaeK8GJ9dyI5DspZfZjZaPlBTtSPoy+W
aUgaxFBjtC73ui5voZGbkUS0DaDteDENNuceqz9WAmSKkTU5bcD61z0+4zyak7c1WF4jVLGPHgAA
AAAAAA==

--Apple-Mail=_7A4C5FC5-8EAA-42A3-9E56-57BBE543B5DF--

From sberyozkin@gmail.com  Mon Feb 18 09:00:43 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 592C421F8C45 for ; Mon, 18 Feb 2013 09:00:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.44
X-Spam-Level: 
X-Spam-Status: No, score=-3.44 tagged_above=-999 required=5 tests=[AWL=0.159,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7SFLxZK9xUL for ; Mon, 18 Feb 2013 09:00:41 -0800 (PST)
Received: from mail-bk0-f49.google.com (mail-bk0-f49.google.com [209.85.214.49]) by ietfa.amsl.com (Postfix) with ESMTP id 74E7F21F8AA3 for ; Mon, 18 Feb 2013 09:00:40 -0800 (PST)
Received: by mail-bk0-f49.google.com with SMTP id w11so2656954bku.8 for ; Mon, 18 Feb 2013 09:00:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=a+Nhv+LeDP670cFS5tjnPwcSUEritB7pk4V/fB2GhGo=; b=PdG/KkILUNOkkrBGCKTOJ2XjxqaNHVFfjfdgNBuJ2mZNl7hxptFZUWPC3UYvfYfC/8 84UUSb6f9lKwCWYr/NRHYIaUDtXX8WWbwwLxcGY7oDEA6uiIeyA+QNqDv9oXzGC0b5sU Uu2J22L1CnWUkHK49FYKPGHbgTzMONaEb4i3TLHmDGGug9iV05jQFBGpRzUCpRlLql7q pDCKADOHvHSGLS2/nrPr6o938YjMsA16GzHdz4eTSmoCQSSWV2z/mPXoI+Y0fm+DG/a9 Tlzj0Z74mi9yfoXkIQfRctDhTR5dIFSKV+Byr3x33tKTPaqKnMSAtk9MhBoawpfAXY4S JtKg==
X-Received: by 10.204.13.28 with SMTP id z28mr5046677bkz.83.1361206838639; Mon, 18 Feb 2013 09:00:38 -0800 (PST)
Received: from [10.36.226.5] ([217.173.99.61]) by mx.google.com with ESMTPS id go8sm21155107bkc.20.2013.02.18.09.00.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Feb 2013 09:00:37 -0800 (PST)
Message-ID: <51225E33.3030109@gmail.com>
Date: Mon, 18 Feb 2013 17:00:35 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: John Bradley 
References: <5122533C.8020204@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" 
Subject: Re: [OAUTH-WG] Saml2 Bearer and base64url question
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Feb 2013 17:00:44 -0000

On 18/02/13 16:54, John Bradley wrote:
> A base64url decoder doesn't need the padding bytes in this case.  They are really only useful if you are concatenating outputs together.   The number of missing pads characters can be calculated from the number of base64url encoded octets to be decoded.
>
> So the padding and any other line wraps SHOULD NOT be included.  If the recipient is known to have a problem with missing padding then they must be %encoded if the transport requires it.
>
The above is helpful, thanks

> I will grant you that changing it to MUST NOT may be clearer to people.  I suspect that it is easier to fix broken decoders than try and accommodate them.
>
Now that I have a better understanding, either SHOULD or MUST will work 
for me at least :-)

Cheers, Sergey

> John B.
>
>
> On 2013-02-18, at 1:13 PM, Sergey Beryozkin  wrote:
>
>> Hi,
>>
>> RFC4648 [1] says:
>>
>> "The pad character "=" is typically percent-encoded when used in an
>> URI [9], but if the data length is known implicitly, this can be
>> avoided by skipping the padding; see section 3.2."
>>
>> while the SAML2 Bearer token draft says:
>>
>> "The SAML Assertion XML data MUST be encoded using
>>    base64url, where the encoding adheres to the definition in Section 5
>>    of RFC4648 [RFC4648] and where the padding bits are set to zero.  To
>>    avoid the need for subsequent encoding steps (by "application/
>>    x-www-form-urlencoded" [W3C.REC-html401-19991224], for example), the
>>    base64url encoded data SHOULD NOT be line wrapped and pad characters
>>    ("=") SHOULD NOT be included."
>>
>> I'd appreciate some clarifications on the above:
>> - SHOULD NOT implies that actually including the pad characters("=") is still going to work, right ? Why was it so important that the spec decided to mention it at all ?
>> - 'SHOULD NOT be included' implies the pad characters ("=") will be percent-encoded or not included at all ? If it is the latter, how will the decoder correctly read the assertion ?
>>
>> Thanks, Sergey
>>
>>
>> [1] http://tools.ietf.org/html/rfc4648#section-5
>> [2] http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-15#section-2.1
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>

From Michael.Jones@microsoft.com  Mon Feb 18 10:07:06 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 641E921F86D5 for ; Mon, 18 Feb 2013 10:07:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.286
X-Spam-Level: 
X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vuLLhQTzK6E for ; Mon, 18 Feb 2013 10:07:01 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.32]) by ietfa.amsl.com (Postfix) with ESMTP id 62AE921F88AE for ; Mon, 18 Feb 2013 10:07:00 -0800 (PST)
Received: from BL2FFO11FD023.protection.gbl (10.173.161.200) by BL2FFO11HUB019.protection.gbl (10.173.160.111) with Microsoft SMTP Server (TLS) id 15.0.620.12; Mon, 18 Feb 2013 18:06:56 +0000
Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD023.mail.protection.outlook.com (10.173.161.102) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Mon, 18 Feb 2013 18:06:55 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.96]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Mon, 18 Feb 2013 18:06:33 +0000
From: Mike Jones 
To: Barry Leiba 
Thread-Topic: [OAUTH-WG] oauth assertions plan
Thread-Index: AQHODUSFJYuGTyHp/UK+QNplisn2A5h+fdTAgAASPICAAAGIAIAAiDaAgADB2bA=
Date: Mon, 18 Feb 2013 18:06:32 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436747042A@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <51212E78.1050206@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DC1C@TK5EX14MBXC284.redmond.corp.microsoft.com> <51214AC5.3090807@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DE40@TK5EX14MBXC284.redmond.corp.microsoft.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.32]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436747042ATK5EX14MBXC284r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(24454001)(13464002)(189002)(199002)(377454001)(53806001)(77982001)(59766001)(54356001)(16236675001)(55846006)(51856001)(49866001)(47736001)(47976001)(512954001)(50986001)(54316002)(4396001)(76482001)(44976002)(74662001)(74502001)(31966008)(15202345001)(47446002)(65816001)(5343655001)(5343635001)(80022001)(46102001)(66066001)(63696002)(33656001)(20776003)(16406001)(79102001)(56776001)(56816002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB019; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0761DE1EDD
Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] oauth assertions plan
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Feb 2013 18:07:06 -0000

--_000_4E1F6AAD24975D4BA5B16804296739436747042ATK5EX14MBXC284r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

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

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

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

   urn:ietf:params:banana

...and like this in another

   abra:cadabra

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

You can write applications to that by having the profile chain end, and wit=
h the contents of the Audience field being completely specified somewhere i=
n the profile chain being used.  Also, I'll observe that we are using the "=
tagged field" approach that you mention in the assertions specs, using the =
defined tag values urn:ietf:params:oauth:grant-type:saml2-bearer, urn:ietf:=
params:oauth:client-assertion-type:saml2-bearer, urn:ietf:params:oauth:gran=
t-type:jwt-bearer, and urn:ietf:params:oauth:client-assertion-type:jwt-bear=
er to declare the token type and use of that token type.  (The OpenID Conne=
ct profile also uses a "tagged field" which is an OAuth scope value of "ope=
nid" to dynamically declare to the OAuth implementation that the OpenID Con=
nect profile is being used.  Other profiles may similarly indicate their us=
age through different scope values.)

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

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

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

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

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

                                                            Best wishes,

                                                            -- Mike

-----Original Message-----
From: barryleiba@gmail.com [mailto:barryleiba@gmail.com] On Behalf Of Barry=
 Leiba
Sent: Sunday, February 17, 2013 9:38 PM
To: Mike Jones
Cc: Stephen Farrell; oauth@ietf.org; oauth-chairs@tools.ietf.org
Subject: Re: [OAUTH-WG] oauth assertions plan

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

Let's look at the general mechanism that oauth provides, using one use case=
:

A client asks an authorization server for authorization to do something.

The authorization server responds with an authorization token, which the cl=
ient is required to understand.

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

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

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

Now, suppose that the server decides to give back an assertion:

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

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

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

I understand that you want certain things to be handled differently by diff=
erent applications, and I'm fine with that in principle.  But the other par=
t of the principle is that I have to be able to write an application that i=
nteroperates with yours *purely by reading the specs*.

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

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

   urn:ietf:params:banana

...and like this in another

   abra:cadabra

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

For your specific questions:

> Barry, are you proposing that we require that the Audience contain a

> specific data format tailored to a particular application of

> assertions?  If so, what format are you proposing, and for which

> application of assertions?  Likewise, are you proposing that the

> Subject field contain a particular data format tailored to a particular a=
pplication?  And also the Issuer field?

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

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

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

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

Can you do that here?  Please explain how.

Barry

--_000_4E1F6AAD24975D4BA5B16804296739436747042ATK5EX14MBXC284r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Barry.  Tha=
nks for your response.  I believe we share the same goals here (the &q=
uot;what").  Where I think we need to focus the discussion then i=
s on the mechanisms to achieve that (the "how").  Let me fil=
l
 in the details, as I see them, by responding to a few things you wrote:

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

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

Now, the way we usuall=
y handle the need for "different kinds of things" is to have diff=
erent fields for each, or to have one field tagged so that it's self-defini=
ng (as URIs have a scheme that says what to do
 with them).  If the Audience field might look like this in one applic=
ation:
   urn:ietf:=
params:banana
...and like this in an=
other
   abra:cada=
bra
...where the first is =
understood to be a URI and the second is something else, then please explai=
n how you and I can each write applications to that?

You can write applicat=
ions to that by having the profile chain end, and with the contents of the =
Audience field being completely specified somewhere in the profile chain be=
ing used.  Also, I’ll observe that we
are using the “tagged field” approach that you mention i=
n the assertions specs, using the defined tag values
urn:ietf:params:oauth:grant-type:saml2-bearer,
urn:ie=
tf:params:oauth:client-assertion-type:saml2-bearer,
urn:ie=
tf:params:oauth:grant-type:jwt-bearer,=
 and
urn:ietf:params:oauth:client-assertion-type:jwt-bearer to declare the token type and use of that token type.&n=
bsp; (The OpenID Connect profile also uses a “tagged
 field” which is an OAuth scope=
 value of “openid” to dyn=
amically
 declare to the OAuth implementation that the OpenID Connect profile is bei=
ng used.  Other profiles may similarly indicate their usage through di=
fferent
scope values.)

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

I agree with what I=
 think you mean, but possibly not with how you’re saying it.  Us=
ing the TCP analogy again, in fact, to understand the contents of the TCP s=
tream for port 25, one has to go to the documentation
 of the application communicating on port 25.  In this case, that docu=
mentation is RFC 821 and its successors.  SMTP is a profile of TCP tha=
t further specifies the contents of the data being exchanged.  An anal=
ogous situation exists when using OAuth Assertions.

I’ll also obs=
erve that the working group is also working on a specification that enables=
 an OAuth client to dynamically register itself with the Authorization Serv=
er (draft-ietf-oauth-dyn-reg)
and that that registration does declare information about what profile i=
s being used, as John Bradley pointed out in his response.  That&#=
8217;s a key piece of the whole solution to enable interoperable implementa=
tions.

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

I agree with Stephe=
n that we should let this conversation run for a while to make sure everyon=
e comes to a common understanding, but ultimately, I hope that you’ll=
 withdraw your DISCUSS, because, in fact,
 interoperable implementations can be written by reading the specs used alo=
ne.

   &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;      Best wishes,
   &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;      -- Mike

-----Original Message-----

From: barryleiba@gmail.com [mailto:barryleiba@gmail.com] On Behalf Of Barry=
 Leiba

Sent: Sunday, February 17, 2013 9:38 PM

To: Mike Jones

Cc: Stephen Farrell; oauth@ietf.org; oauth-chairs@tools.ietf.org

Subject: Re: [OAUTH-WG] oauth assertions plan

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

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

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

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

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

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

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

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

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

For your specific questions:

> Barry, are you proposing that we require tha=
t the Audience contain a

> specific data format tailored to a particula=
r application of

> assertions?  If so, what format are you=
 proposing, and for which

> application of assertions?  Likewise, a=
re you proposing that the

> Subject field contain a particular data form=
at tailored to a particular application?  And also the Issuer field?

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

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

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

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

Can you do that here?  Please explain how.

Barry

--_000_4E1F6AAD24975D4BA5B16804296739436747042ATK5EX14MBXC284r_--

From barryleiba.mailing.lists@gmail.com  Mon Feb 18 10:37:11 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A0221F8B02 for ; Mon, 18 Feb 2013 10:37:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.931
X-Spam-Level: 
X-Spam-Status: No, score=-102.931 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQwiAKQLMPAQ for ; Mon, 18 Feb 2013 10:37:10 -0800 (PST)
Received: from mail-vb0-f52.google.com (mail-vb0-f52.google.com [209.85.212.52]) by ietfa.amsl.com (Postfix) with ESMTP id 3644421F8AD8 for ; Mon, 18 Feb 2013 10:37:10 -0800 (PST)
Received: by mail-vb0-f52.google.com with SMTP id fa15so3673418vbb.39 for ; Mon, 18 Feb 2013 10:37:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=LD4ilCkLbRjWH+m3Eq1AfJQlJH0Zy8MYFuf8jhEH6fg=; b=PK7US1/hsVf9cSqiUCDbLQFf4+p9nsjj8cbfnz4P6yuc1yrq//Vv/o9yxCg8wBNUX3 M5IsH/Z7xpxQVcgKgd9lorloVjaZRZK8p/ozBhuerU1Tia4rVreVKtCTNJFhEIgo4YwU juwDsfnq5K1XW+O9ZYNIORdgcgCMJST1RD1c/ucs0yjJt5VwTu9efZaPNKIgoioIuXA0 EzoUsuhPXEUW06au2hKr1kqLfqJ1EqaB7hHPp9sWXcxjW17sq87miwOSqkX/gmzFHnaC P60HWmNukBcv+8hVIJbUJ2KubMvbkQeBHnKdrsdfToclouNwWBixS3ODtAiqJ/wq8Qcl MP0g==
MIME-Version: 1.0
X-Received: by 10.59.9.201 with SMTP id du9mr17427662ved.38.1361212629577; Mon, 18 Feb 2013 10:37:09 -0800 (PST)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.59.3.41 with HTTP; Mon, 18 Feb 2013 10:37:09 -0800 (PST)
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436747042A@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <51212E78.1050206@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DC1C@TK5EX14MBXC284.redmond.corp.microsoft.com> <51214AC5.3090807@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DE40@TK5EX14MBXC284.redmond.corp.microsoft.com>  <4E1F6AAD24975D4BA5B16804296739436747042A@TK5EX14MBXC284.redmond.corp.microsoft.com>
Date: Mon, 18 Feb 2013 13:37:09 -0500
X-Google-Sender-Auth: GsoYlMTEw0dbl7wWDlV-ni76uYw
Message-ID: 
From: Barry Leiba 
To: Mike Jones 
Content-Type: multipart/alternative; boundary=047d7beb971e3feeb104d60403c7
Cc: "oauth-chairs@tools.ietf.org" , Barry Leiba , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] oauth assertions plan
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Feb 2013 18:37:11 -0000

--047d7beb971e3feeb104d60403c7
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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

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

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

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

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

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

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

Barry

--047d7beb971e3feeb104d60403c7
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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

please explain how you and I can each wr=
ite applications to that?

=A0
You can write applicat=
ions to that by having the profile chain end, and with the contents of the =
Audience field being completely specified somewhere in the profile chain be=
ing used.

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

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

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

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

It sounds like it is a =
key piece, and in that case I think that document needs to come forward alo=
ng with (or before) the ones that depend on it for interoperability. =A0Abs=
ent something like that, we can't evaluate whether it's possible to=
 write interoperable implementations of this spec.
=A0We already do have mechanis=
ms for dynamically declaring what profile is being used, and we are using t=
hem.

"Dynamically decla=
ring," in what sense? =A0Where are those mechanisms documented?<=
div>=A0

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

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

Barry
=A0

--047d7beb971e3feeb104d60403c7--

From Michael.Jones@microsoft.com  Mon Feb 18 11:02:50 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834D921F8929 for ; Mon, 18 Feb 2013 11:02:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.58
X-Spam-Level: 
X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.018,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZhJz0zzXtHy for ; Mon, 18 Feb 2013 11:02:47 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.31]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4F121F88F0 for ; Mon, 18 Feb 2013 11:02:47 -0800 (PST)
Received: from BL2FFO11FD014.protection.gbl (10.173.161.204) by BL2FFO11HUB022.protection.gbl (10.173.161.46) with Microsoft SMTP Server (TLS) id 15.0.620.12; Mon, 18 Feb 2013 19:02:40 +0000
Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD014.mail.protection.outlook.com (10.173.160.222) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Mon, 18 Feb 2013 19:02:40 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.96]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0318.003; Mon, 18 Feb 2013 19:02:12 +0000
From: Mike Jones 
To: Barry Leiba 
Thread-Topic: [OAUTH-WG] oauth assertions plan
Thread-Index: AQHODUSFJYuGTyHp/UK+QNplisn2A5h+fdTAgAASPICAAAGIAIAAiDaAgADB2bCAABe6gIAAAWoQ
Date: Mon, 18 Feb 2013 19:02:11 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436747063A@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <51212E78.1050206@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DC1C@TK5EX14MBXC284.redmond.corp.microsoft.com> <51214AC5.3090807@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DE40@TK5EX14MBXC284.redmond.corp.microsoft.com>  <4E1F6AAD24975D4BA5B16804296739436747042A@TK5EX14MBXC284.redmond.corp.microsoft.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.32]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436747063ATK5EX14MBXC284r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(199002)(189002)(51444002)(76482001)(16236675001)(65816001)(63696002)(47976001)(50986001)(77982001)(59766001)(16297215001)(56816002)(20776003)(15202345001)(4396001)(74502001)(47446002)(16406001)(46102001)(44976002)(49866001)(80022001)(47736001)(74662001)(56776001)(54316002)(51856001)(53806001)(31966008)(54356001)(33656001)(512954001)(15395725002)(79102001)(66066001)(5343645001)(5343635001)(55846006)(5343655001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB022; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0761DE1EDD
Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] oauth assertions plan
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Feb 2013 19:02:50 -0000

--_000_4E1F6AAD24975D4BA5B16804296739436747063ATK5EX14MBXC284r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

"Dynamically declaring," in what sense?  Where are those mechanisms documen=
ted?

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

One profile (an outer doll :)) that enables fully interoperable implementat=
ions is documented in draft-hardjono-oauth-umacore.  It uses the "http://do=
cs.kantarainitiative.org/uma/scopes/prot.json" scope value as its "tagged f=
ield" value.  Another related profile that enables fully interoperable impl=
ementations is documented in http://openid.net/specs/openid-connect-message=
s-1_0.html.  It uses the "openid" scope value as its "tagged field" value, =
per http://openid.net/specs/openid-connect-messages-1_0.html#scopes.  I kno=
w that Dick Hardt has another profile that's using the JWT Assertion Profil=
e for a BC Government identity project.  I know of ones used inside of ente=
rprises and at cloud services as well.

                                                            -- Mike

From: barryleiba.mailing.lists@gmail.com [mailto:barryleiba.mailing.lists@g=
mail.com] On Behalf Of Barry Leiba
Sent: Monday, February 18, 2013 10:37 AM
To: Mike Jones
Cc: Barry Leiba; oauth-chairs@tools.ietf.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] oauth assertions plan

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

please explain how you and I can each write applications to that?

You can write applications to that by having the profile chain end, and wit=
h the contents of the Audience field being completely specified somewhere i=
n the profile chain being used.

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

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

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

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

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

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

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

"Dynamically declaring," in what sense?  Where are those mechanisms documen=
ted?

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

I still don't see that that's true (how did those interoperable implementat=
ions resolve the incompletely specified bits?), but, in any case, don't obs=
ess over the DISCUSS ballot, because it no longer matters: Stephen has retu=
rned the document to the working group, and when it comes back to IESG Eval=
uation again I'm sure Stephen will issue a new ballot and we'll start the p=
rocess from a clean slate.

Barry

--_000_4E1F6AAD24975D4BA5B16804296739436747063ATK5EX14MBXC284r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

"Dynamically declari=
ng," in what sense?  Where are those mechanisms documented?<=
/o:p>
 <=
/p>
Many of them are document=
ed in draft-ietf-oauth-dyn-reg.
 <=
/p>
One profile (an outer dol=
l
J) that enables fully interoperable impl=
ementations is documented in draft-hardjono-oauth-umacore. 
 It uses the “http://docs.kantarainitiative.org/uma/scopes/prot.json=
” scope value as its “tagged =
field” value. 
 Another related profile that enables fully interoperable implementations i=
s documented in
http:/=
/openid.net/specs/openid-connect-messages-1_0.html.  It uses the &=
#8220;openid”
 scope value as its “tagged field” value, per 
http://openid.net/specs/openid-connect-messages-1_0.html#scopes.  =
I know that Dick Hardt has another profile that’s using the JWT Asser=
tion Profile for a BC Government identity project.  I know of ones use=
d inside of enterprises and at cloud services as
 well.
 <=
/p>
    &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;     -- Mike
 <=
/p>
From: barrylei=
ba.mailing.lists@gmail.com [mailto:barryleiba.mailing.lists@gmail.com]
On Behalf Of Barry Leiba

Sent: Monday, February 18, 2013 10:37 AM

To: Mike Jones

Cc: Barry Leiba; oauth-chairs@tools.ietf.org; oauth@ietf.org

Subject: Re: [OAUTH-WG] oauth assertions plan

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

please explain how you and I can each write a=
pplications to that?

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

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

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

I agree with what I think you mean, but po=
ssibly not with how you’re saying it.  Using the TCP analogy aga=
in, in fact, to understand the contents of the TCP stream for port 25, one =
has to go to the documentation of the application
 communicating on port 25.  In this case, that documentation is RFC 82=
1 and its successors.

Yeh, here's where we're disconnected.  One does=
 NOT have to go to the documentation of the application at all.  One h=
as to go to the specification of SMTP.  But one needn't know *anything=
* about any other implementations of SMTP: everything
 you need is in the SMTP spec (including that it runs on port 25).

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

I’ll also observe that the working g=
roup is also working on a specification that enables an OAuth client to dyn=
amically register itself with the Authorization Server (draft-ietf-oauth-dy=
n-reg)
and that that registration does declare information about what profile i=
s being used, as John Bradley pointed out in his response.  That&#=
8217;s a key piece of the whole solution to enable interoperable implementa=
tions.

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

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

"Dynamically declaring," in what sense? &n=
bsp;Where are those mechanisms documented?

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

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

Barry

--_000_4E1F6AAD24975D4BA5B16804296739436747063ATK5EX14MBXC284r_--

From barryleiba@gmail.com  Mon Feb 18 11:03:06 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F04A621F8A56 for ; Mon, 18 Feb 2013 11:03:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.932
X-Spam-Level: 
X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZX2yQZawYzdf for ; Mon, 18 Feb 2013 11:03:05 -0800 (PST)
Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by ietfa.amsl.com (Postfix) with ESMTP id D64DB21F8A85 for ; Mon, 18 Feb 2013 11:03:04 -0800 (PST)
Received: by mail-lb0-f178.google.com with SMTP id n1so4424807lba.23 for ; Mon, 18 Feb 2013 11:03:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=amo06yK6s53tsVe2f8Wv3ILhe77vFGBr8mqiUFiUPvI=; b=pbpgA9d5wm12X7iyJcRGsBuMf5j1NNiDmszxtN+zuPF4w59tMtKbnxMa/9hyXJB4RK cebsnPrqLkWXb4z6Q2MufyWxRDbrjH8kqmh3+5iWbT7VP20uaJvbTKGvI6DSM0YELITD x29ISy259jTZAqpz5L0mAcxpsAEDAxTnY+fYkcntFUBYPpLkIdNYcA15Qv3IxakERSw6 HWqiPqH2d5sl2KQv5ChFFXeuGgYxW2X9mqXq6CzYw0r3I7QOg8qls6Ua30GdgZWFWm4b xIIecbfyc8eYO9m+4YTDAgEOjimge38waSLWFRocNP13p9k52J+NHRoE+QyBBXnZ7cYW dfhQ==
MIME-Version: 1.0
X-Received: by 10.112.100.103 with SMTP id ex7mr6050476lbb.80.1361214183835; Mon, 18 Feb 2013 11:03:03 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.112.76.98 with HTTP; Mon, 18 Feb 2013 11:03:03 -0800 (PST)
In-Reply-To: <37B4C89F-2864-4317-BF87-F562241C176D@ve7jtb.com>
References: <51212E78.1050206@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DC1C@TK5EX14MBXC284.redmond.corp.microsoft.com> <51214AC5.3090807@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DE40@TK5EX14MBXC284.redmond.corp.microsoft.com>  <37B4C89F-2864-4317-BF87-F562241C176D@ve7jtb.com>
Date: Mon, 18 Feb 2013 14:03:03 -0500
X-Google-Sender-Auth: a1eVR0NSfLo9YgiRavJqatoK7Q0
Message-ID: 
From: Barry Leiba 
To: John Bradley 
Content-Type: multipart/alternative; boundary=f46d04016b05e408eb04d6045fcd
Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] oauth assertions plan
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Feb 2013 19:03:06 -0000

--f46d04016b05e408eb04d6045fcd
Content-Type: text/plain; charset=ISO-8859-1

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

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

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

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

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

We do agree on that; cool.

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

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

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

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

Barry

--f46d04016b05e408eb04d6045fcd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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

No, and I'm sorry if it came acr=
oss that way. =A0I mentioned the token-type issue only by way of background=
. =A0As it happens, I do think it was a mistake to publish the oauth framew=
ork spec without a mechanism for discovery/negotiation/communication of tok=
en types, but I'm not holding that against this document at all.
=A0
In OpenID Connect we implemented a discovery and registration la=
yer for clients to discover what the Authorization server supports.

Great! =A0I think that each use of t=
he protocol shouldn't have to roll this on its own, but it's good t=
hat=A0OIDC did it.
=A0

To acceve real interoperability th=
ese things need to be profiled or you need a negotiation mechanism.

We do agree on that; cool.
=A0
Are you saying that Assertions needs a low level mechanism to ne=
gotiate capabilities? =A0=A0
Many will argue that specs at a higher level like like Dynamic Client =
Registration=A0https://datatracker.ietf.org/doc/draft-ietf-oa=
uth-dyn-reg/ are better places to address these capability negotiations=
 because as you point out there is more to be negotiated than just assertio=
ns.

I would be happy to have it done tha=
t way, but then I think that needs to happen first, and this needs to refer=
 to that (normatively) as the (or a) mechanism that helps this interoperate=
.
=A0
It has been stated by one of the WG chairs that some =
of us are anti interoperability, so some of us may be a touch sensitive, ar=
ound this, as it is not the case.

Yeh, we very much need to keep that =
kind of rhetoric and questioning of motives out of the discussion. =A0You w=
on't hear it from me, certainly. =A0Quite the opposite: I'm quite c=
onfident that we all share the goal of developing good specs from which int=
eroperable implementations can be built. =A0It's not a question of anti=
-anything, but of disagreement about how to accomplish that.

Barry

--f46d04016b05e408eb04d6045fcd--

From barryleiba@gmail.com  Mon Feb 18 11:09:53 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27EF721F8AED for ; Mon, 18 Feb 2013 11:09:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.933
X-Spam-Level: 
X-Spam-Status: No, score=-102.933 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ELKdhg2L4JW for ; Mon, 18 Feb 2013 11:09:52 -0800 (PST)
Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by ietfa.amsl.com (Postfix) with ESMTP id BC37821F8B07 for ; Mon, 18 Feb 2013 11:09:51 -0800 (PST)
Received: by mail-lb0-f180.google.com with SMTP id q12so4459341lbc.39 for ; Mon, 18 Feb 2013 11:09:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=n24yvjEZaDiag62uo78VdOmIdwTPqLnQtpAS2YsmNrc=; b=iw9QKjAoyvGC07n8BszH5hSRgydm15VhfclJNws7ifxwt4wJ5kq+uqkCIwfIOEVQeA JD6iq0JiJZmnYBCcHs3D0jv5/yCsTUAnupSgtUDc1FjjFmaHNKcnnWS25RVuzJkb2vGV on1UuzAkozT8wzJNxD53Gk7KYEPyfZNi5F8NhiXIbN5CjMh7vCb+wJfnR8I4seJFWPYG 6N7+zogDnjI5Z9zaRrjJ/KG6VtXuZg2kw/b8hsxT3dR6JAgqJ0n2HX4Prbu5FTjAfqc2 mXBiqUFZagGYdfdZwbex/4s/lQFb6h1KURAxhA1el7lWZqlyvK9dzETthVc74KtLSeND Bn+A==
MIME-Version: 1.0
X-Received: by 10.152.111.67 with SMTP id ig3mr4851811lab.41.1361214590617; Mon, 18 Feb 2013 11:09:50 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.112.76.98 with HTTP; Mon, 18 Feb 2013 11:09:50 -0800 (PST)
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436747063A@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <51212E78.1050206@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DC1C@TK5EX14MBXC284.redmond.corp.microsoft.com> <51214AC5.3090807@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DE40@TK5EX14MBXC284.redmond.corp.microsoft.com>  <4E1F6AAD24975D4BA5B16804296739436747042A@TK5EX14MBXC284.redmond.corp.microsoft.com>  <4E1F6AAD24975D4BA5B16804296739436747063A@TK5EX14MBXC284.redmond.corp.microsoft.com>
Date: Mon, 18 Feb 2013 14:09:50 -0500
X-Google-Sender-Auth: 2UMhM8WNv8s0xcAqxOmT-Ph40HQ
Message-ID: 
From: Barry Leiba 
To: Mike Jones 
Content-Type: multipart/alternative; boundary=f46d04088f172306c904d6047856
Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] oauth assertions plan
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Feb 2013 19:09:53 -0000

--f46d04088f172306c904d6047856
Content-Type: text/plain; charset=ISO-8859-1

>
> "Dynamically declaring," in what sense?  Where are those mechanisms
> documented?****
>
> ** **
>
> Many of them are documented in draft-ietf-oauth-dyn-reg.****
>
> ** **
>
> One profile (an outer doll J) that enables fully interoperable
> implementations is documented in draft-hardjono-oauth-umacore.
>
> ...

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

So maybe that's one way through this.

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

Barry

--f46d04088f172306c904d6047856
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

"Dynamic=
ally declaring," in what sense? =A0Where are those mechanisms document=
ed?

=A0<=
/p>
Many of them are document=
ed in draft-ietf-oauth-dyn-reg.
=A0<=
/p>
One profile (an outer dol=
l
J) that enables fully interoperable impl=
ementations is documented in draft-hardjono-oauth-umacore.=A0

...

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

It's possible, then, that this isn't an issue of major changes=
 needed in this document, but one of document ordering. =A0It's possibl=
e (I'm still not sure, but maybe) that if some of these other documents=
 came out before or at the same time as this one, they would all fit togeth=
er and all would be clear.

So maybe that's one way through this.
In the end, all I'm saying is that if I hear that everyone =
is using oauth to peel bananas, and I want put my banana-peeling applicatio=
n on the market by adding oauth to it, I need to be able to read a set of s=
pecs that say how to do that, and that's all. =A0And if I do that, my a=
pplication will work when it's slotted into any oauth-based banana-peel=
ing system.

Barry=A0

--f46d04088f172306c904d6047856--

From bcampbell@pingidentity.com  Mon Feb 18 11:34:47 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7031421F8BBB for ; Mon, 18 Feb 2013 11:34:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.976
X-Spam-Level: 
X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3tehCKWSWYr for ; Mon, 18 Feb 2013 11:34:46 -0800 (PST)
Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by ietfa.amsl.com (Postfix) with ESMTP id DE4D921F8B26 for ; Mon, 18 Feb 2013 11:34:45 -0800 (PST)
Received: from mail-we0-f199.google.com ([74.125.82.199]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKUSKCVPYDtk8PVHddIwRW9P5+cPHY4DI/@postini.com; Mon, 18 Feb 2013 11:34:46 PST
Received: by mail-we0-f199.google.com with SMTP id t11so7107231wey.6 for ; Mon, 18 Feb 2013 11:34:43 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=A6Vc2krnQoSB0DKUG3m0bcDLGGf5oRVHHBX257IBIl0=; b=d3iwh9c7VQxYzqTTVa/8ex7AxjyzbAlEmqv8InZIywcq6Mgp/9wFG/NhHMPMPJ1oDo v7JtX19W4WcH5IWOGtVACKisB3a9rznZL59m0/W2ZCRP5pIPCkulLtNlUOcmob1rpPxq VxnlYpGXq1SQ0W0jdIZG2zfM63FuLwK13OXuDKIQJ8N2Do+UytKgAcvSuesZtCD7Wisb IZDDEilbRGLLZwUwxckwP/BUQPWtaCRAlm17TNSiAFiSF+VpdOcFE6OWc7nLV43B6nss Mi9sk+aoQWtIyFXNMTSPUNt5PhkIbrYH4KlU01bNU6YnXuye73IyyyAkvtCq5Qy48g6V vTbg==
X-Received: by 10.14.183.198 with SMTP id q46mr48416221eem.1.1361216083281; Mon, 18 Feb 2013 11:34:43 -0800 (PST)
X-Received: by 10.14.183.198 with SMTP id q46mr48416190eem.1.1361216083122; Mon, 18 Feb 2013 11:34:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.14.173.9 with HTTP; Mon, 18 Feb 2013 11:34:13 -0800 (PST)
In-Reply-To: 
References: <51212E78.1050206@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DC1C@TK5EX14MBXC284.redmond.corp.microsoft.com> <51214AC5.3090807@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DE40@TK5EX14MBXC284.redmond.corp.microsoft.com>  <4E1F6AAD24975D4BA5B16804296739436747042A@TK5EX14MBXC284.redmond.corp.microsoft.com>  <4E1F6AAD24975D4BA5B16804296739436747063A@TK5EX14MBXC284.redmond.corp.microsoft.com> 
From: Brian Campbell 
Date: Mon, 18 Feb 2013 12:34:13 -0700
Message-ID: 
To: Barry Leiba 
Content-Type: multipart/alternative; boundary=047d7b34414218d91a04d604d1f5
X-Gm-Message-State: ALoCoQlsWZXYLq38CxhYN2LytnfusmX6us5kP1p2+nGH3+lMORBwt4WD1vkPDaro1f1eWBsDv4gbOEoKC3f13jROLPbHrUshc0uVMZqePxYNsK9w6QVvi6nk4wrykKPnlHxvbAGYyvro
Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] oauth assertions plan
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Feb 2013 19:34:47 -0000

--047d7b34414218d91a04d604d1f5
Content-Type: text/plain; charset=ISO-8859-1

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

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

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

On Mon, Feb 18, 2013 at 12:09 PM, Barry Leiba wrote:

> "Dynamically declaring," in what sense?  Where are those mechanisms
>> documented?****
>>
>> ** **
>>
>> Many of them are documented in draft-ietf-oauth-dyn-reg.****
>>
>> ** **
>>
>> One profile (an outer doll J) that enables fully interoperable
>> implementations is documented in draft-hardjono-oauth-umacore.
>>
>> ...
>
>>  Another related profile that enables fully interoperable
>> implementations is documented in
>> http://openid.net/specs/openid-connect-messages-1_0.html.
>>
>>
> It's possible, then, that this isn't an issue of major changes needed in
> this document, but one of document ordering.  It's possible (I'm still not
> sure, but maybe) that if some of these other documents came out before or
> at the same time as this one, they would all fit together and all would be
> clear.
>
> So maybe that's one way through this.
>
> In the end, all I'm saying is that if I hear that everyone is using oauth
> to peel bananas, and I want put my banana-peeling application on the market
> by adding oauth to it, I need to be able to read a set of specs that say
> how to do that, and that's all.  And if I do that, my application will work
> when it's slotted into any oauth-based banana-peeling system.
>
> Barry
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--047d7b34414218d91a04d604d1f5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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

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

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

On Mon,=
 Feb 18, 2013 at 12:09 PM, Barry Leiba <barryleiba@computer.org&=
gt; wrote:

"Dynamically de=
claring," in what sense? =A0Where are those mechanisms documented?<=
/u>

=A0<=
/p>
Many of them are document=
ed in draft-ietf-oauth-dyn-reg.
=A0<=
/p>
One profile (an outer dol=
l
J) that enables fully interoperable impl=
ementations is documented in draft-hardjono-oauth-umacore.=A0

...
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">

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

It's possible, then, that this isn't an issue of major c=
hanges needed in this document, but one of document ordering. =A0It's p=
ossible (I'm still not sure, but maybe) that if some of these other doc=
uments came out before or at the same time as this one, they would all fit =
together and all would be clear.

So maybe that's one way through this.
In the end, all I'm saying is that if I hear that everyone =
is using oauth to peel bananas, and I want put my banana-peeling applicatio=
n on the market by adding oauth to it, I need to be able to read a set of s=
pecs that say how to do that, and that's all. =A0And if I do that, my a=
pplication will work when it's slotted into any oauth-based banana-peel=
ing system.

Barry=A0

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

--047d7b34414218d91a04d604d1f5--

From torsten@lodderstedt.net  Mon Feb 18 12:05:00 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1658221F8835 for ; Mon, 18 Feb 2013 12:05:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.242
X-Spam-Level: 
X-Spam-Status: No, score=-1.242 tagged_above=-999 required=5 tests=[AWL=1.008,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MT8adBd0gPuK for ; Mon, 18 Feb 2013 12:04:59 -0800 (PST)
Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.104]) by ietfa.amsl.com (Postfix) with ESMTP id 2591B21F87B6 for ; Mon, 18 Feb 2013 12:04:58 -0800 (PST)
Received: from [80.187.107.137] (helo=[100.93.203.64]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1U7WxM-0003lF-HD; Mon, 18 Feb 2013 21:04:56 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: 
References: <20130215215423.23019.50224.idtracker@ietfa.amsl.com>  <5120B6EE.60801@lodderstedt.net> <51223B5A.5050008@mitre.org> 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Torsten Lodderstedt 
Date: Mon, 18 Feb 2013 21:04:53 +0100
To: John Bradley ,Justin Richer 
Message-ID: <711590de-79f4-4054-a379-f74e78d144b2@email.android.com>
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: "" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Feb 2013 20:05:00 -0000

>or non-existent. Note that for security reasons, to inhibit brute force
>attacks, endpoints MUST NOT return 404 Not Found error codes.
>
>From a security point of view differentiating the two is bad as it
>helps an attacker find valid notes to brute force.  Ideally you want an
>attacker to spend time truing to break into resources that don't exist
>as well as ones that do.

Good point!

From ve7jtb@ve7jtb.com  Mon Feb 18 12:55:38 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCDA21F886C for ; Mon, 18 Feb 2013 12:55:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.412
X-Spam-Level: 
X-Spam-Status: No, score=-4.412 tagged_above=-999 required=5 tests=[AWL=1.186,  BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZZMJQwQGPXT for ; Mon, 18 Feb 2013 12:55:36 -0800 (PST)
Received: from mail-qe0-f41.google.com (mail-qe0-f41.google.com [209.85.128.41]) by ietfa.amsl.com (Postfix) with ESMTP id 90C4221F8812 for ; Mon, 18 Feb 2013 12:55:36 -0800 (PST)
Received: by mail-qe0-f41.google.com with SMTP id 7so2727867qeb.28 for ; Mon, 18 Feb 2013 12:55:32 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=uemAQlhzsRvhBHZDGP9M7ELfyQJ4t7yrlNe5+LhTxng=; b=jSyMfyKfijaVYfhXiKX3o/1yAWWyg2NfXlrG80y+sUWIpIYNAeo8zyH4YpRhhIHZtI hbQAFhnY2J2BtaaPFvYwiTlQ/uWz54YRkqrhO960KR7muTzyKNBfQpxUQ5R6OfAIyMDE lrUUVUhyk1SZ4gzKFqFHN/GHTkQKSsKfNYglqHRY7QNvDvVB56jAZpGvEs+PZtz+iNEI MtApdK7+BMsK/FJUL27QA0ejObPLxn+/VXik4cxC0Rdmckt1FYXtH0pZPkND9839sKni lEB/2OkR7VCEXIWpOr1Wt8O6GKA+x6BVAxllKVSLEaX+P5CxiLnVXmljjO+I2MbBsjcF jqgg==
X-Received: by 10.224.96.4 with SMTP id f4mr6119250qan.79.1361220932289; Mon, 18 Feb 2013 12:55:32 -0800 (PST)
Received: from [192.168.1.213] (190-20-56-120.baf.movistar.cl. [190.20.56.120]) by mx.google.com with ESMTPS id s6sm6557103qaz.13.2013.02.18.12.55.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Feb 2013 12:55:30 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_87A58D0C-AD37-4D06-9F57-8423414E3B61"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: 
Date: Mon, 18 Feb 2013 17:54:40 -0300
Message-Id: <87A4BE12-AC72-4E35-A95F-E6F161CF170B@ve7jtb.com>
References: <51212E78.1050206@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DC1C@TK5EX14MBXC284.redmond.corp.microsoft.com> <51214AC5.3090807@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DE40@TK5EX14MBXC284.redmond.corp.microsoft.com>  <37B4C89F-2864-4317-BF87-F562241C176D@ve7jtb.com> 
To: Barry Leiba 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQm7l5ywQ/lU+KLp9HNq1p2Vy72nyDR5kxX8xj+qF9L4ZJnY/s515FBikj2FhheqGCRChTzJ
Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] oauth assertions plan
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Feb 2013 20:55:38 -0000

--Apple-Mail=_87A58D0C-AD37-4D06-9F57-8423414E3B61
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_99BBEE36-0B72-4353-80DD-73DCBC9418E3"

--Apple-Mail=_99BBEE36-0B72-4353-80DD-73DCBC9418E3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Thanks Barry,

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

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

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

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

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

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

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

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

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

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

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

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

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

I look forward to the discussion.

John B.

On 2013-02-18, at 4:03 PM, Barry Leiba  wrote:

> It seems like the scope of your criticism has more to do with RFC 6749 =
& RFC 6750 overall, than the assertions drafts themselves.
>=20
> No, and I'm sorry if it came across that way.  I mentioned the =
token-type issue only by way of background.  As it happens, I do think =
it was a mistake to publish the oauth framework spec without a mechanism =
for discovery/negotiation/communication of token types, but I'm not =
holding that against this document at all.
> =20
> In OpenID Connect we implemented a discovery and registration layer =
for clients to discover what the Authorization server supports.
>=20
> Great!  I think that each use of the protocol shouldn't have to roll =
this on its own, but it's good that OIDC did it.
> =20
> To acceve real interoperability these things need to be profiled or =
you need a negotiation mechanism.
>=20
> We do agree on that; cool.
> =20
> Are you saying that Assertions needs a low level mechanism to =
negotiate capabilities?  =20
> Many will argue that specs at a higher level like like Dynamic Client =
Registration https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/ =
are better places to address these capability negotiations because as =
you point out there is more to be negotiated than just assertions.
>=20
> I would be happy to have it done that way, but then I think that needs =
to happen first, and this needs to refer to that (normatively) as the =
(or a) mechanism that helps this interoperate.
> =20
> It has been stated by one of the WG chairs that some of us are anti =
interoperability, so some of us may be a touch sensitive, around this, =
as it is not the case.
>=20
> Yeh, we very much need to keep that kind of rhetoric and questioning =
of motives out of the discussion.  You won't hear it from me, certainly. =
 Quite the opposite: I'm quite confident that we all share the goal of =
developing good specs from which interoperable implementations can be =
built.  It's not a question of anti-anything, but of disagreement about =
how to accomplish that.
>=20
> Barry
>=20

--Apple-Mail=_99BBEE36-0B72-4353-80DD-73DCBC9418E3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-re=
g/ based on implementation experience to produce a common way =
to do it.
I don't think this is the first spec =
to develop that way.

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

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

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

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

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

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

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

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

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

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

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

I look forward to the =
discussion.

John =
B.

On 2013-02-18, at 4:03 PM, =
Barry Leiba <barryleiba@computer.org> =
wrote:

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

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

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

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

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

We do agree on =
that; cool.

Are you saying =
that Assertions needs a low level mechanism to negotiate capabilities? =

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

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

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

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

Barry

=

--Apple-Mail=_99BBEE36-0B72-4353-80DD-73DCBC9418E3--

--Apple-Mail=_87A58D0C-AD37-4D06-9F57-8423414E3B61
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMjE4MjA1NDU2WjAjBgkqhkiG9w0BCQQxFgQUB/cLscA6
zGNmFzx7hJ8cTjTxRZUwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAkalOXpMD6SLOWaBiKfGiRZ43Jsk4arZQgmgCE/zY
b34L1jUbk9cJgqOdH7l+1H7DrWHlIrwO7spl7IdECpsvWfTH5uacCS+QGEtlOgqzEkesona7mR/H
axtJUJ4i6YX6wBkpvIHUr78Dm09PNl10RpzrUWYmlSuXeR1ym4Z6hOW5wXe/LuyoCdHliHIUozzV
/EBpb2hCbXYq1xGlBq0VVbe6WJFCQg6tfK78ZqA2j9zVknrfVMdQI5xVfw0ikejevqLF+Y56OMV5
yfwCngsdB97K6iHCzoDB9Z5xr/E0zkhzonC89o15NuOt0QRDDJRTMGb5HBv27+rR6F8GmMXVjAAA
AAAAAA==

--Apple-Mail=_87A58D0C-AD37-4D06-9F57-8423414E3B61--

From Adam.Lewis@motorolasolutions.com  Mon Feb 18 14:51:40 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBEA121E804C for ; Mon, 18 Feb 2013 14:51:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.766
X-Spam-Level: 
X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=0.700,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIQOxhoDgdMW for ; Mon, 18 Feb 2013 14:51:32 -0800 (PST)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8824721E8039 for ; Mon, 18 Feb 2013 14:51:32 -0800 (PST)
Received: from mail95-co9-R.bigfish.com (10.236.132.227) by CO9EHSOBE042.bigfish.com (10.236.130.105) with Microsoft SMTP Server id 14.1.225.23; Mon, 18 Feb 2013 22:51:25 +0000
Received: from mail95-co9 (localhost [127.0.0.1])	by mail95-co9-R.bigfish.com (Postfix) with ESMTP id 64EB98C01F9	for ; Mon, 18 Feb 2013 22:51:25 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:192.160.210.14; KIP:(null); UIP:(null); IPV:NLI; H:ct11msg02.am.mot-solutions.com; RD:ct11msg02.mot-solutions.com; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz17326ah8275bh8275dh18c673hz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1155h)
Received-SPF: pass (mail95-co9: domain of motorolasolutions.com designates 192.160.210.14 as permitted sender) client-ip=192.160.210.14; envelope-from=Adam.Lewis@motorolasolutions.com; helo=ct11msg02.am.mot-solutions.com ; olutions.com ; 
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.237.133; KIP:(null); UIP:(null); (null); H:BY2PRD0411HT002.namprd04.prod.outlook.com; R:internal; EFV:INT
Received: from mail95-co9 (localhost.localdomain [127.0.0.1]) by mail95-co9 (MessageSwitch) id 1361227865401562_1751; Mon, 18 Feb 2013 22:51:05 +0000 (UTC)
Received: from CO9EHSMHS003.bigfish.com (unknown [10.236.132.227])	by mail95-co9.bigfish.com (Postfix) with ESMTP id 5E43ACA0057	for ; Mon, 18 Feb 2013 22:51:05 +0000 (UTC)
Received: from ct11msg02.am.mot-solutions.com (192.160.210.14) by CO9EHSMHS003.bigfish.com (10.236.130.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 18 Feb 2013 22:51:04 +0000
Received: from ct11msg02.am.mot-solutions.com (ct11vts02.am.mot.com [10.177.16.160])	by ct11msg02.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r1IN0jtD014695	for ; Mon, 18 Feb 2013 18:00:45 -0500 (EST)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183])	by ct11msg02.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r1IN0iLu014692 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL)	for ; Mon, 18 Feb 2013 18:00:44 -0500 (EST)
Received: from mail10-ch1-R.bigfish.com (10.43.68.225) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.23; Mon, 18 Feb 2013 22:51:02 +0000
Received: from mail10-ch1 (localhost [127.0.0.1])	by mail10-ch1-R.bigfish.com (Postfix) with ESMTP id AD4E62200AF	for ; Mon, 18 Feb 2013 22:51:02 +0000 (UTC)
Received: from mail10-ch1 (localhost.localdomain [127.0.0.1]) by mail10-ch1 (MessageSwitch) id 1361227834513255_24973; Mon, 18 Feb 2013 22:50:34 +0000 (UTC)
Received: from CH1EHSMHS026.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.227])	by mail10-ch1.bigfish.com (Postfix) with ESMTP id 7AB0F1003CA for ; Mon, 18 Feb 2013 22:50:34 +0000 (UTC)
Received: from BY2PRD0411HT002.namprd04.prod.outlook.com (157.56.237.133) by CH1EHSMHS026.bigfish.com (10.43.70.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 18 Feb 2013 22:50:29 +0000
Received: from BY2PRD0411MB441.namprd04.prod.outlook.com ([169.254.5.136]) by BY2PRD0411HT002.namprd04.prod.outlook.com ([10.255.128.37]) with mapi id 14.16.0263.000; Mon, 18 Feb 2013 22:50:28 +0000
From: Lewis Adam-CAL022 
To: "oauth@ietf.org WG" 
Thread-Topic: JWT grant_type and client_id
Thread-Index: Ac4OKlgNygAJgL9ySFC/PJajtkIVLA==
Date: Mon, 18 Feb 2013 22:50:27 +0000
Message-ID: <59E470B10C4630419ED717AC79FCF9A948D552B8@BY2PRD0411MB441.namprd04.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [150.130.138.231]
Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A948D552B8BY2PRD0411MB441_"
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn%
X-CFilter-Loop: Reflected
X-OriginatorOrg: motorolasolutions.com
Subject: [OAUTH-WG] JWT grant_type and client_id
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Feb 2013 22:51:43 -0000

--_000_59E470B10C4630419ED717AC79FCF9A948D552B8BY2PRD0411MB441_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Is there any guidance on the usage of client_id when using the JWT assertio=
n profile as a grant type?  draft-ietf-oauth-jwt-bearer-04 makes no mention=
 so I assume that it is not required ... but it would be necessary if using=
 in conjunction with a HOK profile where the JWT assertion is issued to - a=
nd may only be used by - the intended client.  Obviously this is straight f=
orward enough, really I'm just looking to be sure that I'm not missing anyt=
hing.

tx
adam

--_000_59E470B10C4630419ED717AC79FCF9A948D552B8BY2PRD0411MB441_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Is there any guidance on the usage of c=
lient_id when using the JWT assertion profile as a grant type?  draft-=
ietf-oauth-jwt-bearer-04 makes no mention so I assume that it
 is not required … but it would be necessary if using in conjunction =
with a HOK profile where the JWT assertion is issued to – and may onl=
y be used by – the intended client.  Obviously this is straight =
forward enough, really I’m just looking to be sure that
 I’m not missing anything.

tx
adam

--_000_59E470B10C4630419ED717AC79FCF9A948D552B8BY2PRD0411MB441_--

From Michael.Jones@microsoft.com  Mon Feb 18 16:58:32 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4EB21E8051 for ; Mon, 18 Feb 2013 16:58:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.581
X-Spam-Level: 
X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.017,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJsE19WOme-T for ; Mon, 18 Feb 2013 16:58:30 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.26]) by ietfa.amsl.com (Postfix) with ESMTP id E2FFC21E8045 for ; Mon, 18 Feb 2013 16:58:30 -0800 (PST)
Received: from BY2FFO11FD011.protection.gbl (10.1.15.204) by BY2FFO11HUB027.protection.gbl (10.1.14.113) with Microsoft SMTP Server (TLS) id 15.0.620.12; Tue, 19 Feb 2013 00:58:29 +0000
Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD011.mail.protection.outlook.com (10.1.14.129) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Tue, 19 Feb 2013 00:58:28 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.96]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Tue, 19 Feb 2013 00:58:02 +0000
From: Mike Jones 
To: Lewis Adam-CAL022 , "oauth@ietf.org WG" 
Thread-Topic: JWT grant_type and client_id
Thread-Index: Ac4OKlgNygAJgL9ySFC/PJajtkIVLAAEbxLQ
Date: Tue, 19 Feb 2013 00:58:02 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394367472284@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <59E470B10C4630419ED717AC79FCF9A948D552B8@BY2PRD0411MB441.namprd04.prod.outlook.com>
In-Reply-To: <59E470B10C4630419ED717AC79FCF9A948D552B8@BY2PRD0411MB441.namprd04.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.75]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367472284TK5EX14MBXC284r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(199002)(189002)(56776001)(63696002)(54316002)(46102001)(31966008)(76482001)(56816002)(20776003)(47736001)(51856001)(16236675001)(47976001)(50986001)(4396001)(44976002)(74662001)(49866001)(512954001)(33656001)(16406001)(5343635001)(54356001)(74502001)(65816001)(15202345001)(5343655001)(79102001)(53806001)(47446002)(77982001)(59766001)(80022001)(55846006)(66066001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB027; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0762FFD075
Subject: Re: [OAUTH-WG] JWT grant_type and client_id
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Feb 2013 00:58:32 -0000

--_000_4E1F6AAD24975D4BA5B168042967394367472284TK5EX14MBXC284r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The client_id value and the access token value are independent.

                                                                -- Mike

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of L=
ewis Adam-CAL022
Sent: Monday, February 18, 2013 2:50 PM
To: oauth@ietf.org WG
Subject: [OAUTH-WG] JWT grant_type and client_id

Is there any guidance on the usage of client_id when using the JWT assertio=
n profile as a grant type?  draft-ietf-oauth-jwt-bearer-04 makes no mention=
 so I assume that it is not required ... but it would be necessary if using=
 in conjunction with a HOK profile where the JWT assertion is issued to - a=
nd may only be used by - the intended client.  Obviously this is straight f=
orward enough, really I'm just looking to be sure that I'm not missing anyt=
hing.

tx
adam

--_000_4E1F6AAD24975D4BA5B168042967394367472284TK5EX14MBXC284r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The client_id value an=
d the access token value are independent.

   &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;          -- Mike=

From: oauth-bo=
unces@ietf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Lewis Adam-CAL022

Sent: Monday, February 18, 2013 2:50 PM

To: oauth@ietf.org WG

Subject: [OAUTH-WG] JWT grant_type and client_id

Is there any guidance on the usage of c=
lient_id when using the JWT assertion profile as a grant type?  draft-=
ietf-oauth-jwt-bearer-04 makes no mention so I assume that it
 is not required … but it would be necessary if using in conjunction =
with a HOK profile where the JWT assertion is issued to – and may onl=
y be used by – the intended client.  Obviously this is straight =
forward enough, really I’m just looking to be sure that
 I’m not missing anything.

tx
adam

--_000_4E1F6AAD24975D4BA5B168042967394367472284TK5EX14MBXC284r_--

From sm@resistor.net  Mon Feb 18 23:25:05 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0164421F8D02 for ; Mon, 18 Feb 2013 23:25:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.577
X-Spam-Level: 
X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Sig+9F3TusI for ; Mon, 18 Feb 2013 23:25:03 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B828621F8CFB for ; Mon, 18 Feb 2013 23:25:03 -0800 (PST)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r1J7Ovm3006861; Mon, 18 Feb 2013 23:25:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1361258702; bh=dfgtV+eHlCT1lZdp21sWvE/K+EEu5jqZAC/zBao2uYs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=QojHLTBHoBvYIl2OB3Fw/1bLQbnDNl35XS1CHnM0wyl98mPGNoZDSpYfhZDbJgiCH NX+cAeUx+SZ9nTDQYfNiaw5KR6gP5tXnqTExArwrMPd3CGdpNLKCO3Tqkan7R7t3cL TdnbBJxa/7CDIQfy9R49/pYIlHgBOOYTV5rbMDUA=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1361258702; i=@resistor.net; bh=dfgtV+eHlCT1lZdp21sWvE/K+EEu5jqZAC/zBao2uYs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=VjIKq1p5S042nD9hAFzacUVhydxFpqVQBaoekXJS/QdBUWnagTTzV3temdCbemkAt 0JXQUMV0li+sRTW6Y9KIwazoibOTVpR/hYgX7g89PbDEr9ekTmmUIU5KNzLMAyoIHp 00fdCm+iH9wbPhbkjaI2jPMnc/ROG6Kao/0L1UjA=
Message-Id: <6.2.5.6.2.20130218225317.09ae39d8@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 18 Feb 2013 23:22:50 -0800
To: John Bradley 
From: SM 
In-Reply-To: <87A4BE12-AC72-4E35-A95F-E6F161CF170B@ve7jtb.com>
References: <51212E78.1050206@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DC1C@TK5EX14MBXC284.redmond.corp.microsoft.com> <51214AC5.3090807@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DE40@TK5EX14MBXC284.redmond.corp.microsoft.com>  <37B4C89F-2864-4317-BF87-F562241C176D@ve7jtb.com>  <87A4BE12-AC72-4E35-A95F-E6F161CF170B@ve7jtb.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: oauth@ietf.org
Subject: [OAUTH-WG] Mandatory to implement (was: oauth assertions plan)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Feb 2013 07:25:05 -0000

Hi John,
At 12:54 18-02-2013, John Bradley wrote:
>That is where we get into the area Stephen Farrell has been raising 
>about MTI not being required to deploy.

The topic of mandatory to implement has been discussed previously in 
the working group.
Stephen Farrell explained [1] what it meant.  Barry Leiba explained 
what it meant.

In my humble opinion a mandatory to implement feature is about having 
the code for the feature.  If the code is out there it is easier to 
get what you want.

Regards,
-sm 

From sberyozkin@gmail.com  Tue Feb 19 05:54:34 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB5221F8CF4 for ; Tue, 19 Feb 2013 05:54:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.457
X-Spam-Level: 
X-Spam-Status: No, score=-3.457 tagged_above=-999 required=5 tests=[AWL=0.142,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpuBwv7TX2Sx for ; Tue, 19 Feb 2013 05:54:31 -0800 (PST)
Received: from mail-ea0-f174.google.com (mail-ea0-f174.google.com [209.85.215.174]) by ietfa.amsl.com (Postfix) with ESMTP id 3D30821F88EA for ; Tue, 19 Feb 2013 05:54:28 -0800 (PST)
Received: by mail-ea0-f174.google.com with SMTP id 1so2827647eaa.33 for ; Tue, 19 Feb 2013 05:54:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=o2GpcFH2A80yleovpaqwWMRtHQmhHKDlgsHsmtYIKnk=; b=SofyOivkzS9to5rY6xdLUgK4RbtfnfJloaZvIweCahv2irU4D1BMxerZNj39G/bFIM 4xL5Ik8kcyNb7oit0VQPOesf+QWlDxlWAO036/2lcf9apsBXXE0CUPuLIqR6v0BZmZWa 1I7fl92TQIvRPhrYshtX2Qlu/INCITdXTtX4cE1Z54AP09tj5Ju4+PKxWPcG5OQFqqPM IYhchvsQWeWGGZaS0WLJcSEfOEssH0Pm0V9KGxHxZgTF0IQUD2bhM0IO6OQMMTGc1W/c zBX7NWdpRTWGVkLo/EDs7NUTUTYRJw0tNoBIBGb5NFz+lKAROxoP3qA3R85n9+c8kkju d6ug==
X-Received: by 10.14.210.8 with SMTP id t8mr57236385eeo.35.1361282067184; Tue, 19 Feb 2013 05:54:27 -0800 (PST)
Received: from [10.36.226.5] ([217.173.99.61]) by mx.google.com with ESMTPS id q42sm94827425eem.14.2013.02.19.05.54.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Feb 2013 05:54:26 -0800 (PST)
Message-ID: <51238410.8040705@gmail.com>
Date: Tue, 19 Feb 2013 13:54:24 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: "" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [OAUTH-WG] Using SAML2 Bearer for the authentication
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Feb 2013 13:54:34 -0000

Hi,

Assertions like SAML2 Bearer can be used for authenticating the client.
Why a dedicated Authorization scheme can not be introduced, instead of 
or in addition to "client_assertion" & "client_assertion_type" parameters ?

IMHO, the following

Authorization: SAML "base64url-encoded assertion"

grant_type=authorization_code&code=123456

is more in line with OAuth2 recommending not to prefer including client 
id & secret in the body:

"Including the client credentials in the request-body using the two
parameters is NOT RECOMMENDED and SHOULD be limited to clients unable
to directly utilize the HTTP Basic authentication scheme (or other
password-based HTTP authentication schemes)" - though it talks about a 
password based scheme...

similarly:

Authorization: JWT "encoded jwt assertion"

grant_type=authorization_code&code=123456

Just a thought.

Cheers, Sergey

From bcampbell@pingidentity.com  Tue Feb 19 06:20:42 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5D021F8DAC for ; Tue, 19 Feb 2013 06:20:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.984
X-Spam-Level: 
X-Spam-Status: No, score=-5.984 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiTQY8XDLoM7 for ; Tue, 19 Feb 2013 06:20:41 -0800 (PST)
Received: from na3sys009aog112.obsmtp.com (na3sys009aog112.obsmtp.com [74.125.149.207]) by ietfa.amsl.com (Postfix) with ESMTP id 0A51021F87CD for ; Tue, 19 Feb 2013 06:20:40 -0800 (PST)
Received: from mail-ie0-f199.google.com ([209.85.223.199]) (using TLSv1) by na3sys009aob112.postini.com ([74.125.148.12]) with SMTP ID DSNKUSOKN0DMyIOdnGOSu34Ua1PJNgztVYU5@postini.com; Tue, 19 Feb 2013 06:20:41 PST
Received: by mail-ie0-f199.google.com with SMTP id c13so32741717ieb.6 for ; Tue, 19 Feb 2013 06:20:39 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=V9Vta2P282StoxrJjbX4lyoYc0K9xJmmUWn8joCAd10=; b=eulioQtnSZDWZqr/P88jqVd1jiil4X8WDX7r3dFZbAZvKitP28nBZ/3/sDl0nO2WvO JzvSuRDxSSpZGlplrkh1vPC6IbotHn8r1Ts6cFGrg0OPbmGmtRfTZuz2y/i+Jdt4t1IJ ufArnqrCsJzQ8YrKuixwbf1w5FDj+cMUHBEPVnWu61SGBx4gpqHdUxEOFafYdg48kpyM NsFDE+vIkCDpvlHRihEqFYm9/AF2vmkC6/nP9DsgLTNRWQCpI2po0eW/9xcg6CF+ohO4 nrEjyrfmueXmaejwXsfcvBJJSw+W87x/Gvr+TbL3G6Qd+NxcvQ3z17jeOtkn1mwir0iz W6TQ==
X-Received: by 10.50.184.226 with SMTP id ex2mr9677135igc.24.1361283639355; Tue, 19 Feb 2013 06:20:39 -0800 (PST)
X-Received: by 10.50.184.226 with SMTP id ex2mr9677128igc.24.1361283639230; Tue, 19 Feb 2013 06:20:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.63.3 with HTTP; Tue, 19 Feb 2013 06:20:09 -0800 (PST)
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367472284@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <59E470B10C4630419ED717AC79FCF9A948D552B8@BY2PRD0411MB441.namprd04.prod.outlook.com> <4E1F6AAD24975D4BA5B168042967394367472284@TK5EX14MBXC284.redmond.corp.microsoft.com>
From: Brian Campbell 
Date: Tue, 19 Feb 2013 07:20:09 -0700
Message-ID: 
To: Mike Jones 
Content-Type: multipart/alternative; boundary=14dae9340dadc1420704d6148b45
X-Gm-Message-State: ALoCoQmOQCenUih8BNrCx2D2NIJFZ4e3ZNcm7Jx0h29a9aZp5cNIVis/GWQOkownFwpPyDNKaZajRNJivc6Jsf9a/Hi6GSdUKMVqs2ishrdeVpCM/dY6pgFTb5Sq0TcdPD8U4ntNdS20
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] JWT grant_type and client_id
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Feb 2013 14:20:42 -0000

--14dae9340dadc1420704d6148b45
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Yeah, in general the client identification/authentication is independent
from the grant being presented. There may be policy (maybe unidentified
clients aren't allowed) or other protocol details (like some kind of HoK
bound to the client, though that doesn't exist yet) that dictate more
requirements on the client identifier.  But in the general case they are
independent and the client_id is not required.

On Mon, Feb 18, 2013 at 5:58 PM, Mike Jones wr=
ote:

>  The client_id value and the access token value are independent.****
>
> ** **
>
>                                                                 -- Mike**=
*
> *
>
> ** **
>
> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf
> Of *Lewis Adam-CAL022
> *Sent:* Monday, February 18, 2013 2:50 PM
> *To:* oauth@ietf.org WG
> *Subject:* [OAUTH-WG] JWT grant_type and client_id****
>
> ** **
>
> ** **
>
> Is there any guidance on the usage of client_id when using the JWT
> assertion profile as a grant type?  draft-ietf-oauth-jwt-bearer-04 makes =
no
> mention so I assume that it is not required =85 but it would be necessary=
 if
> using in conjunction with a HOK profile where the JWT assertion is issued
> to =96 and may only be used by =96 the intended client.  Obviously this i=
s
> straight forward enough, really I=92m just looking to be sure that I=92m =
not
> missing anything.****
>
> ** **
>
> tx****
>
> adam****
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--14dae9340dadc1420704d6148b45
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Yeah, in general the client identification/authentication =
is independent from the grant being presented. There may be policy (maybe u=
nidentified clients aren't allowed) or other protocol details (like som=
e kind of HoK bound to the client, though that doesn't exist yet) that =
dictate more requirements on the client identifier.=A0 But in the general c=
ase they are independent and the client_id is not required.

On Mon,=
 Feb 18, 2013 at 5:58 PM, Mike Jones <Michael.Jones@microsoft.co=
m> wrote:

The client_id value an=
d the access token value are independent.
=A0
=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0 -- Mike
=A0

From: oauth-bounces@ietf.org=
 [mailto:oa=
uth-bounces@ietf.org]
On Behalf Of Lewis Adam-CAL022

Sent: Monday, February 18, 2013 2:50 PM

To: oauth@ietf.o=
rg WG

Subject: [OAUTH-WG] JWT grant_type and client_id

=A0
=A0
Is there any guidance on the usage of c=
lient_id when using the JWT assertion profile as a grant type?=A0 draft-iet=
f-oauth-jwt-bearer-04 makes no mention so I assume that it
 is not required =85 but it would be necessary if using in conjunction with=
 a HOK profile where the JWT assertion is issued to =96 and may only be use=
d by =96 the intended client.=A0 Obviously this is straight forward enough,=
 really I=92m just looking to be sure that
 I=92m not missing anything.
=A0
tx
adam

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

--14dae9340dadc1420704d6148b45--

From bcampbell@pingidentity.com  Tue Feb 19 06:27:51 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F9F21F8A56 for ; Tue, 19 Feb 2013 06:27:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.15
X-Spam-Level: 
X-Spam-Status: No, score=-5.15 tagged_above=-999 required=5 tests=[AWL=-0.840,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oj42uZuXxG-w for ; Tue, 19 Feb 2013 06:27:51 -0800 (PST)
Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by ietfa.amsl.com (Postfix) with ESMTP id DFFBB21F89EF for ; Tue, 19 Feb 2013 06:27:50 -0800 (PST)
Received: from mail-oa0-f69.google.com ([209.85.219.69]) (using TLSv1) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKUSOL5q9VwH+G7bcxODiSIHKoi/6/PK9/@postini.com; Tue, 19 Feb 2013 06:27:50 PST
Received: by mail-oa0-f69.google.com with SMTP id k14so35220453oag.8 for ; Tue, 19 Feb 2013 06:27:50 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=gNqtpNVttBJc1TYkfSkS8VhukPbqB+IC4gATjXqrFEI=; b=ov9P9Fc0tHqmXnXhAD/f+A4pQP29AUCXk4j1gzjTETEBy3QfZLfu1pcw/oWBgZuGbJ nd7sjvV10ndjLorWP6e6NA3hFevISKKVgrZqDyf2Z5YYadvszqdkkvivK1Ip/WY46HVO b/ByBqu5JaQ+Ovdee7gMsBwFYjqylPI3tnRBBi4mYDJbUytkniZkeLa/ov2K9QR7XbTY sN2PD97tUe1MUguP4bSNkJWABWe4bQagGz1lkCxcJZmR5jNF/dVNucdZ7A/onHdcqz2X sVpPr36MAXXN9VRc0Zt2+SbL3fgvvhHVQEIl1CqbbtkNBrtgXFIQYgJPiThjgGws7O/l RmFg==
X-Received: by 10.50.193.129 with SMTP id ho1mr2641411igc.94.1361284070023; Tue, 19 Feb 2013 06:27:50 -0800 (PST)
X-Received: by 10.50.193.129 with SMTP id ho1mr2641406igc.94.1361284069885; Tue, 19 Feb 2013 06:27:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.63.3 with HTTP; Tue, 19 Feb 2013 06:27:19 -0800 (PST)
In-Reply-To: <51238410.8040705@gmail.com>
References: <51238410.8040705@gmail.com>
From: Brian Campbell 
Date: Tue, 19 Feb 2013 07:27:19 -0700
Message-ID: 
To: Sergey Beryozkin 
Content-Type: multipart/alternative; boundary=14dae93410896c855604d614a587
X-Gm-Message-State: ALoCoQlND9cUqmGZJs5GD/Plxql3JSqa6TNkgGAcwmJzjpDqjrJBY+TdyUj22NTmgtlO2OdhqKs8FOLIJ5d/zXPll64vP38neOFYTsoXoyP+XbxZ675dnZX/gmfkXJgIo9VgttCH3oR1
Cc: "" 
Subject: Re: [OAUTH-WG] Using SAML2 Bearer for the authentication
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Feb 2013 14:27:51 -0000

--14dae93410896c855604d614a587
Content-Type: text/plain; charset=ISO-8859-1

The scope of assertion based client authentication is only in OAuth and
only for the client calling the AS's token endpoint. Defining a general
HTTP auth scheme for assertions would have a much broader scope and be much
more difficult to standardize.

On Tue, Feb 19, 2013 at 6:54 AM, Sergey Beryozkin wrote:

> Hi,
>
> Assertions like SAML2 Bearer can be used for authenticating the client.
> Why a dedicated Authorization scheme can not be introduced, instead of or
> in addition to "client_assertion" & "client_assertion_type" parameters ?
>
> IMHO, the following
>
> Authorization: SAML "base64url-encoded assertion"
>
> grant_type=authorization_code&**code=123456
>
> is more in line with OAuth2 recommending not to prefer including client id
> & secret in the body:
>
> "Including the client credentials in the request-body using the two
> parameters is NOT RECOMMENDED and SHOULD be limited to clients unable
> to directly utilize the HTTP Basic authentication scheme (or other
> password-based HTTP authentication schemes)" - though it talks about a
> password based scheme...
>
> similarly:
>
> Authorization: JWT "encoded jwt assertion"
>
> grant_type=authorization_code&**code=123456
>
> Just a thought.
>
> Cheers, Sergey
>
>
> ______________________________**_________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/**listinfo/oauth
>

--14dae93410896c855604d614a587
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The scope of assertion based client authentication is=
 only in OAuth and only for the client calling the AS's token endpoint.=
 Defining a general HTTP auth scheme for assertions would have a much broad=
er scope and be much more difficult to standardize. 

O=
n Tue, Feb 19, 2013 at 6:54 AM, Sergey Beryozkin <sberyozkin@gmail.com<=
/a>> wrote:

Hi,

Assertions like SAML2 Bearer can be used for authenticating the client.

Why a dedicated Authorization scheme can not be introduced, instead of or i=
n addition to "client_assertion" & "client_assertion_typ=
e" parameters ?

IMHO, the following

Authorization: SAML "base64url-encoded assertion"

grant_type=3Dauthorization_code&code=3D123456

is more in line with OAuth2 recommending not to prefer including client id =
& secret in the body:

"Including the client credentials in the request-body using the two
parameters is NOT RECOMMENDED and SHOULD be limited to clients unable

to directly utilize the HTTP Basic authentication scheme (or other

password-based HTTP authentication schemes)" - though it talks about a=
 password based scheme...

similarly:

Authorization: JWT "encoded jwt assertion"

grant_type=3Dauthorization_code&code=3D123456

Just a thought.

Cheers, Sergey

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

--14dae93410896c855604d614a587--

From ve7jtb@ve7jtb.com  Tue Feb 19 06:59:13 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9893F21F880F for ; Tue, 19 Feb 2013 06:59:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.448
X-Spam-Level: 
X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.151,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzkSPfFxpe63 for ; Tue, 19 Feb 2013 06:59:12 -0800 (PST)
Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) by ietfa.amsl.com (Postfix) with ESMTP id 4040A21F8806 for ; Tue, 19 Feb 2013 06:59:12 -0800 (PST)
Received: by mail-qc0-f180.google.com with SMTP id v28so2553462qcm.25 for ; Tue, 19 Feb 2013 06:59:11 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=IWaRhQvHNYt3Sw/Pro03C0xIuVOnQlmDQYVNFH1khoU=; b=YixTNUTMECpiU4hKLGOgpoFl2wfufBsnnlV4T+bXA6zjqewDxkFE49IfDF03FB+Ap1 CWGQF+RyLuKK8CbFknnkT9zfn1O9JXPYr+NMudywY38xuYfPx1qEziUtmhArSXPGsyEa JEMgCEmRcsP0THQMe520oUFXYOb5whnlJ+hx8xkDnsGnguuSh3/aF9xMZ/7n9xtOAiyX ViUu6Z5DMrtNTRcAryHm37bbI0+Dr1hiQJRiejS1PUmQKhHMK/3gMyQbSBYBF/zFXsex yD5gMsY4HekdK17NTyxcFV27U8d5PmMAsNTV4zneVnDcz7KMgbu5JI+ZHKJ6z73W8paz 000Q==
X-Received: by 10.224.188.13 with SMTP id cy13mr7026904qab.53.1361285951556; Tue, 19 Feb 2013 06:59:11 -0800 (PST)
Received: from [192.168.1.213] (190-20-4-185.baf.movistar.cl. [190.20.4.185]) by mx.google.com with ESMTPS id g6sm681039qav.6.2013.02.19.06.59.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Feb 2013 06:59:09 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_CA2D3D2F-6C19-4BEE-A579-95AE2B0A2851"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <6.2.5.6.2.20130218225317.09ae39d8@resistor.net>
Date: Tue, 19 Feb 2013 11:58:01 -0300
Message-Id: <5766DCFA-2A1B-4E55-AA29-58038C3A4515@ve7jtb.com>
References: <51212E78.1050206@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DC1C@TK5EX14MBXC284.redmond.corp.microsoft.com> <51214AC5.3090807@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DE40@TK5EX14MBXC284.redmond.corp.microsoft.com>  <37B4C89F-2864-4317-BF87-F562241C176D@ve7jtb.com>  <87A4BE12-AC72-4E35-A95F-E6F161CF170B@ve7jtb.com> <6.2.5.6.2.20130218225317.09ae39d8@resistor.net>
To: SM 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQlEcPUw3gJ44h0qWYVu4JnWfAzM45p8EMbCbeX4ZZq1YB5PfiY26I99Zhw2sdIevbOYRafv
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Mandatory to implement (was: oauth assertions plan)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Feb 2013 14:59:13 -0000

--Apple-Mail=_CA2D3D2F-6C19-4BEE-A579-95AE2B0A2851
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

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

While having code available in libraries is generally a good thing, I =
agree.  That is likely not going to address all of Barry's issues.

A number of us recommended that Assertions , JWT-assertions and SAML =
assertions go ahead together because they are interrelated.  The chairs =
decided to send assertions on on it's own and it has been pushed back.
That is not especialy surprising, because it is not intended to be =
complete and interoperable in a end to end system on its own.

The question remains where to make what MTI.   While it may be logical =
to make SAML support MTI in SAML assertions should every library =
supporting assertions have full SAML support even if the applications =
are only using JWT assertions? =20

Where I think Barry and I agree is that we need to look at a group of =
documents that are intended to be used together for MTI rather than =
trying to overload Assertions which is only a small part of the whole.

So where we may disagree is if requiring libraries to have code that =
systems don't use and is effectively dead, helps with overall =
interoperability or is mostly theatre.

I suspect it is a continuum in that having the RS256 algorithm available =
in all the JWT assertion libraries lets applications using assertions =
choose to use it, but that doesn't guarantee all applications will,  or =
allow a client to figure out if that algorithm is available for use.

Hence my position that MTI without additional =
profiles/Discovery/negotiation is interoperability theatre if you are =
pretending it will make arbitrary OAuth deployments automatically work =
together.

Regards
John B.

On 2013-02-19, at 4:22 AM, SM  wrote:

> Hi John,
> At 12:54 18-02-2013, John Bradley wrote:
>> That is where we get into the area Stephen Farrell has been raising =
about MTI not being required to deploy.
>=20
> The topic of mandatory to implement has been discussed previously in =
the working group.
> Stephen Farrell explained [1] what it meant.  Barry Leiba explained =
what it meant.
>=20
> In my humble opinion a mandatory to implement feature is about having =
the code for the feature.  If the code is out there it is easier to get =
what you want.
>=20
> Regards,
> -sm=20

--Apple-Mail=_CA2D3D2F-6C19-4BEE-A579-95AE2B0A2851
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMjE5MTQ1ODA4WjAjBgkqhkiG9w0BCQQxFgQUqUj3zNwI
GftqDT350QEEdPPbaGUwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAPfu49dZAPmJe6UtH+8yVRuRg+GVGEGp799w/o3SK
AVlqXzRAERCtgM8iQcHw/L0W/5AqBK3lmmKsZlH75Z+DfC3C8QgCtxKcuxgaf/Tr5LQabr+H+xFR
gt0QIY5mJNzYHgkTeZca1c4cFH9RvFVtD9Qy42UaxLBei7mrJxEuI4InN9Z2UMMkyICP3PYYAmo3
eodIx4BrYnpbuGdXm4nE3clB+eVlnkSdHY13Ubd4cOm8slgRKK0zok8qnDkrviroLTyabHRz5Cj8
1CIyEBoOgWA4D+BsnxJ2qYCaT3ShbJhvT3Fi4flrvMopoWIMtIOC6Y16w40n02/Vu/9OFaWBjgAA
AAAAAA==

--Apple-Mail=_CA2D3D2F-6C19-4BEE-A579-95AE2B0A2851--

From stephen.farrell@cs.tcd.ie  Tue Feb 19 07:15:50 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6393E21F8DD5 for ; Tue, 19 Feb 2013 07:15:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.524
X-Spam-Level: 
X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77GArtc9kb4q for ; Tue, 19 Feb 2013 07:15:49 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 194E721F8DF1 for ; Tue, 19 Feb 2013 07:15:49 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3A90BBE1E; Tue, 19 Feb 2013 15:15:26 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syzPmZZPeRAz; Tue, 19 Feb 2013 15:15:26 +0000 (GMT)
Received: from [IPv6:2001:770:10:203:8900:f848:d9d4:67b7] (unknown [IPv6:2001:770:10:203:8900:f848:d9d4:67b7]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 10195BE1D; Tue, 19 Feb 2013 15:15:26 +0000 (GMT)
Message-ID: <5123970D.6010000@cs.tcd.ie>
Date: Tue, 19 Feb 2013 15:15:25 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: John Bradley 
References: <51212E78.1050206@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DC1C@TK5EX14MBXC284.redmond.corp.microsoft.com> <51214AC5.3090807@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DE40@TK5EX14MBXC284.redmond.corp.microsoft.com>  <37B4C89F-2864-4317-BF87-F562241C176D@ve7jtb.com>  <87A4BE12-AC72-4E35-A95F-E6F161CF170B@ve7jtb.com> <6.2.5.6.2.20130218225317.09ae39d8@resistor.net> <5766DCFA-2A1B-4E55-AA29-58038C3A4515@ve7jtb.com>
In-Reply-To: <5766DCFA-2A1B-4E55-AA29-58038C3A4515@ve7jtb.com>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Mandatory to implement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Feb 2013 15:15:50 -0000

On 02/19/2013 02:58 PM, John Bradley wrote:
> Yes but that contradicts what Barry is appearing to ask for which is run time interoperability, by profile or configuration.

I can tell you that I don't think Barry and I are asking for
contradictory things. They are different, but not contradictory,
and have the same goal (interop). I believe Barry would agree
with that.

Saying that field X is MTI can be entirely consistent with
defining a protocol that allow for negotiating whether or
not to use field X for example.

So you seem to be starting from a false dichotomy.

S.

> 
> While having code available in libraries is generally a good thing, I agree.  That is likely not going to address all of Barry's issues.
> 
> A number of us recommended that Assertions , JWT-assertions and SAML assertions go ahead together because they are interrelated.  The chairs decided to send assertions on on it's own and it has been pushed back.
> That is not especialy surprising, because it is not intended to be complete and interoperable in a end to end system on its own.
> 
> The question remains where to make what MTI.   While it may be logical to make SAML support MTI in SAML assertions should every library supporting assertions have full SAML support even if the applications are only using JWT assertions?  
> 
> Where I think Barry and I agree is that we need to look at a group of documents that are intended to be used together for MTI rather than trying to overload Assertions which is only a small part of the whole.
> 
> So where we may disagree is if requiring libraries to have code that systems don't use and is effectively dead, helps with overall interoperability or is mostly theatre.
> 
> I suspect it is a continuum in that having the RS256 algorithm available in all the JWT assertion libraries lets applications using assertions choose to use it, but that doesn't guarantee all applications will,  or allow a client to figure out if that algorithm is available for use.
> 
> Hence my position that MTI without additional profiles/Discovery/negotiation is interoperability theatre if you are pretending it will make arbitrary OAuth deployments automatically work together.
> 
> Regards
> John B.
> 
> On 2013-02-19, at 4:22 AM, SM  wrote:
> 
>> Hi John,
>> At 12:54 18-02-2013, John Bradley wrote:
>>> That is where we get into the area Stephen Farrell has been raising about MTI not being required to deploy.
>>
>> The topic of mandatory to implement has been discussed previously in the working group.
>> Stephen Farrell explained [1] what it meant.  Barry Leiba explained what it meant.
>>
>> In my humble opinion a mandatory to implement feature is about having the code for the feature.  If the code is out there it is easier to get what you want.
>>
>> Regards,
>> -sm 
> 
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 

From ve7jtb@ve7jtb.com  Tue Feb 19 07:58:16 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56DE21F8952 for ; Tue, 19 Feb 2013 07:58:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.452
X-Spam-Level: 
X-Spam-Status: No, score=-3.452 tagged_above=-999 required=5 tests=[AWL=0.146,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyUTIHDwjSDR for ; Tue, 19 Feb 2013 07:58:16 -0800 (PST)
Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) by ietfa.amsl.com (Postfix) with ESMTP id 7D52B21F87E4 for ; Tue, 19 Feb 2013 07:58:15 -0800 (PST)
Received: by mail-qc0-f175.google.com with SMTP id j3so2587383qcs.20 for ; Tue, 19 Feb 2013 07:58:14 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=8WRmFHomr7F/1cQiSl/A7xG/KcLC5IuI4iaEEvwJ1hE=; b=jcBYxYr+vGMZhVV0Z/cmxD2eI8mI7qWY9y5HaQ6515HwiKNSfUy4HSlZTO5rnNTW3a neErGnjn7wD7lt9YAPzO0ocVfj/QuzU0a0neHS16XvS/T8ut5KTDCCVIuoVI0y/rGJ4g ktPXem2NtNfgPG32uc2e2mhxqGsTdV9AvW5DVu9A060ZANSzFbcZCsqp4hKM1PgD0JqS pGZ57SM3417XM7UbwmkbOdRNSXlHixqO1s9S/C2jycJswgp6H0Ddbdj/EEKU2AQhA6xV QSnkofBrnUvtRxM1lLqYtz+G7g6AQT3ehK9A3en6qws0aZLzUlJX2PkYs3oZ/Efub/gR DvCg==
X-Received: by 10.49.133.68 with SMTP id pa4mr7624472qeb.50.1361289494766; Tue, 19 Feb 2013 07:58:14 -0800 (PST)
Received: from [192.168.1.213] (190-20-4-185.baf.movistar.cl. [190.20.4.185]) by mx.google.com with ESMTPS id no8sm15032371qeb.0.2013.02.19.07.58.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Feb 2013 07:58:09 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_FB3D99D5-4FB6-4975-888F-48383E7AD92A"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <59E470B10C4630419ED717AC79FCF9A948D552B8@BY2PRD0411MB441.namprd04.prod.outlook.com>
Date: Tue, 19 Feb 2013 12:57:27 -0300
Message-Id: <91236FDA-46F3-457F-AB60-CC08EF5A4574@ve7jtb.com>
References: <59E470B10C4630419ED717AC79FCF9A948D552B8@BY2PRD0411MB441.namprd04.prod.outlook.com>
To: Lewis Adam-CAL022 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQk4CwQrxx0J0NcSkN9k4ZyPbfIUK/6lxEIKM+UR2jVJoQvFDCcne/CLffmsm/TuZ2l86HkA
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] JWT grant_type and client_id
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Feb 2013 15:58:17 -0000

--Apple-Mail=_FB3D99D5-4FB6-4975-888F-48383E7AD92A
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_42D0620B-1CD0-4C9F-A2F5-CA9B394FA241"

--Apple-Mail=_42D0620B-1CD0-4C9F-A2F5-CA9B394FA241
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

At the moment no,

The HoK work is ongoing.

If you are talking about using an assertion as a authorization grant the =
subject should be the resource owner or some proxy for that. =20

In Connect that would be the user_id not the client_id.  We have added =
Authorized party "azp" to connect id_tokens that would be where the =
client_id of the requester of the token would go.
That however is a Connect extension of JWT and not documented as part of =
assertion processing.

One might expect that in some cases the token endpoint might =
authenticate the client and match the client_id with the value of "azp" =
for increased security.  That can be done now and is a bit like =
symmetric proof of possession where azp is used as a reference.

Once you start crossing trust boundaries things get more complicated as =
the client probably has different client_id for each AS.  So at that =
point you can't use the client_id and need to probably go to asymmetric =
proof of possession and trust that the initial assertion in the chain =
has properly authenticated the client.

This needs more work to flesh out.  I know Justin is also working on =
some token chaining proposals.

John B.

On 2013-02-18, at 7:50 PM, Lewis Adam-CAL022 =
 wrote:

> =20
> Is there any guidance on the usage of client_id when using the JWT =
assertion profile as a grant type?  draft-ietf-oauth-jwt-bearer-04 makes =
no mention so I assume that it is not required =85 but it would be =
necessary if using in conjunction with a HOK profile where the JWT =
assertion is issued to =96 and may only be used by =96 the intended =
client.  Obviously this is straight forward enough, really I=92m just =
looking to be sure that I=92m not missing anything.
> =20
> tx
> adam
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail=_42D0620B-1CD0-4C9F-A2F5-CA9B394FA241
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

At the moment =
no,
The HoK work is =
ongoing.

If you are talking about using an =
assertion as a authorization grant the subject should be the resource =
owner or some proxy for that.  

In Connect =
that would be the user_id not the client_id.  We have added =
Authorized party "azp" to connect id_tokens that would be where the =
client_id of the requester of the token would go.
That however =
is a Connect extension of JWT and not documented as part of assertion =
processing.

One might expect that in some cases =
the token endpoint might authenticate the client and match the client_id =
with the value of "azp" for increased security.  That can be done =
now and is a bit like symmetric proof of possession where azp is used as =
a reference.

Once you start crossing trust =
boundaries things get more complicated as the client probably has =
different client_id for each AS.  So at that point you can't use =
the client_id and need to probably go to asymmetric proof of possession =
and trust that the initial assertion in the chain has properly =
authenticated the client.

This needs more work =
to flesh out.  I know Justin is also working on some token chaining =
proposals.

John =
B.

On 2013-02-18, =
at 7:50 PM, Lewis Adam-CAL022 <Adam.Lewis@motorolasoluti=
ons.com> wrote:

Is =
there any guidance on the usage of client_id when using the JWT =
assertion profile as a grant type?  draft-ietf-oauth-jwt-bearer-04 =
makes no mention so I assume that it is not required =85 but it would be =
necessary if using in conjunction with a HOK profile where the JWT =
assertion is issued to =96 and may only be used by =96 the intended =
client.  Obviously this is straight forward enough, really I=92m =
just looking to be sure that I=92m not missing =
anything.
Subject: Re: [OAUTH-WG] Mandatory to implement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Feb 2013 19:16:27 -0000

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

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

				Thanks,
				-- Mike

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B=
arry Leiba
Sent: Tuesday, February 19, 2013 11:10 AM
To: Stephen Farrell
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Mandatory to implement

> I can tell you that I don't think Barry and I are asking for=20
> contradictory things. They are different, but not contradictory, and=20
> have the same goal (interop). I believe Barry would agree with that.
>
> Saying that field X is MTI can be entirely consistent with defining a=20
> protocol that allow for negotiating whether or not to use field X for=20
> example.

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

Barry
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

From ve7jtb@ve7jtb.com  Tue Feb 19 11:27:54 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C6D21F8E84 for ; Tue, 19 Feb 2013 11:27:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.456
X-Spam-Level: 
X-Spam-Status: No, score=-3.456 tagged_above=-999 required=5 tests=[AWL=0.143,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUQ+TL9goyRi for ; Tue, 19 Feb 2013 11:27:54 -0800 (PST)
Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id E5BAD21F8E5A for ; Tue, 19 Feb 2013 11:27:53 -0800 (PST)
Received: by mail-qc0-f173.google.com with SMTP id b12so2702381qca.18 for ; Tue, 19 Feb 2013 11:27:53 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=vKtCxH512U3QbkRHfvvMkYlp0BQDFRHE3KfjAon0bMc=; b=MD5UKv2nSGo5IIwXvWgtDjynOJUbUABSUT411cOk80rHF0bNY4JahMqKkXUy1dvDzw wtubl2tRHjghYRMioD3iRHEf1BrqzN8nF4ooZHfvFrAY/s6xzp18uuZwLK1/SzdNC2Tv h1gc+N8GVOUcNKDNp6FxPg+6MZSIypJ0ZMhAJDU+goNxqt6ypcC7mfgemqpgqSERJSp0 f+q63IS9l2Hp2GWrAjQaQNMY0vJCBg37XLQgRDVxfH8R3ohfc0du80rBucr5s8EVFhkh Jhw5SoERyfGjQYAr5GBiXX4RMK1soBYs7B8bfG+YTb+4xEU+x22h32YmpyyCqsuPScp4 uvXg==
X-Received: by 10.224.58.147 with SMTP id g19mr8143590qah.22.1361302073369; Tue, 19 Feb 2013 11:27:53 -0800 (PST)
Received: from [192.168.1.213] (190-20-4-185.baf.movistar.cl. [190.20.4.185]) by mx.google.com with ESMTPS id t2sm28552708qav.1.2013.02.19.11.27.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Feb 2013 11:27:50 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_1435B0A5-F4A5-432E-A170-AD01727FFC57"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <5123970D.6010000@cs.tcd.ie>
Date: Tue, 19 Feb 2013 16:26:37 -0300
Message-Id: <1FF61B36-AF1F-47B9-9D68-7C22EB93449B@ve7jtb.com>
References: <51212E78.1050206@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DC1C@TK5EX14MBXC284.redmond.corp.microsoft.com> <51214AC5.3090807@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436746DE40@TK5EX14MBXC284.redmond.corp.microsoft.com>  <37B4C89F-2864-4317-BF87-F562241C176D@ve7jtb.com>  <87A4BE12-AC72-4E35-A95F-E6F161CF170B@ve7jtb.com> <6.2.5.6.2.20130218225317.09ae39d8@resistor.net> <5766DCFA-2A1B-4E55-AA29-58038C3A4515@ve7jtb.com> <5123970D.6010000@cs.tcd.ie>
To: Stephen Farrell 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQmiK/26UtdQDdyGzLnUYfUqyUIUK5sbo+l+5dqs4pvRz8/Qj0DcKOIbB4gtThXEX1gcxAe3
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Mandatory to implement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Feb 2013 19:27:55 -0000

--Apple-Mail=_1435B0A5-F4A5-432E-A170-AD01727FFC57
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Sorry I did not intend to imply that what Barry is asking for is =
contradictory to MTI, only that it is different enough that it may =
require more than MTI of the existing features.
As stated in the second line of the message.

I think we need to get down to discussing specific changes.

John B.

On 2013-02-19, at 12:15 PM, Stephen Farrell  =
wrote:

>=20
>=20
> On 02/19/2013 02:58 PM, John Bradley wrote:
>> Yes but that contradicts what Barry is appearing to ask for which is =
run time interoperability, by profile or configuration.
>=20
> I can tell you that I don't think Barry and I are asking for
> contradictory things. They are different, but not contradictory,
> and have the same goal (interop). I believe Barry would agree
> with that.
>=20
> Saying that field X is MTI can be entirely consistent with
> defining a protocol that allow for negotiating whether or
> not to use field X for example.
>=20
> So you seem to be starting from a false dichotomy.
>=20
> S.
>=20
>>=20
>> While having code available in libraries is generally a good thing, I =
agree.  That is likely not going to address all of Barry's issues.
>>=20
>> A number of us recommended that Assertions , JWT-assertions and SAML =
assertions go ahead together because they are interrelated.  The chairs =
decided to send assertions on on it's own and it has been pushed back.
>> That is not especialy surprising, because it is not intended to be =
complete and interoperable in a end to end system on its own.
>>=20
>> The question remains where to make what MTI.   While it may be =
logical to make SAML support MTI in SAML assertions should every library =
supporting assertions have full SAML support even if the applications =
are only using JWT assertions? =20
>>=20
>> Where I think Barry and I agree is that we need to look at a group of =
documents that are intended to be used together for MTI rather than =
trying to overload Assertions which is only a small part of the whole.
>>=20
>> So where we may disagree is if requiring libraries to have code that =
systems don't use and is effectively dead, helps with overall =
interoperability or is mostly theatre.
>>=20
>> I suspect it is a continuum in that having the RS256 algorithm =
available in all the JWT assertion libraries lets applications using =
assertions choose to use it, but that doesn't guarantee all applications =
will,  or allow a client to figure out if that algorithm is available =
for use.
>>=20
>> Hence my position that MTI without additional =
profiles/Discovery/negotiation is interoperability theatre if you are =
pretending it will make arbitrary OAuth deployments automatically work =
together.
>>=20
>> Regards
>> John B.
>>=20
>> On 2013-02-19, at 4:22 AM, SM  wrote:
>>=20
>>> Hi John,
>>> At 12:54 18-02-2013, John Bradley wrote:
>>>> That is where we get into the area Stephen Farrell has been raising =
about MTI not being required to deploy.
>>>=20
>>> The topic of mandatory to implement has been discussed previously in =
the working group.
>>> Stephen Farrell explained [1] what it meant.  Barry Leiba explained =
what it meant.
>>>=20
>>> In my humble opinion a mandatory to implement feature is about =
having the code for the feature.  If the code is out there it is easier =
to get what you want.
>>>=20
>>> Regards,
>>> -sm=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20

--Apple-Mail=_1435B0A5-F4A5-432E-A170-AD01727FFC57
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMjE5MTkyNzE2WjAjBgkqhkiG9w0BCQQxFgQUaaLdGTo5
PAvtcBzzhXW4farv6cAwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAlbvpUIFSvoozNdGKGfIYx1TYeEzwjyiqxlLrmnyV
Fl/QG/KOZ+YkaOKU333EjA7cm61vNn+eB9pij/D/miY0u5LxkdyRP1MF/dChrh8psDdQHKqHqV9G
vYEezmGxGN12lS9seyxP+FCW5ZfgSYQtCYn4suL8aDP+hhC2y766BsNNB4nCSgds8SoTUgLyfFc2
TltZppgKU5KfVhei230FVuPwkdnTmm7ocYEwBTuSwAx5pfqz7mxw8Q2rOuN0vD9RIrdEsv0WPR5Y
GVdMnk4W21TQgcl8rTj6lTbTm4eC+kGLdj2gnF7WPa2mOmM50EyPiseB8B/O/raWTXX9zi9shwAA
AAAAAA==

--Apple-Mail=_1435B0A5-F4A5-432E-A170-AD01727FFC57--

From ietf-ipr@ietf.org  Tue Feb 19 11:58:20 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5508C21F8BEC; Tue, 19 Feb 2013 11:58:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.426
X-Spam-Level: 
X-Spam-Status: No, score=-102.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWIjnrQhPv9W; Tue, 19 Feb 2013 11:58:19 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2AE21F8878; Tue, 19 Feb 2013 11:58:19 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: IETF Secretariat 
To: mbj@microsoft.com, ve7jtb@ve7jtb.com, n-sakimura@nri.co.jp
X-Test-IDTracker: no
X-IETF-IDTracker: 4.40
Message-ID: <20130219195819.10604.99356.idtracker@ietfa.amsl.com>
Date: Tue, 19 Feb 2013 11:58:19 -0800
Cc: derek@ihtfp.com, oauth@ietf.org, ipr-announce@ietf.org
Subject: [OAUTH-WG] IPR Disclosure: Certicom Corporation's Statement about IPR related to	draft-ietf-oauth-json-web-token-06
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Feb 2013 19:58:20 -0000

Dear Michael Jones, John Bradley, Nat Sakimura:

 An IPR disclosure that pertains to your Internet-Draft entitled "JSON Web =
Token
(JWT)" (draft-ietf-oauth-json-web-token) was submitted to the IETF Secretar=
iat
on 2013-02-19 and has been posted on the "IETF Page of Intellectual Property
Rights Disclosures" (https://datatracker.ietf.org/ipr/1964/). The title of =
the
IPR disclosure is "Certicom Corporation's Statement about IPR related to dr=
aft-
ietf-oauth-json-web-token-06."");

The IETF Secretariat

From sberyozkin@gmail.com  Wed Feb 20 03:45:34 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E3B21F8759 for ; Wed, 20 Feb 2013 03:45:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level: 
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHWFenKeA4Gm for ; Wed, 20 Feb 2013 03:45:33 -0800 (PST)
Received: from mail-ea0-f181.google.com (mail-ea0-f181.google.com [209.85.215.181]) by ietfa.amsl.com (Postfix) with ESMTP id 6118D21F8754 for ; Wed, 20 Feb 2013 03:45:33 -0800 (PST)
Received: by mail-ea0-f181.google.com with SMTP id i13so3243254eaa.26 for ; Wed, 20 Feb 2013 03:45:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xgnIcgmfZpo7i2vAv9Lcx9SKjMQVchjxuaoD6WwW280=; b=ZBOQ47cp/+PZSJvxYLgXJRcqWedbfKrRG6WfDnAtJydmEYCupY73BDDS1pFGH398i1 +rb1oCqMl5tUbiMxYUtfjRCxCXCyI35DJdph0v9cf1ZTDoAq8z/Ry5JDJ0xdMiiWkYIM VAarWEkjY2R6bJxb2gcrnshoHLg90VfKOFirmMjIi442OmWZm37/hXVxwO0akbgv1CV7 7qR+Yxij6Wojk6kxn/Lqlm5uigTzYikKUcmscyL7brRFOQaLav/eBFCgvpxZJZdJEpZx 1W1rCzNkS+dulmdjOn7bvmV3zB4Q70aq+Vz0/qKYax++K3aiCHqXporX6izZloTozSg8 nABg==
X-Received: by 10.14.211.65 with SMTP id v41mr67897229eeo.33.1361360732580; Wed, 20 Feb 2013 03:45:32 -0800 (PST)
Received: from [192.168.2.5] ([79.97.76.201]) by mx.google.com with ESMTPS id s3sm38370095eem.4.2013.02.20.03.45.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 03:45:31 -0800 (PST)
Message-ID: <5124B749.9050402@gmail.com>
Date: Wed, 20 Feb 2013 11:45:13 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Brian Campbell 
References: <51238410.8040705@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" 
Subject: Re: [OAUTH-WG] Using SAML2 Bearer for the authentication
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2013 11:45:34 -0000

On 19/02/13 14:27, Brian Campbell wrote:
> The scope of assertion based client authentication is only in OAuth and
> only for the client calling the AS's token endpoint. Defining a general
> HTTP auth scheme for assertions would have a much broader scope and be
> much more difficult to standardize.
Understood, thanks.

I'd like to ask another question related to the subject of this thread, 
though the same would likely be relevant for using JWT for authenticating.

When the assertion is used for authenticating the client, a form 
"client_id" parameter is said to be optional.
Next, section 6.1 [1] says that "Subject" of the assertion SHOULD be 
"client_id".

I interpret it like this.

If "Subject" is set to "client_id" then there the actual client_id must 
be available as "client_id" form parameter, which will be posted 
alongside the assertion.

If not then the client_id is an actual Subject value and no "client_id" 
form parameter is expected to be available.

Is it correct ?

Thanks, Sergey

[1] http://tools.ietf.org/html/draft-ietf-oauth-assertions-10#section-6.1

>
>
> On Tue, Feb 19, 2013 at 6:54 AM, Sergey Beryozkin  > wrote:
>
>     Hi,
>
>     Assertions like SAML2 Bearer can be used for authenticating the client.
>     Why a dedicated Authorization scheme can not be introduced, instead
>     of or in addition to "client_assertion" & "client_assertion_type"
>     parameters ?
>
>     IMHO, the following
>
>     Authorization: SAML "base64url-encoded assertion"
>
>     grant_type=authorization_code&__code=123456
>
>     is more in line with OAuth2 recommending not to prefer including
>     client id & secret in the body:
>
>     "Including the client credentials in the request-body using the two
>     parameters is NOT RECOMMENDED and SHOULD be limited to clients unable
>     to directly utilize the HTTP Basic authentication scheme (or other
>     password-based HTTP authentication schemes)" - though it talks about
>     a password based scheme...
>
>     similarly:
>
>     Authorization: JWT "encoded jwt assertion"
>
>     grant_type=authorization_code&__code=123456
>
>     Just a thought.
>
>     Cheers, Sergey
>
>
>     _________________________________________________
>     OAuth mailing list
>     OAuth@ietf.org 
>     https://www.ietf.org/mailman/__listinfo/oauth
>     
>
>

From sakimura@gmail.com  Wed Feb 20 07:58:27 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C78021F86C3 for ; Wed, 20 Feb 2013 07:58:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.316
X-Spam-Level: 
X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=0.283,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ssijo2GDA6xW for ; Wed, 20 Feb 2013 07:58:26 -0800 (PST)
Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id C8D2D21F86BE for ; Wed, 20 Feb 2013 07:58:25 -0800 (PST)
Received: by mail-la0-f52.google.com with SMTP id fs12so7735068lab.39 for ; Wed, 20 Feb 2013 07:58:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=I8wAX7vz37JZHlnlbj3x+onpNqFBpPpS5zmY0BXBYlc=; b=z5Q0UW6Q0pFN4pJNZcgy98H8Gik7K+ECVI2hMpdBL7jQojioOewzFDYzSo2wfaS16x SRtXqPLU/pEiTxTgWTkA299uu4ejMnlnWVoNHj1bkJpa3HjikiSJP9Pb2p6vPokguEQj hHoGZqu5KYj3/ubqDrkLg4BrJ1+Pq1RXWZJ19hKYgw8jo5GIGGOrK9YyH/NYwFy73bZU YWIXE8tMRQw4mvj90zKlGYYTZa3Z5bq6F9QAWNpI/gJ+KWNlJxuC/YlkPDU6sY3M4Nir XPf4xS1+91cJaWHg4jUghVGEz6b47PBY+ySKGD8/DBYmVKUgm0T111r7gNuh2mA6JjQE 2lNQ==
MIME-Version: 1.0
X-Received: by 10.152.48.45 with SMTP id i13mr18148530lan.11.1361375904530; Wed, 20 Feb 2013 07:58:24 -0800 (PST)
Received: by 10.112.14.44 with HTTP; Wed, 20 Feb 2013 07:58:24 -0800 (PST)
In-Reply-To: 
References: <20130215215423.23019.50224.idtracker@ietfa.amsl.com> 
Date: Wed, 20 Feb 2013 10:58:24 -0500
Message-ID: 
From: Nat Sakimura 
To: "" , "Richer, Justin P." , John Bradley 
Content-Type: multipart/alternative; boundary=bcaec5523b2631ff7304d62a0760
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2013 15:58:27 -0000

--bcaec5523b2631ff7304d62a0760
Content-Type: text/plain; charset=ISO-8859-1

Thanks Justin.

Even if we go flat rather than doing JSON Structure, the "Client
Registration Access Endpoint" is not a good representative name.

What it represents is the client metadata/info.
It is not representing "Client Registration Access".
What does "Client Registration Access" mean?
Does UPDATing "Cleint Registration Access" make sense?

Something in the line of "Client Metadata Endpoint" and
something like "client_metadata_url" or "client_info_url" is much better.

Nat

2013/2/15 Richer, Justin P. 

> Everyone, there's a new draft of DynReg up on the tracker. This draft
> tries to codify the discussions so far from this week into something we can
> all read. There are still plenty of open discussion points and items up for
> debate. Please read through this latest draft and see what's changed and
> help assure that it properly captures the conversations. If you have any
> inputs for the marked [[ Editor's Note ]] sections, please send them to the
> list by next Thursday to give me opportunity to get any necessary changes
> in by the cutoff date of Monday the 22nd.
>
> Thanks for all of your hard work everyone, I think this is *really* coming
> along now.
>
>  -- Justin
>
> On Feb 15, 2013, at 4:54 PM, internet-drafts@ietf.org wrote:
>
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Web Authorization Protocol Working
> Group of the IETF.
> >
> >       Title           : OAuth Dynamic Client Registration Protocol
> >       Author(s)       : Justin Richer
> >                          John Bradley
> >                          Michael B. Jones
> >                          Maciej Machulak
> >       Filename        : draft-ietf-oauth-dyn-reg-06.txt
> >       Pages           : 21
> >       Date            : 2013-02-15
> >
> > Abstract:
> >   This specification defines an endpoint and protocol for dynamic
> >   registration of OAuth Clients at an Authorization Server.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-06
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > 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
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--bcaec5523b2631ff7304d62a0760
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thanks Justin.

Even if we go flat rather than doing JSON Structure, the "Client

Registration Access Endpoint" i=
s not a good representative name.
What it represents is the client metadata/info.

It is not representing "Client =
Registration Access".=A0What does "Client Registratio=
n Access" mean?=A0
Does UPDATing "Cleint Regi=
stration Access" make sense?

Something in the line of "Clien=
t Metadata Endpoint" and

something like "client_metadata=
_url" or=A0"client_=
info_url" is much better=
.

Nat

2013/2/15 Richer, Justin P. <jricher@mitre.=
org>

Everyone, there's a new draft of DynReg up on the tracker. This draft t=
ries to codify the discussions so far from this week into something we can =
all read. There are still plenty of open discussion points and items up for=
 debate. Please read through this latest draft and see what's changed a=
nd help assure that it properly captures the conversations. If you have any=
 inputs for the marked [[ Editor's Note ]] sections, please send them t=
o the list by next Thursday to give me opportunity to get any necessary cha=
nges in by the cutoff date of Monday the 22nd.

Thanks for all of your hard work everyone, I think this is *really* coming =
along now.

=A0-- Justin

On Feb 15, 2013, at 4:54 PM, in=
ternet-drafts@ietf.org wrote:

>

> A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.

> This draft is a work item of the Web Authorization Protocol Working Gr=
oup of the IETF.

>

> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : OAuth Dynamic Client Registrat=
ion Protocol

> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Justin Richer

> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0John Bradley

> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Michael B. Jones
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Maciej Machulak

> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-oauth-dyn-reg-06.txt<=
br>
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 21

> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-02-15

>

> Abstract:

> =A0 This specification defines an endpoint and protocol for dynamic
> =A0 registration of OAuth Clients at an Authorization Server.

>

>

> The IETF datatracker status page for this draft is:

> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg=

>

> There's also a htmlized version available at:

> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06
>

> A diff from the previous version is available at:

> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-=
dyn-reg-06

>

>

> Internet-Drafts are also available by anonymous FTP at:

> ftp:=
//ftp.ietf.org/internet-drafts/

>

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org

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

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

-- 
=
Nat Sakimura (=3Dnat)Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_=
en

--bcaec5523b2631ff7304d62a0760--

From Michael.Jones@microsoft.com  Wed Feb 20 08:05:15 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FACA21F88A0 for ; Wed, 20 Feb 2013 08:05:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.583
X-Spam-Level: 
X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.015,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hButxEVCf-Qf for ; Wed, 20 Feb 2013 08:05:12 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.25]) by ietfa.amsl.com (Postfix) with ESMTP id 86DB821F889C for ; Wed, 20 Feb 2013 08:05:12 -0800 (PST)
Received: from BL2FFO11FD009.protection.gbl (10.173.161.202) by BL2FFO11HUB023.protection.gbl (10.173.161.47) with Microsoft SMTP Server (TLS) id 15.0.620.12; Wed, 20 Feb 2013 16:05:04 +0000
Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD009.mail.protection.outlook.com (10.173.161.15) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Wed, 20 Feb 2013 16:05:03 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.96]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0318.003; Wed, 20 Feb 2013 16:04:40 +0000
From: Mike Jones 
To: Nat Sakimura , "" , "Richer, Justin P." , John Bradley 
Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
Thread-Index: AQHOC8cMkbohP5vU0EO7eTLi/U/hMJh7eCuAgAd2gACAAAA6MA==
Date: Wed, 20 Feb 2013 16:04:39 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436747A665@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <20130215215423.23019.50224.idtracker@ietfa.amsl.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.33]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436747A665TK5EX14MBXC284r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(479174001)(199002)(189002)(24454001)(65554002)(69224001)(51704002)(377454001)(377424002)(65816001)(512954001)(31966008)(16406001)(79102001)(59766001)(66066001)(56816002)(77982001)(80022001)(5343635001)(47976001)(55846006)(47736001)(49866001)(33656001)(51856001)(50986001)(56776001)(54356001)(46102001)(53806001)(20776003)(74662001)(16236675001)(4396001)(15202345001)(5343655001)(76482001)(16297215001)(44976002)(47446002)(54316002)(74502001)(63696002)(491001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB023; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07630F72AD
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2013 16:05:15 -0000

--_000_4E1F6AAD24975D4BA5B16804296739436747A665TK5EX14MBXC284r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

For what it's worth, the name "registration_access_url" was chosen to be pa=
rallel to "registration_access_token".   It's the place you use the access =
token.  And it's where you access an existing registration.  I'm against th=
e name "client_metadata_url" because it's not metadata you're accessing - i=
t's a registration you're accessing.  For the same reason, I don't think th=
e name "client_info_url" gives people the right idea, because it doesn't sa=
y anything it being the registration that you're accessing.

If you really want us to change this, having read what's above, I could liv=
e with "client_registration_url", but I don't think a change is actually ne=
cessary.  (But if we are going to change it, let's do it ASAP, before the O=
penID Connect Implementer's Drafts are published.)

                                                            -- Mike

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of N=
at Sakimura
Sent: Wednesday, February 20, 2013 7:58 AM
To: ; Richer, Justin P.; John Bradley
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

Thanks Justin.

Even if we go flat rather than doing JSON Structure, the "Client
Registration Access Endpoint" is not a good representative name.

What it represents is the client metadata/info.
It is not representing "Client Registration Access".
What does "Client Registration Access" mean?
Does UPDATing "Cleint Registration Access" make sense?

Something in the line of "Client Metadata Endpoint" and
something like "client_metadata_url" or "client_info_url" is much better.

Nat
2013/2/15 Richer, Justin P. >
Everyone, there's a new draft of DynReg up on the tracker. This draft tries=
 to codify the discussions so far from this week into something we can all =
read. There are still plenty of open discussion points and items up for deb=
ate. Please read through this latest draft and see what's changed and help =
assure that it properly captures the conversations. If you have any inputs =
for the marked [[ Editor's Note ]] sections, please send them to the list b=
y next Thursday to give me opportunity to get any necessary changes in by t=
he cutoff date of Monday the 22nd.

Thanks for all of your hard work everyone, I think this is *really* coming =
along now.

 -- Justin

On Feb 15, 2013, at 4:54 PM, internet-drafts@ietf.org wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
> This draft is a work item of the Web Authorization Protocol Working Group=
 of the IETF.
>
>       Title           : OAuth Dynamic Client Registration Protocol
>       Author(s)       : Justin Richer
>                          John Bradley
>                          Michael B. Jones
>                          Maciej Machulak
>       Filename        : draft-ietf-oauth-dyn-reg-06.txt
>       Pages           : 21
>       Date            : 2013-02-15
>
> Abstract:
>   This specification defines an endpoint and protocol for dynamic
>   registration of OAuth Clients at an Authorization Server.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-06
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> 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

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--_000_4E1F6AAD24975D4BA5B16804296739436747A665TK5EX14MBXC284r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

For what it’s worth=
, the name “registration_access_url” was chosen to be parallel =
to “registration_access_token”.   It’s the plac=
e you use the access token. 
 And it’s where you access an existing registration.  I’m =
against the name “client_metadata_url” because it’s not m=
etadata you’re accessing – it’s a registration you’=
re accessing.  For the same reason, I don’t think the name ̶=
0;client_info_url” gives people the
 right idea, because it doesn’t say anything it being the registratio=
n that you’re accessing.
 <=
/p>
If you really want us to =
change this, having read what’s above, I could live with “clien=
t_registration_url”, but I don’t think a change is actually nec=
essary. 
 (But if we are going to change it, let’s do it ASAP, before the Open=
ID Connect Implementer’s Drafts are published.)
 <=
/p>
    &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;     -- Mike
 <=
/p>
From: oauth-bo=
unces@ietf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Nat Sakimura

Sent: Wednesday, February 20, 2013 7:58 AM

To: <oauth@ietf.org>; Richer, Justin P.; John Bradley

Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt<=
o:p>

Thanks Jus=
tin.

Even if we go flat rather than doing JSON =
Structure, the "Client

Registration Access Endpoint" is not =
a good representative name.

What it represents is the client metadata/=
info.

It is not representing "Client Regist=
ration Access". 

What does "Client Registration Access" mea=
n? 

Does UPDATing "Cleint Registration Access" m=
ake sense?

Something in the line of "Client Meta=
data Endpoint" and

something like "client_metadata_url&q=
uot; or "client_info_url" is much better.

Nat

2013/2/15 Richer, Justin P. <jricher@mitre.org>
Everyone, there's a new draft of DynReg up on the tr=
acker. This draft tries to codify the discussions so far from this week int=
o something we can all read. There are still plenty of open discussion poin=
ts and items up for debate. Please
 read through this latest draft and see what's changed and help assure that=
 it properly captures the conversations. If you have any inputs for the mar=
ked [[ Editor's Note ]] sections, please send them to the list by next Thur=
sday to give me opportunity to get
 any necessary changes in by the cutoff date of Monday the 22nd.

Thanks for all of your hard work everyone, I think this is *really* coming =
along now.

 -- Justin

On Feb 15, 2013, at 4:54 PM, in=
ternet-drafts@ietf.org wrote:

>

> A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.

> This draft is a work item of the Web Authorization Protocol Working Gr=
oup of the IETF.

>

>       Title           : OAuth =
Dynamic Client Registration Protocol

>       Author(s)       : Justin Richer
>                     =
     John Bradley

>                     =
     Michael B. Jones

>                     =
     Maciej Machulak

>       Filename        : draft-ietf-=
oauth-dyn-reg-06.txt

>       Pages           : 21

>       Date            : 2=
013-02-15

>

> Abstract:

>   This specification defines an endpoint and protocol for dynamic=

>   registration of OAuth Clients at an Authorization Server.

>

>

> The IETF datatracker status page for this draft is:

> 
https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg

>

> There's also a htmlized version available at:

> 
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06

>

> A diff from the previous version is available at:

> 
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-06

>

>

> Internet-Drafts are also available by anonymous FTP at:

> ftp:=
//ftp.ietf.org/internet-drafts/

>

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org

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

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

-- 

Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation

http://nat.sakimura.=
org/

@_nat_en

--_000_4E1F6AAD24975D4BA5B16804296739436747A665TK5EX14MBXC284r_--

From ve7jtb@ve7jtb.com  Wed Feb 20 08:24:09 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061E621F88F1 for ; Wed, 20 Feb 2013 08:24:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.456
X-Spam-Level: 
X-Spam-Status: No, score=-3.456 tagged_above=-999 required=5 tests=[AWL=0.142,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3cAoiChzuY7 for ; Wed, 20 Feb 2013 08:24:07 -0800 (PST)
Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2B621F88F7 for ; Wed, 20 Feb 2013 08:24:07 -0800 (PST)
Received: by mail-qe0-f48.google.com with SMTP id 3so3702049qea.21 for ; Wed, 20 Feb 2013 08:24:06 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=T5jaQoqlAEmojPMik+8Xcffi38ctfvc6ac4IZcBU41c=; b=Y3++r1ENMsZfmtlITUlpcznYfJrd2ihlOyaRXsowgsO0rMA/HCku98sF/F6mro5eZs HN7Yst97NDtWWEmK5cNm6/zussf0Ws9EB5U0t4036kZxAZr1zz2/1AMQlKe4ffo6xZN/ +u4sz5luczzGJV6UA8SjNC5j6FmBVgB3/8A4oQxjt1J/jMHawZ/FvdnbpK+pX8s0ox3c hvOdRewphA/7EPimyvvNCGZDm5J6iLf0U0EHXFsExtEBZR8OAhG60mNt3KLhJ21b2dXF xcMZxK6lRX4IHoLhn9U5tGxGp7cfT2xJDRPKRPWD23JICm+WIZWyZ2vqgSkFKK58VYau n6dg==
X-Received: by 10.49.127.15 with SMTP id nc15mr10143607qeb.61.1361377446394; Wed, 20 Feb 2013 08:24:06 -0800 (PST)
Received: from [192.168.1.213] (190-20-41-134.baf.movistar.cl. [190.20.41.134]) by mx.google.com with ESMTPS id bb8sm29962438qeb.5.2013.02.20.08.24.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 08:24:04 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_6E8803B4-655D-4057-B848-CE30D7F8A5C3"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436747A665@TK5EX14MBXC284.redmond.corp.microsoft.com>
Date: Wed, 20 Feb 2013 13:23:29 -0300
Message-Id: <63255CDA-E93F-4414-B471-B373C4B6F65E@ve7jtb.com>
References: <20130215215423.23019.50224.idtracker@ietfa.amsl.com>   <4E1F6AAD24975D4BA5B16804296739436747A665@TK5EX14MBXC284.redmond.corp.microsoft.com>
To: Mike Jones 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQm+Vywlb/FId5+fmz0QqBpenYf4OOhzqom8Thp6MO9lgL7eGxmT7y/LCU+g1xIAc9snLFAb
Cc: "" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2013 16:24:09 -0000

--Apple-Mail=_6E8803B4-655D-4057-B848-CE30D7F8A5C3
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_37C5F444-EAA9-40DE-89F8-2EA723325CC7"

--Apple-Mail=_37C5F444-EAA9-40DE-89F8-2EA723325CC7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I think registration_access_url is OK.    I haven't heard any better =
names yet.

John B.
On 2013-02-20, at 1:04 PM, Mike Jones  =
wrote:

> For what it=92s worth, the name =93registration_access_url=94 was =
chosen to be parallel to =93registration_access_token=94.   It=92s the =
place you use the access token.  And it=92s where you access an existing =
registration.  I=92m against the name =93client_metadata_url=94 because =
it=92s not metadata you=92re accessing =96 it=92s a registration you=92re =
accessing.  For the same reason, I don=92t think the name =
=93client_info_url=94 gives people the right idea, because it doesn=92t =
say anything it being the registration that you=92re accessing.
> =20
> If you really want us to change this, having read what=92s above, I =
could live with =93client_registration_url=94, but I don=92t think a =
change is actually necessary.  (But if we are going to change it, let=92s =
do it ASAP, before the OpenID Connect Implementer=92s Drafts are =
published.)
> =20
>                                                             -- Mike
> =20
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf =
Of Nat Sakimura
> Sent: Wednesday, February 20, 2013 7:58 AM
> To: ; Richer, Justin P.; John Bradley
> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
> =20
> Thanks Justin.
>=20
> Even if we go flat rather than doing JSON Structure, the "Client
> Registration Access Endpoint" is not a good representative name.
>=20
> What it represents is the client metadata/info.
> It is not representing "Client Registration Access".=20
> What does "Client Registration Access" mean?=20
> Does UPDATing "Cleint Registration Access" make sense?
>=20
> Something in the line of "Client Metadata Endpoint" and
> something like "client_metadata_url" or "client_info_url" is much =
better.
>=20
> Nat
>=20
> 2013/2/15 Richer, Justin P. 
> Everyone, there's a new draft of DynReg up on the tracker. This draft =
tries to codify the discussions so far from this week into something we =
can all read. There are still plenty of open discussion points and items =
up for debate. Please read through this latest draft and see what's =
changed and help assure that it properly captures the conversations. If =
you have any inputs for the marked [[ Editor's Note ]] sections, please =
send them to the list by next Thursday to give me opportunity to get any =
necessary changes in by the cutoff date of Monday the 22nd.
>=20
> Thanks for all of your hard work everyone, I think this is *really* =
coming along now.
>=20
>  -- Justin
>=20
> On Feb 15, 2013, at 4:54 PM, internet-drafts@ietf.org wrote:
>=20
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> > This draft is a work item of the Web Authorization Protocol Working =
Group of the IETF.
> >
> >       Title           : OAuth Dynamic Client Registration Protocol
> >       Author(s)       : Justin Richer
> >                          John Bradley
> >                          Michael B. Jones
> >                          Maciej Machulak
> >       Filename        : draft-ietf-oauth-dyn-reg-06.txt
> >       Pages           : 21
> >       Date            : 2013-02-15
> >
> > Abstract:
> >   This specification defines an endpoint and protocol for dynamic
> >   registration of OAuth Clients at an Authorization Server.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-06
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20
> =20
> --=20
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en

--Apple-Mail=_37C5F444-EAA9-40DE-89F8-2EA723325CC7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

I think registration_access_url =
is OK.    I haven't heard any better names =
yet.
John B.
On 2013-02-20, at 1:04 PM, =
Mike Jones <Michael.Jones@microsoft.com> wrote:

For what it=92s worth, =
the name =93registration_access_url=94 was chosen to be parallel to =
=93registration_access_token=94.   It=92s the place you use =
the access token.  And it=92s where you access an existing =
registration.  I=92m against the name =93client_metadata_url=94 =
because it=92s not metadata you=92re accessing =96 it=92s a registration =
you=92re accessing.  For the same reason, I don=92t think the name =
=93client_info_url=94 gives people the right idea, because it doesn=92t =
say anything it being the registration that you=92re =
accessing.

If you really want us to change this, having =
read what=92s above, I could live with =93client_registration_url=94, =
but I don=92t think a change is actually necessary.  (But if we are =
going to change it, let=92s do it ASAP, before the OpenID Connect =
Implementer=92s Drafts are published.)

  oauth-bounces@ietf.org =
[mailto:oauth-bounces@ietf.org] On Behalf Of Nat =
Sakimura
Sent: Wednesday, February 20, =
2013 7:58 AM
To: <oauth@ietf.org>; Richer, Justin =
P.; John Bradley
Subject: Re: [OAUTH-WG] I-D Action: =
draft-ietf-oauth-dyn-reg-06.txt

Thanks =
Justin.

Even if we go flat rather than =
doing JSON Structure, the "Client
Registration Access Endpoint" is =
not a good representative name.

What it represents is the client =
metadata/info.
It is not representing "Client Registration =
Access". 
What does "Client Registration Access" =
mean? 
Does UPDATing "Cleint Registration Access" make =
sense?

Something in the line of "Client Metadata Endpoint" =
and
something like "client_metadata_url" =
or "client_info_url" is much better.

 -- =
Justin
 internet-drafts@ietf.org wrote:

>
> =
A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the Web Authorization =
Protocol Working Group of the IETF.
>
>       =
Title           : OAuth Dynamic Client =
Registration Protocol
>       Author(s)   =
    : Justin Richer
>           =
               John =
Bradley
>                 =
         Michael B. Jones
>     =
                    =
 Maciej Machulak
>       Filename   =
     : draft-ietf-oauth-dyn-reg-06.txt
>   =
    Pages           : 21
> =
      Date            : =
2013-02-15
>
> Abstract:
>   This specification =
defines an endpoint and protocol for dynamic
>   registration =
of OAuth Clients at an Authorization Server.
>
>
> The =
IETF datatracker status page for this draft is:
>     OAuth@ietf.org
> OAuth@ietf.org

-- 
Nat Sakimura =
(=3Dnat)
Chairman, =
OpenID Foundation
" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2013 16:34:50 -0000

--14dae9340b735c2ca704d62a8931
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

In OAuth, we have redirect_uri not redirect_url; should this be
registration_access_uri for consistency? -T

On Wed, Feb 20, 2013 at 8:23 AM, John Bradley  wrote:

> I think registration_access_url is OK.    I haven't heard any better name=
s
> yet.
>
> John B.
>
> On 2013-02-20, at 1:04 PM, Mike Jones  wrote=
:
>
>  For what it=E2=80=99s worth, the name =E2=80=9Cregistration_access_url=
=E2=80=9D was chosen to be
> parallel to =E2=80=9Cregistration_access_token=E2=80=9D.   It=E2=80=99s t=
he place you use the
> access token.  And it=E2=80=99s where you access an existing registration=
.  I=E2=80=99m
> against the name =E2=80=9Cclient_metadata_url=E2=80=9D because it=E2=80=
=99s not metadata you=E2=80=99re
> accessing =E2=80=93 it=E2=80=99s a registration you=E2=80=99re accessing.=
  For the same reason, I
> don=E2=80=99t think the name =E2=80=9Cclient_info_url=E2=80=9D gives peop=
le the right idea, because
> it doesn=E2=80=99t say anything it being the registration that you=E2=80=
=99re accessing.**
> **
>
> If you really want us to change this, having read what=E2=80=99s above, I=
 could
> live with =E2=80=9Cclient_registration_url=E2=80=9D, but I don=E2=80=99t =
think a change is actually
> necessary.  (But if we are going to change it, let=E2=80=99s do it ASAP, =
before the
> OpenID Connect Implementer=E2=80=99s Drafts are published.)****
>
>                                                             -- Mike****
>
> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf
> Of *Nat Sakimura
> *Sent:* Wednesday, February 20, 2013 7:58 AM
> *To:* ; Richer, Justin P.; John Bradley
> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt****
> ** **
> Thanks Justin.
>
> Even if we go flat rather than doing JSON Structure, the "Client
> Registration Access Endpoint" is not a good representative name.
>
> What it represents is the client metadata/info.
> It is not representing "Client Registration Access". ****
> What does "Client Registration Access" mean? ****
>
> Does UPDATing "Cleint Registration Access" make sense?
>
> Something in the line of "Client Metadata Endpoint" and
> something like "client_metadata_url" or "client_info_url" is much better.
>
> Nat****
> 2013/2/15 Richer, Justin P. ****
> Everyone, there's a new draft of DynReg up on the tracker. This draft
> tries to codify the discussions so far from this week into something we c=
an
> all read. There are still plenty of open discussion points and items up f=
or
> debate. Please read through this latest draft and see what's changed and
> help assure that it properly captures the conversations. If you have any
> inputs for the marked [[ Editor's Note ]] sections, please send them to t=
he
> list by next Thursday to give me opportunity to get any necessary changes
> in by the cutoff date of Monday the 22nd.
>
> Thanks for all of your hard work everyone, I think this is *really* comin=
g
> along now.
>
>  -- Justin****
>
> On Feb 15, 2013, at 4:54 PM, internet-drafts@ietf.org wrote:
>
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Web Authorization Protocol Working
> Group of the IETF.
> >
> >       Title           : OAuth Dynamic Client Registration Protocol
> >       Author(s)       : Justin Richer
> >                          John Bradley
> >                          Michael B. Jones
> >                          Maciej Machulak
> >       Filename        : draft-ietf-oauth-dyn-reg-06.txt
> >       Pages           : 21
> >       Date            : 2013-02-15
> >
> > Abstract:
> >   This specification defines an endpoint and protocol for dynamic
> >   registration of OAuth Clients at an Authorization Server.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-06
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > 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****
>
>
> ****
> ** **
> --
> Nat Sakimura (=3Dnat)****
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--14dae9340b735c2ca704d62a8931
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

In OAuth, we have redirect_uri not redirect_url; should this be registratio=
n_access_uri for consistency? -T

On Wed, =
Feb 20, 2013 at 8:23 AM, John Bradley <ve7jtb@ve7jtb.com> wr=
ote:

I think =
registration_access_url is OK. =C2=A0 =C2=A0I haven't heard any better =
names yet.

John B.
On 2013-02-20, a=
t 1:04 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

For what it=E2=80=99s worth, the name =
=E2=80=9Cregistration_access_url=E2=80=9D was chosen to be parallel to =E2=
=80=9Cregistration_access_token=E2=80=9D.=C2=A0=C2=A0 It=E2=80=99s the plac=
e you use the access token.=C2=A0 And it=E2=80=99s where you access an exis=
ting registration.=C2=A0 I=E2=80=99m against the name =E2=80=9Cclient_metad=
ata_url=E2=80=9D because it=E2=80=99s not metadata you=E2=80=99re accessing=
 =E2=80=93 it=E2=80=99s a registration you=E2=80=99re accessing.=C2=A0 For =
the same reason, I don=E2=80=99t think the name =E2=80=9Cclient_info_url=E2=
=80=9D gives people the right idea, because it doesn=E2=80=99t say anything=
 it being the registration that you=E2=80=99re accessing.

=C2=A0

If you really want us to change this, having read what=E2=80=99s ab=
ove, I could live with =E2=80=9Cclient_registration_url=E2=80=9D, but I don=
=E2=80=99t think a change is actually necessary.=C2=A0 (But if we are going=
 to change it, let=E2=80=99s do it ASAP, before the OpenID Connect Implemen=
ter=E2=80=99s Drafts are published.)

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike<=
/u>

=C2=A0
From:=C2=A0oauth-bounces@ietf.org [ma=
ilto:oauth-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Nat Sakimura

Sent:=C2=A0Wednesday, February 20, 2013 7:58 AM
T=
o:=C2=A0<oauth@ietf.org>; Richer, Justin P.; John Bradley
Subject=
:=C2=A0Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg=
-06.txt

=C2=A0
Thanks Justin.

Even if we go flat ra=
ther than doing JSON Structure, the "Client
Registration Access Endpoint" is not=
 a good representative name.

What it represents is=
 the client metadata/info.
It is not representing "Client Registration Access".=
=C2=A0

What does "Client Registration Access"=
; mean?=C2=A0

Does UPDATing "Cleint Registr=
ation Access" make sense?

Something in the line of =
"Client Metadata Endpoint" and
something like "client_metadata_url" or=
=C2=A0"client_info_url" is much better.

Nat<=
/u>
2013/2/15 Richer, Justin P. <<=
a href=3D"mailto:jricher@mitre.org" style=3D"color:purple;text-decoration:u=
nderline" target=3D"_blank">jricher@mitre.org>

Everyone, there's a new draft of DynReg up on th=
e tracker. This draft tries to codify the discussions so far from this week=
 into something we can all read. There are still plenty of open discussion =
points and items up for debate. Please read through this latest draft and s=
ee what's changed and help assure that it properly captures the convers=
ations. If you have any inputs for the marked [[ Editor's Note ]] secti=
ons, please send them to the list by next Thursday to give me opportunity t=
o get any necessary changes in by the cutoff date of Monday the 22nd.

Thanks for all of your hard work everyone, I think this is *really* com=
ing along now.

=C2=A0--=
 Justin

On Feb 15, 2013, at 4:54 PM,=C2=A0internet-drafts@ietf.org=C2=A0wrote:

&g=
t;
> A New Internet-Draft is available from the on-line Internet-Draf=
ts directories.

> This draft is a work item of the Web Authorization Protocol Working Gr=
oup of the IETF.
>
> =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 : OAuth Dynamic Client Registration Protocol
> =
=C2=A0 =C2=A0 =C2=A0 Author(s) =C2=A0 =C2=A0 =C2=A0 : Justin Richer

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0John Bradley
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Michael B. Jones> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0Maciej Machulak
> =C2=A0 =C2=A0 =C2=A0 Filename =
=C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-ietf-oauth-dyn-reg-06.txt
> =C2=A0=
 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 21

> =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 2=
013-02-15
>
> Abstract:
> =C2=A0 This specification defin=
es an endpoint and protocol for dynamic
> =C2=A0 registration of OAut=
h Clients at an Authorization Server.
>
>

> The IETF datatracker status page for this draft is:
>=C2=
=A0htt=
ps://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg

>
> There's also a htmlized version available at:
>=C2=A0ht=
tp://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06

>
> A diff from the previous version is available at:
>=C2=A0http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-06

>
>
> Internet-Drafts are also available by anonymous FTP at=
:
>=C2=A0ftp://f=
tp.ietf.org/internet-drafts/

>
> _______________________________________________
> OAuth =
mailing list
>=C2=A0OAuth@ietf=
.org

>=C2=A0http=
s://www.ietf.org/mailman/listinfo/oauth

________________________=
_______________________

OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/lis=
tinfo/oauth

=C2=A0
--=C2=A0
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sa=
kimura.org/
@_nat_en

_______________________________________________=

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

--14dae9340b735c2ca704d62a8931--

From sakimura@gmail.com  Wed Feb 20 08:53:43 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB8021F84F9 for ; Wed, 20 Feb 2013 08:53:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.206
X-Spam-Level: 
X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[AWL=0.392,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXXO6UdF8aUY for ; Wed, 20 Feb 2013 08:53:28 -0800 (PST)
Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7E65321F84F8 for ; Wed, 20 Feb 2013 08:53:28 -0800 (PST)
Received: by mail-qa0-f54.google.com with SMTP id hg5so2505787qab.20 for ; Wed, 20 Feb 2013 08:53:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=F9JMCmdvtjY7Zu5368JkIU2ouMHUjpXkem6E9TOsPzE=; b=effEHqZUw6vPsthYDdU3t4DqqEDnfZ71gPmIYIx8BPp+hxOKvWLqYFjJPTQSrunOIN d8aKpa1c3rrdYDURlDbzailwr9S5ArDpZUzXysTXcpim+buHpAdPe2bwfw7u09wNOZCS XhK+nwHHa6ivCdgPryXcMyf+z3gFIwm8uCLaF/evH5yesYchhrAaWaQmOJeczCGBanyp DNWoT58wzdmVIRmMw+vy1dQZjifPBuuOgTppu36TZWYZlQFmpZqa2PkTjElKvhrVQn2n oh0ZeEZf62zou01H53u01vaO3n+6xOafojXHx6V6AJ73n5MEg5bzjQyJ+gPnn3fZ7tW8 u6jA==
MIME-Version: 1.0
X-Received: by 10.224.222.15 with SMTP id ie15mr10029878qab.75.1361379208016;  Wed, 20 Feb 2013 08:53:28 -0800 (PST)
Received: by 10.49.106.161 with HTTP; Wed, 20 Feb 2013 08:53:27 -0800 (PST)
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436747A665@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <20130215215423.23019.50224.idtracker@ietfa.amsl.com>   <4E1F6AAD24975D4BA5B16804296739436747A665@TK5EX14MBXC284.redmond.corp.microsoft.com>
Date: Wed, 20 Feb 2013 11:53:27 -0500
Message-ID: 
From: Nat Sakimura 
To: Mike Jones 
Content-Type: multipart/alternative; boundary=20cf3074b51a19334a04d62acc16
Cc: "" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2013 16:53:43 -0000

--20cf3074b51a19334a04d62acc16
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I have read the whole thing and still ---

Your argument that it is the place for using "registration access token"
thus should have a parallel name "registration access url" is very weak.
There are several weakness.

First, "registration access token" actually is "registration" + "access
token". Extracting "registration access" from "registration access token"
is broken.

Secondly, access token is used to against any protected
resource. Recommending to use the word "access" in naming protected
resources is broken. Should we rename Userinfo endpoint to something like
"Userinfo Access Endpoint"? I do not think so.

Thirdly, the term "Registration Access" does not seem to be meaningful.
When you say "access", I suppose you are using the noun version of it.
(If you are using the verb, then I am even more against as a URL should not
contain a verb.)

According to the Webster, access (n.) is defined as:

*access **n.*

1
*a* *:* onset  2
*b* *:* a fit of intense feeling *:*
outburst
2
*a* *:* permission, liberty, or ability to enter, approach, or pass to and
from a place or to approach or communicate with a person or thing
*b* *:* freedom or ability to obtain or make use of something
*c* *:* a way or means of access
*d* *:* the act or an instance of
accessing
3
*:* an increase by addition 

Replacing "access" with any of the definition above does not seem to work.

Remember, a URL is represents a "thing".
The name of the endpoint should represent the "thing".

I am merginally OK with "client registration url" leveraging on the
definition 2. below (again from Webster -- my OED subscription lapsed for
the time being.)

*registration **n.*

1
*:* the act of registering
2
*:* an entry in a register
3
*:* the number of individuals
registered
 *:* enrollment 
4
*a* *:* the art or act of selecting and adjusting pipe organ stops
*b* *:* the combination of stops selected for performing a particular organ
work
5
*:* a document certifying an act of registering

However, since the most common use of "registration" is actually *1* above,
it still is confusing. If you really want to emphasize the fact that it has
been registered, then something like "registered client info uri" or
"registered client metadata uri" would be better.

Nat

2013/2/20 Mike Jones 

>  For what it=92s worth, the name =93registration_access_url=94 was chosen=
 to be
> parallel to =93registration_access_token=94.   It=92s the place you use t=
he
> access token.  And it=92s where you access an existing registration.  I=
=92m
> against the name =93client_metadata_url=94 because it=92s not metadata yo=
u=92re
> accessing =96 it=92s a registration you=92re accessing.  For the same rea=
son, I
> don=92t think the name =93client_info_url=94 gives people the right idea,=
 because
> it doesn=92t say anything it being the registration that you=92re accessi=
ng.**
> **
>
> ** **
>
> If you really want us to change this, having read what=92s above, I could
> live with =93client_registration_url=94, but I don=92t think a change is =
actually
> necessary.  (But if we are going to change it, let=92s do it ASAP, before=
 the
> OpenID Connect Implementer=92s Drafts are published.)****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf
> Of *Nat Sakimura
> *Sent:* Wednesday, February 20, 2013 7:58 AM
> *To:* ; Richer, Justin P.; John Bradley
>
> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt****
>
> ** **
>
> Thanks Justin.
>
>
> Even if we go flat rather than doing JSON Structure, the "Client
> Registration Access Endpoint" is not a good representative name.
>
> What it represents is the client metadata/info.
> It is not representing "Client Registration Access". ****
>
>  What does "Client Registration Access" mean? ****
>
> Does UPDATing "Cleint Registration Access" make sense?
>
> Something in the line of "Client Metadata Endpoint" and
> something like "client_metadata_url" or "client_info_url" is much better.
>
> Nat****
>
> 2013/2/15 Richer, Justin P. ****
>
> Everyone, there's a new draft of DynReg up on the tracker. This draft
> tries to codify the discussions so far from this week into something we c=
an
> all read. There are still plenty of open discussion points and items up f=
or
> debate. Please read through this latest draft and see what's changed and
> help assure that it properly captures the conversations. If you have any
> inputs for the marked [[ Editor's Note ]] sections, please send them to t=
he
> list by next Thursday to give me opportunity to get any necessary changes
> in by the cutoff date of Monday the 22nd.
>
> Thanks for all of your hard work everyone, I think this is *really* comin=
g
> along now.
>
>  -- Justin****
>
>
> On Feb 15, 2013, at 4:54 PM, internet-drafts@ietf.org wrote:
>
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Web Authorization Protocol Working
> Group of the IETF.
> >
> >       Title           : OAuth Dynamic Client Registration Protocol
> >       Author(s)       : Justin Richer
> >                          John Bradley
> >                          Michael B. Jones
> >                          Maciej Machulak
> >       Filename        : draft-ietf-oauth-dyn-reg-06.txt
> >       Pages           : 21
> >       Date            : 2013-02-15
> >
> > Abstract:
> >   This specification defines an endpoint and protocol for dynamic
> >   registration of OAuth Clients at an Authorization Server.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-06
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > 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****
>
>
>
> ****
>
> ** **
>
> --
> Nat Sakimura (=3Dnat)****
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en****
>

--=20
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--20cf3074b51a19334a04d62acc16
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I have read the whole thing and still ---=A0
Your argume=
nt that it is the place for using "registration access token" thu=
s should have a parallel name "registration access url" is very w=
eak. There are several weakness.=A0

First, "registration access token" actually i=
s "registration" + "access token". Extracting "reg=
istration access" from "registration access token" is broken=
.=A0

Secondly, access token is used to against any protected=
 resource.=A0Recommending=A0to use the word "access" in naming pr=
otected resources is broken. Should we rename Userinfo endpoint to somethin=
g like "Userinfo Access Endpoint"? I do not think so.=A0

Thirdly, the term "Registration Access" does =
not seem to be meaningful.=A0
When you say "access", I =
suppose you are using the noun version of it.=A0(If you are=
 using the verb, then I am even more against as a URL should not contain a =
verb.)=A0

According to the Webster, access (n.) is defined as:=A0=

access n.

=

1a=A0<=
strong>:=A0onset=A02
b=
=A0:=A0a fit of intense feeling=A0:=A0outburst

2<=
/div>
=
a=A0:=A0permission, liberty, or ability to enter, app=
roach, or pass to and from a place or to approach or communicate with a per=
son or thing
b=
=A0:=A0freedom or ability to obtain or make use of somethi=
ng<=
/div>c=
=A0:=A0a way or means of access
d=
=A0:=A0the act or an instance of=A0accessing
3<=
/div>
:=A0an increase by addition=A0<a sudden=A0access=A0of wealth>

Replacing "access" with any of the definition above does not=
 seem to work.=A0

Remember, a URL is represents a =
"thing".=A0
The name of the endpoint should represent t=
he "thing".=A0

I am merginally OK with "client registration url&q=
uot; leveraging on the definition 2. below (again from Webster -- my OED su=
bscription lapsed for the time being.)=A0

regis=
tration n.

1
:=A0the act of=A0registering=

2<=
/div>
:=A0an entry in a=A0register
3<=
/div>
:=A0the number of individuals=A0register=
ed=A0:=A0enrollment
4<=
/div>
=
a=A0:=A0the art or act of selecting and adjusting pip=
e organ stops
b=
=A0:=A0the combination of stops selected for performing a =
particular organ work

5
:=A0a document certifying an act of registering<=
/div>

However, since the most common use of "regis=
tration" is actually 1 above, it still is confusing. If you rea=
lly want to emphasize the fact that it has been registered, then something =
like "registered client info uri" or "registered client meta=
data uri" would be better.=A0

Nat

=
2013/2/20 Mike Jones <Michael.Jones@microsoft.com>=

For what it=92s worth, th=
e name =93registration_access_url=94 was chosen to be parallel to =93regist=
ration_access_token=94.=A0=A0 It=92s the place you use the access token.=A0
 And it=92s where you access an existing registration.=A0 I=92m against the=
 name =93client_metadata_url=94 because it=92s not metadata you=92re access=
ing =96 it=92s a registration you=92re accessing.=A0 For the same reason, I=
 don=92t think the name =93client_info_url=94 gives people the
 right idea, because it doesn=92t say anything it being the registration th=
at you=92re accessing.
=A0<=
/p>
If you really want us to =
change this, having read what=92s above, I could live with =93client_regist=
ration_url=94, but I don=92t think a change is actually necessary.=A0
 (But if we are going to change it, let=92s do it ASAP, before the OpenID C=
onnect Implementer=92s Drafts are published.)
=A0<=
/p>
=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 -- Mike
=A0<=
/p>
From: oauth-bounces@ietf.org=
 [mailto:oa=
uth-bounces@ietf.org]
On Behalf Of Nat Sakimura

Sent: Wednesday, February 20, 2013 7:58 AM

To: <oauth@ie=
tf.org>; Richer, Justin P.; John Bradley

Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt<=
u>

=A0
Thanks Jus=
tin.

Even if we go flat rather than doing JSON =
Structure, the "Client

Registration Access Endpoint" is not =
a good representative name.

What it represents is the client metadata/=
info.

It is not representing "Client Regist=
ration Access".=A0
=

What does "Client Registration Access" mea=
n?=A0

Does UPDATing "Cleint Registration Access" m=
ake sense?

Something in the line of "Client Meta=
data Endpoint" and

something like "client_metadata_url&q=
uot; or=A0"client_info_url" is much better.

Nat

2013/2/15 Richer, Justin P. <jricher@mitre.org><=
/p>
Everyone, there's a new draft of DynReg up on th=
e tracker. This draft tries to codify the discussions so far from this week=
 into something we can all read. There are still plenty of open discussion =
points and items up for debate. Please
 read through this latest draft and see what's changed and help assure =
that it properly captures the conversations. If you have any inputs for the=
 marked [[ Editor's Note ]] sections, please send them to the list by n=
ext Thursday to give me opportunity to get
 any necessary changes in by the cutoff date of Monday the 22nd.

Thanks for all of your hard work everyone, I think this is *really* coming =
along now.

=A0-- Justin

On Feb 15, 2013, at 4:54 PM, internet-drafts@ietf.org wrote:

>

> A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.

> This draft is a work item of the Web Authorization Protocol Working Gr=
oup of the IETF.

>

> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : OAuth Dynamic Client Registrat=
ion Protocol

> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Justin Richer

> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0John Bradley

> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Michael B. Jones
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Maciej Machulak

> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-oauth-dyn-reg-06.txt<=
br>
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 21

> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-02-15

>

> Abstract:

> =A0 This specification defines an endpoint and protocol for dynamic
> =A0 registration of OAuth Clients at an Authorization Server.

>

>

> The IETF datatracker status page for this draft is:

> 
https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg

>

> There's also a htmlized version available at:

> 
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06

>

> A diff from the previous version is available at:

> 
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-06

>

>

> Internet-Drafts are also available by anonymous FTP at:

> ftp:=
//ftp.ietf.org/internet-drafts/

>

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=

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

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

=A0

-- 

Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation

http://nat.sakimura.=
org/

@_nat_en

-- 
Nat Sakimura=
 (=3Dnat)Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--20cf3074b51a19334a04d62acc16--

From sakimura@gmail.com  Wed Feb 20 08:56:47 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9038321E8048 for ; Wed, 20 Feb 2013 08:56:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.236
X-Spam-Level: 
X-Spam-Status: No, score=-3.236 tagged_above=-999 required=5 tests=[AWL=0.362,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWR8Z1bQrTXm for ; Wed, 20 Feb 2013 08:56:46 -0800 (PST)
Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE9421E8051 for ; Wed, 20 Feb 2013 08:56:46 -0800 (PST)
Received: by mail-qe0-f45.google.com with SMTP id b4so3751346qen.18 for ; Wed, 20 Feb 2013 08:56:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Mi5bueCMZ+cU1OL95VVQ+yMK6Y3+aOu/PIS/6SQ0D64=; b=k4QC3Cxshv6Nti/Mp1080dNae6KLgruaIfR9q7PM6uJBx1xDbZFJMTejqAazAoGOVK q0Jv7oEOfU3mJru7dYWnMmxJVANc+3iSmjJOBbx9hX1WkvhC34sMBDR9kubNmAVlAKEz N0rKLILovFXZmy72Cueco7lTlvQokt0TOW2YvY+mhJrLEPdN9C8cF1E5t3W4zhqsOPsp AKEp7ieoAoESrEstW4JNhWRaEBzcEcOEgYRC3prFzojsubAH4y+cJvfQuqyTfOvRChSU onPouYvUzdZNm2CUiVPMCvQTDzLCV78btenKUamhm7/zGwrXini5Jph1n/u7BMauc2Aj XDhw==
MIME-Version: 1.0
X-Received: by 10.49.75.226 with SMTP id f2mr10205713qew.43.1361379405648; Wed, 20 Feb 2013 08:56:45 -0800 (PST)
Received: by 10.49.106.161 with HTTP; Wed, 20 Feb 2013 08:56:45 -0800 (PST)
In-Reply-To: 
References: <20130215215423.23019.50224.idtracker@ietfa.amsl.com>   <4E1F6AAD24975D4BA5B16804296739436747A665@TK5EX14MBXC284.redmond.corp.microsoft.com> <63255CDA-E93F-4414-B471-B373C4B6F65E@ve7jtb.com> 
Date: Wed, 20 Feb 2013 11:56:45 -0500
Message-ID: 
From: Nat Sakimura 
To: Tim Bray 
Content-Type: multipart/alternative; boundary=047d7bdcab52e0d2d404d62ad730
Cc: "" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2013 16:56:47 -0000

--047d7bdcab52e0d2d404d62ad730
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

You are right. I am in the camp recommending the use of URL when it is a
concrete endpoint and URI when it includes something that is only abstract,
but since OAuth standardized on "uri", we may as well do so here.

Nat

2013/2/20 Tim Bray 

> In OAuth, we have redirect_uri not redirect_url; should this be
> registration_access_uri for consistency? -T
>
>
> On Wed, Feb 20, 2013 at 8:23 AM, John Bradley  wrote:
>
>> I think registration_access_url is OK.    I haven't heard any better
>> names yet.
>>
>> John B.
>>
>> On 2013-02-20, at 1:04 PM, Mike Jones 
>> wrote:
>>
>>  For what it=92s worth, the name =93registration_access_url=94 was chose=
n to
>> be parallel to =93registration_access_token=94.   It=92s the place you u=
se the
>> access token.  And it=92s where you access an existing registration.  I=
=92m
>> against the name =93client_metadata_url=94 because it=92s not metadata y=
ou=92re
>> accessing =96 it=92s a registration you=92re accessing.  For the same re=
ason, I
>> don=92t think the name =93client_info_url=94 gives people the right idea=
, because
>> it doesn=92t say anything it being the registration that you=92re access=
ing.*
>> ***
>>
>> If you really want us to change this, having read what=92s above, I coul=
d
>> live with =93client_registration_url=94, but I don=92t think a change is=
 actually
>> necessary.  (But if we are going to change it, let=92s do it ASAP, befor=
e the
>> OpenID Connect Implementer=92s Drafts are published.)****
>>
>>                                                             -- Mike****
>>
>> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On
>> Behalf Of *Nat Sakimura
>> *Sent:* Wednesday, February 20, 2013 7:58 AM
>> *To:* ; Richer, Justin P.; John Bradley
>> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt***=
*
>> ** **
>> Thanks Justin.
>>
>> Even if we go flat rather than doing JSON Structure, the "Client
>> Registration Access Endpoint" is not a good representative name.
>>
>> What it represents is the client metadata/info.
>> It is not representing "Client Registration Access". ****
>> What does "Client Registration Access" mean? ****
>>
>> Does UPDATing "Cleint Registration Access" make sense?
>>
>> Something in the line of "Client Metadata Endpoint" and
>> something like "client_metadata_url" or "client_info_url" is much better=
.
>>
>> Nat****
>> 2013/2/15 Richer, Justin P. ****
>> Everyone, there's a new draft of DynReg up on the tracker. This draft
>> tries to codify the discussions so far from this week into something we =
can
>> all read. There are still plenty of open discussion points and items up =
for
>> debate. Please read through this latest draft and see what's changed and
>> help assure that it properly captures the conversations. If you have any
>> inputs for the marked [[ Editor's Note ]] sections, please send them to =
the
>> list by next Thursday to give me opportunity to get any necessary change=
s
>> in by the cutoff date of Monday the 22nd.
>>
>> Thanks for all of your hard work everyone, I think this is *really*
>> coming along now.
>>
>>  -- Justin****
>>
>> On Feb 15, 2013, at 4:54 PM, internet-drafts@ietf.org wrote:
>>
>> >
>> > A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> > This draft is a work item of the Web Authorization Protocol Working
>> Group of the IETF.
>> >
>> >       Title           : OAuth Dynamic Client Registration Protocol
>> >       Author(s)       : Justin Richer
>> >                          John Bradley
>> >                          Michael B. Jones
>> >                          Maciej Machulak
>> >       Filename        : draft-ietf-oauth-dyn-reg-06.txt
>> >       Pages           : 21
>> >       Date            : 2013-02-15
>> >
>> > Abstract:
>> >   This specification defines an endpoint and protocol for dynamic
>> >   registration of OAuth Clients at an Authorization Server.
>> >
>> >
>> > The IETF datatracker status page for this draft is:
>> > https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
>> >
>> > There's also a htmlized version available at:
>> > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06
>> >
>> > A diff from the previous version is available at:
>> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-06
>> >
>> >
>> > Internet-Drafts are also available by anonymous FTP at:
>> > ftp://ftp.ietf.org/internet-drafts/
>> >
>> > _______________________________________________
>> > 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****
>>
>>
>> ****
>> ** **
>> --
>> Nat Sakimura (=3Dnat)****
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>>
>>
>>
>> _______________________________________________
>> 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
>
>

--=20
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--047d7bdcab52e0d2d404d62ad730
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

You are right. I am in the camp recommending the use of URL when it is a co=
ncrete endpoint and URI when it includes something that is only abstract, b=
ut since OAuth standardized on "uri", we may as well do so here.=
=A0

Nat

2013/2/20 Tim Bray <t=
wbray@google.com>

In OAuth, we have redirect_uri not redirect_url; should this be registratio=
n_access_uri for consistency? -T
On Wed, Feb 20, 2013 at 8:23 AM, John Bradl=
ey <ve7jtb@ve7jtb.com> wrote:

I think =
registration_access_url is OK. =A0 =A0I haven't heard any better names =
yet.

John B.
On 2013-02-20, at 1:04 PM, Mi=
ke Jones <Michael.Jones@microsoft.com> wrote:

For what it=92s worth, the name =93regi=
stration_access_url=94 was chosen to be parallel to =93registration_access_=
token=94.=A0=A0 It=92s the place you use the access token.=A0 And it=92s wh=
ere you access an existing registration.=A0 I=92m against the name =93clien=
t_metadata_url=94 because it=92s not metadata you=92re accessing =96 it=92s=
 a registration you=92re accessing.=A0 For the same reason, I don=92t think=
 the name =93client_info_url=94 gives people the right idea, because it doe=
sn=92t say anything it being the registration that you=92re accessing.

=A0

If you really want us to change this, having read what=92s above, I=
 could live with =93client_registration_url=94, but I don=92t think a chang=
e is actually necessary.=A0 (But if we are going to change it, let=92s do i=
t ASAP, before the OpenID Connect Implementer=92s Drafts are published.)=

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike

=A0
From:=A0oauth-bounces@ietf.org [mailto:<=
a href=3D"mailto:oauth-" target=3D"_blank">oauth-bounces@ietf.org]=A0On =
Behalf Of=A0Nat Sakimura

Sent:=A0Wednesday, February 20, 2013 7:58 AM
To:<=
/b>=A0<=
oauth@ietf.org>; Richer, Justin P.; John Bradley
Subject:<=
span>=A0Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

=A0
Thanks Justin.

Even if we go flat ra=
ther than doing JSON Structure, the "Client
Registration Access Endpoint" is not=
 a good representative name.

What it represents is=
 the client metadata/info.
It is not representing "Client Registration Access".=
=A0

What does "Client Registration Access"=
; mean?=A0

Does UPDATing "Cleint Registr=
ation Access" make sense?

Something in the line of =
"Client Metadata Endpoint" and
something like "client_metadata_url" or=
=A0"client_info_url" is much better.

Nat<=
/u>
2013/2/15 Richer, Justin P. <<=
a href=3D"mailto:jricher@mitre.org" style=3D"color:purple;text-decoration:u=
nderline" target=3D"_blank">jricher@mitre.org>

Everyone, there's a new draft of DynReg up on th=
e tracker. This draft tries to codify the discussions so far from this week=
 into something we can all read. There are still plenty of open discussion =
points and items up for debate. Please read through this latest draft and s=
ee what's changed and help assure that it properly captures the convers=
ations. If you have any inputs for the marked [[ Editor's Note ]] secti=
ons, please send them to the list by next Thursday to give me opportunity t=
o get any necessary changes in by the cutoff date of Monday the 22nd.

Thanks for all of your hard work everyone, I think this is *really* com=
ing along now.

=A0-- Ju=
stin

On Feb 15, 2013, at 4:54 PM,=A0internet-drafts@ietf.org=A0wrote:

>
=
> A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.

> This draft is a work item of the Web Authorization Protocol Working Gr=
oup of the IETF.
>
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : OA=
uth Dynamic Client Registration Protocol
> =A0 =A0 =A0 Author(s) =A0 =
=A0 =A0 : Justin Richer

> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0John Bradley
>=
; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Michael B. Jones
&g=
t; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Maciej Machulak
&g=
t; =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-oauth-dyn-reg-06.txt> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 21

> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-02-15
>
> A=
bstract:
> =A0 This specification defines an endpoint and protocol fo=
r dynamic
> =A0 registration of OAuth Clients at an Authorization Ser=
ver.
>
>

> The IETF datatracker status page for this draft is:
>=A0https://=
datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg

>
> There's also a htmlized version available at:
>=A0http:=
//tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06

>
> A diff from the previous version is available at:
>=A0http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-06

>
>
> Internet-Drafts are also available by anonymous FTP at=
:
>=A0ftp://ftp.=
ietf.org/internet-drafts/

>
> _______________________________________________
> OAuth =
mailing list
>=A0OAuth@ietf.or=
g

>=A0https:/=
/www.ietf.org/mailman/listinfo/oauth

___________________________=
____________________

OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/lis=
tinfo/oauth

=A0
--=A0
N=
at Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sa=
kimura.org/
@_nat_en

_______________________________________________=

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

-- 
Nat Saki=
mura (=3Dnat)Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--047d7bdcab52e0d2d404d62ad730--

From Michael.Jones@microsoft.com  Wed Feb 20 09:01:23 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC8921F88CB for ; Wed, 20 Feb 2013 09:01:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.584
X-Spam-Level: 
X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.014,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbZ9CWQ5Bls7 for ; Wed, 20 Feb 2013 09:01:06 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.30]) by ietfa.amsl.com (Postfix) with ESMTP id D842421F8836 for ; Wed, 20 Feb 2013 09:01:03 -0800 (PST)
Received: from BL2FFO11FD005.protection.gbl (10.173.161.202) by BL2FFO11HUB014.protection.gbl (10.173.160.106) with Microsoft SMTP Server (TLS) id 15.0.620.12; Wed, 20 Feb 2013 17:00:55 +0000
Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD005.mail.protection.outlook.com (10.173.161.1) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Wed, 20 Feb 2013 17:00:55 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.96]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Wed, 20 Feb 2013 17:00:17 +0000
From: Mike Jones 
To: Nat Sakimura , Tim Bray 
Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
Thread-Index: AQHOC8cMkbohP5vU0EO7eTLi/U/hMJh7eCuAgAd2gACAAAA6MIAABsiAgAADAoCAAAZKgIAAAIEA
Date: Wed, 20 Feb 2013 17:00:17 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436747AD87@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <20130215215423.23019.50224.idtracker@ietfa.amsl.com>   <4E1F6AAD24975D4BA5B16804296739436747A665@TK5EX14MBXC284.redmond.corp.microsoft.com> <63255CDA-E93F-4414-B471-B373C4B6F65E@ve7jtb.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.33]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436747AD87TK5EX14MBXC284r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377424002)(479174001)(377454001)(51704002)(69224001)(199002)(189002)(24454001)(65554002)(5343655001)(74502001)(54356001)(51856001)(74662001)(80022001)(54316002)(66066001)(56776001)(50986001)(16236675001)(56816002)(49866001)(47976001)(55846006)(512954001)(46102001)(47736001)(4396001)(76482001)(77982001)(59766001)(65816001)(79102001)(53806001)(5343635001)(47446002)(44976002)(31966008)(16406001)(15202345001)(20776003)(63696002)(33656001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB014; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07630F72AD
Cc: "" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2013 17:01:23 -0000

--_000_4E1F6AAD24975D4BA5B16804296739436747AD87TK5EX14MBXC284r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Tim, as background, this came from the OpenID Connect specs, where we tried=
 to consistently use the convention that the locator for any resource that =
can be retrieved from the specified location be called a URL, whereas any i=
dentifier that may not be retrievable is called a URI.  That was done as an=
 aid to developer understanding of the specifications.

If the use of "URL" is deprecated by the IETF in favor of always just using=
 "URI", I suppose we could change that, but if it's going to change, it sho=
uld be soon.

                                                            -- Mike

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of N=
at Sakimura
Sent: Wednesday, February 20, 2013 8:57 AM
To: Tim Bray
Cc: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

You are right. I am in the camp recommending the use of URL when it is a co=
ncrete endpoint and URI when it includes something that is only abstract, b=
ut since OAuth standardized on "uri", we may as well do so here.

Nat
2013/2/20 Tim Bray >
In OAuth, we have redirect_uri not redirect_url; should this be registratio=
n_access_uri for consistency? -T

On Wed, Feb 20, 2013 at 8:23 AM, John Bradley > wrote:
I think registration_access_url is OK.    I haven't heard any better names =
yet.

John B.

On 2013-02-20, at 1:04 PM, Mike Jones > wrote:

For what it's worth, the name "registration_access_url" was chosen to be pa=
rallel to "registration_access_token".   It's the place you use the access =
token.  And it's where you access an existing registration.  I'm against th=
e name "client_metadata_url" because it's not metadata you're accessing - i=
t's a registration you're accessing.  For the same reason, I don't think th=
e name "client_info_url" gives people the right idea, because it doesn't sa=
y anything it being the registration that you're accessing.

If you really want us to change this, having read what's above, I could liv=
e with "client_registration_url", but I don't think a change is actually ne=
cessary.  (But if we are going to change it, let's do it ASAP, before the O=
penID Connect Implementer's Drafts are published.)

                                                            -- Mike

From: oauth-bounces@ietf.org [mailto:oauth-<=
mailto:oauth->bounces@ietf.org] On Behalf Of Nat S=
akimura
Sent: Wednesday, February 20, 2013 7:58 AM
To: >; Richer, Justin P.; John Bradle=
y
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

Thanks Justin.

Even if we go flat rather than doing JSON Structure, the "Client
Registration Access Endpoint" is not a good representative name.

What it represents is the client metadata/info.
It is not representing "Client Registration Access".
What does "Client Registration Access" mean?
Does UPDATing "Cleint Registration Access" make sense?

Something in the line of "Client Metadata Endpoint" and
something like "client_metadata_url" or "client_info_url" is much better.

Nat
2013/2/15 Richer, Justin P. >
Everyone, there's a new draft of DynReg up on the tracker. This draft tries=
 to codify the discussions so far from this week into something we can all =
read. There are still plenty of open discussion points and items up for deb=
ate. Please read through this latest draft and see what's changed and help =
assure that it properly captures the conversations. If you have any inputs =
for the marked [[ Editor's Note ]] sections, please send them to the list b=
y next Thursday to give me opportunity to get any necessary changes in by t=
he cutoff date of Monday the 22nd.

Thanks for all of your hard work everyone, I think this is *really* coming =
along now.

 -- Justin

On Feb 15, 2013, at 4:54 PM, internet-drafts@ietf.org wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
> This draft is a work item of the Web Authorization Protocol Working Group=
 of the IETF.
>
>       Title           : OAuth Dynamic Client Registration Protocol
>       Author(s)       : Justin Richer
>                          John Bradley
>                          Michael B. Jones
>                          Maciej Machulak
>       Filename        : draft-ietf-oauth-dyn-reg-06.txt
>       Pages           : 21
>       Date            : 2013-02-15
>
> Abstract:
>   This specification defines an endpoint and protocol for dynamic
>   registration of OAuth Clients at an Authorization Server.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-06
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> 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

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

_______________________________________________
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

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--_000_4E1F6AAD24975D4BA5B16804296739436747AD87TK5EX14MBXC284r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Tim, as background, this =
came from the OpenID Connect specs, where we tried to consistently use the =
convention that the locator for any resource that can be
 retrieved from the specified location be called a URL, whereas any identif=
ier that may not be retrievable is called a URI.  That was done as an =
aid to developer understanding of the specifications.
 <=
/p>
If the use of “URL&=
#8221; is deprecated by the IETF in favor of always just using “URI&#=
8221;, I suppose we could change that, but if it’s going to change, i=
t should be
 soon.
 <=
/p>
    &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;     -- Mike
 <=
/p>
 <=
/p>
From: oauth-bo=
unces@ietf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Nat Sakimura

Sent: Wednesday, February 20, 2013 8:57 AM

To: Tim Bray

Cc: <oauth@ietf.org>

Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt<=
o:p>

You are right. I am in the camp recommending the use=
 of URL when it is a concrete endpoint and URI when it includes something t=
hat is only abstract, but since OAuth standardized on "uri", we m=
ay as well do so here. 

Nat

2013/2/20 Tim Bray <twbray@google.com>
In OAuth, we have redirect_uri not redirect_url; sho=
uld this be registration_access_uri for consistency? -T

On Wed, Feb 20, 2013 at 8:23 AM, John Bradley <ve7jtb@ve7jtb.com&=
gt; wrote:

I think registration_access_url is OK.    =
I haven't heard any better names yet.

John B.

On 2013-02-20, at 1:04 PM, Mike Jones <Michael.Jones@micros=
oft.com> wrote:

For what it’s worth=
, the name “registration_access_url” was chosen to be parallel =
to “registration_access_token”.   It’s the plac=
e you use the access token. 
 And it’s where you access an existing registration.  I’m =
against the name “client_metadata_url” because it’s not m=
etadata you’re accessing – it’s a registration you’=
re accessing.  For the same reason, I don’t think the name ̶=
0;client_info_url” gives people the
 right idea, because it doesn’t say anything it being the registratio=
n that you’re accessing.

 <=
/p>

If you really want us to =
change this, having read what’s above, I could live with “clien=
t_registration_url”, but I don’t think a change is actually nec=
essary. 
 (But if we are going to change it, let’s do it ASAP, before the Open=
ID Connect Implementer’s Drafts are published.)

 <=
/p>

    &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;     -- Mike

 <=
/p>

From: oauth-bounces@ietf=
.org [mailto:oauth-bounces@ietf.org]&nbs=
p;On
 Behalf Of Nat Sakimura

Sent: Wednesday, February 20, 2013 7:58 AM

To: <oau=
th@ietf.org>; Richer, Justin P.; John Bradley

Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06=
.txt

Thanks Justin.

Even if we go flat rather than doing JSON Structure, the "Client

Registration Access Endpoint" is not a good representative name.

What it represents is the client metadata/info.

It is not representing "Client Registration Access". =

What does "Client Registration Access" mea=
n? 

Does UPDATing "Cleint Registration Access" make sense?=

Something in the line of "Client Metadata Endpoint" and

something like "client_metadata_url" or "client_info_ur=
l" is much better.

Nat

2013/2/15 Richer, Justin P. <jricher@mit=
re.org>

Everyone, there's a new draft of DynReg up on the tr=
acker. This draft tries to codify the discussions so far from this week int=
o something we can all read. There are still plenty of open discussion poin=
ts and items up for debate. Please
 read through this latest draft and see what's changed and help assure that=
 it properly captures the conversations. If you have any inputs for the mar=
ked [[ Editor's Note ]] sections, please send them to the list by next Thur=
sday to give me opportunity to get
 any necessary changes in by the cutoff date of Monday the 22nd.

Thanks for all of your hard work everyone, I think this is *really* coming =
along now.

 -- Justin

On Feb 15, 2013, at 4:54 PM, internet-drafts@ietf.org<=
/span> wrote:

>

> A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.

> This draft is a work item of the Web Authorization Protocol Working Gr=
oup of the IETF.

>

>       Title           : OAuth =
Dynamic Client Registration Protocol

>       Author(s)       : Justin Richer
>                     =
     John Bradley

>                     =
     Michael B. Jones

>                     =
     Maciej Machulak

>       Filename        : draft-ietf-=
oauth-dyn-reg-06.txt

>       Pages           : 21

>       Date            : 2=
013-02-15

>

> Abstract:

>   This specification defines an endpoint and protocol for dynamic=

>   registration of OAuth Clients at an Authorization Server.

>

>

> The IETF datatracker status page for this draft is:

> https://datatracker.iet=
f.org/doc/draft-ietf-oauth-dyn-reg

>

> There's also a htmlized version available at:

> http://tools.ietf.org/html=
/draft-ietf-oauth-dyn-reg-06

>

> A diff from the previous version is available at:

> http://www.ietf.or=
g/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-06

>

>

> Internet-Drafts are also available by anonymous FTP at:

> ftp://ftp.ietf.org/internet-drafts/

>

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org

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

_______________________________________________

OAuth mailing list

OAuth@ietf.org

<=
span style=3D"color:purple">https://www.ietf.org/mailman/listinfo/oauth

-- 

Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation

http://nat.sakimura.org/

@_nat_en

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

-- 

Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation

http://nat.sakimura.=
org/

@_nat_en

--_000_4E1F6AAD24975D4BA5B16804296739436747AD87TK5EX14MBXC284r_--

From Michael.Jones@microsoft.com  Wed Feb 20 09:03:50 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B1D21F871C for ; Wed, 20 Feb 2013 09:03:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.584
X-Spam-Level: 
X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.014,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvlq4GIYcBQZ for ; Wed, 20 Feb 2013 09:03:46 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.27]) by ietfa.amsl.com (Postfix) with ESMTP id A4FAD21F87D7 for ; Wed, 20 Feb 2013 09:03:24 -0800 (PST)
Received: from BY2FFO11FD008.protection.gbl (10.1.15.204) by BY2FFO11HUB012.protection.gbl (10.1.14.83) with Microsoft SMTP Server (TLS) id 15.0.620.12; Wed, 20 Feb 2013 17:03:21 +0000
Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD008.mail.protection.outlook.com (10.1.14.159) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Wed, 20 Feb 2013 17:03:21 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.96]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Wed, 20 Feb 2013 17:02:50 +0000
From: Mike Jones 
To: Nat Sakimura 
Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
Thread-Index: AQHOC8cMkbohP5vU0EO7eTLi/U/hMJh7eCuAgAd2gACAAAA6MIAADyiAgAAAlPA=
Date: Wed, 20 Feb 2013 17:02:50 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436747ADDB@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <20130215215423.23019.50224.idtracker@ietfa.amsl.com>   <4E1F6AAD24975D4BA5B16804296739436747A665@TK5EX14MBXC284.redmond.corp.microsoft.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.33]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436747ADDBTK5EX14MBXC284r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(69224001)(51444002)(51704002)(24454001)(65554002)(189002)(199002)(377424002)(377454001)(479174001)(74502001)(47446002)(31966008)(54316002)(74662001)(44976002)(53806001)(16406001)(46102001)(79102001)(63696002)(55846006)(51856001)(77982001)(65816001)(4396001)(47736001)(5343655001)(5343635001)(56776001)(49866001)(1411001)(512954001)(59766001)(76482001)(15202345001)(54356001)(16297215001)(50986001)(47976001)(66066001)(80022001)(56816002)(16236675001)(33656001)(20776003); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB012; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07630F72AD
Cc: "" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2013 17:03:50 -0000

--_000_4E1F6AAD24975D4BA5B16804296739436747ADDBTK5EX14MBXC284r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I could live with "registered_client_url".  I think that adding "_metadata"=
 or "_info" is incorrect, because what's being accessed is the client' regi=
stration - not just metadata or info about the client's registration (altho=
ugh that information can be retrieved as one aspect of the operations on th=
e client's registration).

                                                            -- Mike

From: Nat Sakimura [mailto:sakimura@gmail.com]
Sent: Wednesday, February 20, 2013 8:53 AM
To: Mike Jones
Cc: ; Richer, Justin P.; John Bradley
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

I have read the whole thing and still ---

Your argument that it is the place for using "registration access token" th=
us should have a parallel name "registration access url" is very weak. Ther=
e are several weakness.

First, "registration access token" actually is "registration" + "access tok=
en". Extracting "registration access" from "registration access token" is b=
roken.

Secondly, access token is used to against any protected resource. Recommend=
ing to use the word "access" in naming protected resources is broken. Shoul=
d we rename Userinfo endpoint to something like "Userinfo Access Endpoint"?=
 I do not think so.

Thirdly, the term "Registration Access" does not seem to be meaningful.
When you say "access", I suppose you are using the noun version of it.
(If you are using the verb, then I am even more against as a URL should not=
 contain a verb.)

According to the Webster, access (n.) is defined as:

access n.

1
a : onset 2
b : a fit of intense feeling : outburst
2
a : permission, liberty, or ability to enter, approach, or pass to and from=
 a place or to approach or communicate with a person or thing
b : freedom or ability to obtain or make use of something
c : a way or means of access
d : the act or an instance of accessing
3
: an increase by addition 

Replacing "access" with any of the definition above does not seem to work.

Remember, a URL is represents a "thing".
The name of the endpoint should represent the "thing".

I am merginally OK with "client registration url" leveraging on the definit=
ion 2. below (again from Webster -- my OED subscription lapsed for the time=
 being.)

registration n.

1
: the act of registering
2
: an entry in a register
3
: the number of individuals registered : enrollment
4
a : the art or act of selecting and adjusting pipe organ stops
b : the combination of stops selected for performing a particular organ wor=
k
5
: a document certifying an act of registering

However, since the most common use of "registration" is actually 1 above, i=
t still is confusing. If you really want to emphasize the fact that it has =
been registered, then something like "registered client info uri" or "regis=
tered client metadata uri" would be better.

Nat

2013/2/20 Mike Jones >
For what it's worth, the name "registration_access_url" was chosen to be pa=
rallel to "registration_access_token".   It's the place you use the access =
token.  And it's where you access an existing registration.  I'm against th=
e name "client_metadata_url" because it's not metadata you're accessing - i=
t's a registration you're accessing.  For the same reason, I don't think th=
e name "client_info_url" gives people the right idea, because it doesn't sa=
y anything it being the registration that you're accessing.

If you really want us to change this, having read what's above, I could liv=
e with "client_registration_url", but I don't think a change is actually ne=
cessary.  (But if we are going to change it, let's do it ASAP, before the O=
penID Connect Implementer's Drafts are published.)

                                                            -- Mike

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Nat Sakimura
Sent: Wednesday, February 20, 2013 7:58 AM
To: >; Richer, Justin P.; John Bradle=
y

Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

Thanks Justin.

Even if we go flat rather than doing JSON Structure, the "Client
Registration Access Endpoint" is not a good representative name.

What it represents is the client metadata/info.
It is not representing "Client Registration Access".
What does "Client Registration Access" mean?
Does UPDATing "Cleint Registration Access" make sense?

Something in the line of "Client Metadata Endpoint" and
something like "client_metadata_url" or "client_info_url" is much better.

Nat
2013/2/15 Richer, Justin P. >
Everyone, there's a new draft of DynReg up on the tracker. This draft tries=
 to codify the discussions so far from this week into something we can all =
read. There are still plenty of open discussion points and items up for deb=
ate. Please read through this latest draft and see what's changed and help =
assure that it properly captures the conversations. If you have any inputs =
for the marked [[ Editor's Note ]] sections, please send them to the list b=
y next Thursday to give me opportunity to get any necessary changes in by t=
he cutoff date of Monday the 22nd.

Thanks for all of your hard work everyone, I think this is *really* coming =
along now.

 -- Justin

On Feb 15, 2013, at 4:54 PM, internet-drafts@ietf.org wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
> This draft is a work item of the Web Authorization Protocol Working Group=
 of the IETF.
>
>       Title           : OAuth Dynamic Client Registration Protocol
>       Author(s)       : Justin Richer
>                          John Bradley
>                          Michael B. Jones
>                          Maciej Machulak
>       Filename        : draft-ietf-oauth-dyn-reg-06.txt
>       Pages           : 21
>       Date            : 2013-02-15
>
> Abstract:
>   This specification defines an endpoint and protocol for dynamic
>   registration of OAuth Clients at an Authorization Server.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-06
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> 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

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--_000_4E1F6AAD24975D4BA5B16804296739436747ADDBTK5EX14MBXC284r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I could live with “=
registered_client_url”.  I think that adding “_metadata=
221; or “_info” is incorrect, because what’s being access=
ed is the client’ registration
 – not just metadata or info about the client’s registration (a=
lthough that information can be retrieved as one aspect of the operations o=
n the client’s registration).
 <=
/p>
    &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;     -- Mike
 <=
/p>
From: Nat Saki=
mura [mailto:sakimura@gmail.com]

Sent: Wednesday, February 20, 2013 8:53 AM

To: Mike Jones

Cc: <oauth@ietf.org>; Richer, Justin P.; John Bradley

Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt<=
o:p>

I have read the whole thing and still --- =

Your argument that it is the place for using "r=
egistration access token" thus should have a parallel name "regis=
tration access url" is very weak. There are several weakness. 

First, "registration access token" actuall=
y is "registration" + "access token". Extracting &q=
uot;registration access" from "registration access token" is=
 broken. 

Secondly, access token is used to against any protec=
ted resource. Recommending to use the word "access" in =
naming protected resources is broken. Should we rename Userinfo endpoint to=
 something like "Userinfo Access Endpoint"? I do not think
 so. 

Thirdly, the term "Registration Access" do=
es not seem to be meaningful. 

When you say "access", I suppose you are u=
sing the noun version of it. 

(If you are using the verb, then I am even more agai=
nst as a URL should not contain a verb.) 

According to the Webster, access (n.) is defined as:=

access n.

1

a : onset 2
b : a
 fit of intense feeling : outburst

2

a : permission,
 liberty, or ability to enter, approach, or pass to and from a place or to =
approach or communicate with a person or thing
b : freedom
 or ability to obtain or make use of something
c : a
 way or means of access
d : the
 act or an instance of accessing

3

: an i=
ncrease by addition <a
 sudden access of wealth>

Replacing "access" with any of the definit=
ion above does not seem to work. 

Remember, a URL is represents a "thing".&n=
bsp;

The name of the endpoint should represent the "=
thing". 

I am merginally OK with "client registration ur=
l" leveraging on the definition 2. below (again from Webster -- my OED=
 subscription lapsed for the time being.) 

registration n.

1

: the =
act of registering

2

: an e=
ntry in a register

3

: the =
number of individuals registered<=
/span> : enrollment

4

a : the
 art or act of selecting and adjusting pipe organ stops
b : the
 combination of stops selected for performing a particular organ work

5

: a do=
cument certifying
 an act of registering

However, since the most common use of "registra=
tion" is actually
1 above, it still is confusing. If you really want to emphasize the =
fact that it has been registered, then something like "registered clie=
nt info uri" or "registered client metadata uri" would be be=
tter. 

Nat

2013/2/20 Mike Jones <Michael.Jones@microsoft.com>

For what it’s worth, the name =
220;registration_access_url” was chosen to be parallel to “regi=
stration_access_token”.  
 It’s the place you use the access token.  And it’s where =
you access an existing registration.  I’m against the name ̶=
0;client_metadata_url” because it’s not metadata you’re a=
ccessing – it’s a registration you’re accessing.  Fo=
r the same reason, I don’t think
 the name “client_info_url” gives people the right idea, becaus=
e it doesn’t say anything it being the registration that you’re=
 accessing.

If you really want us to change this, h=
aving read what’s above, I could live with “client_registration=
_url”,
 but I don’t think a change is actually necessary.  (But if we a=
re going to change it, let’s do it ASAP, before the OpenID Connect Im=
plementer’s Drafts are published.)

      &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;   -- Mike

From:
oauth-bounces@i=
etf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Nat Sakimura

Sent: Wednesday, February 20, 2013 7:58 AM

To: <oauth@ie=
tf.org>; Richer, Justin P.; John Bradley

Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt<=
o:p>

Thanks Justin.

Even if we go flat rather than doing JSON =
Structure, the "Client

Registration Access Endpoint" is not =
a good representative name.

What it represents is the client metadata/=
info.

It is not representing "Client Regist=
ration Access". 

What does "Client Registration Access" mean? <=
/o:p>

Does UPDATing "Cleint Reg=
istration Access" make sense?

Something in the line of "Client Meta=
data Endpoint" and

something like "client_metadata_url&q=
uot; or "client_info_url" is much better.

Nat

2013/2/15 Richer, Justin P. <jricher@mitre.org>
Everyone, there's a new draft of DynReg up on the tracker. This dr=
aft tries to codify the discussions so far from this week into something we=
 can all read. There are still plenty
 of open discussion points and items up for debate. Please read through thi=
s latest draft and see what's changed and help assure that it properly capt=
ures the conversations. If you have any inputs for the marked [[ Editor's N=
ote ]] sections, please send them
 to the list by next Thursday to give me opportunity to get any necessary c=
hanges in by the cutoff date of Monday the 22nd.

Thanks for all of your hard work everyone, I think this is *really* coming =
along now.

 -- Justin

On Feb 15, 2013, at 4:54 PM, 
internet-drafts@ietf.org wrote:

>

> A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.

> This draft is a work item of the Web Authorization Protocol Working Gr=
oup of the IETF.

>

>       Title           : OAuth =
Dynamic Client Registration Protocol

>       Author(s)       : Justin Richer
>                     =
     John Bradley

>                     =
     Michael B. Jones

>                     =
     Maciej Machulak

>       Filename        : draft-ietf-=
oauth-dyn-reg-06.txt

>       Pages           : 21

>       Date            : 2=
013-02-15

>

> Abstract:

>   This specification defines an endpoint and protocol for dynamic=

>   registration of OAuth Clients at an Authorization Server.

>

>

> The IETF datatracker status page for this draft is:

> 
https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg

>

> There's also a htmlized version available at:

> 
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06

>

> A diff from the previous version is available at:

> 
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-06

>

>

> Internet-Drafts are also available by anonymous FTP at:

> ftp:=
//ftp.ietf.org/internet-drafts/

>

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=

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

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

--

Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation

http://nat.sakimura.=
org/

@_nat_en

-- 

Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation

http://nat.sakimura.=
org/

@_nat_en

--_000_4E1F6AAD24975D4BA5B16804296739436747ADDBTK5EX14MBXC284r_--

From sakimura@gmail.com  Wed Feb 20 09:20:22 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8738221F8960 for ; Wed, 20 Feb 2013 09:20:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.262
X-Spam-Level: 
X-Spam-Status: No, score=-3.262 tagged_above=-999 required=5 tests=[AWL=0.336,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4USAEpLshJA for ; Wed, 20 Feb 2013 09:20:17 -0800 (PST)
Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5331021F84B9 for ; Wed, 20 Feb 2013 09:20:17 -0800 (PST)
Received: by mail-qe0-f44.google.com with SMTP id a11so3778615qen.17 for ; Wed, 20 Feb 2013 09:20:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=DIBOpMsUle2Xr2MMoUfDndK/aFmqJieQQ+IpnXkeCtU=; b=lpDXjbOlrBU/ZQUEaVDpLxITtxAipMUmazTC/30kDsUpr4o6bQNEqcPOLdv8jEIE7f 0hca4V2EKgquswB/u6Hbt+4NT0xVklJ60VMDM030A9EET7DvRAC6sQRYYJA5IXgy2XXl pnMFmDfZdyfSAevtO+2M3JPTk9OFExgdYSzicz/jfP9zFkI6cOnVOW4zXSiu15YdrbK5 YEk6+EgqYorqq8v2H0bbcAaw+FI4yO7RP3KSprZNXaotk6zUQC5A+fvv7nL7VA2eN97c yZgsQzxTrWt++Cs0nhdaE9MWWQ4ETRFEB0jYsU8hy+TD33Ro6tEeZW7uHAPgpEz3RmF4 XIOQ==
MIME-Version: 1.0
X-Received: by 10.224.177.204 with SMTP id bj12mr4076249qab.67.1361380816817;  Wed, 20 Feb 2013 09:20:16 -0800 (PST)
Received: by 10.49.106.161 with HTTP; Wed, 20 Feb 2013 09:20:16 -0800 (PST)
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436747ADDB@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <20130215215423.23019.50224.idtracker@ietfa.amsl.com>   <4E1F6AAD24975D4BA5B16804296739436747A665@TK5EX14MBXC284.redmond.corp.microsoft.com>  <4E1F6AAD24975D4BA5B16804296739436747ADDB@TK5EX14MBXC284.redmond.corp.microsoft.com>
Date: Wed, 20 Feb 2013 12:20:16 -0500
Message-ID: 
From: Nat Sakimura 
To: Mike Jones 
Content-Type: multipart/alternative; boundary=20cf302ef940fd900604d62b2ba8
Cc: "" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2013 17:20:22 -0000

--20cf302ef940fd900604d62b2ba8
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I have thought about that as well. The the reason I added "info" or
"metadata" was that what was behind the URL is not the client itself. By
"client registration", I suppose you mean "client entry in the register"
(cf. *registration **n* 2.) . It is the "registered data/info/metadata"
about the client.

Nat

2013/2/20 Mike Jones 

>  I could live with =93registered_client_url=94.  I think that adding
> =93_metadata=94 or =93_info=94 is incorrect, because what=92s being acces=
sed is the
> client=92 registration =96 not just metadata or info about the client=92s
> registration (although that information can be retrieved as one aspect of
> the operations on the client=92s registration).****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* Nat Sakimura [mailto:sakimura@gmail.com]
> *Sent:* Wednesday, February 20, 2013 8:53 AM
> *To:* Mike Jones
> *Cc:* ; Richer, Justin P.; John Bradley
>
> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt****
>
> ** **
>
> I have read the whole thing and still --- ****
>
> ** **
>
> Your argument that it is the place for using "registration access token"
> thus should have a parallel name "registration access url" is very weak.
> There are several weakness. ****
>
> ** **
>
> First, "registration access token" actually is "registration" + "access
> token". Extracting "registration access" from "registration access token"
> is broken. ****
>
> ** **
>
> Secondly, access token is used to against any protected
> resource. Recommending to use the word "access" in naming protected
> resources is broken. Should we rename Userinfo endpoint to something like
> "Userinfo Access Endpoint"? I do not think so. ****
>
> ** **
>
> Thirdly, the term "Registration Access" does not seem to be meaningful. *=
*
> **
>
> When you say "access", I suppose you are using the noun version of it. **=
*
> *
>
> (If you are using the verb, then I am even more against as a URL should
> not contain a verb.) ****
>
> ** **
>
> According to the Webster, access (n.) is defined as: ****
>
> ** **
>
> *access **n.*****
>
> ** **
>
> *1*
>
> *a* *:* onset  2****
>
> *b* *:* a fit of intense feeling *:* outburst
> ****
>
> *2*
>
> *a* *:* permission, liberty, or ability to enter, approach, or pass to
> and from a place or to approach or communicate with a person or thing****
>
> *b* *:* freedom or ability to obtain or make use of something****
>
> *c* *:* a way or means of access****
>
> *d* *:* the act or an instance of accessing
> ****
>
> *3*
>
> *:* an increase by addition ****
>
> ** **
>
> Replacing "access" with any of the definition above does not seem to work=
.
> ****
>
> ** **
>
> Remember, a URL is represents a "thing". ****
>
> The name of the endpoint should represent the "thing". ****
>
> ** **
>
> I am merginally OK with "client registration url" leveraging on the
> definition 2. below (again from Webster -- my OED subscription lapsed for
> the time being.) ****
>
> ** **
>
> *registration **n.*****
>
> ** **
>
> *1*
>
> *:* the act of registering
> ****
>
> *2*
>
> *:* an entry in a register
> ****
>
> *3*
>
> *:* the number of individuals registered
>  *:* enrollment ***=
*
>
> *4*
>
> *a* *:* the art or act of selecting and adjusting pipe organ stops****
>
> *b* *:* the combination of stops selected for performing a particular
> organ work****
>
> *5*
>
> *:* a document certifying an act of registering****
>
> ** **
>
> However, since the most common use of "registration" is actually *1*above=
, it still is confusing. If you really want to emphasize the fact that
> it has been registered, then something like "registered client info uri" =
or
> "registered client metadata uri" would be better. ****
>
> ** **
>
> Nat****
>
> ** **
>
> ** **
>
> 2013/2/20 Mike Jones ****
>
> For what it=92s worth, the name =93registration_access_url=94 was chosen =
to be
> parallel to =93registration_access_token=94.   It=92s the place you use t=
he
> access token.  And it=92s where you access an existing registration.  I=
=92m
> against the name =93client_metadata_url=94 because it=92s not metadata yo=
u=92re
> accessing =96 it=92s a registration you=92re accessing.  For the same rea=
son, I
> don=92t think the name =93client_info_url=94 gives people the right idea,=
 because
> it doesn=92t say anything it being the registration that you=92re accessi=
ng.**
> **
>
>  ****
>
> If you really want us to change this, having read what=92s above, I could
> live with =93client_registration_url=94, but I don=92t think a change is =
actually
> necessary.  (But if we are going to change it, let=92s do it ASAP, before=
 the
> OpenID Connect Implementer=92s Drafts are published.)****
>
>  ****
>
>                                                             -- Mike****
>
>  ****
>
> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf
> Of *Nat Sakimura
> *Sent:* Wednesday, February 20, 2013 7:58 AM
> *To:* ; Richer, Justin P.; John Bradley****
>
>
> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt****
>
>  ****
>
> Thanks Justin.****
>
>
>
> Even if we go flat rather than doing JSON Structure, the "Client
> Registration Access Endpoint" is not a good representative name.
>
> What it represents is the client metadata/info.
> It is not representing "Client Registration Access". ****
>
> What does "Client Registration Access" mean? ****
>
> Does UPDATing "Cleint Registration Access" make sense?
>
> Something in the line of "Client Metadata Endpoint" and
> something like "client_metadata_url" or "client_info_url" is much better.
>
> Nat****
>
> 2013/2/15 Richer, Justin P. ****
>
> Everyone, there's a new draft of DynReg up on the tracker. This draft
> tries to codify the discussions so far from this week into something we c=
an
> all read. There are still plenty of open discussion points and items up f=
or
> debate. Please read through this latest draft and see what's changed and
> help assure that it properly captures the conversations. If you have any
> inputs for the marked [[ Editor's Note ]] sections, please send them to t=
he
> list by next Thursday to give me opportunity to get any necessary changes
> in by the cutoff date of Monday the 22nd.
>
> Thanks for all of your hard work everyone, I think this is *really* comin=
g
> along now.
>
>  -- Justin****
>
>
> On Feb 15, 2013, at 4:54 PM, internet-drafts@ietf.org wrote:
>
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Web Authorization Protocol Working
> Group of the IETF.
> >
> >       Title           : OAuth Dynamic Client Registration Protocol
> >       Author(s)       : Justin Richer
> >                          John Bradley
> >                          Michael B. Jones
> >                          Maciej Machulak
> >       Filename        : draft-ietf-oauth-dyn-reg-06.txt
> >       Pages           : 21
> >       Date            : 2013-02-15
> >
> > Abstract:
> >   This specification defines an endpoint and protocol for dynamic
> >   registration of OAuth Clients at an Authorization Server.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-06
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > 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****
>
>
>
> ****
>
>  ****
>
> --
> Nat Sakimura (=3Dnat)****
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en****
>
>
>
> ****
>
> ** **
>
> --
> Nat Sakimura (=3Dnat)****
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en****
>

--=20
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--20cf302ef940fd900604d62b2ba8
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I have thought about that as well. The the reason I added "info" =
or "metadata" was that what was behind the URL is not the client =
itself. By "client registration", I suppose you mean "client=
 entry in the register" (cf. registration n 2.) . It is =
the "registered data/info/metadata" about the client.=A0

Nat

2013/2/20 Mike Jones <=
span dir=3D"ltr"><Michael.Jones@microsoft.com>

I could live with =93regi=
stered_client_url=94.=A0 I think that adding =93_metadata=94 or =93_info=94=
 is incorrect, because what=92s being accessed is the client=92 registratio=
n
 =96 not just metadata or info about the client=92s registration (although =
that information can be retrieved as one aspect of the operations on the cl=
ient=92s registration).
=A0<=
/p>
=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 -- Mike
=A0<=
/p>
From: Nat Saki=
mura [mailto:sakimu=
ra@gmail.com]

Sent: Wednesday, February 20, 2013 8:53 AM

To: Mike Jones

Cc: <oauth@ie=
tf.org>; Richer, Justin P.; John Bradley

Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt<=
u>

=A0
I have read the whole thing and still ---=A0<=
u>

=A0

Your argument that it is the place for using "r=
egistration access token" thus should have a parallel name "regis=
tration access url" is very weak. There are several weakness.=A0

=A0

First, "registration access token" actuall=
y is "registration" + "access token". Extracting "=
registration access" from "registration access token" is bro=
ken.=A0

=A0

Secondly, access token is used to against any protec=
ted resource.=A0Recommending=A0to use the word "access" in naming=
 protected resources is broken. Should we rename Userinfo endpoint to somet=
hing like "Userinfo Access Endpoint"? I do not think
 so.=A0

=A0

Thirdly, the term "Registration Access" do=
es not seem to be meaningful.=A0

When you say "access", I suppose you are u=
sing the noun version of it.=A0

(If you are using the verb, then I am even more agai=
nst as a URL should not contain a verb.)=A0

=A0

According to the Webster, access (n.) is defined as:=
=A0

=A0

access n.

=A0

1

a=A0:=A0onset=A02

b=A0:=A0a
 fit of intense feeling=A0:=A0outburst

2

a=A0:=A0permissio=
n,
 liberty, or ability to enter, approach, or pass to and from a place or to =
approach or communicate with a person or thing<=
/p>
b=A0:=A0freedom
 or ability to obtain or make use of something<=
/p>
c=A0:=A0a
 way or means of access
d=A0:=A0the
 act or an instance of=A0accessing

3

:=A0an increase by addition=
=A0<a
 sudden=A0access=A0of wealth>

=A0

Replacing "access" with any of the definit=
ion above does not seem to work.=A0

=A0

Remember, a URL is represents a "thing".=
=A0

The name of the endpoint should represent the "=
thing".=A0

=A0

I am merginally OK with "client registration ur=
l" leveraging on the definition 2. below (again from Webster -- my OED=
 subscription lapsed for the time being.)=A0

=A0

registration n.

=A0

1

:=A0the act of=A0<=
span style=3D"font-size:10.0pt;color:#1122cc">registering=

2

:=A0an entry in a=A0<=
span style=3D"font-size:10.0pt;color:#1122cc">register

3

:=A0the number of individua=
ls=A0registered=A0:=A0enrollm=
ent

4

a=A0:=A0the
 art or act of selecting and adjusting pipe organ stops

b=A0:=A0the
 combination of stops selected for performing a particular organ work

5

:=A0a document certifying
 an act of registering

=A0

However, since the most common use of "registra=
tion" is actually
1 above, it still is confusing. If you really want to emphasize the =
fact that it has been registered, then something like "registered clie=
nt info uri" or "registered client metadata uri" would be be=
tter.=A0

=A0

Nat

=A0

=A0

2013/2/20 Mike Jones <Michael.Jones@microsoft.com>

For what it=92s worth, th=
e name =93registration_access_url=94 was chosen to be parallel to =93regist=
ration_access_token=94.=A0=A0
 It=92s the place you use the access token.=A0 And it=92s where you access =
an existing registration.=A0 I=92m against the name =93client_metadata_url=
=94 because it=92s not metadata you=92re accessing =96 it=92s a registratio=
n you=92re accessing.=A0 For the same reason, I don=92t think
 the name =93client_info_url=94 gives people the right idea, because it doe=
sn=92t say anything it being the registration that you=92re accessing.
=A0<=
/p>
If you really want us to =
change this, having read what=92s above, I could live with =93client_regist=
ration_url=94,
 but I don=92t think a change is actually necessary.=A0 (But if we are goin=
g to change it, let=92s do it ASAP, before the OpenID Connect Implementer=
=92s Drafts are published.)
=A0<=
/p>
=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 -- Mike
=A0<=
/p>
From:
oauth-bounces@i=
etf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Nat Sakimura

Sent: Wednesday, February 20, 2013 7:58 AM

To: <oauth@ie=
tf.org>; Richer, Justin P.; John Bradley

Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt<=
u>

=A0
Thanks Jus=
tin.

Even if we go flat rather than doing JSON =
Structure, the "Client

Registration Access Endpoint" is not =
a good representative name.

What it represents is the client metadata/=
info.

It is not representing "Client Regist=
ration Access".=A0

What does "Client Registration Access" mea=
n?=A0

Does UPDATing "Cleint Registration Access" m=
ake sense?

Something in the line of "Client Meta=
data Endpoint" and

something like "client_metadata_url&q=
uot; or=A0"client_info_url" is much better.

Nat

2013/2/15 Richer, Justin P. <jricher@mitre.org><=
/p>
Everyone, there's a new draft of DynReg up on th=
e tracker. This draft tries to codify the discussions so far from this week=
 into something we can all read. There are still plenty
 of open discussion points and items up for debate. Please read through thi=
s latest draft and see what's changed and help assure that it properly =
captures the conversations. If you have any inputs for the marked [[ Editor=
's Note ]] sections, please send them
 to the list by next Thursday to give me opportunity to get any necessary c=
hanges in by the cutoff date of Monday the 22nd.

Thanks for all of your hard work everyone, I think this is *really* coming =
along now.

=A0-- Justin

On Feb 15, 2013, at 4:54 PM, 
internet-drafts@ietf.org wrote:

>

> A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.

> This draft is a work item of the Web Authorization Protocol Working Gr=
oup of the IETF.

>

> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : OAuth Dynamic Client Registrat=
ion Protocol

> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Justin Richer

> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0John Bradley

> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Michael B. Jones
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Maciej Machulak

> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-oauth-dyn-reg-06.txt<=
br>
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 21

> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-02-15

>

> Abstract:

> =A0 This specification defines an endpoint and protocol for dynamic
> =A0 registration of OAuth Clients at an Authorization Server.

>

>

> The IETF datatracker status page for this draft is:

> 
https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg

>

> There's also a htmlized version available at:

> 
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06

>

> A diff from the previous version is available at:

> 
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-06

>

>

> Internet-Drafts are also available by anonymous FTP at:

> ftp:=
//ftp.ietf.org/internet-drafts/

>

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=

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

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

=A0

--

Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation

http://nat.sakimura.=
org/

@_nat_en

=A0

-- 

Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation

http://nat.sakimura.=
org/

@_nat_en

-- 
Nat Sakimura=
 (=3Dnat)Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--20cf302ef940fd900604d62b2ba8--

From twbray@google.com  Wed Feb 20 09:22:20 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2720E21F8960 for ; Wed, 20 Feb 2013 09:22:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.858
X-Spam-Level: 
X-Spam-Status: No, score=-101.858 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7o8mQKJGUHH for ; Wed, 20 Feb 2013 09:22:16 -0800 (PST)
Received: from mail-ia0-x22f.google.com (ia-in-x022f.1e100.net [IPv6:2607:f8b0:4001:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 11AF321F84B9 for ; Wed, 20 Feb 2013 09:22:15 -0800 (PST)
Received: by mail-ia0-f175.google.com with SMTP id r4so7281264iaj.20 for ; Wed, 20 Feb 2013 09:22:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Pt96BFbJUTvO1k8SKKJdFhBGjlI1BnoyqxKWHcoQDNY=; b=FnJlnV783h7d0FByOySPSPNO/lXB0MA6yphoBkwUv7Ofb/mlogSH7u5tmBYlfnDdoV dJmkiagoYIa8XOFD4iz5WJ9izuGZE/wP31sUGhvJ0d3iYUVtBGDfeRBWC+pMbj1mgm90 APs5P35r9tQg0/ySvyMQuD4DhykcusULkScoL3mSbwuJE8vP4tWwviC0JnJwRY7yCUZO +MBdS0cCF+s7+bba9QldiXX9Uj7N3KYenLXVn8FgLkXxxROHoZ/24pZikGY33Keo4i8x KHK1C+DbsKIvglkwIlN8P3pV/Xttf6wqzYaYAzGYIcf2nDPkMOyFxEOrPUmWxuevgUo+ uq8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=Pt96BFbJUTvO1k8SKKJdFhBGjlI1BnoyqxKWHcoQDNY=; b=mc7TRUsr/jKYM88VbAgDZCKxuiS4gr3hD+Ck8Xp58Cnh9NgUV0HaDjmA9i6wWRxgI1 qbHeZkdHwu3QD4hlIE4NX2xqOhgku2glkqvn0ubOzlkZVdbIRMX0se1U3uMuFRGUJp6i KLKBrno4oPzjz5Z5yumoR25IAW5FxRh1/e5D5vWhkPzhRQyO2b4dbuUyFTiuDMuEoTeg wkqaXieeQf6ydkT637Ono6ADWIxjutyNf3U5r7OLmGPvZimZxOot0gXujxGAU74WzcbJ R6sLDQVQnhB7ealVtEbnMRpH0objpvnmyqWzCkF5SWNYsUycf3wyAwctrmHZkDBl3bJz EY3Q==
X-Received: by 10.50.181.201 with SMTP id dy9mr9391782igc.18.1361380920495; Wed, 20 Feb 2013 09:22:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.63.11 with HTTP; Wed, 20 Feb 2013 09:21:30 -0800 (PST)
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436747AD87@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <20130215215423.23019.50224.idtracker@ietfa.amsl.com>   <4E1F6AAD24975D4BA5B16804296739436747A665@TK5EX14MBXC284.redmond.corp.microsoft.com> <63255CDA-E93F-4414-B471-B373C4B6F65E@ve7jtb.com>   <4E1F6AAD24975D4BA5B16804296739436747AD87@TK5EX14MBXC284.redmond.corp.microsoft.com>
From: Tim Bray 
Date: Wed, 20 Feb 2013 09:21:30 -0800
Message-ID: 
To: Mike Jones 
Content-Type: multipart/alternative; boundary=14dae934096f2b8d9e04d62b320f
X-Gm-Message-State: ALoCoQlYosDhqN5EDLsJx4v6F3oN/wDY/TJHY4vVDowwvSNmC7ZE0wYQqqvG3zUxlaFpRdyDGw6wS75+to+xY8kVVheYkZQ1KHnKLQCBI+anjj+gx7fbLcchzCtSir8ytKkJBfhRXnt0x68s8m/vhQM8WG5gkE0ofyJBedhIp/nchwoUfzcwkxp/k6654S5Ky8142muTTlu7
Cc: "" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2013 17:22:20 -0000

--14dae934096f2b8d9e04d62b320f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Yes, =E2=80=9CURL=E2=80=9D is strongly and clearly deprecated in RFC3986 se=
ction 1.1.3; one
of the reasons is that the distinction between =E2=80=9Clocator=E2=80=9D an=
d =E2=80=9Cidentifier=E2=80=9D
which sounds like it should be easy, turns out to lead to theological
bikeshed discussions almost inevitably, and in fact be shaky in practice.
 -T

On Wed, Feb 20, 2013 at 9:00 AM, Mike Jones wr=
ote:

>  Tim, as background, this came from the OpenID Connect specs, where we
> tried to consistently use the convention that the locator for any resourc=
e
> that can be retrieved from the specified location be called a URL, wherea=
s
> any identifier that may not be retrievable is called a URI.  That was don=
e
> as an aid to developer understanding of the specifications.****
>
> ** **
>
> If the use of =E2=80=9CURL=E2=80=9D is deprecated by the IETF in favor of=
 always just
> using =E2=80=9CURI=E2=80=9D, I suppose we could change that, but if it=E2=
=80=99s going to change,
> it should be soon.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> ** **
>
> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf
> Of *Nat Sakimura
> *Sent:* Wednesday, February 20, 2013 8:57 AM
> *To:* Tim Bray
> *Cc:* 
> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt****
>
> ** **
>
> You are right. I am in the camp recommending the use of URL when it is a
> concrete endpoint and URI when it includes something that is only abstrac=
t,
> but since OAuth standardized on "uri", we may as well do so here. ****
>
> ** **
>
> Nat****
>
> 2013/2/20 Tim Bray ****
>
> In OAuth, we have redirect_uri not redirect_url; should this be
> registration_access_uri for consistency? -T****
>
> ** **
>
> On Wed, Feb 20, 2013 at 8:23 AM, John Bradley  wrote:*=
*
> **
>
> I think registration_access_url is OK.    I haven't heard any better name=
s
> yet.****
>
> ** **
>
> John B.****
>
> ** **
>
> On 2013-02-20, at 1:04 PM, Mike Jones  wrote=
:
> ****
>
>
>
> ****
>
> For what it=E2=80=99s worth, the name =E2=80=9Cregistration_access_url=E2=
=80=9D was chosen to be
> parallel to =E2=80=9Cregistration_access_token=E2=80=9D.   It=E2=80=99s t=
he place you use the
> access token.  And it=E2=80=99s where you access an existing registration=
.  I=E2=80=99m
> against the name =E2=80=9Cclient_metadata_url=E2=80=9D because it=E2=80=
=99s not metadata you=E2=80=99re
> accessing =E2=80=93 it=E2=80=99s a registration you=E2=80=99re accessing.=
  For the same reason, I
> don=E2=80=99t think the name =E2=80=9Cclient_info_url=E2=80=9D gives peop=
le the right idea, because
> it doesn=E2=80=99t say anything it being the registration that you=E2=80=
=99re accessing.**
> **
>
>  ****
>
> If you really want us to change this, having read what=E2=80=99s above, I=
 could
> live with =E2=80=9Cclient_registration_url=E2=80=9D, but I don=E2=80=99t =
think a change is actually
> necessary.  (But if we are going to change it, let=E2=80=99s do it ASAP, =
before the
> OpenID Connect Implementer=E2=80=99s Drafts are published.)****
>
>  ****
>
>                                                             -- Mike****
>
>  ****
>
> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf
> Of *Nat Sakimura
> *Sent:* Wednesday, February 20, 2013 7:58 AM
> *To:* ; Richer, Justin P.; John Bradley
> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt****
>
>  ****
>
> Thanks Justin.
>
> Even if we go flat rather than doing JSON Structure, the "Client
> Registration Access Endpoint" is not a good representative name.
>
> What it represents is the client metadata/info.
> It is not representing "Client Registration Access". ****
>
> What does "Client Registration Access" mean? ****
>
> Does UPDATing "Cleint Registration Access" make sense?
>
> Something in the line of "Client Metadata Endpoint" and
> something like "client_metadata_url" or "client_info_url" is much better.
>
> Nat****
>
> 2013/2/15 Richer, Justin P. ****
>
> Everyone, there's a new draft of DynReg up on the tracker. This draft
> tries to codify the discussions so far from this week into something we c=
an
> all read. There are still plenty of open discussion points and items up f=
or
> debate. Please read through this latest draft and see what's changed and
> help assure that it properly captures the conversations. If you have any
> inputs for the marked [[ Editor's Note ]] sections, please send them to t=
he
> list by next Thursday to give me opportunity to get any necessary changes
> in by the cutoff date of Monday the 22nd.
>
> Thanks for all of your hard work everyone, I think this is *really* comin=
g
> along now.
>
>  -- Justin****
>
>
> On Feb 15, 2013, at 4:54 PM, internet-drafts@ietf.org wrote:
>
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Web Authorization Protocol Working
> Group of the IETF.
> >
> >       Title           : OAuth Dynamic Client Registration Protocol
> >       Author(s)       : Justin Richer
> >                          John Bradley
> >                          Michael B. Jones
> >                          Maciej Machulak
> >       Filename        : draft-ietf-oauth-dyn-reg-06.txt
> >       Pages           : 21
> >       Date            : 2013-02-15
> >
> > Abstract:
> >   This specification defines an endpoint and protocol for dynamic
> >   registration of OAuth Clients at an Authorization Server.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-06
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > 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****
>
>
>
> ****
>
>  ****
>
> --
> Nat Sakimura (=3Dnat)****
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en****
>
> ** **
>
>
> _______________________________________________
> 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****
>
>
>
> ****
>
> ** **
>
> --
> Nat Sakimura (=3Dnat)****
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en****
>

--14dae934096f2b8d9e04d62b320f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Yes, =E2=80=9CURL=E2=80=9D is strongly and clearly deprecated in RFC3986 se=
ction 1.1.3; one of the reasons is that the distinction between =E2=80=9Clo=
cator=E2=80=9D and =E2=80=9Cidentifier=E2=80=9D which sounds like it should=
 be easy, turns out to lead to theological bikeshed discussions almost inev=
itably, and in fact be shaky in practice. =C2=A0-T

On Wed, Feb 20, 2013 at 9:00 AM, Mike Jones =
<Michael.Jones@microsoft.com> wrote:

Tim, as background, this =
came from the OpenID Connect specs, where we tried to consistently use the =
convention that the locator for any resource that can be
 retrieved from the specified location be called a URL, whereas any identif=
ier that may not be retrievable is called a URI.=C2=A0 That was done as an =
aid to developer understanding of the specifications.<=
/p>

=C2=A0
If the use of =E2=80=9CUR=
L=E2=80=9D is deprecated by the IETF in favor of always just using =E2=80=
=9CURI=E2=80=9D, I suppose we could change that, but if it=E2=80=99s going =
to change, it should be
 soon.
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike
=C2=A0
=C2=A0
From: oauth-bounces@ietf.org=
 [mailto:oa=
uth-bounces@ietf.org]
On Behalf Of Nat Sakimura

Sent: Wednesday, February 20, 2013 8:57 AM

To: Tim Bray

Cc: <oauth@ie=
tf.org>

Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt<=
u>
=C2=A0
You are right. I am in the camp recommending the use=
 of URL when it is a concrete endpoint and URI when it includes something t=
hat is only abstract, but since OAuth standardized on "uri", we m=
ay as well do so here.=C2=A0

=C2=A0

Nat

2013/2/20 Tim Bray <twbray@google.com>
In OAuth, we have redirect_uri not redirect_url; sho=
uld this be registration_access_uri for consistency? -T

=C2=A0<=
/p>

On Wed, Feb 20, 2013 at 8:23 AM, John Bradley <ve7jtb@ve7jtb.com&=
gt; wrote:

I think registration_access_url is OK. =C2=A0 =C2=A0=
I haven't heard any better names yet.

=C2=A0

John B.

=C2=A0

On 2013-02-20, at 1:04 PM, Mike Jones <Michael.Jones@micros=
oft.com> wrote:

For what it=E2=80=99s wor=
th, the name =E2=80=9Cregistration_access_url=E2=80=9D was chosen to be par=
allel to =E2=80=9Cregistration_access_token=E2=80=9D.=C2=A0=C2=A0 It=E2=80=
=99s the place you use the access token.=C2=A0
 And it=E2=80=99s where you access an existing registration.=C2=A0 I=E2=80=
=99m against the name =E2=80=9Cclient_metadata_url=E2=80=9D because it=E2=
=80=99s not metadata you=E2=80=99re accessing =E2=80=93 it=E2=80=99s a regi=
stration you=E2=80=99re accessing.=C2=A0 For the same reason, I don=E2=80=
=99t think the name =E2=80=9Cclient_info_url=E2=80=9D gives people the
 right idea, because it doesn=E2=80=99t say anything it being the registrat=
ion that you=E2=80=99re accessing.

=C2=A0

If you really want us to =
change this, having read what=E2=80=99s above, I could live with =E2=80=9Cc=
lient_registration_url=E2=80=9D, but I don=E2=80=99t think a change is actu=
ally necessary.=C2=A0
 (But if we are going to change it, let=E2=80=99s do it ASAP, before the Op=
enID Connect Implementer=E2=80=99s Drafts are published.)<=
/u>

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0

From:=C2=A0oauth-bounces@ietf=
.org [mailto:oauth-bounces@ietf.org]=C2=
=A0On
 Behalf Of=C2=A0Nat Sakimura

Sent:=C2=A0Wednesday, February 20, 2013 7:58 AM

To:=C2=A0<oau=
th@ietf.org>; Richer, Justin P.; John Bradley

Subject:=C2=A0Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06=
.txt

=C2=A0

Thanks Justin.

Even if we go flat rather than doing JSON Structure, the "Client

Registration Access Endpoint" is not a good representative name.

What it represents is the client metadata/info.

It is not representing "Client Registration Access".=C2=A0=

What does "Client Registration Access" mea=
n?=C2=A0

Does UPDATing "Cleint Registration Access" make sense?=

Something in the line of "Client Metadata Endpoint" and

something like "client_metadata_url" or=C2=A0"client_info_ur=
l" is much better.

Nat

2013/2/15 Richer, Justin P. <jricher@mit=
re.org>

Everyone, there's a new draft of DynReg up on th=
e tracker. This draft tries to codify the discussions so far from this week=
 into something we can all read. There are still plenty of open discussion =
points and items up for debate. Please
 read through this latest draft and see what's changed and help assure =
that it properly captures the conversations. If you have any inputs for the=
 marked [[ Editor's Note ]] sections, please send them to the list by n=
ext Thursday to give me opportunity to get
 any necessary changes in by the cutoff date of Monday the 22nd.

Thanks for all of your hard work everyone, I think this is *really* coming =
along now.

=C2=A0-- Justin

On Feb 15, 2013, at 4:54 PM,=C2=A0internet-drafts@ietf.org<=
/span>=C2=A0wrote:

>

> A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.

> This draft is a work item of the Web Authorization Protocol Working Gr=
oup of the IETF.

>

> =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : OAuth =
Dynamic Client Registration Protocol

> =C2=A0 =C2=A0 =C2=A0 Author(s) =C2=A0 =C2=A0 =C2=A0 : Justin Richer
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0John Bradley

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0Michael B. Jones

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0Maciej Machulak

> =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-ietf-=
oauth-dyn-reg-06.txt

> =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 21

> =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 2=
013-02-15

>

> Abstract:

> =C2=A0 This specification defines an endpoint and protocol for dynamic=

> =C2=A0 registration of OAuth Clients at an Authorization Server.

>

>

> The IETF datatracker status page for this draft is:

>=C2=A0https://datatracker.iet=
f.org/doc/draft-ietf-oauth-dyn-reg

>

> There's also a htmlized version available at:

>=C2=A0http://tools.ietf.org/html=
/draft-ietf-oauth-dyn-reg-06

>

> A diff from the previous version is available at:

>=C2=A0http://www.ietf.or=
g/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-06

>

>

> Internet-Drafts are also available by anonymous FTP at:

>=C2=A0ftp://ftp.ietf.org/internet-drafts/

>

> _______________________________________________

> OAuth mailing list

>=C2=A0OAuth@ietf.org

>=C2=A0https://www.ietf.org/mailman/listinfo=
/oauth

_______________________________________________

OAuth mailing list

OAuth@ietf.org

<=
span style=3D"color:purple">https://www.ietf.org/mailman/listinfo/oauth

=C2=A0

--=C2=A0

Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation

http://nat.sakimura.org/

@_nat_en

=C2=A0

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

=C2=A0

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

=C2=A0

-- 

Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation

http://nat.sakimura.=
org/

@_nat_en

--14dae934096f2b8d9e04d62b320f--

From Michael.Jones@microsoft.com  Wed Feb 20 09:58:19 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0687321F8681 for ; Wed, 20 Feb 2013 09:58:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.584
X-Spam-Level: 
X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.014,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1q0ohMb-ZibB for ; Wed, 20 Feb 2013 09:58:16 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.24]) by ietfa.amsl.com (Postfix) with ESMTP id 35E8D21F8473 for ; Wed, 20 Feb 2013 09:58:15 -0800 (PST)
Received: from BY2FFO11FD013.protection.gbl (10.1.15.204) by BY2FFO11HUB011.protection.gbl (10.1.14.82) with Microsoft SMTP Server (TLS) id 15.0.620.12; Wed, 20 Feb 2013 17:58:12 +0000
Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD013.mail.protection.outlook.com (10.1.14.75) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Wed, 20 Feb 2013 17:58:12 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.96]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0318.003; Wed, 20 Feb 2013 17:57:43 +0000
From: Mike Jones 
To: Tim Bray 
Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
Thread-Index: AQHOC8cMkbohP5vU0EO7eTLi/U/hMJh7eCuAgAd2gACAAAA6MIAABsiAgAADAoCAAAZKgIAAAIEAgAAGaQCAAAoJgA==
Date: Wed, 20 Feb 2013 17:57:42 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436747B12D@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <20130215215423.23019.50224.idtracker@ietfa.amsl.com>   <4E1F6AAD24975D4BA5B16804296739436747A665@TK5EX14MBXC284.redmond.corp.microsoft.com> <63255CDA-E93F-4414-B471-B373C4B6F65E@ve7jtb.com>   <4E1F6AAD24975D4BA5B16804296739436747AD87@TK5EX14MBXC284.redmond.corp.microsoft.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.33]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436747B12DTK5EX14MBXC284r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(24454001)(65554002)(189002)(377454001)(479174001)(377424002)(69224001)(51704002)(51914002)(54356001)(15202345001)(47976001)(50986001)(59766001)(76482001)(512874001)(56816002)(33656001)(20776003)(16236675001)(80022001)(66066001)(55846006)(63696002)(51856001)(77982001)(79102001)(74662001)(54316002)(31966008)(74502001)(47446002)(44976002)(16406001)(46102001)(65816001)(53806001)(47736001)(5343655001)(5343635001)(56776001)(49866001)(4396001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB011; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07630F72AD
Cc: "" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2013 17:58:19 -0000

--_000_4E1F6AAD24975D4BA5B16804296739436747B12DTK5EX14MBXC284r_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

T0ssIHdlIHNob3VsZCBtYWtlIHRoZSBjaGFuZ2UgdGhlbi4gIFRoYW5rcyBmb3IgdGhlIGlucHV0
Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAtLSBNaWtlDQoNCkZyb206IFRpbSBCcmF5IFttYWlsdG86dHdicmF5QGdvb2dsZS5j
b21dDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDIwLCAyMDEzIDk6MjIgQU0NClRvOiBNaWtl
IEpvbmVzDQpDYzogTmF0IFNha2ltdXJhOyA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog
W09BVVRILVdHXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW9hdXRoLWR5bi1yZWctMDYudHh0DQoN
Clllcywg4oCcVVJM4oCdIGlzIHN0cm9uZ2x5IGFuZCBjbGVhcmx5IGRlcHJlY2F0ZWQgaW4gUkZD
Mzk4NiBzZWN0aW9uIDEuMS4zOyBvbmUgb2YgdGhlIHJlYXNvbnMgaXMgdGhhdCB0aGUgZGlzdGlu
Y3Rpb24gYmV0d2VlbiDigJxsb2NhdG9y4oCdIGFuZCDigJxpZGVudGlmaWVy4oCdIHdoaWNoIHNv
dW5kcyBsaWtlIGl0IHNob3VsZCBiZSBlYXN5LCB0dXJucyBvdXQgdG8gbGVhZCB0byB0aGVvbG9n
aWNhbCBiaWtlc2hlZCBkaXNjdXNzaW9ucyBhbG1vc3QgaW5ldml0YWJseSwgYW5kIGluIGZhY3Qg
YmUgc2hha3kgaW4gcHJhY3RpY2UuICAtVA0KT24gV2VkLCBGZWIgMjAsIDIwMTMgYXQgOTowMCBB
TSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVs
LkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNClRpbSwgYXMgYmFja2dyb3VuZCwgdGhpcyBj
YW1lIGZyb20gdGhlIE9wZW5JRCBDb25uZWN0IHNwZWNzLCB3aGVyZSB3ZSB0cmllZCB0byBjb25z
aXN0ZW50bHkgdXNlIHRoZSBjb252ZW50aW9uIHRoYXQgdGhlIGxvY2F0b3IgZm9yIGFueSByZXNv
dXJjZSB0aGF0IGNhbiBiZSByZXRyaWV2ZWQgZnJvbSB0aGUgc3BlY2lmaWVkIGxvY2F0aW9uIGJl
IGNhbGxlZCBhIFVSTCwgd2hlcmVhcyBhbnkgaWRlbnRpZmllciB0aGF0IG1heSBub3QgYmUgcmV0
cmlldmFibGUgaXMgY2FsbGVkIGEgVVJJLiAgVGhhdCB3YXMgZG9uZSBhcyBhbiBhaWQgdG8gZGV2
ZWxvcGVyIHVuZGVyc3RhbmRpbmcgb2YgdGhlIHNwZWNpZmljYXRpb25zLg0KDQpJZiB0aGUgdXNl
IG9mIOKAnFVSTOKAnSBpcyBkZXByZWNhdGVkIGJ5IHRoZSBJRVRGIGluIGZhdm9yIG9mIGFsd2F5
cyBqdXN0IHVzaW5nIOKAnFVSSeKAnSwgSSBzdXBwb3NlIHdlIGNvdWxkIGNoYW5nZSB0aGF0LCBi
dXQgaWYgaXTigJlzIGdvaW5nIHRvIGNoYW5nZSwgaXQgc2hvdWxkIGJlIHNvb24uDQoNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0t
IE1pa2UNCg0KDQpGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3Vu
Y2VzQGlldGYub3JnPiBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRo
LWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgTmF0IFNha2ltdXJhDQpTZW50OiBXZWRu
ZXNkYXksIEZlYnJ1YXJ5IDIwLCAyMDEzIDg6NTcgQU0NClRvOiBUaW0gQnJheQ0KQ2M6IDxvYXV0
aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1X
R10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1vYXV0aC1keW4tcmVnLTA2LnR4dA0KDQpZb3UgYXJl
IHJpZ2h0LiBJIGFtIGluIHRoZSBjYW1wIHJlY29tbWVuZGluZyB0aGUgdXNlIG9mIFVSTCB3aGVu
IGl0IGlzIGEgY29uY3JldGUgZW5kcG9pbnQgYW5kIFVSSSB3aGVuIGl0IGluY2x1ZGVzIHNvbWV0
aGluZyB0aGF0IGlzIG9ubHkgYWJzdHJhY3QsIGJ1dCBzaW5jZSBPQXV0aCBzdGFuZGFyZGl6ZWQg
b24gInVyaSIsIHdlIG1heSBhcyB3ZWxsIGRvIHNvIGhlcmUuDQoNCk5hdA0KMjAxMy8yLzIwIFRp
bSBCcmF5IDx0d2JyYXlAZ29vZ2xlLmNvbTxtYWlsdG86dHdicmF5QGdvb2dsZS5jb20+Pg0KSW4g
T0F1dGgsIHdlIGhhdmUgcmVkaXJlY3RfdXJpIG5vdCByZWRpcmVjdF91cmw7IHNob3VsZCB0aGlz
IGJlIHJlZ2lzdHJhdGlvbl9hY2Nlc3NfdXJpIGZvciBjb25zaXN0ZW5jeT8gLVQNCg0KT24gV2Vk
LCBGZWIgMjAsIDIwMTMgYXQgODoyMyBBTSwgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNv
bTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PiB3cm90ZToNCkkgdGhpbmsgcmVnaXN0cmF0aW9u
X2FjY2Vzc191cmwgaXMgT0suICAgIEkgaGF2ZW4ndCBoZWFyZCBhbnkgYmV0dGVyIG5hbWVzIHll
dC4NCg0KSm9obiBCLg0KDQpPbiAyMDEzLTAyLTIwLCBhdCAxOjA0IFBNLCBNaWtlIEpvbmVzIDxN
aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0
LmNvbT4+IHdyb3RlOg0KDQpGb3Igd2hhdCBpdOKAmXMgd29ydGgsIHRoZSBuYW1lIOKAnHJlZ2lz
dHJhdGlvbl9hY2Nlc3NfdXJs4oCdIHdhcyBjaG9zZW4gdG8gYmUgcGFyYWxsZWwgdG8g4oCccmVn
aXN0cmF0aW9uX2FjY2Vzc190b2tlbuKAnS4gICBJdOKAmXMgdGhlIHBsYWNlIHlvdSB1c2UgdGhl
IGFjY2VzcyB0b2tlbi4gIEFuZCBpdOKAmXMgd2hlcmUgeW91IGFjY2VzcyBhbiBleGlzdGluZyBy
ZWdpc3RyYXRpb24uICBJ4oCZbSBhZ2FpbnN0IHRoZSBuYW1lIOKAnGNsaWVudF9tZXRhZGF0YV91
cmzigJ0gYmVjYXVzZSBpdOKAmXMgbm90IG1ldGFkYXRhIHlvdeKAmXJlIGFjY2Vzc2luZyDigJMg
aXTigJlzIGEgcmVnaXN0cmF0aW9uIHlvdeKAmXJlIGFjY2Vzc2luZy4gIEZvciB0aGUgc2FtZSBy
ZWFzb24sIEkgZG9u4oCZdCB0aGluayB0aGUgbmFtZSDigJxjbGllbnRfaW5mb191cmzigJ0gZ2l2
ZXMgcGVvcGxlIHRoZSByaWdodCBpZGVhLCBiZWNhdXNlIGl0IGRvZXNu4oCZdCBzYXkgYW55dGhp
bmcgaXQgYmVpbmcgdGhlIHJlZ2lzdHJhdGlvbiB0aGF0IHlvdeKAmXJlIGFjY2Vzc2luZy4NCg0K
SWYgeW91IHJlYWxseSB3YW50IHVzIHRvIGNoYW5nZSB0aGlzLCBoYXZpbmcgcmVhZCB3aGF04oCZ
cyBhYm92ZSwgSSBjb3VsZCBsaXZlIHdpdGgg4oCcY2xpZW50X3JlZ2lzdHJhdGlvbl91cmzigJ0s
IGJ1dCBJIGRvbuKAmXQgdGhpbmsgYSBjaGFuZ2UgaXMgYWN0dWFsbHkgbmVjZXNzYXJ5LiAgKEJ1
dCBpZiB3ZSBhcmUgZ29pbmcgdG8gY2hhbmdlIGl0LCBsZXTigJlzIGRvIGl0IEFTQVAsIGJlZm9y
ZSB0aGUgT3BlbklEIENvbm5lY3QgSW1wbGVtZW50ZXLigJlzIERyYWZ0cyBhcmUgcHVibGlzaGVk
LikNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpv
YXV0aC1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOm9hdXRoLTxtYWlsdG86b2F1dGgtPmJvdW5j
ZXNAaWV0Zi5vcmc8bWFpbHRvOmJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgTmF0IFNh
a2ltdXJhDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDIwLCAyMDEzIDc6NTggQU0NClRvOiA8
b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj47IFJpY2hlciwgSnVzdGluIFAu
OyBKb2huIEJyYWRsZXkNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEktRCBBY3Rpb246IGRyYWZ0
LWlldGYtb2F1dGgtZHluLXJlZy0wNi50eHQNCg0KVGhhbmtzIEp1c3Rpbi4NCg0KRXZlbiBpZiB3
ZSBnbyBmbGF0IHJhdGhlciB0aGFuIGRvaW5nIEpTT04gU3RydWN0dXJlLCB0aGUgIkNsaWVudA0K
UmVnaXN0cmF0aW9uIEFjY2VzcyBFbmRwb2ludCIgaXMgbm90IGEgZ29vZCByZXByZXNlbnRhdGl2
ZSBuYW1lLg0KDQpXaGF0IGl0IHJlcHJlc2VudHMgaXMgdGhlIGNsaWVudCBtZXRhZGF0YS9pbmZv
Lg0KSXQgaXMgbm90IHJlcHJlc2VudGluZyAiQ2xpZW50IFJlZ2lzdHJhdGlvbiBBY2Nlc3MiLg0K
V2hhdCBkb2VzICJDbGllbnQgUmVnaXN0cmF0aW9uIEFjY2VzcyIgbWVhbj8NCkRvZXMgVVBEQVRp
bmcgIkNsZWludCBSZWdpc3RyYXRpb24gQWNjZXNzIiBtYWtlIHNlbnNlPw0KDQpTb21ldGhpbmcg
aW4gdGhlIGxpbmUgb2YgIkNsaWVudCBNZXRhZGF0YSBFbmRwb2ludCIgYW5kDQpzb21ldGhpbmcg
bGlrZSAiY2xpZW50X21ldGFkYXRhX3VybCIgb3IgImNsaWVudF9pbmZvX3VybCIgaXMgbXVjaCBi
ZXR0ZXIuDQoNCk5hdA0KMjAxMy8yLzE1IFJpY2hlciwgSnVzdGluIFAuIDxqcmljaGVyQG1pdHJl
Lm9yZzxtYWlsdG86anJpY2hlckBtaXRyZS5vcmc+Pg0KRXZlcnlvbmUsIHRoZXJlJ3MgYSBuZXcg
ZHJhZnQgb2YgRHluUmVnIHVwIG9uIHRoZSB0cmFja2VyLiBUaGlzIGRyYWZ0IHRyaWVzIHRvIGNv
ZGlmeSB0aGUgZGlzY3Vzc2lvbnMgc28gZmFyIGZyb20gdGhpcyB3ZWVrIGludG8gc29tZXRoaW5n
IHdlIGNhbiBhbGwgcmVhZC4gVGhlcmUgYXJlIHN0aWxsIHBsZW50eSBvZiBvcGVuIGRpc2N1c3Np
b24gcG9pbnRzIGFuZCBpdGVtcyB1cCBmb3IgZGViYXRlLiBQbGVhc2UgcmVhZCB0aHJvdWdoIHRo
aXMgbGF0ZXN0IGRyYWZ0IGFuZCBzZWUgd2hhdCdzIGNoYW5nZWQgYW5kIGhlbHAgYXNzdXJlIHRo
YXQgaXQgcHJvcGVybHkgY2FwdHVyZXMgdGhlIGNvbnZlcnNhdGlvbnMuIElmIHlvdSBoYXZlIGFu
eSBpbnB1dHMgZm9yIHRoZSBtYXJrZWQgW1sgRWRpdG9yJ3MgTm90ZSBdXSBzZWN0aW9ucywgcGxl
YXNlIHNlbmQgdGhlbSB0byB0aGUgbGlzdCBieSBuZXh0IFRodXJzZGF5IHRvIGdpdmUgbWUgb3Bw
b3J0dW5pdHkgdG8gZ2V0IGFueSBuZWNlc3NhcnkgY2hhbmdlcyBpbiBieSB0aGUgY3V0b2ZmIGRh
dGUgb2YgTW9uZGF5IHRoZSAyMm5kLg0KDQpUaGFua3MgZm9yIGFsbCBvZiB5b3VyIGhhcmQgd29y
ayBldmVyeW9uZSwgSSB0aGluayB0aGlzIGlzICpyZWFsbHkqIGNvbWluZyBhbG9uZyBub3cuDQoN
CiAtLSBKdXN0aW4NCg0KT24gRmViIDE1LCAyMDEzLCBhdCA0OjU0IFBNLCBpbnRlcm5ldC1kcmFm
dHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQoNCj4N
Cj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50
ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9m
IHRoZSBXZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRG
Lg0KPg0KPiAgICAgICBUaXRsZSAgICAgICAgICAgOiBPQXV0aCBEeW5hbWljIENsaWVudCBSZWdp
c3RyYXRpb24gUHJvdG9jb2wNCj4gICAgICAgQXV0aG9yKHMpICAgICAgIDogSnVzdGluIFJpY2hl
cg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgSm9obiBCcmFkbGV5DQo+ICAgICAgICAgICAg
ICAgICAgICAgICAgICBNaWNoYWVsIEIuIEpvbmVzDQo+ICAgICAgICAgICAgICAgICAgICAgICAg
ICBNYWNpZWogTWFjaHVsYWsNCj4gICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1v
YXV0aC1keW4tcmVnLTA2LnR4dA0KPiAgICAgICBQYWdlcyAgICAgICAgICAgOiAyMQ0KPiAgICAg
ICBEYXRlICAgICAgICAgICAgOiAyMDEzLTAyLTE1DQo+DQo+IEFic3RyYWN0Og0KPiAgIFRoaXMg
c3BlY2lmaWNhdGlvbiBkZWZpbmVzIGFuIGVuZHBvaW50IGFuZCBwcm90b2NvbCBmb3IgZHluYW1p
Yw0KPiAgIHJlZ2lzdHJhdGlvbiBvZiBPQXV0aCBDbGllbnRzIGF0IGFuIEF1dGhvcml6YXRpb24g
U2VydmVyLg0KPg0KPg0KPiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhp
cyBkcmFmdCBpczoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0
Zi1vYXV0aC1keW4tcmVnDQo+DQo+IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZh
aWxhYmxlIGF0Og0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRo
LWR5bi1yZWctMDYNCj4NCj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZh
aWxhYmxlIGF0Og0KPiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRm
LW9hdXRoLWR5bi1yZWctMDYNCj4NCj4NCj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWls
YWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQt
ZHJhZnRzLw0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRo
QGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo
DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0
aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCi0tDQpOYXQg
U2FraW11cmEgKD1uYXQpDQpDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24NCmh0dHA6Ly9uYXQu
c2FraW11cmEub3JnLw0KQF9uYXRfZW4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxt
YWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL29hdXRoDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGll
dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoN
Cg0KLS0NCk5hdCBTYWtpbXVyYSAoPW5hdCkNCkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbg0K
aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvDQpAX25hdF9lbg0KDQo=

--_000_4E1F6AAD24975D4BA5B16804296739436747B12DTK5EX14MBXC284r_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0
YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl
LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206
LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt
c2VyaWYiO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVt
YWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29u
VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5
bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1m
YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls
ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7
fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp
biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp
b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1
bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt
LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp
ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl
bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i
cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T0ssIHdlIHNob3Vs
ZCBtYWtlIHRoZSBjaGFuZ2UgdGhlbi4mbmJzcDsgVGhhbmtzIGZvciB0aGUgaW5wdXQuPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7Ij4gVGltIEJyYXkgW21haWx0bzp0d2JyYXlAZ29vZ2xlLmNvbV0NCjxicj4NCjxi
PlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDIwLCAyMDEzIDk6MjIgQU08YnI+DQo8Yj5U
bzo8L2I+IE1pa2UgSm9uZXM8YnI+DQo8Yj5DYzo8L2I+IE5hdCBTYWtpbXVyYTsgJmx0O29hdXRo
QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBJLUQgQWN0
aW9uOiBkcmFmdC1pZXRmLW9hdXRoLWR5bi1yZWctMDYudHh0PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlllcywg4oCcVVJM4oCdIGlz
IHN0cm9uZ2x5IGFuZCBjbGVhcmx5IGRlcHJlY2F0ZWQgaW4gUkZDMzk4NiBzZWN0aW9uIDEuMS4z
OyBvbmUgb2YgdGhlIHJlYXNvbnMgaXMgdGhhdCB0aGUgZGlzdGluY3Rpb24gYmV0d2VlbiDigJxs
b2NhdG9y4oCdIGFuZCDigJxpZGVudGlmaWVy4oCdIHdoaWNoIHNvdW5kcyBsaWtlIGl0IHNob3Vs
ZCBiZSBlYXN5LCB0dXJucyBvdXQgdG8gbGVhZCB0bw0KIHRoZW9sb2dpY2FsIGJpa2VzaGVkIGRp
c2N1c3Npb25zIGFsbW9zdCBpbmV2aXRhYmx5LCBhbmQgaW4gZmFjdCBiZSBzaGFreSBpbiBwcmFj
dGljZS4gJm5ic3A7LVQ8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5PbiBXZWQsIEZlYiAyMCwgMjAxMyBhdCA5OjAwIEFNLCBNaWtlIEpvbmVzICZsdDs8YSBocmVm
PSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWlj
aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRpbSwgYXMgYmFja2dyb3VuZCwgdGhpcyBjYW1lIGZyb20g
dGhlIE9wZW5JRCBDb25uZWN0IHNwZWNzLCB3aGVyZSB3ZSB0cmllZCB0byBjb25zaXN0ZW50bHkg
dXNlIHRoZQ0KIGNvbnZlbnRpb24gdGhhdCB0aGUgbG9jYXRvciBmb3IgYW55IHJlc291cmNlIHRo
YXQgY2FuIGJlIHJldHJpZXZlZCBmcm9tIHRoZSBzcGVjaWZpZWQgbG9jYXRpb24gYmUgY2FsbGVk
IGEgVVJMLCB3aGVyZWFzIGFueSBpZGVudGlmaWVyIHRoYXQgbWF5IG5vdCBiZSByZXRyaWV2YWJs
ZSBpcyBjYWxsZWQgYSBVUkkuJm5ic3A7IFRoYXQgd2FzIGRvbmUgYXMgYW4gYWlkIHRvIGRldmVs
b3BlciB1bmRlcnN0YW5kaW5nIG9mIHRoZSBzcGVjaWZpY2F0aW9ucy48L3NwYW4+PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J
ZiB0aGUgdXNlIG9mIOKAnFVSTOKAnSBpcyBkZXByZWNhdGVkIGJ5IHRoZSBJRVRGIGluIGZhdm9y
IG9mIGFsd2F5cyBqdXN0IHVzaW5nIOKAnFVSSeKAnSwgSSBzdXBwb3NlIHdlIGNvdWxkDQogY2hh
bmdlIHRoYXQsIGJ1dCBpZiBpdOKAmXMgZ29pbmcgdG8gY2hhbmdlLCBpdCBzaG91bGQgYmUgc29v
bi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw
Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+DQo8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0
PSJfYmxhbmsiPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86PGEgaHJlZj0ibWFp
bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2Vz
QGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TmF0IFNha2ltdXJhPGJyPg0KPGI+
U2VudDo8L2I+IFdlZG5lc2RheSwgRmVicnVhcnkgMjAsIDIwMTMgODo1NyBBTTxicj4NCjxiPlRv
OjwvYj4gVGltIEJyYXk8YnI+DQo8Yj5DYzo8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhA
aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+
U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtb2F1dGgt
ZHluLXJlZy0wNi50eHQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Zb3UgYXJl
IHJpZ2h0LiBJIGFtIGluIHRoZSBjYW1wIHJlY29tbWVuZGluZyB0aGUgdXNlIG9mIFVSTCB3aGVu
IGl0IGlzIGEgY29uY3JldGUgZW5kcG9pbnQgYW5kIFVSSSB3aGVuIGl0IGluY2x1ZGVzIHNvbWV0
aGluZyB0aGF0IGlzIG9ubHkgYWJzdHJhY3QsIGJ1dCBzaW5jZSBPQXV0aCBzdGFuZGFyZGl6ZWQN
CiBvbiAmcXVvdDt1cmkmcXVvdDssIHdlIG1heSBhcyB3ZWxsIGRvIHNvIGhlcmUuJm5ic3A7PG86
cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+TmF0PG86cD48L286cD48
L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4yMDEzLzIvMjAgVGltIEJyYXkgJmx0
OzxhIGhyZWY9Im1haWx0bzp0d2JyYXlAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnR3YnJh
eUBnb29nbGUuY29tPC9hPiZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+SW4gT0F1dGgsIHdlIGhhdmUgcmVkaXJlY3RfdXJpIG5vdCByZWRpcmVjdF91cmw7IHNob3Vs
ZCB0aGlzIGJlIHJlZ2lzdHJhdGlvbl9hY2Nlc3NfdXJpIGZvciBjb25zaXN0ZW5jeT8gLVQ8bzpw
PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFdlZCwgRmViIDIwLCAy
MDEzIGF0IDg6MjMgQU0sIEpvaG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2
ZTdqdGIuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0OyB3cm90
ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgdGhpbmsg
cmVnaXN0cmF0aW9uX2FjY2Vzc191cmwgaXMgT0suICZuYnNwOyAmbmJzcDtJIGhhdmVuJ3QgaGVh
cmQgYW55IGJldHRlciBuYW1lcyB5ZXQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Sm9obiBCLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIDIwMTMtMDItMjAsIGF0IDE6MDQgUE0sIE1pa2Ug
Sm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRh
cmdldD0iX2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZvciB3aGF0IGl04oCZcyB3b3J0
aCwgdGhlIG5hbWUg4oCccmVnaXN0cmF0aW9uX2FjY2Vzc191cmzigJ0gd2FzIGNob3NlbiB0byBi
ZSBwYXJhbGxlbCB0byDigJxyZWdpc3RyYXRpb25fYWNjZXNzX3Rva2Vu4oCdLiZuYnNwOyZuYnNw
Ow0KIEl04oCZcyB0aGUgcGxhY2UgeW91IHVzZSB0aGUgYWNjZXNzIHRva2VuLiZuYnNwOyBBbmQg
aXTigJlzIHdoZXJlIHlvdSBhY2Nlc3MgYW4gZXhpc3RpbmcgcmVnaXN0cmF0aW9uLiZuYnNwOyBJ
4oCZbSBhZ2FpbnN0IHRoZSBuYW1lIOKAnGNsaWVudF9tZXRhZGF0YV91cmzigJ0gYmVjYXVzZSBp
dOKAmXMgbm90IG1ldGFkYXRhIHlvdeKAmXJlIGFjY2Vzc2luZyDigJMgaXTigJlzIGEgcmVnaXN0
cmF0aW9uIHlvdeKAmXJlIGFjY2Vzc2luZy4mbmJzcDsgRm9yIHRoZSBzYW1lIHJlYXNvbiwgSSBk
b27igJl0IHRoaW5rDQogdGhlIG5hbWUg4oCcY2xpZW50X2luZm9fdXJs4oCdIGdpdmVzIHBlb3Bs
ZSB0aGUgcmlnaHQgaWRlYSwgYmVjYXVzZSBpdCBkb2VzbuKAmXQgc2F5IGFueXRoaW5nIGl0IGJl
aW5nIHRoZSByZWdpc3RyYXRpb24gdGhhdCB5b3XigJlyZSBhY2Nlc3NpbmcuPC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgeW91IHJlYWxseSB3YW50IHVzIHRv
IGNoYW5nZSB0aGlzLCBoYXZpbmcgcmVhZCB3aGF04oCZcyBhYm92ZSwgSSBjb3VsZCBsaXZlIHdp
dGgg4oCcY2xpZW50X3JlZ2lzdHJhdGlvbl91cmzigJ0sDQogYnV0IEkgZG9u4oCZdCB0aGluayBh
IGNoYW5nZSBpcyBhY3R1YWxseSBuZWNlc3NhcnkuJm5ic3A7IChCdXQgaWYgd2UgYXJlIGdvaW5n
IHRvIGNoYW5nZSBpdCwgbGV04oCZcyBkbyBpdCBBU0FQLCBiZWZvcmUgdGhlIE9wZW5JRCBDb25u
ZWN0IEltcGxlbWVudGVy4oCZcyBEcmFmdHMgYXJlIHB1Ymxpc2hlZC4pPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDsiPiZuYnNwOzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3Jn
IiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4NCiBbbWFpbHRvOjxh
IGhyZWY9Im1haWx0bzpvYXV0aC0iIHRhcmdldD0iX2JsYW5rIj5vYXV0aC08L2E+PGEgaHJlZj0i
bWFpbHRvOmJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ib3VuY2VzQGlldGYub3Jn
PC9hPl0mbmJzcDs8Yj5PbiBCZWhhbGYgT2YmbmJzcDs8L2I+TmF0IFNha2ltdXJhPGJyPg0KPGI+
U2VudDo8L2I+Jm5ic3A7V2VkbmVzZGF5LCBGZWJydWFyeSAyMCwgMjAxMyA3OjU4IEFNPGJyPg0K
PGI+VG86PC9iPiZuYnNwOyZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdl
dD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7OyBSaWNoZXIsIEp1c3RpbiBQLjsgSm9o
biBCcmFkbGV5PGJyPg0KPGI+U3ViamVjdDo8L2I+Jm5ic3A7UmU6IFtPQVVUSC1XR10gSS1EIEFj
dGlvbjogZHJhZnQtaWV0Zi1vYXV0aC1keW4tcmVnLTA2LnR4dDwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+VGhhbmtzIEp1c3Rpbi48YnI+DQo8YnI+DQpF
dmVuIGlmIHdlIGdvIGZsYXQgcmF0aGVyIHRoYW4gZG9pbmcgSlNPTiBTdHJ1Y3R1cmUsIHRoZSAm
cXVvdDtDbGllbnQ8YnI+DQpSZWdpc3RyYXRpb24gQWNjZXNzIEVuZHBvaW50JnF1b3Q7IGlzIG5v
dCBhIGdvb2QgcmVwcmVzZW50YXRpdmUgbmFtZS48YnI+DQo8YnI+DQpXaGF0IGl0IHJlcHJlc2Vu
dHMgaXMgdGhlIGNsaWVudCBtZXRhZGF0YS9pbmZvLjxicj4NCkl0IGlzIG5vdCByZXByZXNlbnRp
bmcgJnF1b3Q7Q2xpZW50IFJlZ2lzdHJhdGlvbiBBY2Nlc3MmcXVvdDsuJm5ic3A7PC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+V2hhdCBkb2VzICZxdW90O0NsaWVudCBSZWdpc3RyYXRpb24gQWNjZXNzJnF1b3Q7IG1lYW4/
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy
LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj5Eb2VzIFVQREFU
aW5nICZxdW90O0NsZWludCBSZWdpc3RyYXRpb24gQWNjZXNzJnF1b3Q7IG1ha2Ugc2Vuc2U/PC9z
cGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+PGJyPg0K
U29tZXRoaW5nIGluIHRoZSBsaW5lIG9mICZxdW90O0NsaWVudCBNZXRhZGF0YSBFbmRwb2ludCZx
dW90OyBhbmQ8YnI+DQpzb21ldGhpbmcgbGlrZSAmcXVvdDtjbGllbnRfbWV0YWRhdGFfdXJsJnF1
b3Q7IG9yJm5ic3A7JnF1b3Q7Y2xpZW50X2luZm9fdXJsJnF1b3Q7IGlzIG11Y2ggYmV0dGVyLjxi
cj4NCjxicj4NCk5hdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj4yMDEzLzIvMTUgUmljaGVyLCBKdXN0aW4gUC4gJmx0OzxhIGhyZWY9
Im1haWx0bzpqcmljaGVyQG1pdHJlLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj
b2xvcjpwdXJwbGUiPmpyaWNoZXJAbWl0cmUub3JnPC9zcGFuPjwvYT4mZ3Q7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkV2ZXJ5b25lLCB0aGVy
ZSdzIGEgbmV3IGRyYWZ0IG9mIER5blJlZyB1cCBvbiB0aGUgdHJhY2tlci4gVGhpcyBkcmFmdCB0
cmllcyB0byBjb2RpZnkgdGhlIGRpc2N1c3Npb25zIHNvIGZhciBmcm9tIHRoaXMgd2VlayBpbnRv
IHNvbWV0aGluZyB3ZSBjYW4gYWxsIHJlYWQuIFRoZXJlIGFyZSBzdGlsbCBwbGVudHkNCiBvZiBv
cGVuIGRpc2N1c3Npb24gcG9pbnRzIGFuZCBpdGVtcyB1cCBmb3IgZGViYXRlLiBQbGVhc2UgcmVh
ZCB0aHJvdWdoIHRoaXMgbGF0ZXN0IGRyYWZ0IGFuZCBzZWUgd2hhdCdzIGNoYW5nZWQgYW5kIGhl
bHAgYXNzdXJlIHRoYXQgaXQgcHJvcGVybHkgY2FwdHVyZXMgdGhlIGNvbnZlcnNhdGlvbnMuIElm
IHlvdSBoYXZlIGFueSBpbnB1dHMgZm9yIHRoZSBtYXJrZWQgW1sgRWRpdG9yJ3MgTm90ZSBdXSBz
ZWN0aW9ucywgcGxlYXNlIHNlbmQgdGhlbQ0KIHRvIHRoZSBsaXN0IGJ5IG5leHQgVGh1cnNkYXkg
dG8gZ2l2ZSBtZSBvcHBvcnR1bml0eSB0byBnZXQgYW55IG5lY2Vzc2FyeSBjaGFuZ2VzIGluIGJ5
IHRoZSBjdXRvZmYgZGF0ZSBvZiBNb25kYXkgdGhlIDIybmQuPGJyPg0KPGJyPg0KVGhhbmtzIGZv
ciBhbGwgb2YgeW91ciBoYXJkIHdvcmsgZXZlcnlvbmUsIEkgdGhpbmsgdGhpcyBpcyAqcmVhbGx5
KiBjb21pbmcgYWxvbmcgbm93Ljxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+
DQombmJzcDstLSBKdXN0aW48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQpPbiBGZWIgMTUsIDIwMTMsIGF0IDQ6
NTQgUE0sJm5ic3A7PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgdGFy
Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmludGVybmV0LWRyYWZ0c0Bp
ZXRmLm9yZzwvc3Bhbj48L2E+Jm5ic3A7d3JvdGU6PGJyPg0KPGJyPg0KJmd0Ozxicj4NCiZndDsg
QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJu
ZXQtRHJhZnRzIGRpcmVjdG9yaWVzLjxicj4NCiZndDsgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRl
bSBvZiB0aGUgV2ViIEF1dGhvcml6YXRpb24gUHJvdG9jb2wgV29ya2luZyBHcm91cCBvZiB0aGUg
SUVURi48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaXRsZSAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogT0F1dGggRHluYW1pYyBDbGllbnQgUmVn
aXN0cmF0aW9uIFByb3RvY29sPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBdXRob3Io
cykgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBKdXN0aW4gUmljaGVyPGJyPg0KJmd0OyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtKb2huIEJyYWRsZXk8YnI+DQomZ3Q7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO01pY2hhZWwgQi4gSm9uZXM8YnI+DQomZ3Q7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO01hY2llaiBNYWNodWxhazxicj4NCiZndDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgRmlsZW5hbWUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBk
cmFmdC1pZXRmLW9hdXRoLWR5bi1yZWctMDYudHh0PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyBQYWdlcyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogMjE8YnI+DQom
Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IERhdGUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDs6IDIwMTMtMDItMTU8YnI+DQomZ3Q7PGJyPg0KJmd0OyBBYnN0cmFjdDo8
YnI+DQomZ3Q7ICZuYnNwOyBUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyBhbiBlbmRwb2ludCBh
bmQgcHJvdG9jb2wgZm9yIGR5bmFtaWM8YnI+DQomZ3Q7ICZuYnNwOyByZWdpc3RyYXRpb24gb2Yg
T0F1dGggQ2xpZW50cyBhdCBhbiBBdXRob3JpemF0aW9uIFNlcnZlci48YnI+DQomZ3Q7PGJyPg0K
Jmd0Ozxicj4NCiZndDsgVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMg
ZHJhZnQgaXM6PGJyPg0KJmd0OyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0
Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtZHluLXJlZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu
IHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry
YWZ0LWlldGYtb2F1dGgtZHluLXJlZzwvc3Bhbj48L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhl
cmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6PGJyPg0KJmd0OyZuYnNw
OzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtZHlu
LXJlZy0wNiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHA6
Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtZHluLXJlZy0wNjwvc3Bhbj48
L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24g
aXMgYXZhaWxhYmxlIGF0Ojxicj4NCiZndDsmbmJzcDs8YSBocmVmPSJodHRwOi8vd3d3LmlldGYu
b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW9hdXRoLWR5bi1yZWctMDYiIHRhcmdldD0iX2Js
YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwOi8vd3d3LmlldGYub3JnL3JmY2Rp
ZmY/dXJsMj1kcmFmdC1pZXRmLW9hdXRoLWR5bi1yZWctMDY8L3NwYW4+PC9hPjxicj4NCiZndDs8
YnI+DQomZ3Q7PGJyPg0KJmd0OyBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5
IGFub255bW91cyBGVFAgYXQ6PGJyPg0KJmd0OyZuYnNwOzxhIGhyZWY9ImZ0cDovL2Z0cC5pZXRm
Lm9yZy9pbnRlcm5ldC1kcmFmdHMvIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9y
OnB1cnBsZSI+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88L3NwYW4+PC9hPjxi
cj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fPGJyPg0KJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jm5ic3A7PGEg
aHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9
ImNvbG9yOnB1cnBsZSI+T0F1dGhAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCiZndDsmbmJzcDs8
YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJn
ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvc3Bhbj48L2E+PGJyPg0KPGJyPg0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5n
IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r
Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5PQXV0aEBpZXRmLm9yZzwvc3Bhbj48L2E+PGJy
Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIg
dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJy
Pg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tLSZuYnNwOzxicj4NCk5hdCBT
YWtpbXVyYSAoPW5hdCk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCjxhIGhy
ZWY9Imh0dHA6Ly9uYXQuc2FraW11cmEub3JnLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl
PSJjb2xvcjpwdXJwbGUiPmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzwvc3Bhbj48L2E+PGJyPg0K
QF9uYXRfZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJy
Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpP
QXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRh
cmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0K
PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0
Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxiciBjbGVhcj0iYWxs
Ij4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4
ODgiPi0tDQo8YnI+DQpOYXQgU2FraW11cmEgKD1uYXQpPG86cD48L286cD48L3NwYW4+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgi
PkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCjxhIGhyZWY9Imh0dHA6Ly9uYXQuc2Fr
aW11cmEub3JnLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzwvYT48
YnI+DQpAX25hdF9lbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_4E1F6AAD24975D4BA5B16804296739436747B12DTK5EX14MBXC284r_--

From jricher@mitre.org  Wed Feb 20 10:11:54 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0930821F87CD for ; Wed, 20 Feb 2013 10:11:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.574
X-Spam-Level: 
X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.024,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gg9Cfk-oonef for ; Wed, 20 Feb 2013 10:11:52 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id B889E21F871D for ; Wed, 20 Feb 2013 10:11:51 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5201D1F2AF1; Wed, 20 Feb 2013 13:11:50 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id E66D01F2AF9; Wed, 20 Feb 2013 13:11:49 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 20 Feb 2013 13:11:49 -0500
Message-ID: <512511B0.5090102@mitre.org>
Date: Wed, 20 Feb 2013 13:10:56 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Nat Sakimura 
References: <20130215215423.23019.50224.idtracker@ietfa.amsl.com>   <4E1F6AAD24975D4BA5B16804296739436747A665@TK5EX14MBXC284.redmond.corp.microsoft.com>  <4E1F6AAD24975D4BA5B16804296739436747ADDB@TK5EX14MBXC284.redmond.corp.microsoft.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040405010901080302000403"
X-Originating-IP: [129.83.31.58]
Cc: "" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2013 18:11:54 -0000

--------------040405010901080302000403
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit

I like "registered_client_uri", given all of the other discussions on 
this thread, because:

URL/URI: It *is* a URL, and an https one at that, but if the IETF 
convention is to call it URI, then I'm fine with that.

registered_client/registration_access: The former is a good description 
of what's actually *at* the URL, which fits better with the RESTful 
entity model. I think Nat's criticisms about the original formation of 
the parameter name are spot on, though at the time we hadn't heard 
anything better.

So I'd like to change it to "registered_client_uri" in the next draft.

  -- Justin

On 02/20/2013 12:20 PM, Nat Sakimura wrote:
> I have thought about that as well. The the reason I added "info" or 
> "metadata" was that what was behind the URL is not the client itself. 
> By "client registration", I suppose you mean "client entry in the 
> register" (cf. *registration */n/ 2.) . It is the "registered 
> data/info/metadata" about the client.
>
> Nat
>
> 2013/2/20 Mike Jones  >
>
>     I could live with �registered_client_url�.  I think that adding
>     �_metadata� or �_info� is incorrect, because what�s being accessed
>     is the client� registration � not just metadata or info about the
>     client�s registration (although that information can be retrieved
>     as one aspect of the operations on the client�s registration).
>
>     -- Mike
>
>     *From:*Nat Sakimura [mailto:sakimura@gmail.com
>     ]
>     *Sent:* Wednesday, February 20, 2013 8:53 AM
>     *To:* Mike Jones
>     *Cc:* >; Richer, Justin P.;
>     John Bradley
>
>
>     *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
>
>     I have read the whole thing and still ---
>
>     Your argument that it is the place for using "registration access
>     token" thus should have a parallel name "registration access url"
>     is very weak. There are several weakness.
>
>     First, "registration access token" actually is "registration" +
>     "access token". Extracting "registration access" from
>     "registration access token" is broken.
>
>     Secondly, access token is used to against any protected
>     resource. Recommending to use the word "access" in naming
>     protected resources is broken. Should we rename Userinfo endpoint
>     to something like "Userinfo Access Endpoint"? I do not think so.
>
>     Thirdly, the term "Registration Access" does not seem to be
>     meaningful.
>
>     When you say "access", I suppose you are using the noun version of
>     it.
>
>     (If you are using the verb, then I am even more against as a URL
>     should not contain a verb.)
>
>     According to the Webster, access (n.) is defined as:
>
>     *access */n./
>
>     *1*
>
>     /*a*/*:*onset  2
>
>     /*b*/*:* a fit of intense feeling *:*outburst
>     
>
>     *2*
>
>     /*a*/*:* permission, liberty, or ability to enter, approach, or
>     pass to and from a place or to approach or communicate with a
>     person or thing
>
>     /*b*/*:* freedom or ability to obtain or make use of something
>
>     /*c*/*:* a way or means of access
>
>     /*d*/*:* the act or an instance of accessing
>     
>
>     *3*
>
>     *:* an increase by addition 
>
>     Replacing "access" with any of the definition above does not seem
>     to work.
>
>     Remember, a URL is represents a "thing".
>
>     The name of the endpoint should represent the "thing".
>
>     I am merginally OK with "client registration url" leveraging on
>     the definition 2. below (again from Webster -- my OED subscription
>     lapsed for the time being.)
>
>     *registration */n./
>
>     *1*
>
>     *:* the act of registering
>     
>
>     *2*
>
>     *:* an entry in a register
>     
>
>     *3*
>
>     *:* the number of individuals registered
>     
>     *:*enrollment 
>
>     *4*
>
>     /*a*/*:* the art or act of selecting and adjusting pipe organ stops
>
>     /*b*/*:* the combination of stops selected for performing a
>     particular organ work
>
>     *5*
>
>     *:* a document certifying an act of registering
>
>     However, since the most common use of "registration" is actually
>     *1* above, it still is confusing. If you really want to emphasize
>     the fact that it has been registered, then something like
>     "registered client info uri" or "registered client metadata uri"
>     would be better.
>
>     Nat
>
>     2013/2/20 Mike Jones      >
>
>     For what it�s worth, the name �registration_access_url� was chosen
>     to be parallel to �registration_access_token�.   It�s the place
>     you use the access token. And it�s where you access an existing
>     registration.  I�m against the name �client_metadata_url� because
>     it�s not metadata you�re accessing � it�s a registration you�re
>     accessing.  For the same reason, I don�t think the name
>     �client_info_url� gives people the right idea, because it doesn�t
>     say anything it being the registration that you�re accessing.
>
>     If you really want us to change this, having read what�s above, I
>     could live with �client_registration_url�, but I don�t think a
>     change is actually necessary.  (But if we are going to change it,
>     let�s do it ASAP, before the OpenID Connect Implementer�s Drafts
>     are published.)
>
>     -- Mike
>
>     *From:*oauth-bounces@ietf.org 
>     [mailto:oauth-bounces@ietf.org ]
>     *On Behalf Of *Nat Sakimura
>     *Sent:* Wednesday, February 20, 2013 7:58 AM
>     *To:* >; Richer, Justin P.;
>     John Bradley
>
>
>     *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
>
>     Thanks Justin.
>
>
>
>     Even if we go flat rather than doing JSON Structure, the "Client
>     Registration Access Endpoint" is not a good representative name.
>
>     What it represents is the client metadata/info.
>     It is not representing "Client Registration Access".
>
>     What does "Client Registration Access" mean?
>
>     Does UPDATing "Cleint Registration Access" make sense?
>
>     Something in the line of "Client Metadata Endpoint" and
>     something like "client_metadata_url" or "client_info_url" is much
>     better.
>
>     Nat
>
>     2013/2/15 Richer, Justin P.      >
>
>     Everyone, there's a new draft of DynReg up on the tracker. This
>     draft tries to codify the discussions so far from this week into
>     something we can all read. There are still plenty of open
>     discussion points and items up for debate. Please read through
>     this latest draft and see what's changed and help assure that it
>     properly captures the conversations. If you have any inputs for
>     the marked [[ Editor's Note ]] sections, please send them to the
>     list by next Thursday to give me opportunity to get any necessary
>     changes in by the cutoff date of Monday the 22nd.
>
>     Thanks for all of your hard work everyone, I think this is
>     *really* coming along now.
>
>      -- Justin
>
>
>     On Feb 15, 2013, at 4:54 PM, internet-drafts@ietf.org
>      wrote:
>
>     >
>     > A New Internet-Draft is available from the on-line
>     Internet-Drafts directories.
>     > This draft is a work item of the Web Authorization Protocol
>     Working Group of the IETF.
>     >
>     >       Title           : OAuth Dynamic Client Registration Protocol
>     >       Author(s)       : Justin Richer
>     >  John Bradley
>     >  Michael B. Jones
>     >  Maciej Machulak
>     >       Filename        : draft-ietf-oauth-dyn-reg-06.txt
>     >       Pages           : 21
>     >       Date            : 2013-02-15
>     >
>     > Abstract:
>     >   This specification defines an endpoint and protocol for dynamic
>     >   registration of OAuth Clients at an Authorization Server.
>     >
>     >
>     > The IETF datatracker status page for this draft is:
>     > https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
>     >
>     > There's also a htmlized version available at:
>     > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06
>     >
>     > A diff from the previous version is available at:
>     > http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-06
>     >
>     >
>     > Internet-Drafts are also available by anonymous FTP at:
>     > ftp://ftp.ietf.org/internet-drafts/
>     >
>     > _______________________________________________
>     > 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
>
>
>
>     -- 
>     Nat Sakimura (=nat)
>
>     Chairman, OpenID Foundation
>     http://nat.sakimura.org/
>     @_nat_en
>
>
>
>     -- 
>     Nat Sakimura (=nat)
>
>     Chairman, OpenID Foundation
>     http://nat.sakimura.org/
>     @_nat_en
>
>
>
>
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en

--------------040405010901080302000403
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit

    I like "registered_client_uri", given all of the other discussions
    on this thread, because:

    URL/URI: It *is* a URL, and an https one at that, but if the IETF
    convention is to call it URI, then I'm fine with that.

    registered_client/registration_access: The former is a good
    description of what's actually *at* the URL, which fits better with
    the RESTful entity model. I think Nat's criticisms about the
    original formation of the parameter name are spot on, though at the
    time we hadn't heard anything better.

    So I'd like to change it to "registered_client_uri" in the next
    draft.

    �-- Justin

    On 02/20/2013 12:20 PM, Nat Sakimura
      wrote:

      I have thought about that as well. The the reason I added "info"
      or "metadata" was that what was behind the URL is not the client
      itself. By "client registration", I suppose you mean "client entry
      in the register" (cf. registration n 2.) . It is
      the "registered data/info/metadata" about the client.�

      Nat

        2013/2/20 Mike Jones <Michael.Jones@microsoft.com>

                I
                    could live with �registered_client_url�.� I think
                    that adding �_metadata� or �_info� is incorrect,
                    because what�s being accessed is the client�
                    registration � not just metadata or info about the
                    client�s registration (although that information can
                    be retrieved as one aspect of the operations on the
                    client�s registration).
                �
                �����������������������������������������������������������
                    -- Mike
                �
                From:
                    Nat Sakimura [mailto:sakimura@gmail.com]

                    Sent: Wednesday, February 20, 2013 8:53 AM

                    To: Mike Jones

                    Cc: <oauth@ietf.org>;
                    Richer, Justin P.; John Bradley

                    Subject: Re: [OAUTH-WG] I-D Action:
                    draft-ietf-oauth-dyn-reg-06.txt

                    �
                    I have read the whole thing and
                      still ---�

                      �

                      Your argument that it is the
                        place for using "registration access token" thus
                        should have a parallel name "registration access
                        url" is very weak. There are several weakness.�

                      �

                      First, "registration access
                        token" actually is "registration" + "access
                        token". Extracting "registration access" from
                        "registration access token" is broken.�

                      �

                      Secondly, access token is
                        used to against any protected
                        resource.�Recommending�to use the word "access"
                        in naming protected resources is broken. Should
                        we rename Userinfo endpoint to something like
                        "Userinfo Access Endpoint"? I do not think so.�

                      �

                      Thirdly, the term
                        "Registration Access" does not seem to be
                        meaningful.�

                      When you say "access", I
                        suppose you are using the noun version of it.�

                        (If you are using the verb,
                          then I am even more against as a URL should
                          not contain a verb.)�

                        �

                        According to the Webster,
                          access (n.) is defined as:�

                        �

                        access n.

                        �

                            1

                            a�:�onset�2
                            b�:�a

                                  fit of intense feeling�:�outburst

                            2

                            a�:�permission,

                                  liberty, or ability to enter,
                                  approach, or pass to and from a place
                                  or to approach or communicate with a
                                  person or thing
                            b�:�freedom

                                  or ability to obtain or make use of
                                  something
                            c�:�a

                                  way or means of access
                            d�:�the

                                  act or an instance of�accessing

                            3

                            :�an
                                  increase by addition�<a

                                  sudden�access�of
                                  wealth>

                          �

                          Replacing "access" with
                            any of the definition above does not seem to
                            work.�

                          �

                          Remember, a URL is
                            represents a "thing".�

                          The name of the endpoint
                            should represent the "thing".�

                          �

                          I am merginally OK with
                            "client registration url" leveraging on the
                            definition 2. below (again from Webster --
                            my OED subscription lapsed for the time
                            being.)�

                          �

                          registration n.

                          �

                              1

                              :�the
                                    act of�registering

                              2

                              :�an
                                    entry in a�register

                              3

                              :�the
                                    number of individuals�registered�:�enrollment

                              4

                              a�:�the

                                    art or act of selecting and
                                    adjusting pipe organ stops
                              b�:�the

                                    combination of stops selected for
                                    performing a particular organ work

                              5

                              :�a
                                    document certifying an act of
                                    registering

                          �

                          However, since the most
                            common use of "registration" is actually
                            1 above, it still is confusing. If
                            you really want to emphasize the fact that
                            it has been registered, then something like
                            "registered client info uri" or "registered
                            client metadata uri" would be better.�

                          �

                          Nat

                          �

                        �

                          2013/2/20 Mike Jones <Michael.Jones@microsoft.com>

                              For
                                  what it�s worth, the name
                                  �registration_access_url� was chosen
                                  to be parallel to
                                  �registration_access_token�.�� It�s
                                  the place you use the access token.�
                                  And it�s where you access an existing
                                  registration.� I�m against the name
                                  �client_metadata_url� because it�s not
                                  metadata you�re accessing � it�s a
                                  registration you�re accessing.� For
                                  the same reason, I don�t think the
                                  name �client_info_url� gives people
                                  the right idea, because it doesn�t say
                                  anything it being the registration
                                  that you�re accessing.
                              �
                              If
                                  you really want us to change this,
                                  having read what�s above, I could live
                                  with �client_registration_url�, but I
                                  don�t think a change is actually
                                  necessary.� (But if we are going to
                                  change it, let�s do it ASAP, before
                                  the OpenID Connect Implementer�s
                                  Drafts are published.)
                              �
                              �����������������������������������������������������������
                                  -- Mike
                              �
                              From:
                                  oauth-bounces@ietf.org
                                  [mailto:oauth-bounces@ietf.org]
                                  On Behalf Of Nat Sakimura

                                  Sent: Wednesday, February 20,
                                  2013 7:58 AM

                                  To: <oauth@ietf.org>;
                                  Richer, Justin P.; John Bradley

                                  Subject: Re: [OAUTH-WG] I-D
                                  Action:
                                  draft-ietf-oauth-dyn-reg-06.txt

                              �
                              Thanks
                                  Justin.

                                      Even
                                        if we go flat rather than doing
                                        JSON Structure, the "Client

                                      Registration
                                        Access Endpoint" is not a good
                                        representative name.

                                      What
                                        it represents is the client
                                        metadata/info.

                                      It
                                        is not representing "Client
                                        Registration Access".�

                                    What does
                                      "Client Registration Access"
                                      mean?�

                                    Does
                                        UPDATing "Cleint Registration
                                        Access" make sense?

                                        Something
                                          in the line of "Client
                                          Metadata Endpoint" and

                                        something
                                          like "client_metadata_url"
                                          or�"client_info_url" is much
                                          better.

                                        Nat

                                      2013/2/15
                                        Richer, Justin P. <jricher@mitre.org>
                                      Everyone,
                                        there's a new draft of DynReg up
                                        on the tracker. This draft tries
                                        to codify the discussions so far
                                        from this week into something we
                                        can all read. There are still
                                        plenty of open discussion points
                                        and items up for debate. Please
                                        read through this latest draft
                                        and see what's changed and help
                                        assure that it properly captures
                                        the conversations. If you have
                                        any inputs for the marked [[
                                        Editor's Note ]] sections,
                                        please send them to the list by
                                        next Thursday to give me
                                        opportunity to get any necessary
                                        changes in by the cutoff date of
                                        Monday the 22nd.

                                        Thanks for all of your hard work
                                        everyone, I think this is
                                        *really* coming along now.

                                          �-- Justin

                                            On Feb 15, 2013, at 4:54 PM,

                                              internet-drafts@ietf.org
                                            wrote:

                                            >

                                            > A New Internet-Draft is
                                            available from the on-line
                                            Internet-Drafts directories.

                                            > This draft is a work
                                            item of the Web
                                            Authorization Protocol
                                            Working Group of the IETF.

                                            >

                                            > � � � Title � � � � � :
                                            OAuth Dynamic Client
                                            Registration Protocol

                                            > � � � Author(s) � � � :
                                            Justin Richer

                                            > � � � � � � � � � � � �
                                            �John Bradley

                                            > � � � � � � � � � � � �
                                            �Michael B. Jones

                                            > � � � � � � � � � � � �
                                            �Maciej Machulak

                                            > � � � Filename � � � �:
draft-ietf-oauth-dyn-reg-06.txt

                                            > � � � Pages � � � � � :
                                            21

                                            > � � � Date � � � � � �:
                                            2013-02-15

                                            >

                                            > Abstract:

                                            > � This specification
                                            defines an endpoint and
                                            protocol for dynamic

                                            > � registration of OAuth
                                            Clients at an Authorization
                                            Server.

                                            >

                                            >

                                            > The IETF datatracker
                                            status page for this draft
                                            is:

                                            > 
https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg

                                            >

                                            > There's also a htmlized
                                            version available at:

                                            > 
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06

                                            >

                                            > A diff from the
                                            previous version is
                                            available at:

                                            > 
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-06

                                            >

                                            >

                                            > Internet-Drafts are
                                            also available by anonymous
                                            FTP at:

                                            > ftp://ftp.ietf.org/internet-drafts/

                                            >

                                            >
                                            _______________________________________________

                                            > 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

                                      �

                                    --

                                      Nat Sakimura (=nat)

                                      Chairman,
                                        OpenID Foundation

                                        http://nat.sakimura.org/

                                        @_nat_en

                          �

                        -- 

                          Nat Sakimura (=nat)

                          Chairman, OpenID
                            Foundation

                            http://nat.sakimura.org/

                            @_nat_en

        -- 

        Nat Sakimura (=nat)
        Chairman, OpenID Foundation

          http://nat.sakimura.org/

          @_nat_en

--------------040405010901080302000403--

From Michael.Jones@microsoft.com  Wed Feb 20 10:14:19 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D659A21F8881 for ; Wed, 20 Feb 2013 10:14:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.585
X-Spam-Level: 
X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.013,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxtzMBZNUtGy for ; Wed, 20 Feb 2013 10:14:14 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7B221F8880 for ; Wed, 20 Feb 2013 10:14:14 -0800 (PST)
Received: from BL2FFO11FD014.protection.gbl (10.173.161.200) by BL2FFO11HUB009.protection.gbl (10.173.161.111) with Microsoft SMTP Server (TLS) id 15.0.620.12; Wed, 20 Feb 2013 18:14:02 +0000
Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD014.mail.protection.outlook.com (10.173.160.222) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Wed, 20 Feb 2013 18:14:02 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.96]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Wed, 20 Feb 2013 18:13:33 +0000
From: Mike Jones 
To: Justin Richer , Nat Sakimura 
Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
Thread-Index: AQHOC8cMkbohP5vU0EO7eTLi/U/hMJh7eCuAgAd2gACAAAA6MIAADyiAgAAAlPCAAAbqAIAADigAgAAAsbA=
Date: Wed, 20 Feb 2013 18:13:32 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436747B2BB@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <20130215215423.23019.50224.idtracker@ietfa.amsl.com>   <4E1F6AAD24975D4BA5B16804296739436747A665@TK5EX14MBXC284.redmond.corp.microsoft.com>  <4E1F6AAD24975D4BA5B16804296739436747ADDB@TK5EX14MBXC284.redmond.corp.microsoft.com>  <512511B0.5090102@mitre.org>
In-Reply-To: <512511B0.5090102@mitre.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.33]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436747B2BBTK5EX14MBXC284r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704002)(377424002)(377454001)(51444002)(65554002)(24454001)(69224001)(479174001)(189002)(199002)(56816002)(4396001)(50986001)(16236675001)(31966008)(47736001)(74662001)(66066001)(16297215001)(74502001)(47446002)(80022001)(79102001)(76482001)(49866001)(54316002)(33656001)(15202345001)(46102001)(55846006)(44976002)(63696002)(47976001)(54356001)(512954001)(16406001)(53806001)(59766001)(77982001)(5343635001)(5343655001)(65816001)(51856001)(56776001)(20776003); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB009; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07630F72AD
Cc: "" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2013 18:14:20 -0000

--_000_4E1F6AAD24975D4BA5B16804296739436747B2BBTK5EX14MBXC284r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

SGTM

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Wednesday, February 20, 2013 10:11 AM
To: Nat Sakimura
Cc: Mike Jones; ; John Bradley
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

I like "registered_client_uri", given all of the other discussions on this =
thread, because:

URL/URI: It *is* a URL, and an https one at that, but if the IETF conventio=
n is to call it URI, then I'm fine with that.

registered_client/registration_access: The former is a good description of =
what's actually *at* the URL, which fits better with the RESTful entity mod=
el. I think Nat's criticisms about the original formation of the parameter =
name are spot on, though at the time we hadn't heard anything better.

So I'd like to change it to "registered_client_uri" in the next draft.

 -- Justin
On 02/20/2013 12:20 PM, Nat Sakimura wrote:
I have thought about that as well. The the reason I added "info" or "metada=
ta" was that what was behind the URL is not the client itself. By "client r=
egistration", I suppose you mean "client entry in the register" (cf. regist=
ration n 2.) . It is the "registered data/info/metadata" about the client.

Nat
2013/2/20 Mike Jones >
I could live with "registered_client_url".  I think that adding "_metadata"=
 or "_info" is incorrect, because what's being accessed is the client' regi=
stration - not just metadata or info about the client's registration (altho=
ugh that information can be retrieved as one aspect of the operations on th=
e client's registration).

                                                            -- Mike

From: Nat Sakimura [mailto:sakimura@gmail.com]
Sent: Wednesday, February 20, 2013 8:53 AM
To: Mike Jones
Cc: >; Richer, Justin P.; John Bradle=
y

Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

I have read the whole thing and still ---

Your argument that it is the place for using "registration access token" th=
us should have a parallel name "registration access url" is very weak. Ther=
e are several weakness.

First, "registration access token" actually is "registration" + "access tok=
en". Extracting "registration access" from "registration access token" is b=
roken.

Secondly, access token is used to against any protected resource. Recommend=
ing to use the word "access" in naming protected resources is broken. Shoul=
d we rename Userinfo endpoint to something like "Userinfo Access Endpoint"?=
 I do not think so.

Thirdly, the term "Registration Access" does not seem to be meaningful.
When you say "access", I suppose you are using the noun version of it.
(If you are using the verb, then I am even more against as a URL should not=
 contain a verb.)

According to the Webster, access (n.) is defined as:

access n.

1
a : onset 2
b : a fit of intense feeling : outburst
2
a : permission, liberty, or ability to enter, approach, or pass to and from=
 a place or to approach or communicate with a person or thing
b : freedom or ability to obtain or make use of something
c : a way or means of access
d : the act or an instance of accessing
3
: an increase by addition 

Replacing "access" with any of the definition above does not seem to work.

Remember, a URL is represents a "thing".
The name of the endpoint should represent the "thing".

I am merginally OK with "client registration url" leveraging on the definit=
ion 2. below (again from Webster -- my OED subscription lapsed for the time=
 being.)

registration n.

1
: the act of registering
2
: an entry in a register
3
: the number of individuals registered : enrollment
4
a : the art or act of selecting and adjusting pipe organ stops
b : the combination of stops selected for performing a particular organ wor=
k
5
: a document certifying an act of registering

However, since the most common use of "registration" is actually 1 above, i=
t still is confusing. If you really want to emphasize the fact that it has =
been registered, then something like "registered client info uri" or "regis=
tered client metadata uri" would be better.

Nat

2013/2/20 Mike Jones >
For what it's worth, the name "registration_access_url" was chosen to be pa=
rallel to "registration_access_token".   It's the place you use the access =
token.  And it's where you access an existing registration.  I'm against th=
e name "client_metadata_url" because it's not metadata you're accessing - i=
t's a registration you're accessing.  For the same reason, I don't think th=
e name "client_info_url" gives people the right idea, because it doesn't sa=
y anything it being the registration that you're accessing.

If you really want us to change this, having read what's above, I could liv=
e with "client_registration_url", but I don't think a change is actually ne=
cessary.  (But if we are going to change it, let's do it ASAP, before the O=
penID Connect Implementer's Drafts are published.)

                                                            -- Mike

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Nat Sakimura
Sent: Wednesday, February 20, 2013 7:58 AM
To: >; Richer, Justin P.; John Bradle=
y

Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

Thanks Justin.

Even if we go flat rather than doing JSON Structure, the "Client
Registration Access Endpoint" is not a good representative name.

What it represents is the client metadata/info.
It is not representing "Client Registration Access".
What does "Client Registration Access" mean?
Does UPDATing "Cleint Registration Access" make sense?

Something in the line of "Client Metadata Endpoint" and
something like "client_metadata_url" or "client_info_url" is much better.

Nat
2013/2/15 Richer, Justin P. >
Everyone, there's a new draft of DynReg up on the tracker. This draft tries=
 to codify the discussions so far from this week into something we can all =
read. There are still plenty of open discussion points and items up for deb=
ate. Please read through this latest draft and see what's changed and help =
assure that it properly captures the conversations. If you have any inputs =
for the marked [[ Editor's Note ]] sections, please send them to the list b=
y next Thursday to give me opportunity to get any necessary changes in by t=
he cutoff date of Monday the 22nd.

Thanks for all of your hard work everyone, I think this is *really* coming =
along now.

 -- Justin

On Feb 15, 2013, at 4:54 PM, internet-drafts@ietf.org wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
> This draft is a work item of the Web Authorization Protocol Working Group=
 of the IETF.
>
>       Title           : OAuth Dynamic Client Registration Protocol
>       Author(s)       : Justin Richer
>                          John Bradley
>                          Michael B. Jones
>                          Maciej Machulak
>       Filename        : draft-ietf-oauth-dyn-reg-06.txt
>       Pages           : 21
>       Date            : 2013-02-15
>
> Abstract:
>   This specification defines an endpoint and protocol for dynamic
>   registration of OAuth Clients at an Authorization Server.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-06
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> 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

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--_000_4E1F6AAD24975D4BA5B16804296739436747B2BBTK5EX14MBXC284r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

SGTM
 <=
/p>

From: Justin Richer [mailto:jricher@mitre.org]

Sent: Wednesday, February 20, 2013 10:11 AM

To: Nat Sakimura

Cc: Mike Jones; <oauth@ietf.org>; John Bradley

Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt<=
o:p>

I like "register=
ed_client_uri", given all of the other discussions on this thread, bec=
ause:

URL/URI: It *is* a URL, and an https one at that, but if the IETF conventio=
n is to call it URI, then I'm fine with that.

registered_client/registration_access: The former is a good description of =
what's actually *at* the URL, which fits better with the RESTful entity mod=
el. I think Nat's criticisms about the original formation of the parameter =
name are spot on, though at the
 time we hadn't heard anything better.

So I'd like to change it to "registered_client_uri" in the next d=
raft.

 -- Justin

On 02/20/2013 12:20 PM, Nat Sakimura wrote:

I have thought about that as well. The the reason I =
added "info" or "metadata" was that what was behind the=
 URL is not the client itself. By "client registration", I suppos=
e you mean "client entry in the register" (cf.
registration n 2.) . It is the "registered data/info/met=
adata" about the client. 

Nat

2013/2/20 Mike Jones <Michael.Jones@microsoft.com>

I could live with “registered_cli=
ent_url”.  I think that adding “_metadata” or “=
;_info” is incorrect,
 because what’s being accessed is the client’ registration R=
11; not just metadata or info about the client’s registration (althou=
gh that information can be retrieved as one aspect of the operations on the=
 client’s registration).

      &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;   -- Mike

From: Nat Sakimura [mailto:<=
a href=3D"mailto:sakimura@gmail.com" target=3D"_blank">sakimura@gmail.com]

Sent: Wednesday, February 20, 2013 8:53 AM

To: Mike Jones

Cc: <oauth@ie=
tf.org>; Richer, Justin P.; John Bradley

Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt<=
o:p>

I have read the whole thing and still --- 

Your argument that it is the place for using "registration ac=
cess token" thus should have a parallel name "registration access=
 url" is very weak. There are several weakness. 

First, "registration access token" actually is "reg=
istration" + "access token". Extracting "registrati=
on access" from "registration access token" is broken. =

Secondly, access token is used to against any protected resource.&=
nbsp;Recommending to use the word "access" in naming protect=
ed resources is broken. Should we rename Userinfo endpoint
 to something like "Userinfo Access Endpoint"? I do not think so.=

Thirdly, the term "Registration Access" does not seem to=
 be meaningful. 

When you say "access", I suppose you are using the noun =
version of it. 

(If you are using the verb, then I am even more against as a URL s=
hould not contain a verb.) 

According to the Webster, access (n.) is defined as: 

access
n.

1

a : onset 2

b : a fit of
 intense feeling : outburst

2

a : permission,
 liberty, or ability to enter, approach, or pass to and from a place or to =
approach or communicate with a person or thing

b : freedom or
 ability to obtain or make use of something

c : a way or
 means of access

d : the act or
 an instance of =
accessing

3

: an increase by addit=
ion <a sudden access of
 wealth>

Replacing "access" with any of the definition above does=
 not seem to work. 

Remember, a URL is represents a "thing". 

The name of the endpoint should represent the "thing".&n=
bsp;

I am merginally OK with "client registration url" levera=
ging on the definition 2. below (again from Webster -- my OED subscription =
lapsed for the time being.) 

registration
n.

1

: the act of registering<=
/span>

2

: an entry in a <=
a href=3D"http://www.merriam-webster.com/dictionary/register" target=3D"_bl=
ank">register

3

: the number of indivi=
duals registere=
d : enrollment

4

a : the art or
 act of selecting and adjusting pipe organ stops

b : the combination
 of stops selected for performing a particular organ work=

5

: a document certifyin=
g an act of registering

However, since the most common use of "registration" is =
actually
1 above, it still is confusing. If you really want to emphasize the =
fact that it has been registered, then something like "registered clie=
nt info uri" or "registered client metadata uri" would be be=
tter. 

Nat

2013/2/20 Mike Jones <Michael.Jones@microsoft.com>

For what it’s worth, the name =
220;registration_access_url” was chosen to be parallel to “regi=
stration_access_token”.  
 It’s the place you use the access token.  And it’s where =
you access an existing registration.  I’m against the name ̶=
0;client_metadata_url” because it’s not metadata you’re a=
ccessing – it’s a registration you’re accessing.  Fo=
r the same reason, I don’t think
 the name “client_info_url” gives people the right idea, becaus=
e it doesn’t say anything it being the registration that you’re=
 accessing.

If you really want us to change this, h=
aving read what’s above, I could live with “client_registration=
_url”,
 but I don’t think a change is actually necessary.  (But if we a=
re going to change it, let’s do it ASAP, before the OpenID Connect Im=
plementer’s Drafts are published.)

      &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;   -- Mike

From:
oauth-bounces@i=
etf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Nat Sakimura

Sent: Wednesday, February 20, 2013 7:58 AM

To: <oauth@ie=
tf.org>; Richer, Justin P.; John Bradley

Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt<=
o:p>

Thanks Justin.

Even if we go flat rather than doing JSON =
Structure, the "Client

Registration Access Endpoint" is not =
a good representative name.

What it represents is the client metadata/=
info.

It is not representing "Client Regist=
ration Access". 

What does "Client Registration Access" mean? <=
/o:p>

Does UPDATing "Cleint Reg=
istration Access" make sense?

Something in the line of "Client Meta=
data Endpoint" and

something like "client_metadata_url&q=
uot; or "client_info_url" is much better.

Nat

2013/2/15 Richer, Justin P. <jricher@mitre.org>
Everyone, there's a new draft of DynReg up on the tracker. This dr=
aft tries to codify the discussions so far from this week into something we=
 can all read. There are still plenty
 of open discussion points and items up for debate. Please read through thi=
s latest draft and see what's changed and help assure that it properly capt=
ures the conversations. If you have any inputs for the marked [[ Editor's N=
ote ]] sections, please send them
 to the list by next Thursday to give me opportunity to get any necessary c=
hanges in by the cutoff date of Monday the 22nd.

Thanks for all of your hard work everyone, I think this is *really* coming =
along now.

 -- Justin

On Feb 15, 2013, at 4:54 PM, 
internet-drafts@ietf.org wrote:

>

> A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.

> This draft is a work item of the Web Authorization Protocol Working Gr=
oup of the IETF.

>

>       Title           : OAuth =
Dynamic Client Registration Protocol

>       Author(s)       : Justin Richer
>                     =
     John Bradley

>                     =
     Michael B. Jones

>                     =
     Maciej Machulak

>       Filename        : draft-ietf-=
oauth-dyn-reg-06.txt

>       Pages           : 21

>       Date            : 2=
013-02-15

>

> Abstract:

>   This specification defines an endpoint and protocol for dynamic=

>   registration of OAuth Clients at an Authorization Server.

>

>

> The IETF datatracker status page for this draft is:

> 
https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg

>

> There's also a htmlized version available at:

> 
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06

>

> A diff from the previous version is available at:

> 
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-06

>

>

> Internet-Drafts are also available by anonymous FTP at:

> ftp:=
//ftp.ietf.org/internet-drafts/

>

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=

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

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

--

Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation

http://nat.sakimura.=
org/

@_nat_en

--

Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation

http://nat.sakimura.=
org/

@_nat_en

-- 

Nat Sakimura (=3Dnat) 

Chairman, OpenID Foundation

http://nat.sakimura.=
org/

@_nat_en

--_000_4E1F6AAD24975D4BA5B16804296739436747B2BBTK5EX14MBXC284r_--

From jricher@mitre.org  Wed Feb 20 11:04:09 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E131A21F886B for ; Wed, 20 Feb 2013 11:04:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.574
X-Spam-Level: 
X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.024,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlbCMxgJscaa for ; Wed, 20 Feb 2013 11:04:06 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6AC21F87BA for ; Wed, 20 Feb 2013 11:04:05 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 145EC5310189; Wed, 20 Feb 2013 14:04:05 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id EFA255310176; Wed, 20 Feb 2013 14:04:04 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 20 Feb 2013 14:04:04 -0500
Message-ID: <51251DF0.8000804@mitre.org>
Date: Wed, 20 Feb 2013 14:03:12 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Mike Jones 
References: <20130215215423.23019.50224.idtracker@ietfa.amsl.com>   <4E1F6AAD24975D4BA5B16804296739436747A665@TK5EX14MBXC284.redmond.corp.microsoft.com>  <4E1F6AAD24975D4BA5B16804296739436747ADDB@TK5EX14MBXC284.redmond.corp.microsoft.com>  <512511B0.5090102@mitre.org> <4E1F6AAD24975D4BA5B16804296739436747B2BB@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436747B2BB@TK5EX14MBXC284.redmond.corp.microsoft.com>
Content-Type: multipart/alternative; boundary="------------010709050103070701040005"
X-Originating-IP: [129.83.31.58]
Cc: "" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2013 19:04:10 -0000

--------------010709050103070701040005
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

On second thought, how about "registration_client_uri"? It's the URI for 
a particular client's registration. Use of the verb "registered" makes 
it sound like the result of an action that the client took, as if the 
client itself had registered the URI. That's obviously not the case, and 
we don't want to convey that.

So, new proposed name: "registration_client_uri"

This has the nice side effect of being more parallel with 
"reigstration_access_token".

  -- Justin

On 02/20/2013 01:13 PM, Mike Jones wrote:
>
> SGTM
>
> *From:*Justin Richer [mailto:jricher@mitre.org]
> *Sent:* Wednesday, February 20, 2013 10:11 AM
> *To:* Nat Sakimura
> *Cc:* Mike Jones; ; John Bradley
> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
>
> I like "registered_client_uri", given all of the other discussions on 
> this thread, because:
>
> URL/URI: It *is* a URL, and an https one at that, but if the IETF 
> convention is to call it URI, then I'm fine with that.
>
> registered_client/registration_access: The former is a good 
> description of what's actually *at* the URL, which fits better with 
> the RESTful entity model. I think Nat's criticisms about the original 
> formation of the parameter name are spot on, though at the time we 
> hadn't heard anything better.
>
>
> So I'd like to change it to "registered_client_uri" in the next draft.
>
>  -- Justin
>
> On 02/20/2013 12:20 PM, Nat Sakimura wrote:
>
>     I have thought about that as well. The the reason I added "info"
>     or "metadata" was that what was behind the URL is not the client
>     itself. By "client registration", I suppose you mean "client entry
>     in the register" (cf. *registration */n/ 2.) . It is the
>     "registered data/info/metadata" about the client.
>
>     Nat
>
>     2013/2/20 Mike Jones      >
>
>     I could live with "registered_client_url".  I think that adding
>     "_metadata" or "_info" is incorrect, because what's being accessed
>     is the client' registration -- not just metadata or info about the
>     client's registration (although that information can be retrieved
>     as one aspect of the operations on the client's registration).
>
>     -- Mike
>
>     *From:*Nat Sakimura [mailto:sakimura@gmail.com
>     ]
>     *Sent:* Wednesday, February 20, 2013 8:53 AM
>     *To:* Mike Jones
>     *Cc:* >; Richer, Justin P.;
>     John Bradley
>
>
>     *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
>
>     I have read the whole thing and still ---
>
>     Your argument that it is the place for using "registration access
>     token" thus should have a parallel name "registration access url"
>     is very weak. There are several weakness.
>
>     First, "registration access token" actually is "registration" +
>     "access token". Extracting "registration access" from
>     "registration access token" is broken.
>
>     Secondly, access token is used to against any protected
>     resource. Recommending to use the word "access" in naming
>     protected resources is broken. Should we rename Userinfo endpoint
>     to something like "Userinfo Access Endpoint"? I do not think so.
>
>     Thirdly, the term "Registration Access" does not seem to be
>     meaningful.
>
>     When you say "access", I suppose you are using the noun version of
>     it.
>
>     (If you are using the verb, then I am even more against as a URL
>     should not contain a verb.)
>
>     According to the Webster, access (n.) is defined as:
>
>     *access */n./
>
>     *1*
>
>     /*a*/*:* onset  2
>
>     /*b*/*:* a fit of intense feeling *:* outburst
>     
>
>     *2*
>
>     /*a*/*:* permission, liberty, or ability to enter, approach, or
>     pass to and from a place or to approach or communicate with a
>     person or thing
>
>     /*b*/*:* freedom or ability to obtain or make use of something
>
>     /*c*/*:* a way or means of access
>
>     /*d*/*:* the act or an instance of accessing
>     
>
>     *3*
>
>     *:* an increase by addition 
>
>     Replacing "access" with any of the definition above does not seem
>     to work.
>
>     Remember, a URL is represents a "thing".
>
>     The name of the endpoint should represent the "thing".
>
>     I am merginally OK with "client registration url" leveraging on
>     the definition 2. below (again from Webster -- my OED subscription
>     lapsed for the time being.)
>
>     *registration */n./
>
>     *1*
>
>     *:* the act of registering
>     
>
>     *2*
>
>     *:* an entry in a register
>     
>
>     *3*
>
>     *:* the number of individuals registered
>      *:*
>     enrollment 
>
>     *4*
>
>     /*a*/*:* the art or act of selecting and adjusting pipe organ stops
>
>     /*b*/*:* the combination of stops selected for performing a
>     particular organ work
>
>     *5*
>
>     *:* a document certifying an act of registering
>
>     However, since the most common use of "registration" is actually
>     *1* above, it still is confusing. If you really want to emphasize
>     the fact that it has been registered, then something like
>     "registered client info uri" or "registered client metadata uri"
>     would be better.
>
>     Nat
>
>     2013/2/20 Mike Jones      >
>
>     For what it's worth, the name "registration_access_url" was chosen
>     to be parallel to "registration_access_token".   It's the place
>     you use the access token. And it's where you access an existing
>     registration.  I'm against the name "client_metadata_url" because
>     it's not metadata you're accessing -- it's a registration you're
>     accessing.  For the same reason, I don't think the name
>     "client_info_url" gives people the right idea, because it doesn't
>     say anything it being the registration that you're accessing.
>
>     If you really want us to change this, having read what's above, I
>     could live with "client_registration_url", but I don't think a
>     change is actually necessary.  (But if we are going to change it,
>     let's do it ASAP, before the OpenID Connect Implementer's Drafts
>     are published.)
>
>     -- Mike
>
>     *From:*oauth-bounces@ietf.org 
>     [mailto:oauth-bounces@ietf.org ]
>     *On Behalf Of *Nat Sakimura
>     *Sent:* Wednesday, February 20, 2013 7:58 AM
>     *To:* >; Richer, Justin P.;
>     John Bradley
>
>
>     *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
>
>     Thanks Justin.
>
>
>
>     Even if we go flat rather than doing JSON Structure, the "Client
>     Registration Access Endpoint" is not a good representative name.
>
>     What it represents is the client metadata/info.
>     It is not representing "Client Registration Access".
>
>     What does "Client Registration Access" mean?
>
>     Does UPDATing "Cleint Registration Access" make sense?
>
>     Something in the line of "Client Metadata Endpoint" and
>     something like "client_metadata_url" or "client_info_url" is much
>     better.
>
>     Nat
>
>     2013/2/15 Richer, Justin P.      >
>
>     Everyone, there's a new draft of DynReg up on the tracker. This
>     draft tries to codify the discussions so far from this week into
>     something we can all read. There are still plenty of open
>     discussion points and items up for debate. Please read through
>     this latest draft and see what's changed and help assure that it
>     properly captures the conversations. If you have any inputs for
>     the marked [[ Editor's Note ]] sections, please send them to the
>     list by next Thursday to give me opportunity to get any necessary
>     changes in by the cutoff date of Monday the 22nd.
>
>     Thanks for all of your hard work everyone, I think this is
>     *really* coming along now.
>
>      -- Justin
>
>
>     On Feb 15, 2013, at 4:54 PM, internet-drafts@ietf.org
>      wrote:
>
>     >
>     > A New Internet-Draft is available from the on-line
>     Internet-Drafts directories.
>     > This draft is a work item of the Web Authorization Protocol
>     Working Group of the IETF.
>     >
>     >       Title : OAuth Dynamic Client Registration Protocol
>     >       Author(s) : Justin Richer
>     >    John Bradley
>     >    Michael B. Jones
>     >    Maciej Machulak
>     >       Filename  : draft-ietf-oauth-dyn-reg-06.txt
>     >       Pages : 21
>     >       Date  : 2013-02-15
>     >
>     > Abstract:
>     >   This specification defines an endpoint and protocol for dynamic
>     >   registration of OAuth Clients at an Authorization Server.
>     >
>     >
>     > The IETF datatracker status page for this draft is:
>     > https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
>     >
>     > There's also a htmlized version available at:
>     > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06
>     >
>     > A diff from the previous version is available at:
>     > http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-06
>     >
>     >
>     > Internet-Drafts are also available by anonymous FTP at:
>     > ftp://ftp.ietf.org/internet-drafts/
>     >
>     > _______________________________________________
>     > 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
>
>
>
>     -- 
>     Nat Sakimura (=nat)
>
>     Chairman, OpenID Foundation
>     http://nat.sakimura.org/
>     @_nat_en
>
>
>
>     -- 
>     Nat Sakimura (=nat)
>
>     Chairman, OpenID Foundation
>     http://nat.sakimura.org/
>     @_nat_en
>
>
>
>     -- 
>     Nat Sakimura (=nat)
>
>     Chairman, OpenID Foundation
>     http://nat.sakimura.org/
>     @_nat_en
>

--------------010709050103070701040005
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

    On second thought, how about "registration_client_uri"? It's the URI
    for a particular client's registration. Use of the verb "registered"
    makes it sound like the result of an action that the client took, as
    if the client itself had registered the URI. That's obviously not
    the case, and we don't want to convey that. 

    So, new proposed name: "registration_client_uri"

    This has the nice side effect of being more parallel with
    "reigstration_access_token". 

     -- Justin

    On 02/20/2013 01:13 PM, Mike Jones
      wrote:

        SGTM

            From:
                Justin Richer [mailto:jricher@mitre.org]

                Sent: Wednesday, February 20, 2013 10:11 AM

                To: Nat Sakimura

                Cc: Mike Jones; <oauth@ietf.org>; John
                Bradley

                Subject: Re: [OAUTH-WG] I-D Action:
                draft-ietf-oauth-dyn-reg-06.txt

        I like
          "registered_client_uri", given all of the other discussions on
          this thread, because:

          URL/URI: It *is* a URL, and an https one at that, but if the
          IETF convention is to call it URI, then I'm fine with that.

          registered_client/registration_access: The former is a good
          description of what's actually *at* the URL, which fits better
          with the RESTful entity model. I think Nat's criticisms about
          the original formation of the parameter name are spot on,
          though at the time we hadn't heard anything better.

          So I'd like to change it to "registered_client_uri" in the
          next draft.

           -- Justin

          On 02/20/2013 12:20 PM, Nat Sakimura
            wrote:

          I have thought about that as well. The
            the reason I added "info" or "metadata" was that what was
            behind the URL is not the client itself. By "client
            registration", I suppose you mean "client entry in the
            register" (cf.
            registration n 2.) . It is the "registered
            data/info/metadata" about the client. 

            Nat

              2013/2/20 Mike Jones <Michael.Jones@microsoft.com>

                  I
                      could live with “registered_client_url”.  I think
                      that adding “_metadata” or “_info” is incorrect,
                      because what’s being accessed is the client’
                      registration – not just metadata or info about the
                      client’s registration (although that information
                      can be retrieved as one aspect of the operations
                      on the client’s registration).

                      -- Mike

                  From:
                      Nat Sakimura [mailto:sakimura@gmail.com]

                      Sent: Wednesday, February 20, 2013 8:53 AM

                      To: Mike Jones

                      Cc: <oauth@ietf.org>;
                      Richer, Justin P.; John Bradley

                        Subject: Re: [OAUTH-WG] I-D Action:
                        draft-ietf-oauth-dyn-reg-06.txt

                      I
                        have read the whole thing and still --- 

                        Your
                          argument that it is the place for using
                          "registration access token" thus should have a
                          parallel name "registration access url" is
                          very weak. There are several weakness. 

                        First,
                          "registration access token" actually is
                          "registration" + "access token". Extracting
                          "registration access" from "registration
                          access token" is broken. 

                        Secondly,
                          access token is used to against any protected
                          resource. Recommending to use the word
                          "access" in naming protected resources is
                          broken. Should we rename Userinfo endpoint to
                          something like "Userinfo Access Endpoint"? I
                          do not think so. 

                        Thirdly,
                          the term "Registration Access" does not seem
                          to be meaningful. 

                        When
                          you say "access", I suppose you are using the
                          noun version of it. 

                          (If
                            you are using the verb, then I am even more
                            against as a URL should not contain a
                            verb.) 

                          According
                            to the Webster, access (n.) is defined as: 

                          access
                            n.

                              1

                              a : onset 2
                              b : a
                                  fit of intense feeling : outburst

                              2

                              a : permission,

                                  liberty, or ability to enter,
                                  approach, or pass to and from a place
                                  or to approach or communicate with a
                                  person or thing
                              b : freedom
                                  or ability to obtain or make use of
                                  something
                              c : a
                                  way or means of access
                              d : the
                                  act or an instance of accessing

                              3

                              : an
                                  increase by addition <a sudden access of

                                  wealth>

                            Replacing
                              "access" with any of the definition above
                              does not seem to work. 

                            Remember,
                              a URL is represents a "thing". 

                            The
                              name of the endpoint should represent the
                              "thing". 

                            I
                              am merginally OK with "client registration
                              url" leveraging on the definition 2. below
                              (again from Webster -- my OED subscription
                              lapsed for the time being.) 

                            registration
                              n.

                                1

                                : the
                                    act of registering

                                2

                                : an
                                    entry in a register

                                3

                                : the
                                    number of individuals registered : enrollment

                                4

                                a : the
                                    art or act of selecting and
                                    adjusting pipe organ stops
                                b : the
                                    combination of stops selected for
                                    performing a particular organ work

                                5

                                : a
                                    document certifying an act of
                                    registering

                            However,
                              since the most common use of
                              "registration" is actually
                              1 above, it still is confusing. If
                              you really want to emphasize the fact that
                              it has been registered, then something
                              like "registered client info uri" or
                              "registered client metadata uri" would be
                              better. 

                            Nat

                            2013/2/20
                              Mike Jones <Michael.Jones@microsoft.com>

                                For
                                    what it’s worth, the name
                                    “registration_access_url” was chosen
                                    to be parallel to
                                    “registration_access_token”.   It’s
                                    the place you use the access token. 
                                    And it’s where you access an
                                    existing registration.  I’m against
                                    the name “client_metadata_url”
                                    because it’s not metadata you’re
                                    accessing – it’s a registration
                                    you’re accessing.  For the same
                                    reason, I don’t think the name
                                    “client_info_url” gives people the
                                    right idea, because it doesn’t say
                                    anything it being the registration
                                    that you’re accessing.

                                If
                                    you really want us to change this,
                                    having read what’s above, I could
                                    live with “client_registration_url”,
                                    but I don’t think a change is
                                    actually necessary.  (But if we are
                                    going to change it, let’s do it
                                    ASAP, before the OpenID Connect
                                    Implementer’s Drafts are published.)

                                    -- Mike

                                From:
                                    oauth-bounces@ietf.org
                                    [mailto:oauth-bounces@ietf.org]
                                    On Behalf Of Nat Sakimura

                                    Sent: Wednesday, February 20,
                                    2013 7:58 AM

                                    To: <oauth@ietf.org>;
                                    Richer, Justin P.; John Bradley

                                    Subject: Re: [OAUTH-WG] I-D
                                    Action:
                                    draft-ietf-oauth-dyn-reg-06.txt

                                Thanks
                                    Justin.

                                        Even
                                          if we go flat rather than
                                          doing JSON Structure, the
                                          "Client

                                        Registration
                                          Access Endpoint" is not a good
                                          representative name.

                                        What
                                          it represents is the client
                                          metadata/info.

                                        It
                                          is not representing "Client
                                          Registration Access". 

                                      What
                                        does "Client Registration
                                        Access" mean? 

                                      Does
                                          UPDATing "Cleint Registration
                                          Access" make sense?

                                          Something
                                            in the line of "Client
                                            Metadata Endpoint" and

                                          something
                                            like "client_metadata_url"
                                            or "client_info_url" is much
                                            better.

                                          Nat

                                        2013/2/15
                                          Richer, Justin P. <jricher@mitre.org>
                                        Everyone,
                                          there's a new draft of DynReg
                                          up on the tracker. This draft
                                          tries to codify the
                                          discussions so far from this
                                          week into something we can all
                                          read. There are still plenty
                                          of open discussion points and
                                          items up for debate. Please
                                          read through this latest draft
                                          and see what's changed and
                                          help assure that it properly
                                          captures the conversations. If
                                          you have any inputs for the
                                          marked [[ Editor's Note ]]
                                          sections, please send them to
                                          the list by next Thursday to
                                          give me opportunity to get any
                                          necessary changes in by the
                                          cutoff date of Monday the
                                          22nd.

                                          Thanks for all of your hard
                                          work everyone, I think this is
                                          *really* coming along now.

                                             -- Justin

                                              On Feb 15, 2013, at 4:54
                                              PM, 
                                                internet-drafts@ietf.org
                                              wrote:

                                              >

                                              > A New Internet-Draft
                                              is available from the
                                              on-line Internet-Drafts
                                              directories.

                                              > This draft is a work
                                              item of the Web
                                              Authorization Protocol
                                              Working Group of the IETF.

                                              >

                                              >       Title          
                                              : OAuth Dynamic Client
                                              Registration Protocol

                                              >       Author(s)      
                                              : Justin Richer

                                              >                      
                                                 John Bradley

                                              >                      
                                                 Michael B. Jones

                                              >                      
                                                 Maciej Machulak

                                              >       Filename      
                                               :
                                              draft-ietf-oauth-dyn-reg-06.txt

                                              >       Pages          
                                              : 21

                                              >       Date          
                                               : 2013-02-15

                                              >

                                              > Abstract:

                                              >   This specification
                                              defines an endpoint and
                                              protocol for dynamic

                                              >   registration of
                                              OAuth Clients at an
                                              Authorization Server.

                                              >

                                              >

                                              > The IETF datatracker
                                              status page for this draft
                                              is:

                                              > 
https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg

                                              >

                                              > There's also a
                                              htmlized version available
                                              at:

                                              > 
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06

                                              >

                                              > A diff from the
                                              previous version is
                                              available at:

                                              > 
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-06

                                              >

                                              >

                                              > Internet-Drafts are
                                              also available by
                                              anonymous FTP at:

                                              > ftp://ftp.ietf.org/internet-drafts/

                                              >

                                              >
                                              _______________________________________________

                                              > 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

                                      --

                                        Nat Sakimura (=nat)

                                        Chairman,
                                          OpenID Foundation

                                          http://nat.sakimura.org/

                                          @_nat_en

                          --

                            Nat Sakimura (=nat)

                            Chairman,
                              OpenID Foundation

                              http://nat.sakimura.org/

                              @_nat_en

            -- 

              Nat Sakimura (=nat) 

              Chairman, OpenID Foundation

                http://nat.sakimura.org/

                @_nat_en

--------------010709050103070701040005--

From Michael.Jones@microsoft.com  Wed Feb 20 11:09:29 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF32A21F8506 for ; Wed, 20 Feb 2013 11:09:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.585
X-Spam-Level: 
X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.013,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysIM9k9MGgPW for ; Wed, 20 Feb 2013 11:09:24 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.30]) by ietfa.amsl.com (Postfix) with ESMTP id 1027821F852C for ; Wed, 20 Feb 2013 11:09:23 -0800 (PST)
Received: from BL2FFO11FD017.protection.gbl (10.173.161.204) by BL2FFO11HUB005.protection.gbl (10.173.160.225) with Microsoft SMTP Server (TLS) id 15.0.620.12; Wed, 20 Feb 2013 19:09:12 +0000
Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD017.mail.protection.outlook.com (10.173.161.35) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Wed, 20 Feb 2013 19:09:12 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.96]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Wed, 20 Feb 2013 19:08:44 +0000
From: Mike Jones 
To: Justin Richer 
Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
Thread-Index: AQHOC8cMkbohP5vU0EO7eTLi/U/hMJh7eCuAgAd2gACAAAA6MIAADyiAgAAAlPCAAAbqAIAADigAgAAAsbCAAA3pAIAAAW8Q
Date: Wed, 20 Feb 2013 19:08:43 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436747B78E@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <20130215215423.23019.50224.idtracker@ietfa.amsl.com>   <4E1F6AAD24975D4BA5B16804296739436747A665@TK5EX14MBXC284.redmond.corp.microsoft.com>  <4E1F6AAD24975D4BA5B16804296739436747ADDB@TK5EX14MBXC284.redmond.corp.microsoft.com>  <512511B0.5090102@mitre.org> <4E1F6AAD24975D4BA5B16804296739436747B2BB@TK5EX14MBXC284.redmond.corp.microsoft.com> <51251DF0.8000804@mitre.org>
In-Reply-To: <51251DF0.8000804@mitre.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.75]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436747B78ETK5EX14MBXC284r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(377424002)(51704002)(377454001)(24454001)(51444002)(69224001)(65554002)(479174001)(20776003)(74662001)(47446002)(16406001)(56816002)(4396001)(54316002)(80022001)(56776001)(77982001)(59766001)(33656001)(63696002)(76482001)(51856001)(15202345001)(512954001)(53806001)(54356001)(74502001)(46102001)(31966008)(66066001)(16297215001)(55846006)(79102001)(47736001)(47976001)(49866001)(5343635001)(65816001)(16236675001)(5343655001)(44976002)(50986001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB005; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07630F72AD
Cc: "" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2013 19:09:30 -0000

--_000_4E1F6AAD24975D4BA5B16804296739436747B78ETK5EX14MBXC284r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

That's OK by me too.

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Wednesday, February 20, 2013 11:03 AM
To: Mike Jones
Cc: Nat Sakimura; ; John Bradley
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

On second thought, how about "registration_client_uri"? It's the URI for a =
particular client's registration. Use of the verb "registered" makes it sou=
nd like the result of an action that the client took, as if the client itse=
lf had registered the URI. That's obviously not the case, and we don't want=
 to convey that.

So, new proposed name: "registration_client_uri"

This has the nice side effect of being more parallel with "reigstration_acc=
ess_token".

 -- Justin
On 02/20/2013 01:13 PM, Mike Jones wrote:
SGTM

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Wednesday, February 20, 2013 10:11 AM
To: Nat Sakimura
Cc: Mike Jones; ; John Bradley
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

I like "registered_client_uri", given all of the other discussions on this =
thread, because:

URL/URI: It *is* a URL, and an https one at that, but if the IETF conventio=
n is to call it URI, then I'm fine with that.

registered_client/registration_access: The former is a good description of =
what's actually *at* the URL, which fits better with the RESTful entity mod=
el. I think Nat's criticisms about the original formation of the parameter =
name are spot on, though at the time we hadn't heard anything better.

So I'd like to change it to "registered_client_uri" in the next draft.

 -- Justin
On 02/20/2013 12:20 PM, Nat Sakimura wrote:
I have thought about that as well. The the reason I added "info" or "metada=
ta" was that what was behind the URL is not the client itself. By "client r=
egistration", I suppose you mean "client entry in the register" (cf. regist=
ration n 2.) . It is the "registered data/info/metadata" about the client.

Nat
2013/2/20 Mike Jones >
I could live with "registered_client_url".  I think that adding "_metadata"=
 or "_info" is incorrect, because what's being accessed is the client' regi=
stration - not just metadata or info about the client's registration (altho=
ugh that information can be retrieved as one aspect of the operations on th=
e client's registration).

                                                            -- Mike

From: Nat Sakimura [mailto:sakimura@gmail.com]
Sent: Wednesday, February 20, 2013 8:53 AM
To: Mike Jones
Cc: >; Richer, Justin P.; John Bradle=
y

Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

I have read the whole thing and still ---

Your argument that it is the place for using "registration access token" th=
us should have a parallel name "registration access url" is very weak. Ther=
e are several weakness.

First, "registration access token" actually is "registration" + "access tok=
en". Extracting "registration access" from "registration access token" is b=
roken.

Secondly, access token is used to against any protected resource. Recommend=
ing to use the word "access" in naming protected resources is broken. Shoul=
d we rename Userinfo endpoint to something like "Userinfo Access Endpoint"?=
 I do not think so.

Thirdly, the term "Registration Access" does not seem to be meaningful.
When you say "access", I suppose you are using the noun version of it.
(If you are using the verb, then I am even more against as a URL should not=
 contain a verb.)

According to the Webster, access (n.) is defined as:

access n.

1
a : onset 2
b : a fit of intense feeling : outburst
2
a : permission, liberty, or ability to enter, approach, or pass to and from=
 a place or to approach or communicate with a person or thing
b : freedom or ability to obtain or make use of something
c : a way or means of access
d : the act or an instance of accessing
3
: an increase by addition 

Replacing "access" with any of the definition above does not seem to work.

Remember, a URL is represents a "thing".
The name of the endpoint should represent the "thing".

I am merginally OK with "client registration url" leveraging on the definit=
ion 2. below (again from Webster -- my OED subscription lapsed for the time=
 being.)

registration n.

1
: the act of registering
2
: an entry in a register
3
: the number of individuals registered : enrollment
4
a : the art or act of selecting and adjusting pipe organ stops
b : the combination of stops selected for performing a particular organ wor=
k
5
: a document certifying an act of registering

However, since the most common use of "registration" is actually 1 above, i=
t still is confusing. If you really want to emphasize the fact that it has =
been registered, then something like "registered client info uri" or "regis=
tered client metadata uri" would be better.

Nat

2013/2/20 Mike Jones >
For what it's worth, the name "registration_access_url" was chosen to be pa=
rallel to "registration_access_token".   It's the place you use the access =
token.  And it's where you access an existing registration.  I'm against th=
e name "client_metadata_url" because it's not metadata you're accessing - i=
t's a registration you're accessing.  For the same reason, I don't think th=
e name "client_info_url" gives people the right idea, because it doesn't sa=
y anything it being the registration that you're accessing.

If you really want us to change this, having read what's above, I could liv=
e with "client_registration_url", but I don't think a change is actually ne=
cessary.  (But if we are going to change it, let's do it ASAP, before the O=
penID Connect Implementer's Drafts are published.)

                                                            -- Mike

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Nat Sakimura
Sent: Wednesday, February 20, 2013 7:58 AM
To: >; Richer, Justin P.; John Bradle=
y

Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

Thanks Justin.

Even if we go flat rather than doing JSON Structure, the "Client
Registration Access Endpoint" is not a good representative name.

What it represents is the client metadata/info.
It is not representing "Client Registration Access".
What does "Client Registration Access" mean?
Does UPDATing "Cleint Registration Access" make sense?

Something in the line of "Client Metadata Endpoint" and
something like "client_metadata_url" or "client_info_url" is much better.

Nat
2013/2/15 Richer, Justin P. >
Everyone, there's a new draft of DynReg up on the tracker. This draft tries=
 to codify the discussions so far from this week into something we can all =
read. There are still plenty of open discussion points and items up for deb=
ate. Please read through this latest draft and see what's changed and help =
assure that it properly captures the conversations. If you have any inputs =
for the marked [[ Editor's Note ]] sections, please send them to the list b=
y next Thursday to give me opportunity to get any necessary changes in by t=
he cutoff date of Monday the 22nd.

Thanks for all of your hard work everyone, I think this is *really* coming =
along now.

 -- Justin

On Feb 15, 2013, at 4:54 PM, internet-drafts@ietf.org wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
> This draft is a work item of the Web Authorization Protocol Working Group=
 of the IETF.
>
>       Title           : OAuth Dynamic Client Registration Protocol
>       Author(s)       : Justin Richer
>                          John Bradley
>                          Michael B. Jones
>                          Maciej Machulak
>       Filename        : draft-ietf-oauth-dyn-reg-06.txt
>       Pages           : 21
>       Date            : 2013-02-15
>
> Abstract:
>   This specification defines an endpoint and protocol for dynamic
>   registration of OAuth Clients at an Authorization Server.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-06
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> 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

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--_000_4E1F6AAD24975D4BA5B16804296739436747B78ETK5EX14MBXC284r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

That’s OK by me too=
.
 <=
/p>

From: Justin Richer [mailto:jricher@mitre.org]

Sent: Wednesday, February 20, 2013 11:03 AM

To: Mike Jones

Cc: Nat Sakimura; <oauth@ietf.org>; John Bradley

Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt<=
o:p>

On second thought, ho=
w about "registration_client_uri"? It's the URI for a particular =
client's registration. Use of the verb "registered" makes it soun=
d like the result of an action that the client took, as
 if the client itself had registered the URI. That's obviously not the case=
, and we don't want to convey that.

So, new proposed name: "registration_client_uri"

This has the nice side effect of being more parallel with "reigstratio=
n_access_token".

 -- Justin

On 02/20/2013 01:13 PM, Mike Jones wrote:=

SGTM
 <=
/p>

From: Justin Richer [mailto:jricher@mitre.org]

Sent: Wednesday, February 20, 2013 10:11 AM

To: Nat Sakimura

Cc: Mike Jones; <oauth@ietf.org=
>; John Bradley

Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt<=
/span>

I like "register=
ed_client_uri", given all of the other discussions on this thread, bec=
ause:

URL/URI: It *is* a URL, and an https one at that, but if the IETF conventio=
n is to call it URI, then I'm fine with that.

registered_client/registration_access: The former is a good description of =
what's actually *at* the URL, which fits better with the RESTful entity mod=
el. I think Nat's criticisms about the original formation of the parameter =
name are spot on, though at the
 time we hadn't heard anything better.

So I'd like to change it to "registered_client_uri" in the next d=
raft.

 -- Justin

On 02/20/2013 12:20 PM, Nat Sakimura wrote:

I have thought about that as well. The the reason I =
added "info" or "metadata" was that what was behind the=
 URL is not the client itself. By "client registration", I suppos=
e you mean "client entry in the register" (cf.
registration n 2.) . It is the "registered data/info/met=
adata" about the client. 

Nat

2013/2/20 Mike Jones <Michael.Jones@microsoft.com>

I could live with “registered_cli=
ent_url”.  I think that adding “_metadata” or “=
;_info” is incorrect,
 because what’s being accessed is the client’ registration R=
11; not just metadata or info about the client’s registration (althou=
gh that information can be retrieved as one aspect of the operations on the=
 client’s registration).

      &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;   -- Mike

From: Nat Sakimura [mailto:<=
a href=3D"mailto:sakimura@gmail.com" target=3D"_blank">sakimura@gmail.com]

Sent: Wednesday, February 20, 2013 8:53 AM

To: Mike Jones

Cc: <oauth@ie=
tf.org>; Richer, Justin P.; John Bradley

Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt<=
o:p>

I have read the whole thing and still --- 

Your argument that it is the place for using "registration ac=
cess token" thus should have a parallel name "registration access=
 url" is very weak. There are several weakness. 

First, "registration access token" actually is "reg=
istration" + "access token". Extracting "registrati=
on access" from "registration access token" is broken. =

Secondly, access token is used to against any protected resource.&=
nbsp;Recommending to use the word "access" in naming protect=
ed resources is broken. Should we rename Userinfo endpoint
 to something like "Userinfo Access Endpoint"? I do not think so.=

Thirdly, the term "Registration Access" does not seem to=
 be meaningful. 

When you say "access", I suppose you are using the noun =
version of it. 

(If you are using the verb, then I am even more against as a URL s=
hould not contain a verb.) 

According to the Webster, access (n.) is defined as: 

access
n.

1

a : onset 2

b : a fit of
 intense feeling : outburst

2

a : permission,
 liberty, or ability to enter, approach, or pass to and from a place or to =
approach or communicate with a person or thing

b : freedom or
 ability to obtain or make use of something

c : a way or
 means of access

d : the act or
 an instance of =
accessing

3

: an increase by addit=
ion <a sudden access of
 wealth>

Replacing "access" with any of the definition above does=
 not seem to work. 

Remember, a URL is represents a "thing". 

The name of the endpoint should represent the "thing".&n=
bsp;

I am merginally OK with "client registration url" levera=
ging on the definition 2. below (again from Webster -- my OED subscription =
lapsed for the time being.) 

registration
n.

1

: the act of registering<=
/span>

2

: an entry in a <=
a href=3D"http://www.merriam-webster.com/dictionary/register" target=3D"_bl=
ank">register

3

: the number of indivi=
duals registere=
d : enrollment

4

a : the art or
 act of selecting and adjusting pipe organ stops

b : the combination
 of stops selected for performing a particular organ work=

5

: a document certifyin=
g an act of registering

However, since the most common use of "registration" is =
actually
1 above, it still is confusing. If you really want to emphasize the =
fact that it has been registered, then something like "registered clie=
nt info uri" or "registered client metadata uri" would be be=
tter. 

Nat

2013/2/20 Mike Jones <Michael.Jones@microsoft.com>

For what it’s worth, the name =
220;registration_access_url” was chosen to be parallel to “regi=
stration_access_token”.  
 It’s the place you use the access token.  And it’s where =
you access an existing registration.  I’m against the name ̶=
0;client_metadata_url” because it’s not metadata you’re a=
ccessing – it’s a registration you’re accessing.  Fo=
r the same reason, I don’t think
 the name “client_info_url” gives people the right idea, becaus=
e it doesn’t say anything it being the registration that you’re=
 accessing.

If you really want us to change this, h=
aving read what’s above, I could live with “client_registration=
_url”,
 but I don’t think a change is actually necessary.  (But if we a=
re going to change it, let’s do it ASAP, before the OpenID Connect Im=
plementer’s Drafts are published.)

      &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;   -- Mike

From:
oauth-bounces@i=
etf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Nat Sakimura

Sent: Wednesday, February 20, 2013 7:58 AM

To: <oauth@ie=
tf.org>; Richer, Justin P.; John Bradley

Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt<=
o:p>

Thanks Justin.

Even if we go flat rather than doing JSON =
Structure, the "Client

Registration Access Endpoint" is not =
a good representative name.

What it represents is the client metadata/=
info.

It is not representing "Client Regist=
ration Access". 

What does "Client Registration Access" mean? <=
/o:p>

Does UPDATing "Cleint Reg=
istration Access" make sense?

Something in the line of "Client Meta=
data Endpoint" and

something like "client_metadata_url&q=
uot; or "client_info_url" is much better.

Nat

2013/2/15 Richer, Justin P. <jricher@mitre.org>
Everyone, there's a new draft of DynReg up on the tracker. This dr=
aft tries to codify the discussions so far from this week into something we=
 can all read. There are still plenty
 of open discussion points and items up for debate. Please read through thi=
s latest draft and see what's changed and help assure that it properly capt=
ures the conversations. If you have any inputs for the marked [[ Editor's N=
ote ]] sections, please send them
 to the list by next Thursday to give me opportunity to get any necessary c=
hanges in by the cutoff date of Monday the 22nd.

Thanks for all of your hard work everyone, I think this is *really* coming =
along now.

 -- Justin

On Feb 15, 2013, at 4:54 PM, 
internet-drafts@ietf.org wrote:

>

> A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.

> This draft is a work item of the Web Authorization Protocol Working Gr=
oup of the IETF.

>

>       Title           : OAuth =
Dynamic Client Registration Protocol

>       Author(s)       : Justin Richer
>                     =
     John Bradley

>                     =
     Michael B. Jones

>                     =
     Maciej Machulak

>       Filename        : draft-ietf-=
oauth-dyn-reg-06.txt

>       Pages           : 21

>       Date            : 2=
013-02-15

>

> Abstract:

>   This specification defines an endpoint and protocol for dynamic=

>   registration of OAuth Clients at an Authorization Server.

>

>

> The IETF datatracker status page for this draft is:

> 
https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg

>

> There's also a htmlized version available at:

> 
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06

>

> A diff from the previous version is available at:

> 
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-06

>

>

> Internet-Drafts are also available by anonymous FTP at:

> ftp:=
//ftp.ietf.org/internet-drafts/

>

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=

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

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

--

Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation

http://nat.sakimura.=
org/

@_nat_en

--

Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation

http://nat.sakimura.=
org/

@_nat_en

-- 

Nat Sakimura (=3Dnat) 

Chairman, OpenID Foundation

http://nat.sakimura.=
org/

@_nat_en

--_000_4E1F6AAD24975D4BA5B16804296739436747B78ETK5EX14MBXC284r_--

From donald.coffin@reminetworks.com  Wed Feb 20 11:31:21 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D501F0D0C for ; Wed, 20 Feb 2013 11:31:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.207
X-Spam-Level: 
X-Spam-Status: No, score=-1.207 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_05=-1.11, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IU539VcuI7ZU for ; Wed, 20 Feb 2013 11:31:20 -0800 (PST)
Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 0BF341F0D0A for ; Wed, 20 Feb 2013 11:31:19 -0800 (PST)
Received: (qmail 6058 invoked by uid 0); 20 Feb 2013 19:30:58 -0000
Received: from unknown (HELO host125.hostmonster.com) (74.220.207.125) by cpoproxy3.bluehost.com with SMTP; 20 Feb 2013 19:30:58 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default;  h=Content-Type:MIME-Version:Message-ID:Date:Subject:Cc:To:From; bh=BKvo1Lrq9rDA58rrpk7PmaClYZS04MdVWZ5W7hxQuLg=;  b=YzSiqUAoRtFvPwO9h0up0wBCojGHHl5WWQR/zIQp+rLGE1+a5hrw2melqQJlaRY9HENUeB+t5D9/W4riWb1XoE+a97CvauvePAPytSoyiGWKLmwiCjKutPr0zK0uHgPS;
Received: from [68.4.207.246] (port=1232 helo=HPPavilionElite) by host125.hostmonster.com with esmtpa (Exim 4.80) (envelope-from ) id 1U8FNa-0001rE-Fz; Wed, 20 Feb 2013 12:30:58 -0700
From: "Donald F Coffin" 
To: "Justin Richer" 
Date: Wed, 20 Feb 2013 11:29:40 -0800
Message-ID: <00ac01ce0fa0$a1325f20$e3971d60$@reminetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AD_01CE0F5D.930F1F20"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac4PoKDVLB+L7M/SQmiveWS+IxR60A==
Content-Language: en-us
X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.4.207.246 authed with donald.coffin@reminetworks.com}
Cc: oauth@ietf.org
Subject: [OAUTH-WG] Additional Oauth Dynamic Client Registration Protocol Information
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2013 19:31:21 -0000

This is a multipart message in MIME format.

------=_NextPart_000_00AD_01CE0F5D.930F1F20
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Justin,

I understand the current Client Registration request and response
information is based on the OPENID model for consistency, but has there been
any thought or discussion of adding the AS OAuth 2.0 endpoint URIs as part
of the registration response?  I believe the addition of the endpoint URIs
would make the dynamic client registration process truly a dynamic feature
of OAuth 2.0.

If the ability to discover the AS OAuth 2.0 endpoint URIs is being covered
by another IETF draft, I'd appreciate learning which current draft is being
worked on to achieve that result.

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

Phone:      (949) 636-8571

Email:       donald.coffin@reminetworks.com

------=_NextPart_000_00AD_01CE0F5D.930F1F20
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Justin,

I understand =
the current Client Registration request and response information is =
based on the OPENID model for consistency, but has there been any =
thought or discussion of adding the AS OAuth 2.0 endpoint URIs as part =
of the registration response?  I believe the addition of the =
endpoint URIs would make the dynamic client registration process truly a =
dynamic feature of OAuth 2.0.

If the ability =
to discover the AS OAuth 2.0 endpoint URIs is being covered by another =
IETF draft, I’d appreciate learning which current draft is being =
worked on to achieve that result.

Best =
regards,
Don
Donald F. Coffin
Founder/CTO

REMI =
Networks
22751 El Prado Suite =
6216
Rancho Santa Margarita, CA  =
92688-3836

Phone:      (949) =
636-8571
Email:       donald.coffin@reminetworks=
.com

------=_NextPart_000_00AD_01CE0F5D.930F1F20--

From Michael.Jones@microsoft.com  Wed Feb 20 11:38:15 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F1A21F84D9 for ; Wed, 20 Feb 2013 11:38:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.585
X-Spam-Level: 
X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.013,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIIBljWnB8V7 for ; Wed, 20 Feb 2013 11:38:13 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.24]) by ietfa.amsl.com (Postfix) with ESMTP id 227EA21F88CC for ; Wed, 20 Feb 2013 11:38:12 -0800 (PST)
Received: from BL2FFO11FD001.protection.gbl (10.173.161.204) by BL2FFO11HUB011.protection.gbl (10.173.161.117) with Microsoft SMTP Server (TLS) id 15.0.620.12; Wed, 20 Feb 2013 19:38:10 +0000
Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD001.mail.protection.outlook.com (10.173.160.101) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Wed, 20 Feb 2013 19:38:10 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.96]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Wed, 20 Feb 2013 19:37:49 +0000
From: Mike Jones 
To: Donald F Coffin , Justin Richer 
Thread-Topic: [OAUTH-WG] Additional Oauth Dynamic Client Registration Protocol	Information
Thread-Index: Ac4PoKDVLB+L7M/SQmiveWS+IxR60AAAJY5w
Date: Wed, 20 Feb 2013 19:37:48 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436747B862@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <00ac01ce0fa0$a1325f20$e3971d60$@reminetworks.com>
In-Reply-To: <00ac01ce0fa0$a1325f20$e3971d60$@reminetworks.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.75]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436747B862TK5EX14MBXC284r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(377454001)(252514003)(47976001)(63696002)(44976002)(54356001)(46102001)(55846006)(16406001)(53806001)(512954001)(54316002)(15395725002)(49866001)(15202345001)(33656001)(51856001)(56776001)(20776003)(77982001)(59766001)(5343635001)(5343655001)(65816001)(66066001)(74502001)(74662001)(31966008)(16236675001)(50986001)(56816002)(4396001)(47736001)(5343645001)(76482001)(79102001)(47446002)(80022001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB011; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07630F72AD
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Additional Oauth Dynamic Client Registration Protocol	Information
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2013 19:38:15 -0000

--_000_4E1F6AAD24975D4BA5B16804296739436747B862TK5EX14MBXC284r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Don,

Discovery is a process that happens before Registration, and that's the poi=
nt at which you would return the AS (and registration!) endpoints to the Cl=
ient.  The OAuth WG considered doing its own discovery work but ultimately =
decided to have that happen in the Apps Area WG instead, which is close to =
completing the WebFinger discovery specification.

If you want to see how OpenID Connect is performing discovery using WebFing=
er, including discovery of the AS endpoint, have a look at http://openid.ne=
t/specs/openid-connect-discovery-1_0.html.

                                                                Best wishes=
,
                                                                -- Mike

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of D=
onald F Coffin
Sent: Wednesday, February 20, 2013 11:30 AM
To: Justin Richer
Cc: oauth@ietf.org
Subject: [OAUTH-WG] Additional Oauth Dynamic Client Registration Protocol I=
nformation

Justin,

I understand the current Client Registration request and response informati=
on is based on the OPENID model for consistency, but has there been any tho=
ught or discussion of adding the AS OAuth 2.0 endpoint URIs as part of the =
registration response?  I believe the addition of the endpoint URIs would m=
ake the dynamic client registration process truly a dynamic feature of OAut=
h 2.0.

If the ability to discover the AS OAuth 2.0 endpoint URIs is being covered =
by another IETF draft, I'd appreciate learning which current draft is being=
 worked on to achieve that result.

Best regards,
Don
Donald F. Coffin
Founder/CTO

REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA  92688-3836

Phone:      (949) 636-8571
Email:       donald.coffin@reminetworks.com

--_000_4E1F6AAD24975D4BA5B16804296739436747B862TK5EX14MBXC284r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Don,

Discovery is a process=
 that happens before Registration, and that’s the point at which you =
would return the AS (and registration!) endpoints to the Client.  The =
OAuth WG considered doing its own discovery work
 but ultimately decided to have that happen in the Apps Area WG instead, wh=
ich is close to completing the WebFinger discovery specification.

If you want to see how=
 OpenID Connect is performing discovery using WebFinger, including discover=
y of the AS endpoint, have a look at
http:=
//openid.net/specs/openid-connect-discovery-1_0.html.=

   &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;          Best wishes,<=
/o:p>
   &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;          -- Mike=

From: oauth-bo=
unces@ietf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Donald F Coffin

Sent: Wednesday, February 20, 2013 11:30 AM

To: Justin Richer

Cc: oauth@ietf.org

Subject: [OAUTH-WG] Additional Oauth Dynamic Client Registration Pro=
tocol Information

Justin,

I understand the current Client Registration=
 request and response information is based on the OPENID model for consiste=
ncy, but has there been any thought or discussion of adding
 the AS OAuth 2.0 endpoint URIs as part of the registration response? =
 I believe the addition of the endpoint URIs would make the dynamic client =
registration process truly a dynamic feature of OAuth 2.0.

If the ability to discover the AS OAuth 2.0 =
endpoint URIs is being covered by another IETF draft, I’d appreciate =
learning which current draft is being worked on to achieve that
 result.

Best regards,<=
/o:p>
Don
Donald F. Coffin
Founder/CTO

REMI Networks<=
/o:p>
22751 El Prado Suit=
e 6216
Rancho Santa Margar=
ita, CA  92688-3836

Phone:  &=
nbsp;   (949) 636-8571
Email:  &=
nbsp;    
donald.coffin@reminetworks.com

--_000_4E1F6AAD24975D4BA5B16804296739436747B862TK5EX14MBXC284r_--

From jricher@mitre.org  Wed Feb 20 11:51:04 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E2221F8619 for ; Wed, 20 Feb 2013 11:51:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.575
X-Spam-Level: 
X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.023,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7zKoEOXpzgl for ; Wed, 20 Feb 2013 11:51:02 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0878621F85F5 for ; Wed, 20 Feb 2013 11:51:02 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7A49E53101E2; Wed, 20 Feb 2013 14:50:59 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 613F653101EC; Wed, 20 Feb 2013 14:50:59 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 20 Feb 2013 14:50:59 -0500
Message-ID: <512528EE.8000303@mitre.org>
Date: Wed, 20 Feb 2013 14:50:06 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Mike Jones 
References: <00ac01ce0fa0$a1325f20$e3971d60$@reminetworks.com> <4E1F6AAD24975D4BA5B16804296739436747B862@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436747B862@TK5EX14MBXC284.redmond.corp.microsoft.com>
Content-Type: multipart/alternative; boundary="------------060009050904040202070809"
X-Originating-IP: [129.83.31.58]
Cc: Donald F Coffin , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Additional Oauth Dynamic Client Registration Protocol Information
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2013 19:51:04 -0000

--------------060009050904040202070809
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Additionally, there is an individual draft that registers LRDD Link 
Types for discovery using LRDD and HostMeta:

http://tools.ietf.org/html/draft-wmills-oauth-lrdd-07

  -- Justin

On 02/20/2013 02:37 PM, Mike Jones wrote:
>
> Hi Don,
>
> Discovery is a process that happens before Registration, and that's 
> the point at which you would return the AS (and registration!) 
> endpoints to the Client.  The OAuth WG considered doing its own 
> discovery work but ultimately decided to have that happen in the Apps 
> Area WG instead, which is close to completing the WebFinger discovery 
> specification.
>
> If you want to see how OpenID Connect is performing discovery using 
> WebFinger, including discovery of the AS endpoint, have a look at 
> http://openid.net/specs/openid-connect-discovery-1_0.html.
>
> Best wishes,
>
> -- Mike
>
> *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On 
> Behalf Of *Donald F Coffin
> *Sent:* Wednesday, February 20, 2013 11:30 AM
> *To:* Justin Richer
> *Cc:* oauth@ietf.org
> *Subject:* [OAUTH-WG] Additional Oauth Dynamic Client Registration 
> Protocol Information
>
> Justin,
>
> I understand the current Client Registration request and response 
> information is based on the OPENID model for consistency, but has 
> there been any thought or discussion of adding the AS OAuth 2.0 
> endpoint URIs as part of the registration response?  I believe the 
> addition of the endpoint URIs would make the dynamic client 
> registration process truly a dynamic feature of OAuth 2.0.
>
> If the ability to discover the AS OAuth 2.0 endpoint URIs is being 
> covered by another IETF draft, I'd appreciate learning which current 
> draft is being worked on to achieve that result.
>
> Best regards,
>
> Don
>
> Donald F. Coffin
>
> Founder/CTO
>
> REMI Networks
>
> 22751 El Prado Suite 6216
>
> Rancho Santa Margarita, CA  92688-3836
>
> Phone: (949) 636-8571
>
> Email: donald.coffin@reminetworks.com 
> 
>

--------------060009050904040202070809
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

    Additionally, there is an individual draft that registers LRDD Link
    Types for discovery using LRDD and HostMeta:

    http://tools.ietf.org/html/draft-wmills-oauth-lrdd-07

     -- Justin

    On 02/20/2013 02:37 PM, Mike Jones
      wrote:

        Hi Don,

        Discovery is a
            process that happens before Registration, and that’s the
            point at which you would return the AS (and registration!)
            endpoints to the Client.  The OAuth WG considered doing its
            own discovery work but ultimately decided to have that
            happen in the Apps Area WG instead, which is close to
            completing the WebFinger discovery specification.

        If you want to
            see how OpenID Connect is performing discovery using
            WebFinger, including discovery of the AS endpoint, have a
            look at
            http://openid.net/specs/openid-connect-discovery-1_0.html.

            Best wishes,

            -- Mike

            From:
                oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]
                On Behalf Of Donald F Coffin

                Sent: Wednesday, February 20, 2013 11:30 AM

                To: Justin Richer

                Cc: oauth@ietf.org

                Subject: [OAUTH-WG] Additional Oauth Dynamic
                Client Registration Protocol Information

        Justin,

        I
            understand the current Client Registration request and
            response information is based on the OPENID model for
            consistency, but has there been any thought or discussion of
            adding the AS OAuth 2.0 endpoint URIs as part of the
            registration response?  I believe the addition of the
            endpoint URIs would make the dynamic client registration
            process truly a dynamic feature of OAuth 2.0.

        If
            the ability to discover the AS OAuth 2.0 endpoint URIs is
            being covered by another IETF draft, I’d appreciate learning
            which current draft is being worked on to achieve that
            result.

        Best
            regards,
        Don
        Donald F.
            Coffin
        Founder/CTO

        REMI
            Networks
        22751 El
            Prado Suite 6216
        Rancho Santa
            Margarita, CA  92688-3836

        Phone:     
            (949) 636-8571
        Email:      

              donald.coffin@reminetworks.com

--------------060009050904040202070809--

From ve7jtb@ve7jtb.com  Wed Feb 20 12:01:01 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6312E21E80E6 for ; Wed, 20 Feb 2013 12:01:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.459
X-Spam-Level: 
X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.139,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ujnj9HetjyrB for ; Wed, 20 Feb 2013 12:00:59 -0800 (PST)
Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by ietfa.amsl.com (Postfix) with ESMTP id DF73D21E80C4 for ; Wed, 20 Feb 2013 12:00:56 -0800 (PST)
Received: by mail-qa0-f48.google.com with SMTP id j8so2624602qah.0 for ; Wed, 20 Feb 2013 12:00:56 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=uS68PLc7kXwZGlW5cG/Ohqzezr37n4l7A12NPQrtkHQ=; b=Vf7QowREEUc1plfSNB1ZHfSWCRu9dv2zc3s+7WBUktdBuA/M7LhWoLwhJaNNuytHm6 Wg764eaWiB1XmM6PdGZMiGE8Fu0tX+CJOLuttWqwpkLgGG1ofoAC1Yz9k8PS8yqlGra/ qtcKEDIrblwSyAb2myR8AHmDlLho6F0kSiQZwfP6CXu76o9BmK14va/0AwSojHnoryzA wsVoUquVghoCPRd0A+Z8GbaoTO7rG6zWGEcqTqom2fx6A5AYGyZdWBrWlGrdkBGIqH6F RZ5QGfLOtEE5wKoNJ5dv9TIEvq/3U7Ex7rJdGj9K3I9rE2kZD96av1mLgHG+1VJIbsM7 sVdA==
X-Received: by 10.224.176.70 with SMTP id bd6mr10198001qab.26.1361390456248; Wed, 20 Feb 2013 12:00:56 -0800 (PST)
Received: from [192.168.1.213] (190-20-41-134.baf.movistar.cl. [190.20.41.134]) by mx.google.com with ESMTPS id s6sm11554941qaz.13.2013.02.20.12.00.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 12:00:54 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_1F9B7C9B-F76A-4E2F-923C-67CD5FDE1A8F"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <51251DF0.8000804@mitre.org>
Date: Wed, 20 Feb 2013 17:00:20 -0300
Message-Id: <133FFE3D-70FD-48C3-B95F-AB26DEC1F7E8@ve7jtb.com>
References: <20130215215423.23019.50224.idtracker@ietfa.amsl.com>   <4E1F6AAD24975D4BA5B16804296739436747A665@TK5EX14MBXC284.redmond.corp.microsoft.com>  <4E1F6AAD24975D4BA5B16804296739436747ADDB@TK5EX14MBXC284.redmond.corp.microsoft.com>  <512511B0.5090102@mitre.org> <4E1F6AAD24975D4BA5B16804296739436747B2BB@TK5EX14MBXC284.redmond.corp.microsoft.com> <51251DF0.8000804@mitre.org>
To: Justin Richer 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQlnLpami3Q4knzxi6s0QZK8ikGP3lLgvstYkXvjZrufrAgj5R9rLT/3Eac02dDeoVRKrTnq
Cc: "" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2013 20:01:01 -0000

--Apple-Mail=_1F9B7C9B-F76A-4E2F-923C-67CD5FDE1A8F
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_53748FC4-84C5-4596-9D1B-0CB10917D991"

--Apple-Mail=_53748FC4-84C5-4596-9D1B-0CB10917D991
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I am OK with that.
On 2013-02-20, at 4:03 PM, Justin Richer  wrote:

> On second thought, how about "registration_client_uri"? It's the URI =
for a particular client's registration. Use of the verb "registered" =
makes it sound like the result of an action that the client took, as if =
the client itself had registered the URI. That's obviously not the case, =
and we don't want to convey that.=20
>=20
> So, new proposed name: "registration_client_uri"
>=20
> This has the nice side effect of being more parallel with =
"reigstration_access_token".=20
>=20
>  -- Justin
>=20
> On 02/20/2013 01:13 PM, Mike Jones wrote:
>> SGTM
>> =20
>> From: Justin Richer [mailto:jricher@mitre.org]=20
>> Sent: Wednesday, February 20, 2013 10:11 AM
>> To: Nat Sakimura
>> Cc: Mike Jones; ; John Bradley
>> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
>> =20
>> I like "registered_client_uri", given all of the other discussions on =
this thread, because:
>>=20
>> URL/URI: It *is* a URL, and an https one at that, but if the IETF =
convention is to call it URI, then I'm fine with that.
>>=20
>> registered_client/registration_access: The former is a good =
description of what's actually *at* the URL, which fits better with the =
RESTful entity model. I think Nat's criticisms about the original =
formation of the parameter name are spot on, though at the time we =
hadn't heard anything better.
>>=20
>>=20
>> So I'd like to change it to "registered_client_uri" in the next =
draft.
>>=20
>>  -- Justin
>>=20
>> On 02/20/2013 12:20 PM, Nat Sakimura wrote:
>> I have thought about that as well. The the reason I added "info" or =
"metadata" was that what was behind the URL is not the client itself. By =
"client registration", I suppose you mean "client entry in the register" =
(cf. registration n 2.) . It is the "registered data/info/metadata" =
about the client.=20
>> =20
>> Nat
>>=20
>> 2013/2/20 Mike Jones 
>> I could live with =93registered_client_url=94.  I think that adding =
=93_metadata=94 or =93_info=94 is incorrect, because what=92s being =
accessed is the client=92 registration =96 not just metadata or info =
about the client=92s registration (although that information can be =
retrieved as one aspect of the operations on the client=92s =
registration).
>> =20
>>                                                             -- Mike
>> =20
>> From: Nat Sakimura [mailto:sakimura@gmail.com]=20
>> Sent: Wednesday, February 20, 2013 8:53 AM
>> To: Mike Jones
>> Cc: ; Richer, Justin P.; John Bradley
>>=20
>> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
>> =20
>> I have read the whole thing and still ---=20
>> =20
>> Your argument that it is the place for using "registration access =
token" thus should have a parallel name "registration access url" is =
very weak. There are several weakness.=20
>> =20
>> First, "registration access token" actually is "registration" + =
"access token". Extracting "registration access" from "registration =
access token" is broken.=20
>> =20
>> Secondly, access token is used to against any protected resource. =
Recommending to use the word "access" in naming protected resources is =
broken. Should we rename Userinfo endpoint to something like "Userinfo =
Access Endpoint"? I do not think so.=20
>> =20
>> Thirdly, the term "Registration Access" does not seem to be =
meaningful.=20
>> When you say "access", I suppose you are using the noun version of =
it.=20
>> (If you are using the verb, then I am even more against as a URL =
should not contain a verb.)=20
>> =20
>> According to the Webster, access (n.) is defined as:=20
>> =20
>> access n.
>> =20
>> 1
>> a : onset 2
>> b : a fit of intense feeling : outburst
>> 2
>> a : permission, liberty, or ability to enter, approach, or pass to =
and from a place or to approach or communicate with a person or thing
>> b : freedom or ability to obtain or make use of something
>> c : a way or means of access
>> d : the act or an instance of accessing
>> 3
>> : an increase by addition 
>> =20
>> Replacing "access" with any of the definition above does not seem to =
work.=20
>> =20
>> Remember, a URL is represents a "thing".=20
>> The name of the endpoint should represent the "thing".=20
>> =20
>> I am merginally OK with "client registration url" leveraging on the =
definition 2. below (again from Webster -- my OED subscription lapsed =
for the time being.)=20
>> =20
>> registration n.
>> =20
>> 1
>> : the act of registering
>> 2
>> : an entry in a register
>> 3
>> : the number of individuals registered : enrollment
>> 4
>> a : the art or act of selecting and adjusting pipe organ stops
>> b : the combination of stops selected for performing a particular =
organ work
>> 5
>> : a document certifying an act of registering
>> =20
>> However, since the most common use of "registration" is actually 1 =
above, it still is confusing. If you really want to emphasize the fact =
that it has been registered, then something like "registered client info =
uri" or "registered client metadata uri" would be better.=20
>> =20
>> Nat
>> =20
>> =20
>> 2013/2/20 Mike Jones 
>> For what it=92s worth, the name =93registration_access_url=94 was =
chosen to be parallel to =93registration_access_token=94.   It=92s the =
place you use the access token.  And it=92s where you access an existing =
registration.  I=92m against the name =93client_metadata_url=94 because =
it=92s not metadata you=92re accessing =96 it=92s a registration you=92re =
accessing.  For the same reason, I don=92t think the name =
=93client_info_url=94 gives people the right idea, because it doesn=92t =
say anything it being the registration that you=92re accessing.
>> =20
>> If you really want us to change this, having read what=92s above, I =
could live with =93client_registration_url=94, but I don=92t think a =
change is actually necessary.  (But if we are going to change it, let=92s =
do it ASAP, before the OpenID Connect Implementer=92s Drafts are =
published.)
>> =20
>>                                                             -- Mike
>> =20
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf Of Nat Sakimura
>> Sent: Wednesday, February 20, 2013 7:58 AM
>> To: ; Richer, Justin P.; John Bradley
>>=20
>> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
>> =20
>> Thanks Justin.
>>=20
>>=20
>> Even if we go flat rather than doing JSON Structure, the "Client
>> Registration Access Endpoint" is not a good representative name.
>>=20
>> What it represents is the client metadata/info.
>> It is not representing "Client Registration Access".=20
>> What does "Client Registration Access" mean?=20
>> Does UPDATing "Cleint Registration Access" make sense?
>>=20
>> Something in the line of "Client Metadata Endpoint" and
>> something like "client_metadata_url" or "client_info_url" is much =
better.
>>=20
>> Nat
>>=20
>> 2013/2/15 Richer, Justin P. 
>> Everyone, there's a new draft of DynReg up on the tracker. This draft =
tries to codify the discussions so far from this week into something we =
can all read. There are still plenty of open discussion points and items =
up for debate. Please read through this latest draft and see what's =
changed and help assure that it properly captures the conversations. If =
you have any inputs for the marked [[ Editor's Note ]] sections, please =
send them to the list by next Thursday to give me opportunity to get any =
necessary changes in by the cutoff date of Monday the 22nd.
>>=20
>> Thanks for all of your hard work everyone, I think this is *really* =
coming along now.
>>=20
>>  -- Justin
>>=20
>> On Feb 15, 2013, at 4:54 PM, internet-drafts@ietf.org wrote:
>>=20
>> >
>> > A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>> > This draft is a work item of the Web Authorization Protocol Working =
Group of the IETF.
>> >
>> >       Title           : OAuth Dynamic Client Registration Protocol
>> >       Author(s)       : Justin Richer
>> >                          John Bradley
>> >                          Michael B. Jones
>> >                          Maciej Machulak
>> >       Filename        : draft-ietf-oauth-dyn-reg-06.txt
>> >       Pages           : 21
>> >       Date            : 2013-02-15
>> >
>> > Abstract:
>> >   This specification defines an endpoint and protocol for dynamic
>> >   registration of OAuth Clients at an Authorization Server.
>> >
>> >
>> > The IETF datatracker status page for this draft is:
>> > https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
>> >
>> > There's also a htmlized version available at:
>> > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06
>> >
>> > A diff from the previous version is available at:
>> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-06
>> >
>> >
>> > Internet-Drafts are also available by anonymous FTP at:
>> > ftp://ftp.ietf.org/internet-drafts/
>> >
>> > _______________________________________________
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>>=20
>> =20
>> --=20
>> Nat Sakimura (=3Dnat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>>=20
>>=20
>> =20
>> --=20
>> Nat Sakimura (=3Dnat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>>=20
>>=20
>> =20
>> --=20
>> Nat Sakimura (=3Dnat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>> =20
>=20

--Apple-Mail=_53748FC4-84C5-4596-9D1B-0CB10917D991
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

I am =
OK with that.
On 2013-02-20, at 4:03 PM, Justin Richer =
<jricher@mitre.org> =
wrote:

 =20

 =20

    On second thought, how about "registration_client_uri"? It's the URI
    for a particular client's registration. Use of the verb "registered"
    makes it sound like the result of an action that the client took, as
    if the client itself had registered the URI. That's obviously not
    the case, and we don't want to convey that. 

    So, new proposed name: "registration_client_uri"

    This has the nice side effect of being more parallel with
    "reigstration_access_token". 

     -- Justin

    On 02/20/2013 01:13 PM, Mike Jones
      wrote:

      SGTM

          From:
                Justin Richer [mailto:jricher@mitre.org]

                Sent: Wednesday, February 20, 2013 10:11 AM

                To: Nat Sakimura

                Cc: Mike Jones; <oauth@ietf.org>; John
                Bradley

                Subject: Re: [OAUTH-WG] I-D Action:
                draft-ietf-oauth-dyn-reg-06.txt

I like
          "registered_client_uri", given all of the other discussions on
          this thread, because:

          URL/URI: It *is* a URL, and an https one at that, but if the
          IETF convention is to call it URI, then I'm fine with =
that.

          registered_client/registration_access: The former is a good
          description of what's actually *at* the URL, which fits better
          with the RESTful entity model. I think Nat's criticisms about
          the original formation of the parameter name are spot on,
          though at the time we hadn't heard anything better.

          So I'd like to change it to "registered_client_uri" in the
          next draft.

           -- Justin
        On 02/20/2013 12:20 PM, Nat Sakimura
            wrote:

        I have thought about that as well. The
            the reason I added "info" or "metadata" was that what was
            behind the URL is not the client itself. By "client
            registration", I suppose you mean "client entry in the
            register" (cf.
            registration n 2.) . It is the "registered
            data/info/metadata" about the client. 

          Nat
            2013/2/20 Mike Jones <Michael.Jones@microsoft.com>

                I
                      could live with =93registered_client_url=94.  =
I think
                      that adding =93_metadata=94 or =93_info=94 is =
incorrect,
                      because what=92s being accessed is the client=92
                      registration =96 not just metadata or info about =
the
                      client=92s registration (although that information
                      can be retrieved as one aspect of the operations
                      on the client=92s =
registration).

        &nbs=
p;            =
            &n=
bsp;           &nbs=
p;            =

                      -- Mike

From:
                      Nat Sakimura [mailto:sakimura@gmail.com]

                      Sent: Wednesday, February 20, 2013 8:53 =
AM

                      To: Mike Jones

                      Cc: <oauth@ietf.org>;
                      Richer, Justin P.; John =
Bradley

                        Subject: Re: [OAUTH-WG] I-D Action:
                        draft-ietf-oauth-dyn-reg-06.txt

I
                        have read the whole thing and still =
--- 

                      Your
                          argument that it is the place for using
                          "registration access token" thus should have a
                          parallel name "registration access url" is
                          very weak. There are several =
weakness. 

                      First,
                          "registration access token" actually is
                          "registration" + "access token". Extracting
                          "registration access" from "registration
                          access token" is broken. 

                      Secondly,
                          access token is used to against any protected
                          resource. Recommending to use the =
word
                          "access" in naming protected resources is
                          broken. Should we rename Userinfo endpoint to
                          something like "Userinfo Access Endpoint"? I
                          do not think so. 

                      Thirdly,
                          the term "Registration Access" does not seem
                          to be meaningful. 

                      When
                          you say "access", I suppose you are using the
                          noun version of it. 

                        (If
                            you are using the verb, then I am even more
                            against as a URL should not contain a
                            verb.) 

                        According
                            to the Webster, access (n.) is defined =
as: 

                        access
                            n.

                            1

                            a :<=
/strong> onset 2
b :<=
/strong> a
                                  fit of intense =
feeling :<=
/strong> outburst=

                            2

                            a :<=
/strong> permission,

                                  liberty, or ability to enter,
                                  approach, or pass to and from a place
                                  or to approach or communicate with a
                                  person or =
thing
b :<=
/strong> freedom
                                  or ability to obtain or make use of
                                  something
c :<=
/strong> a
                                  way or means of =
access
d :<=
/strong> the
                                  act or an instance of accessing<=
/o:p>

                            3

                            : an
                                  increase by addition <a =
sudden access of

                                  wealth>

                          Replacing
                              "access" with any of the definition above
                              does not seem to =
work. 

                          Remember,
                              a URL is represents a =
"thing". 

                          The
                              name of the endpoint should represent the
                              "thing". 

                          I
                              am merginally OK with "client registration
                              url" leveraging on the definition 2. below
                              (again from Webster -- my OED subscription
                              lapsed for the time =
being.) 

                          registrati=
on
                              n.

                              1

                              : the
                                    act of registering

                              2

                              : an
                                    entry in a register

                              3

                              : the
                                    number of individuals registered :<=
/strong> enrollment

                              4

                              a :<=
/strong> the
                                    art or act of selecting and
                                    adjusting pipe organ =
stops
b :<=
/strong> the
                                    combination of stops selected for
                                    performing a particular organ =
work

                              5

                              : a
                                    document certifying an act of
                                    registering

                          However,
                              since the most common use of
                              "registration" is actually
                              1 above, it still is confusing. If
                              you really want to emphasize the fact that
                              it has been registered, then something
                              like "registered client info uri" or
                              "registered client metadata uri" would be
                              better. 

                          Nat

                          2013/2/20
                              Mike Jones <Michael.Jones@microsoft.com>

                              For
                                    what it=92s worth, the name
                                    =93registration_access_url=94 was =
chosen
                                    to be parallel to
                                    =
=93registration_access_token=94.   It=92s
                                    the place you use the access =
token. 
                                    And it=92s where you access an
                                    existing registration.  I=92m =
against
                                    the name =93client_metadata_url=94
                                    because it=92s not metadata you=92re
                                    accessing =96 it=92s a registration
                                    you=92re accessing.  For the =
same
                                    reason, I don=92t think the name
                                    =93client_info_url=94 gives people =
the
                                    right idea, because it doesn=92t say
                                    anything it being the registration
                                    that you=92re =
accessing.

If
                                    you really want us to change this,
                                    having read what=92s above, I could
                                    live with =93client_registration_url=94=
,
                                    but I don=92t think a change is
                                    actually necessary.  (But if we =
are
                                    going to change it, let=92s do it
                                    ASAP, before the OpenID Connect
                                    Implementer=92s Drafts are =
published.)

        &nbs=
p;            =
            &n=
bsp;           &nbs=
p;            =

                                    -- Mike

From:
                                    oauth-bounces@ietf.org
                                    [mailto:oauth-bounces@ietf.org]
                                    On Behalf Of Nat Sakimura

                                    Sent: Wednesday, February 20,
                                    2013 7:58 AM

                                    To: <oauth@ietf.org>;
                                    Richer, Justin P.; John =
Bradley

                                    Subject: Re: [OAUTH-WG] I-D
                                    Action:
                                    =
draft-ietf-oauth-dyn-reg-06.txt

Thanks
                                    Justin.

                                        Even
                                          if we go flat rather than
                                          doing JSON Structure, the
                                          "Client

                                        Registration
                                          Access Endpoint" is not a good
                                          representative =
name.

                                        What
                                          it represents is the client
                                          metadata/info.

                                        It
                                          is not representing "Client
                                          Registration =
Access". 

                                    What
                                        does "Client Registration
                                        Access" =
mean? 

                                    Does
                                          UPDATing "Cleint Registration
                                          Access" make sense?

                                          Something
                                            in the line of "Client
                                            Metadata Endpoint" =
and

                                          something
                                            like "client_metadata_url"
                                            or "client_info_url" is =
much
                                            better.

                                          Nat
                                      2013/2/15
                                          Richer, Justin P. <jricher@mitre.org>
Everyone,
                                          there's a new draft of DynReg
                                          up on the tracker. This draft
                                          tries to codify the
                                          discussions so far from this
                                          week into something we can all
                                          read. There are still plenty
                                          of open discussion points and
                                          items up for debate. Please
                                          read through this latest draft
                                          and see what's changed and
                                          help assure that it properly
                                          captures the conversations. If
                                          you have any inputs for the
                                          marked [[ Editor's Note ]]
                                          sections, please send them to
                                          the list by next Thursday to
                                          give me opportunity to get any
                                          necessary changes in by the
                                          cutoff date of Monday the
                                          22nd.

                                          Thanks for all of your hard
                                          work everyone, I think this is
                                          *really* coming along now.

                                             -- =
Justin

                                              On Feb 15, 2013, at 4:54
                                              PM, 
                                                =
internet-drafts@ietf.org
                                              wrote:

                                              >

                                              > A New Internet-Draft
                                              is available from the
                                              on-line Internet-Drafts
                                              directories.

                                              > This draft is a work
                                              item of the Web
                                              Authorization Protocol
                                              Working Group of the =
IETF.

                                              >

                                              >       =
Title          
                                              : OAuth Dynamic Client
                                              Registration Protocol

                                              >       =
Author(s)      
                                              : Justin Richer

                                              >       =

                                                 John =
Bradley

                                              >       =

                                                 Michael B. =
Jones

                                              >       =

                                                 Maciej =
Machulak

                                              >       =
Filename      
                                               :
                                              =
draft-ietf-oauth-dyn-reg-06.txt

                                              >       =
Pages          
                                              : 21

                                              >       =
Date          
                                               : 2013-02-15

                                              >

                                              > Abstract:

                                              >   This =
specification
                                              defines an endpoint and
                                              protocol for dynamic

                                              >   registration =
of
                                              OAuth Clients at an
                                              Authorization Server.

                                              >

                                              >

                                              > The IETF datatracker
                                              status page for this draft
                                              is:

                                              > 
https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg

                                              >

                                              > There's also a
                                              htmlized version available
                                              at:

                                              > 
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06

                                              >

                                              > A diff from the
                                              previous version is
                                              available at:

                                              > 
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-06

                                              >

                                              >

                                              > Internet-Drafts are
                                              also available by
                                              anonymous FTP at:

                                              > ftp://ftp.ietf.org/internet-drafts/

                                              >

                                              >
                                              =
_______________________________________________

                                              > 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

--

                                        Nat Sakimura =
(=3Dnat)
                                      Chairman,
                                          OpenID Foundation

                                          http://nat.sakimura.org/

                                          @_nat_en

--

                            Nat Sakimura (=3Dnat)
                          Chairman,
                              OpenID Foundation

                              http://nat.sakimura.org/

                              @_nat_en

-- 

              Nat Sakimura (=3Dnat) 
            Chairman, OpenID Foundation

                http://nat.sakimura.org/

                @_nat_en

=

--Apple-Mail=_53748FC4-84C5-4596-9D1B-0CB10917D991--

--Apple-Mail=_1F9B7C9B-F76A-4E2F-923C-67CD5FDE1A8F
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMjIwMjAwMDI0WjAjBgkqhkiG9w0BCQQxFgQUTgmgTcxa
5sNEd4LgFJqo2l3x920wgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAKdstqYstYjMttOalfvwRz8VhavWwe4VfWOtB+cMq
nQqbn+XkP3aNAl/FU51Vnvn2Ql2lU7bpuGFhYrtwV3zkaAANxaTezv1jQDLVcIaBmrELTwgeC/ut
DPjg+vmFzuTsnPFKpVRuMJhIBYRXoIqkjUVITDnq8NnJ+Z3WZRQ7EVR4CnSVI6c7kcfBqK9mRBsE
LxGGQm5cbJvZ1tbmfDI5m9BPdQR1Oot/BOrkNwgKj/mNnFXcAOPhVeBBFTVgVkxlZ88VPz3AkZLi
crf/MTo2LaHw8zE9suDmoFrb3nhKnMAiry3NEtDDnyZm+yK3OE1KEVMf/8u3FkESq4xbRYVJbAAA
AAAAAA==

--Apple-Mail=_1F9B7C9B-F76A-4E2F-923C-67CD5FDE1A8F--

From sakimura@gmail.com  Wed Feb 20 12:32:30 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344AD21F869F for ; Wed, 20 Feb 2013 12:32:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.285
X-Spam-Level: 
X-Spam-Status: No, score=-3.285 tagged_above=-999 required=5 tests=[AWL=0.313,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+i3S5WnEQ-8 for ; Wed, 20 Feb 2013 12:32:28 -0800 (PST)
Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id B4C7121F869A for ; Wed, 20 Feb 2013 12:32:27 -0800 (PST)
Received: by mail-qa0-f46.google.com with SMTP id o13so2637766qaj.5 for ; Wed, 20 Feb 2013 12:32:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=I49D/CT8oqV3HCfQYXXjiAcx4hs245PzoZAUNieGa0o=; b=mA4aAu1Qgair0w4HTQcF/hcA51eDd48vsP2fr+AfLAEzH73w+gtVv/HH66ASvjFdzJ 2+jy4adA091ApaC9SfmMW6v9cSo1BlVw1nmD5W2oI6HBqAhHZhqEazeuo2VWMxCv+K5u 7QsXWY4JpBDJabnMeavBEkYrIlYC/2FplafduzDxQJLpP6nZTBG/peUcg9+JqIUNeVdP gmdi1GkZV0c4wwK5QiFYvRDvs7svjTfodk2B1KFYdKdkuAH7Fgarc7sButGHC35/pncQ 7nyhHT/QePqqw9wk1urd2VkJPYlU5H7FafJQtIYAT7nfhawBOzslEN4fxc0bTlsY8GOZ gIsg==
MIME-Version: 1.0
X-Received: by 10.224.177.204 with SMTP id bj12mr4537965qab.67.1361392347011;  Wed, 20 Feb 2013 12:32:27 -0800 (PST)
Received: by 10.49.106.161 with HTTP; Wed, 20 Feb 2013 12:32:26 -0800 (PST)
In-Reply-To: <133FFE3D-70FD-48C3-B95F-AB26DEC1F7E8@ve7jtb.com>
References: <20130215215423.23019.50224.idtracker@ietfa.amsl.com>   <4E1F6AAD24975D4BA5B16804296739436747A665@TK5EX14MBXC284.redmond.corp.microsoft.com>  <4E1F6AAD24975D4BA5B16804296739436747ADDB@TK5EX14MBXC284.redmond.corp.microsoft.com>  <512511B0.5090102@mitre.org> <4E1F6AAD24975D4BA5B16804296739436747B2BB@TK5EX14MBXC284.redmond.corp.microsoft.com> <51251DF0.8000804@mitre.org> <133FFE3D-70FD-48C3-B95F-AB26DEC1F7E8@ve7jtb.com>
Date: Wed, 20 Feb 2013 15:32:26 -0500
Message-ID: 
From: Nat Sakimura 
To: John Bradley 
Content-Type: multipart/alternative; boundary=20cf302ef9403e5a1004d62ddbdd
Cc: "" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2013 20:32:30 -0000

--20cf302ef9403e5a1004d62ddbdd
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hmmm.

*registered *is adjective, not verb.

registration client is noun + noun, and sounds funny to me.
When expanded, it becomes "an entry in a
register client",
which does not sound right.

Nat

2013/2/20 John Bradley 

> I am OK with that.
>
> On 2013-02-20, at 4:03 PM, Justin Richer  wrote:
>
>  On second thought, how about "registration_client_uri"? It's the URI for
> a particular client's registration. Use of the verb "registered" makes it
> sound like the result of an action that the client took, as if the client
> itself had registered the URI. That's obviously not the case, and we don'=
t
> want to convey that.
>
> So, new proposed name: "registration_client_uri"
>
> This has the nice side effect of being more parallel with
> "reigstration_access_token".
>
>  -- Justin
>
> On 02/20/2013 01:13 PM, Mike Jones wrote:
>
> SGTM****
>
>
>
> *From:* Justin Richer [mailto:jricher@mitre.org ]
> *Sent:* Wednesday, February 20, 2013 10:11 AM
> *To:* Nat Sakimura
> *Cc:* Mike Jones;  ; John Bradley
> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt****
>
> ** **
>
> I like "registered_client_uri", given all of the other discussions on thi=
s
> thread, because:
>
> URL/URI: It *is* a URL, and an https one at that, but if the IETF
> convention is to call it URI, then I'm fine with that.
>
> registered_client/registration_access: The former is a good description o=
f
> what's actually *at* the URL, which fits better with the RESTful entity
> model. I think Nat's criticisms about the original formation of the
> parameter name are spot on, though at the time we hadn't heard anything
> better.
>
>
> So I'd like to change it to "registered_client_uri" in the next draft.
>
>  -- Justin****
>
> On 02/20/2013 12:20 PM, Nat Sakimura wrote:****
>
> I have thought about that as well. The the reason I added "info" or
> "metadata" was that what was behind the URL is not the client itself. By
> "client registration", I suppose you mean "client entry in the register"
> (cf. *registration **n* 2.) . It is the "registered data/info/metadata"
> about the client.  ****
>
> ** **
>
> Nat****
>
> 2013/2/20 Mike Jones ****
>
> I could live with =93registered_client_url=94.  I think that adding
> =93_metadata=94 or =93_info=94 is incorrect, because what=92s being acces=
sed is the
> client=92 registration =96 not just metadata or info about the client=92s
> registration (although that information can be retrieved as one aspect of
> the operations on the client=92s registration).****
>
>  ****
>
>                                                             -- Mike****
>
>  ****
>
> *From:* Nat Sakimura [mailto:sakimura@gmail.com]
> *Sent:* Wednesday, February 20, 2013 8:53 AM
> *To:* Mike Jones
> *Cc:* ; Richer, Justin P.; John Bradley****
>
>
> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt****
>
>  ****
>
> I have read the whole thing and still --- ****
>
>  ****
>
> Your argument that it is the place for using "registration access token"
> thus should have a parallel name "registration access url" is very weak.
> There are several weakness. ****
>
>  ****
>
> First, "registration access token" actually is "registration" + "access
> token". Extracting "registration access" from "registration access token"
> is broken. ****
>
>  ****
>
> Secondly, access token is used to against any protected
> resource. Recommending to use the word "access" in naming protected
> resources is broken. Should we rename Userinfo endpoint to something like
> "Userinfo Access Endpoint"? I do not think so. ****
>
>  ****
>
> Thirdly, the term "Registration Access" does not seem to be meaningful. *=
*
> **
>
> When you say "access", I suppose you are using the noun version of it. **=
*
> *
>
> (If you are using the verb, then I am even more against as a URL should
> not contain a verb.) ****
>
>  ****
>
> According to the Webster, access (n.) is defined as: ****
>
>  ****
>
> *access **n.*****
>
>  ****
>
> *1*****
>
> *a* *:* onset  2****
>
> *b* *:* a fit of intense feeling *:* outburst
> ****
>
> *2*****
>
> *a* *:* permission, liberty, or ability to enter, approach, or pass to
> and from a place or to approach or communicate with a person or thing****
>
> *b* *:* freedom or ability to obtain or make use of something****
>
> *c* *:* a way or means of access****
>
> *d* *:* the act or an instance of accessing
> ****
>
> *3*****
>
> *:* an increase by addition ****
>
>  ****
>
> Replacing "access" with any of the definition above does not seem to work=
.
> ****
>
>  ****
>
> Remember, a URL is represents a "thing". ****
>
> The name of the endpoint should represent the "thing". ****
>
>  ****
>
> I am merginally OK with "client registration url" leveraging on the
> definition 2. below (again from Webster -- my OED subscription lapsed for
> the time being.) ****
>
>  ****
>
> *registration **n.*****
>
>  ****
>
> *1*****
>
> *:* the act of registering
> ****
>
> *2*****
>
> *:* an entry in a register
> ****
>
> *3*****
>
> *:* the number of individuals registered
>  *:* enrollment ***=
*
>
> *4*****
>
> *a* *:* the art or act of selecting and adjusting pipe organ stops****
>
> *b* *:* the combination of stops selected for performing a particular
> organ work****
>
> *5*****
>
> *:* a document certifying an act of registering****
>
>  ****
>
> However, since the most common use of "registration" is actually *1*above=
, it still is confusing. If you really want to emphasize the fact that
> it has been registered, then something like "registered client info uri" =
or
> "registered client metadata uri" would be better. ****
>
>  ****
>
> Nat****
>
>  ****
>
>  ****
>
> 2013/2/20 Mike Jones ****
>
> For what it=92s worth, the name =93registration_access_url=94 was chosen =
to be
> parallel to =93registration_access_token=94.   It=92s the place you use t=
he
> access token.  And it=92s where you access an existing registration.  I=
=92m
> against the name =93client_metadata_url=94 because it=92s not metadata yo=
u=92re
> accessing =96 it=92s a registration you=92re accessing.  For the same rea=
son, I
> don=92t think the name =93client_info_url=94 gives people the right idea,=
 because
> it doesn=92t say anything it being the registration that you=92re accessi=
ng.**
> **
>
>  ****
>
> If you really want us to change this, having read what=92s above, I could
> live with =93client_registration_url=94, but I don=92t think a change is =
actually
> necessary.  (But if we are going to change it, let=92s do it ASAP, before=
 the
> OpenID Connect Implementer=92s Drafts are published.)****
>
>  ****
>
>                                                             -- Mike****
>
>  ****
>
> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf
> Of *Nat Sakimura
> *Sent:* Wednesday, February 20, 2013 7:58 AM
> *To:* ; Richer, Justin P.; John Bradley****
>
>
> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt****
>
>  ****
>
> Thanks Justin.****
>
>
>
> Even if we go flat rather than doing JSON Structure, the "Client
> Registration Access Endpoint" is not a good representative name.
>
> What it represents is the client metadata/info.
> It is not representing "Client Registration Access". ****
>
> What does "Client Registration Access" mean? ****
>
> Does UPDATing "Cleint Registration Access" make sense?
>
> Something in the line of "Client Metadata Endpoint" and
> something like "client_metadata_url" or "client_info_url" is much better.
>
> Nat****
>
> 2013/2/15 Richer, Justin P. ****
>
> Everyone, there's a new draft of DynReg up on the tracker. This draft
> tries to codify the discussions so far from this week into something we c=
an
> all read. There are still plenty of open discussion points and items up f=
or
> debate. Please read through this latest draft and see what's changed and
> help assure that it properly captures the conversations. If you have any
> inputs for the marked [[ Editor's Note ]] sections, please send them to t=
he
> list by next Thursday to give me opportunity to get any necessary changes
> in by the cutoff date of Monday the 22nd.
>
> Thanks for all of your hard work everyone, I think this is *really* comin=
g
> along now.
>
>  -- Justin****
>
>
> On Feb 15, 2013, at 4:54 PM, internet-drafts@ietf.org wrote:
>
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Web Authorization Protocol Working
> Group of the IETF.
> >
> >       Title           : OAuth Dynamic Client Registration Protocol
> >       Author(s)       : Justin Richer
> >                          John Bradley
> >                          Michael B. Jones
> >                          Maciej Machulak
> >       Filename        : draft-ietf-oauth-dyn-reg-06.txt
> >       Pages           : 21
> >       Date            : 2013-02-15
> >
> > Abstract:
> >   This specification defines an endpoint and protocol for dynamic
> >   registration of OAuth Clients at an Authorization Server.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-06
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > 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****
>
>
>
> ****
>
>  ****
>
> --
> Nat Sakimura (=3Dnat)****
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en****
>
>
>
> ****
>
>  ****
>
> --
> Nat Sakimura (=3Dnat)****
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en****
>
>
>
> ****
>
> ** **
>
> --
> Nat Sakimura (=3Dnat) ****
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en****
>
> ** **
>
>
>
>

--=20
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--20cf302ef9403e5a1004d62ddbdd
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hmmm.=A0
registered is adjective, not verb.=A0
registration client is noun + noun, and sounds funny=
 to me.=A0When expanded, it becomes "an entr=
y in a=A0register=A0client", which does not sound right.=A0

Nat

2013/2=
/20 John Bradley <ve7jtb@ve7jtb.com>

I am OK with that.
On 2013-02-20, at 4:03 PM, Justin Richer <jricher@mitre.org> wrote:

 =20
   =20
 =20

    On second thought, how about "registration_client_uri"? It=
9;s the URI
    for a particular client's registration. Use of the verb "regis=
tered"
    makes it sound like the result of an action that the client took, as
    if the client itself had registered the URI. That's obviously not
    the case, and we don't want to convey that. 

    So, new proposed name: "registration_client_uri"

    This has the nice side effect of being more parallel with
    "reigstration_access_token". 

    =A0-- Justin

    On 02/20/2013 01:13 PM, Mike Jones
      wrote:

     =20
     =20
     =20
      SGTM=
=A0=

          F=
rom:
                Justin Richer [mailto:jricher@mitre.org]

                Sent: Wednesday, February 20, 2013 10:11 AM

                To: Nat Sakimura

                Cc: Mike Jones; <oauth@ietf.org>; John
                Bradley

                Subject: Re: [OAUTH-WG] I-D Action:
                draft-ietf-oauth-dyn-reg-06.txt

=A0
I like
          "registered_client_uri", given all of the other discuss=
ions on
          this thread, because:

          URL/URI: It *is* a URL, and an https one at that, but if the
          IETF convention is to call it URI, then I'm fine with that.

          registered_client/registration_access: The former is a good
          description of what's actually *at* the URL, which fits bette=
r
          with the RESTful entity model. I think Nat's criticisms about
          the original formation of the parameter name are spot on,
          though at the time we hadn't heard anything better.

          So I'd like to change it to "registered_client_uri"=
 in the
          next draft.

          =A0-- Justin
        On 02/20/2013 12:20 PM, Nat Sakimura
            wrote:

        I have thought about that as well. The
            the reason I added "info" or "metadata" was=
 that what was
            behind the URL is not the client itself. By "client
            registration", I suppose you mean "client entry in th=
e
            register" (cf.
            registration n 2.) . It is the "registered
            data/info/metadata" about the client.=A0

          =A0

          Nat=

            2013/2/20 Mike Jones <Michael.Jones@micros=
oft.com>

                I
                      could live with =93registered_client_url=94.=A0 I thi=
nk
                      that adding =93_metadata=94 or =93_info=94 is incorre=
ct,
                      because what=92s being accessed is the client=92
                      registration =96 not just metadata or info about the
                      client=92s registration (although that information
                      can be retrieved as one aspect of the operations
                      on the client=92s registration).=
=A0<=
/u>

=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0
                      -- Mike
=A0

From:
                      Nat Sakimura [mailto:sakimura@gmail.com]

                      Sent: Wednesday, February 20, 2013 8:53 AM

                      To: Mike Jones

                      Cc: <oauth@ietf.org>;
                      Richer, Justin P.; John Bradley<=
/p>

                        Subject: Re: [OAUTH-WG] I-D Action:
                        draft-ietf-oauth-dyn-reg-06.txt

                    =A0I
                        have read the whole thing and still ---=A0
                      =A0

                      Your
                          argument that it is the place for using
                          "registration access token" thus should=
 have a
                          parallel name "registration access url"=
 is
                          very weak. There are several weakness.=A0<=
u>

                      =A0

                      First,
                          "registration access token" actually is
                          "registration" + "access token&quo=
t;. Extracting
                          "registration access" from "regist=
ration
                          access token" is broken.=A0

                      =A0

                      Secondly,
                          access token is used to against any protected
                          resource.=A0Recommending=A0to use the word
                          "access" in naming protected resources =
is
                          broken. Should we rename Userinfo endpoint to
                          something like "Userinfo Access Endpoint&quo=
t;? I
                          do not think so.=A0

                      =A0

                      Thirdly,
                          the term "Registration Access" does not=
 seem
                          to be meaningful.=A0

                      When
                          you say "access", I suppose you are usi=
ng the
                          noun version of it.=A0

                        (If
                            you are using the verb, then I am even more
                            against as a URL should not contain a
                            verb.)=A0

                        =A0

                        According
                            to the Webster, access (n.) is defined as:=A0

                        =A0

                        access
                            n.

                        =A0

                            1

                            a=A0:=
=A0onset=A02
b=A0:=
=A0a
                                  fit of intense feeling=A0:=A0outburs=
t

                            2

                            a=A0:=
=A0permission,

                                  liberty, or ability to enter,
                                  approach, or pass to and from a place
                                  or to approach or communicate with a
                                  person or thing<=
p class=3D"MsoNormal" style=3D"line-height:15.0pt;background:white">=
b=A0:<=
/strong>=A0freedom
                                  or ability to obtain or make use of
                                  something
c=A0:=A0a
                                  way or means of access
=
d=A0:<=
/span>=A0the
                                  act or an instance of=A0accessing<=
/u>

                            3

                            :=A0an
                                  increase by addition=A0<a sudden=A0acc=
ess=A0of

                                  wealth>

                          =A0

                          Replacing
                              "access" with any of the definition=
 above
                              does not seem to work.=A0

                          =A0

                          Remember,
                              a URL is represents a "thing".=A0

                          The
                              name of the endpoint should represent the
                              "thing".=A0

                          =A0

                          I
                              am merginally OK with "client registrati=
on
                              url" leveraging on the definition 2. bel=
ow
                              (again from Webster -- my OED subscription
                              lapsed for the time being.)=A0<=
/p>

                          =A0

                          registration
                              n.

                          =A0

                              1

                              :=A0the
                                    act of=A0registering

                              2

                              :=A0an
                                    entry in a=A0register

                              3

                              :=A0the
                                    number of individuals=A0registered=A0:=A0=
enrollment

                              4

                              a=A0:=A0the
                                    art or act of selecting and
                                    adjusting pipe organ stops
b=A0=
:=A0the
                                    combination of stops selected for
                                    performing a particular organ work

                              5

                              :=A0a
                                    document certifying an act of
                                    registering

                          =A0

                          However,
                              since the most common use of
                              "registration" is actually
                              1 above, it still is confusing. If
                              you really want to emphasize the fact that
                              it has been registered, then something
                              like "registered client info uri" o=
r
                              "registered client metadata uri" wo=
uld be
                              better.=A0

                          =A0

                          Nat

                          =A0

=A0
                          2013/2/20
                              Mike Jones <Michael.Jones@microsoft.com>

                              For
                                    what it=92s worth, the name
                                    =93registration_access_url=94 was chose=
n
                                    to be parallel to
                                    =93registration_access_token=94.=A0=A0 =
It=92s
                                    the place you use the access token.=A0
                                    And it=92s where you access an
                                    existing registration.=A0 I=92m against
                                    the name =93client_metadata_url=94
                                    because it=92s not metadata you=92re
                                    accessing =96 it=92s a registration
                                    you=92re accessing.=A0 For the same
                                    reason, I don=92t think the name
                                    =93client_info_url=94 gives people the
                                    right idea, because it doesn=92t say
                                    anything it being the registration
                                    that you=92re accessing.<=
u>
=A0

If
                                    you really want us to change this,
                                    having read what=92s above, I could
                                    live with =93client_registration_url=94=
,
                                    but I don=92t think a change is
                                    actually necessary.=A0 (But if we are
                                    going to change it, let=92s do it
                                    ASAP, before the OpenID Connect
                                    Implementer=92s Drafts are published.)<=
/span>
=
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0
                                    -- Mike
=A0
From:
                                    oauth-bounces@ietf.org
                                    [mailto:oauth-bounces@ietf.org]
                                    On Behalf Of Nat Sakimura

                                    Sent: Wednesday, February 20,
                                    2013 7:58 AM

                                    To: <oauth@ietf.org>;
                                    Richer, Justin P.; John Bradley<=
u>

                                    Subject: Re: [OAUTH-WG] I-D
                                    Action:
                                    draft-ietf-oauth-dyn-reg-06.txt<=
u>

=A0<=
/u>
Tha=
nks
                                    Justin.

                                        Ev=
en
                                          if we go flat rather than
                                          doing JSON Structure, the
                                          "Client

                                        Re=
gistration
                                          Access Endpoint" is not a go=
od
                                          representative name.

                                        Wh=
at
                                          it represents is the client
                                          metadata/info.

                                        It
                                          is not representing "Client
                                          Registration Access".=A0

                                    What
                                        does "Client Registration
                                        Access" mean?=A0=

                                    Does
                                          UPDATing "Cleint Registratio=
n
                                          Access" make sense?

                                          =
Something
                                            in the line of "Client
                                            Metadata Endpoint" and

                                          =
something
                                            like "client_metadata_url&=
quot;
                                            or=A0"client_info_url"=
; is much
                                            better.

                                          =
Nat
                                      2013/2/15
                                          Richer, Justin P. <jricher@mitre.org>
Everyone,
                                          there's a new draft of DynReg
                                          up on the tracker. This draft
                                          tries to codify the
                                          discussions so far from this
                                          week into something we can all
                                          read. There are still plenty
                                          of open discussion points and
                                          items up for debate. Please
                                          read through this latest draft
                                          and see what's changed and
                                          help assure that it properly
                                          captures the conversations. If
                                          you have any inputs for the
                                          marked [[ Editor's Note ]]
                                          sections, please send them to
                                          the list by next Thursday to
                                          give me opportunity to get any
                                          necessary changes in by the
                                          cutoff date of Monday the
                                          22nd.

                                          Thanks for all of your hard
                                          work everyone, I think this is
                                          *really* coming along now.

                                            =A0-- Justin

                                              On Feb 15, 2013, at 4:54
                                              PM, 
                                                internet-drafts@ietf.org
                                              wrote:

                                              >

                                              > A New Internet-Draft
                                              is available from the
                                              on-line Internet-Drafts
                                              directories.

                                              > This draft is a work
                                              item of the Web
                                              Authorization Protocol
                                              Working Group of the IETF.
                                              >

                                              > =A0 =A0 =A0 Title =A0 =
=A0 =A0 =A0 =A0
                                              : OAuth Dynamic Client
                                              Registration Protocol

                                              > =A0 =A0 =A0 Author(s) =
=A0 =A0 =A0
                                              : Justin Richer

                                              > =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0
                                              =A0 =A0John Bradley

                                              > =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0
                                              =A0 =A0Michael B. Jones

                                              > =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0
                                              =A0 =A0Maciej Machulak

                                              > =A0 =A0 =A0 Filename =A0=
 =A0 =A0
                                              =A0:
                                              draft-ietf-oauth-dyn-reg-06.t=
xt

                                              > =A0 =A0 =A0 Pages =A0 =
=A0 =A0 =A0 =A0
                                              : 21

                                              > =A0 =A0 =A0 Date =A0 =A0=
 =A0 =A0 =A0
                                              =A0: 2013-02-15

                                              >

                                              > Abstract:

                                              > =A0 This specification
                                              defines an endpoint and
                                              protocol for dynamic

                                              > =A0 registration of
                                              OAuth Clients at an
                                              Authorization Server.

                                              >

                                              >

                                              > The IETF datatracker
                                              status page for this draft
                                              is:

                                              > 
https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg

                                              >

                                              > There's also a
                                              htmlized version available
                                              at:

                                              > 
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06

                                              >

                                              > A diff from the
                                              previous version is
                                              available at:

                                              > 
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-06

                                              >

                                              >

                                              > Internet-Drafts are
                                              also available by
                                              anonymous FTP at:

                                              > ftp://ftp.ietf.org/internet-draft=
s/

                                              >

                                              >
                                              _____________________________=
__________________

                                              > OAuth mailing list

                                              > OAuth@ietf.org

                                              > https://www.ietf.org/mail=
man/listinfo/oauth

_______________________________________________

                                              OAuth mailing list

                                              OAuth@ietf.org

                                              https://www.ietf.org/mailman/l=
istinfo/oauth

                                      =A0

--

                                        Nat Sakimura (=3Dnat)=

                                      Chairman,
                                          OpenID Foundation

                                          http://nat.sakimura.org/

                                          @_nat_en

                          =A0

--

                            Nat Sakimura (=3Dnat)
                          Chairman,
                              OpenID Foundation

                              http://nat.sakimura.org/

                              @_nat_en

            =A0

-- 

              Nat Sakimura (=3Dnat) 
            Chairman, OpenID Foundation

                http=
://nat.sakimura.org/

                @_nat_en

=A0

-- 
Nat Sakimura (=3Dnat)Chairman, OpenID F=
oundation
http://=
nat.sakimura.org/

@_nat_en

--20cf302ef9403e5a1004d62ddbdd--

From Michael.Jones@microsoft.com  Wed Feb 20 12:37:53 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF6021E8039 for ; Wed, 20 Feb 2013 12:37:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.585
X-Spam-Level: 
X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.013,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hr1qMLYlKdFx for ; Wed, 20 Feb 2013 12:37:48 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.30]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCC821F86A5 for ; Wed, 20 Feb 2013 12:37:47 -0800 (PST)
Received: from BY2FFO11FD012.protection.gbl (10.1.15.200) by BY2FFO11HUB029.protection.gbl (10.1.14.114) with Microsoft SMTP Server (TLS) id 15.0.620.12; Wed, 20 Feb 2013 20:37:37 +0000
Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD012.mail.protection.outlook.com (10.1.14.130) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Wed, 20 Feb 2013 20:37:37 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.96]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Wed, 20 Feb 2013 20:37:10 +0000
From: Mike Jones 
To: Nat Sakimura , John Bradley 
Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
Thread-Index: AQHOC8cMkbohP5vU0EO7eTLi/U/hMJh7eCuAgAd2gACAAAA6MIAADyiAgAAAlPCAAAbqAIAADigAgAAAsbCAAA3pAIAAD/cAgAAI+ACAAAB+cA==
Date: Wed, 20 Feb 2013 20:37:09 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436747BA8E@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <20130215215423.23019.50224.idtracker@ietfa.amsl.com>   <4E1F6AAD24975D4BA5B16804296739436747A665@TK5EX14MBXC284.redmond.corp.microsoft.com>  <4E1F6AAD24975D4BA5B16804296739436747ADDB@TK5EX14MBXC284.redmond.corp.microsoft.com>  <512511B0.5090102@mitre.org> <4E1F6AAD24975D4BA5B16804296739436747B2BB@TK5EX14MBXC284.redmond.corp.microsoft.com> <51251DF0.8000804@mitre.org> <133FFE3D-70FD-48C3-B95F-AB26DEC1F7E8@ve7jtb.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.75]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436747BA8ETK5EX14MBXC284r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377424002)(479174001)(377454001)(51704002)(51444002)(69224001)(199002)(189002)(60454001)(24454001)(65554002)(66066001)(15202345001)(5343635001)(512954001)(76482001)(53806001)(65816001)(80022001)(16406001)(51856001)(46102001)(55846006)(16297215001)(47976001)(50986001)(4396001)(16236675001)(49866001)(47736001)(56816002)(54316002)(74502001)(5343655001)(47446002)(77982001)(54356001)(63696002)(74662001)(79102001)(44976002)(59766001)(56776001)(31966008)(20776003)(33656001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB029; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07630F72AD
Cc: "" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2013 20:37:54 -0000

--_000_4E1F6AAD24975D4BA5B16804296739436747BA8ETK5EX14MBXC284r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I believe the semantic intent of "registration_client_uri" is "client uri t=
o be used for registration operations", just like the semantic intent of "r=
egistration_access_token" is "access token to be used for registration oper=
ations".  Both perfectly meaningful constructions.

From: Nat Sakimura [mailto:sakimura@gmail.com]
Sent: Wednesday, February 20, 2013 12:32 PM
To: John Bradley
Cc: Justin Richer; Mike Jones; 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

Hmmm.

registered is adjective, not verb.

registration client is noun + noun, and sounds funny to me.
When expanded, it becomes "an entry in a register client", which does not sound right.

Nat

2013/2/20 John Bradley >
I am OK with that.

On 2013-02-20, at 4:03 PM, Justin Richer > wrote:

On second thought, how about "registration_client_uri"? It's the URI for a =
particular client's registration. Use of the verb "registered" makes it sou=
nd like the result of an action that the client took, as if the client itse=
lf had registered the URI. That's obviously not the case, and we don't want=
 to convey that.

So, new proposed name: "registration_client_uri"

This has the nice side effect of being more parallel with "reigstration_acc=
ess_token".

 -- Justin
On 02/20/2013 01:13 PM, Mike Jones wrote:
SGTM

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Wednesday, February 20, 2013 10:11 AM
To: Nat Sakimura
Cc: Mike Jones; ; John Bradley
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

I like "registered_client_uri", given all of the other discussions on this =
thread, because:

URL/URI: It *is* a URL, and an https one at that, but if the IETF conventio=
n is to call it URI, then I'm fine with that.

registered_client/registration_access: The former is a good description of =
what's actually *at* the URL, which fits better with the RESTful entity mod=
el. I think Nat's criticisms about the original formation of the parameter =
name are spot on, though at the time we hadn't heard anything better.

So I'd like to change it to "registered_client_uri" in the next draft.

 -- Justin
On 02/20/2013 12:20 PM, Nat Sakimura wrote:
I have thought about that as well. The the reason I added "info" or "metada=
ta" was that what was behind the URL is not the client itself. By "client r=
egistration", I suppose you mean "client entry in the register" (cf. regist=
ration n 2.) . It is the "registered data/info/metadata" about the client.

Nat
2013/2/20 Mike Jones >
I could live with "registered_client_url".  I think that adding "_metadata"=
 or "_info" is incorrect, because what's being accessed is the client' regi=
stration - not just metadata or info about the client's registration (altho=
ugh that information can be retrieved as one aspect of the operations on th=
e client's registration).

                                                            -- Mike

From: Nat Sakimura [mailto:sakimura@gmail.com]
Sent: Wednesday, February 20, 2013 8:53 AM
To: Mike Jones
Cc: >; Richer, Justin P.; John Bradle=
y

Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

I have read the whole thing and still ---

Your argument that it is the place for using "registration access token" th=
us should have a parallel name "registration access url" is very weak. Ther=
e are several weakness.

First, "registration access token" actually is "registration" + "access tok=
en". Extracting "registration access" from "registration access token" is b=
roken.

Secondly, access token is used to against any protected resource. Recommend=
ing to use the word "access" in naming protected resources is broken. Shoul=
d we rename Userinfo endpoint to something like "Userinfo Access Endpoint"?=
 I do not think so.

Thirdly, the term "Registration Access" does not seem to be meaningful.
When you say "access", I suppose you are using the noun version of it.
(If you are using the verb, then I am even more against as a URL should not=
 contain a verb.)

According to the Webster, access (n.) is defined as:

access n.

1
a : onset 2
b : a fit of intense feeling : outburst
2
a : permission, liberty, or ability to enter, approach, or pass to and from=
 a place or to approach or communicate with a person or thing
b : freedom or ability to obtain or make use of something
c : a way or means of access
d : the act or an instance of accessing
3
: an increase by addition 

Replacing "access" with any of the definition above does not seem to work.

Remember, a URL is represents a "thing".
The name of the endpoint should represent the "thing".

I am merginally OK with "client registration url" leveraging on the definit=
ion 2. below (again from Webster -- my OED subscription lapsed for the time=
 being.)

registration n.

1
: the act of registering
2
: an entry in a register
3
: the number of individuals registered : enrollment
4
a : the art or act of selecting and adjusting pipe organ stops
b : the combination of stops selected for performing a particular organ wor=
k
5
: a document certifying an act of registering

However, since the most common use of "registration" is actually 1 above, i=
t still is confusing. If you really want to emphasize the fact that it has =
been registered, then something like "registered client info uri" or "regis=
tered client metadata uri" would be better.

Nat

2013/2/20 Mike Jones >
For what it's worth, the name "registration_access_url" was chosen to be pa=
rallel to "registration_access_token".   It's the place you use the access =
token.  And it's where you access an existing registration.  I'm against th=
e name "client_metadata_url" because it's not metadata you're accessing - i=
t's a registration you're accessing.  For the same reason, I don't think th=
e name "client_info_url" gives people the right idea, because it doesn't sa=
y anything it being the registration that you're accessing.

If you really want us to change this, having read what's above, I could liv=
e with "client_registration_url", but I don't think a change is actually ne=
cessary.  (But if we are going to change it, let's do it ASAP, before the O=
penID Connect Implementer's Drafts are published.)

                                                            -- Mike

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Nat Sakimura
Sent: Wednesday, February 20, 2013 7:58 AM
To: >; Richer, Justin P.; John Bradle=
y

Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

Thanks Justin.

Even if we go flat rather than doing JSON Structure, the "Client
Registration Access Endpoint" is not a good representative name.

What it represents is the client metadata/info.
It is not representing "Client Registration Access".
What does "Client Registration Access" mean?
Does UPDATing "Cleint Registration Access" make sense?

Something in the line of "Client Metadata Endpoint" and
something like "client_metadata_url" or "client_info_url" is much better.

Nat
2013/2/15 Richer, Justin P. >
Everyone, there's a new draft of DynReg up on the tracker. This draft tries=
 to codify the discussions so far from this week into something we can all =
read. There are still plenty of open discussion points and items up for deb=
ate. Please read through this latest draft and see what's changed and help =
assure that it properly captures the conversations. If you have any inputs =
for the marked [[ Editor's Note ]] sections, please send them to the list b=
y next Thursday to give me opportunity to get any necessary changes in by t=
he cutoff date of Monday the 22nd.

Thanks for all of your hard work everyone, I think this is *really* coming =
along now.

 -- Justin

On Feb 15, 2013, at 4:54 PM, internet-drafts@ietf.org wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
> This draft is a work item of the Web Authorization Protocol Working Group=
 of the IETF.
>
>       Title           : OAuth Dynamic Client Registration Protocol
>       Author(s)       : Justin Richer
>                          John Bradley
>                          Michael B. Jones
>                          Maciej Machulak
>       Filename        : draft-ietf-oauth-dyn-reg-06.txt
>       Pages           : 21
>       Date            : 2013-02-15
>
> Abstract:
>   This specification defines an endpoint and protocol for dynamic
>   registration of OAuth Clients at an Authorization Server.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-06
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> 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

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--_000_4E1F6AAD24975D4BA5B16804296739436747BA8ETK5EX14MBXC284r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I believe the semantic in=
tent of “registration_client_uri” is “client uri t=
o be used for
registration operations”, just like the semantic intent of =
220;registration_access_token” is “access token to be us=
ed for
registration operations”.  Both perfectly meaningful cons=
tructions.
 <=
/p>
 <=
/p>
From: Nat Saki=
mura [mailto:sakimura@gmail.com]

Sent: Wednesday, February 20, 2013 12:32 PM

To: John Bradley

Cc: Justin Richer; Mike Jones; <oauth@ietf.org>

Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt<=
o:p>

Hmmm. 

registered is adjective, not verb. =

registration client is noun + noun, and sounds f=
unny to me. 

When expanded, it becomes "an entry in a register client",
 which does not sound right. 

Nat

2013/2/20 John Bradley <ve7jtb@ve7jtb.com>

I am OK with that.

On 2013-02-20, at 4:03 PM, Justin Richer <jricher@mitre.org> w=
rote:

On second thought, ho=
w about "registration_client_uri"? It's the URI for a particular =
client's registration. Use of the verb "registered" makes it soun=
d like the result of an action that the client took, as
 if the client itself had registered the URI. That's obviously not the case=
, and we don't want to convey that.

So, new proposed name: "registration_client_uri"

This has the nice side effect of being more parallel with "reigstratio=
n_access_token".

 -- Justin

On 02/20/2013 01:13 PM, Mike Jones wrote:=

SGTM

From: Justin Richer [mailto:jricher@mitre.org]

Sent: Wednesday, February 20, 2013 10:11 AM

To: Nat Sakimura

Cc: Mike Jones; =
<oauth@ietf.org>; John Bradley

Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt<=
/span>

I like "registered_client_uri", given all of the other discuss=
ions on this thread, because:

URL/URI: It *is* a URL, and an https one at that, but if the IETF conventio=
n is to call it URI, then I'm fine with that.

registered_client/registration_access: The former is a good description of =
what's actually *at* the URL, which fits better with the RESTful entity mod=
el. I think Nat's criticisms about the original formation of the parameter =
name are spot on, though at the
 time we hadn't heard anything better.

So I'd like to change it to "registered_client_uri" in the next d=
raft.

 -- Justin

On 02/20/2013 12:20 PM, Nat Sakimura wrote:

I have thought about that as well. The the reason I added "in=
fo" or "metadata" was that what was behind the URL is not th=
e client itself. By "client registration", I suppose you
 mean "client entry in the register" (cf. registration =
n 2.) . It is the "registered data/info/metadata" about the c=
lient. 

Nat

2013/2/20 Mike Jones <Michael.Jones@microsoft.com>

I could live with “registered_cli=
ent_url”.  I think that adding “_metadata” or “=
;_info” is incorrect,
 because what’s being accessed is the client’ registration R=
11; not just metadata or info about the client’s registration (althou=
gh that information can be retrieved as one aspect of the operations on the=
 client’s registration).

      &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;   -- Mike

From: Nat Sakimura [mailto:<=
a href=3D"mailto:sakimura@gmail.com" target=3D"_blank">sakimura@gmail.com]

Sent: Wednesday, February 20, 2013 8:53 AM

To: Mike Jones

Cc: <oauth@ie=
tf.org>; Richer, Justin P.; John Bradley

Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt<=
o:p>

I have read the whole thing and still --- 

Your argument that it is the place for using "registration ac=
cess token" thus should have a parallel name "registration access=
 url" is very weak. There are several weakness. 

First, "registration access token" actually is "reg=
istration" + "access token". Extracting "registrati=
on access" from "registration access token" is broken. =

Secondly, access token is used to against any protected resource.&=
nbsp;Recommending to use the word "access" in naming protect=
ed resources is broken. Should we rename Userinfo endpoint
 to something like "Userinfo Access Endpoint"? I do not think so.=

Thirdly, the term "Registration Access" does not seem to=
 be meaningful. 

When you say "access", I suppose you are using the noun =
version of it. 

(If you are using the verb, then I am even more against as a URL s=
hould not contain a verb.) 

According to the Webster, access (n.) is defined as: 

access
n.

1

a : onset 2

b : a fit of
 intense feeling : outburst

2

a : permission,
 liberty, or ability to enter, approach, or pass to and from a place or to =
approach or communicate with a person or thing

b : freedom or
 ability to obtain or make use of something

c : a way or
 means of access

d : the act or
 an instance of =
accessing

3

: an increase by addit=
ion <a sudden access of
 wealth>

Replacing "access" with any of the definition above does=
 not seem to work. 

Remember, a URL is represents a "thing". 

The name of the endpoint should represent the "thing".&n=
bsp;

I am merginally OK with "client registration url" levera=
ging on the definition 2. below (again from Webster -- my OED subscription =
lapsed for the time being.) 

registration
n.

1

: the act of registering<=
/span>

2

: an entry in a <=
a href=3D"http://www.merriam-webster.com/dictionary/register" target=3D"_bl=
ank">register

3

: the number of indivi=
duals registere=
d : enrollment

4

a : the art or
 act of selecting and adjusting pipe organ stops

b : the combination
 of stops selected for performing a particular organ work=

5

: a document certifyin=
g an act of registering

However, since the most common use of "registration" is =
actually
1 above, it still is confusing. If you really want to emphasize the =
fact that it has been registered, then something like "registered clie=
nt info uri" or "registered client metadata uri" would be be=
tter. 

Nat

2013/2/20 Mike Jones <Michael.Jones@microsoft.com>

For what it’s worth, the name =
220;registration_access_url” was chosen to be parallel to “regi=
stration_access_token”.  
 It’s the place you use the access token.  And it’s where =
you access an existing registration.  I’m against the name ̶=
0;client_metadata_url” because it’s not metadata you’re a=
ccessing – it’s a registration you’re accessing.  Fo=
r the same reason, I don’t think
 the name “client_info_url” gives people the right idea, becaus=
e it doesn’t say anything it being the registration that you’re=
 accessing.

If you really want us to change this, h=
aving read what’s above, I could live with “client_registration=
_url”,
 but I don’t think a change is actually necessary.  (But if we a=
re going to change it, let’s do it ASAP, before the OpenID Connect Im=
plementer’s Drafts are published.)

      &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;   -- Mike

From:
oauth-bounces@i=
etf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Nat Sakimura

Sent: Wednesday, February 20, 2013 7:58 AM

To: <oauth@ie=
tf.org>; Richer, Justin P.; John Bradley

Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt<=
o:p>

Thanks Justin.

Even if we go flat rather than doing JSON =
Structure, the "Client

Registration Access Endpoint" is not =
a good representative name.

What it represents is the client metadata/=
info.

It is not representing "Client Regist=
ration Access". 

What does "Client Registration Access" mean? <=
/o:p>

Does UPDATing "Cleint Reg=
istration Access" make sense?

Something in the line of "Client Meta=
data Endpoint" and

something like "client_metadata_url&q=
uot; or "client_info_url" is much better.

Nat

2013/2/15 Richer, Justin P. <jricher@mitre.org>
Everyone, there's a new draft of DynReg up on the tracker. This dr=
aft tries to codify the discussions so far from this week into something we=
 can all read. There are still plenty
 of open discussion points and items up for debate. Please read through thi=
s latest draft and see what's changed and help assure that it properly capt=
ures the conversations. If you have any inputs for the marked [[ Editor's N=
ote ]] sections, please send them
 to the list by next Thursday to give me opportunity to get any necessary c=
hanges in by the cutoff date of Monday the 22nd.

Thanks for all of your hard work everyone, I think this is *really* coming =
along now.

 -- Justin

On Feb 15, 2013, at 4:54 PM, 
internet-drafts@ietf.org wrote:

>

> A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.

> This draft is a work item of the Web Authorization Protocol Working Gr=
oup of the IETF.

>

>       Title           : OAuth =
Dynamic Client Registration Protocol

>       Author(s)       : Justin Richer
>                     =
     John Bradley

>                     =
     Michael B. Jones

>                     =
     Maciej Machulak

>       Filename        : draft-ietf-=
oauth-dyn-reg-06.txt

>       Pages           : 21

>       Date            : 2=
013-02-15

>

> Abstract:

>   This specification defines an endpoint and protocol for dynamic=

>   registration of OAuth Clients at an Authorization Server.

>

>

> The IETF datatracker status page for this draft is:

> 
https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg

>

> There's also a htmlized version available at:

> 
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06

>

> A diff from the previous version is available at:

> 
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-06

>

>

> Internet-Drafts are also available by anonymous FTP at:

> ftp:=
//ftp.ietf.org/internet-drafts/

>

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=

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

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

--

Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation

http://nat.sakimura.=
org/

@_nat_en

--

Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation

http://nat.sakimura.=
org/

@_nat_en

--

Nat Sakimura (=3Dnat) 

Chairman, OpenID Foundation

http://nat.sakimura.=
org/

@_nat_en

-- 

Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation

http://nat.sakimura.=
org/

@_nat_en

--_000_4E1F6AAD24975D4BA5B16804296739436747BA8ETK5EX14MBXC284r_--

From donald.coffin@reminetworks.com  Wed Feb 20 13:08:36 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14C621F866F for ; Wed, 20 Feb 2013 13:08:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.912
X-Spam-Level: 
X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[AWL=0.352,  BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I74elJ9Ljwq0 for ; Wed, 20 Feb 2013 13:08:35 -0800 (PST)
Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 04B1321F84C6 for ; Wed, 20 Feb 2013 13:08:34 -0800 (PST)
Received: (qmail 16388 invoked by uid 0); 20 Feb 2013 21:08:12 -0000
Received: from unknown (HELO host125.hostmonster.com) (74.220.207.125) by oproxy13.unifiedlayer.com with SMTP; 20 Feb 2013 21:08:12 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default;  h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=PKeqb1YftSFhvZ/uNHWymFUEUdDaoc7M22ar+EkUhNI=;  b=Iqan69hjwIr0IRm4iHFFrJNnis15na0eAYdNJ1rv4HScyFyGx8D6g5aQtvTk113W9CCp93Iu0GLv84+06dSAQX1E/2QeVcz+b93fmbsYnNzLT3dCBTF2lzU89ATqxNhs;
Received: from [68.4.207.246] (port=2957 helo=HPPavilionElite) by host125.hostmonster.com with esmtpa (Exim 4.80) (envelope-from ) id 1U8Gtg-0003rc-7Q; Wed, 20 Feb 2013 14:08:12 -0700
From: "Donald F Coffin" 
To: "'Mike Jones'" , "'Justin Richer'" 
References: <00ac01ce0fa0$a1325f20$e3971d60$@reminetworks.com> <4E1F6AAD24975D4BA5B16804296739436747B862@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436747B862@TK5EX14MBXC284.redmond.corp.microsoft.com>
Date: Wed, 20 Feb 2013 13:06:54 -0800
Message-ID: <00ee01ce0fae$36604cd0$a320e670$@reminetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EF_01CE0F6B.283F56C0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQE1OXACFOQN9aNJEkIF7iLiv9DvKwKF7FRdmaC6C/A=
Content-Language: en-us
X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.4.207.246 authed with donald.coffin@reminetworks.com}
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Additional Oauth Dynamic Client Registration Protocol	Information
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2013 21:08:36 -0000

This is a multipart message in MIME format.

------=_NextPart_000_00EF_01CE0F6B.283F56C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Mike,

Thanks for the information.

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

Phone:      (949) 636-8571

Email:        
donald.coffin@reminetworks.com

From: Mike Jones [mailto:Michael.Jones@microsoft.com] 
Sent: Wednesday, February 20, 2013 11:38 AM
To: Donald F Coffin; Justin Richer
Cc: oauth@ietf.org
Subject: RE: [OAUTH-WG] Additional Oauth Dynamic Client Registration
Protocol Information

Hi Don,

Discovery is a process that happens before Registration, and that's the
point at which you would return the AS (and registration!) endpoints to the
Client.  The OAuth WG considered doing its own discovery work but ultimately
decided to have that happen in the Apps Area WG instead, which is close to
completing the WebFinger discovery specification.

If you want to see how OpenID Connect is performing discovery using
WebFinger, including discovery of the AS endpoint, have a look at
http://openid.net/specs/openid-connect-discovery-1_0.html.

                                                                Best wishes,

                                                                -- Mike

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of
Donald F Coffin
Sent: Wednesday, February 20, 2013 11:30 AM
To: Justin Richer
Cc: oauth@ietf.org
Subject: [OAUTH-WG] Additional Oauth Dynamic Client Registration Protocol
Information

Justin,

I understand the current Client Registration request and response
information is based on the OPENID model for consistency, but has there been
any thought or discussion of adding the AS OAuth 2.0 endpoint URIs as part
of the registration response?  I believe the addition of the endpoint URIs
would make the dynamic client registration process truly a dynamic feature
of OAuth 2.0.

If the ability to discover the AS OAuth 2.0 endpoint URIs is being covered
by another IETF draft, I'd appreciate learning which current draft is being
worked on to achieve that result.

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

Phone:      (949) 636-8571

Email:       donald.coffin@reminetworks.com

------=_NextPart_000_00EF_01CE0F6B.283F56C0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Mike,=

Thanks for the =
information.

Best regards,
Don
Donald F. Coffin
Founder/CTO

REMI =
Networks
22751 El Prado Suite =
6216
Rancho Santa Margarita, CA  =
92688-3836

Phone:      (949) =
636-8571
Email:       donald.coffin@reminetworks.com=

From:=
 =
Mike Jones [mailto:Michael.Jones@microsoft.com] 
Sent: =
Wednesday, February 20, 2013 11:38 AM
To: Donald F Coffin; =
Justin Richer
Cc: oauth@ietf.org
Subject: RE: =
[OAUTH-WG] Additional Oauth Dynamic Client Registration Protocol =
Information

Hi Don,

Discovery is a process =
that happens before Registration, and that’s the point at which =
you would return the AS (and registration!) endpoints to the =
Client.  The OAuth WG considered doing its own discovery work but =
ultimately decided to have that happen in the Apps Area WG instead, =
which is close to completing the WebFinger discovery =
specification.

If you want to see how =
OpenID Connect is performing discovery using WebFinger, including =
discovery of the AS endpoint, have a look at http:/=
/openid.net/specs/openid-connect-discovery-1_0.html.

        &=
nbsp;           &n=
bsp;           &nb=
sp;           &nbs=
p;            =
;       Best =
wishes,
        &=
nbsp;           &n=
bsp;           &nb=
sp;           &nbs=
p;            =
;       -- Mike

From:=
 =
oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=
 On Behalf Of Donald F Coffin
Sent: Wednesday, February =
20, 2013 11:30 AM
To: Justin Richer
Cc: oauth@ietf.org
Subject: =
[OAUTH-WG] Additional Oauth Dynamic Client Registration Protocol =
Information

Justin,

I understand =
the current Client Registration request and response information is =
based on the OPENID model for consistency, but has there been any =
thought or discussion of adding the AS OAuth 2.0 endpoint URIs as part =
of the registration response?  I believe the addition of the =
endpoint URIs would make the dynamic client registration process truly a =
dynamic feature of OAuth 2.0.

If the ability =
to discover the AS OAuth 2.0 endpoint URIs is being covered by another =
IETF draft, I’d appreciate learning which current draft is being =
worked on to achieve that result.

Best =
regards,
Don
Donald F. Coffin
Founder/CTO

REMI =
Networks
22751 El Prado Suite =
6216
Rancho Santa Margarita, CA  =
92688-3836

Phone:      (949) =
636-8571
Email:       donald.coffin@reminetworks=
.com

------=_NextPart_000_00EF_01CE0F6B.283F56C0--

From donald.coffin@reminetworks.com  Wed Feb 20 13:09:45 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1B521E8048 for ; Wed, 20 Feb 2013 13:09:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level: 
X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=0.489,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pv4H0myM+yt for ; Wed, 20 Feb 2013 13:09:43 -0800 (PST)
Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by ietfa.amsl.com (Postfix) with SMTP id ACCED21E803F for ; Wed, 20 Feb 2013 13:09:19 -0800 (PST)
Received: (qmail 5858 invoked by uid 0); 20 Feb 2013 21:08:58 -0000
Received: from unknown (HELO host125.hostmonster.com) (74.220.207.125) by oproxy1.bluehost.com with SMTP; 20 Feb 2013 21:08:58 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default;  h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=16W9eeA8jUEbxe6tReztP1w0og4LtZX+pusHD/apwKk=;  b=wuxZAWzKF3olbr0jZoT/F4Qnpuu+NfrscF5Q0TkkhdPW5TIHmb3X1h2+G2HfUAhyox5KzGo9ZJH12qazVRPxxtpuc9sqA/MX6VUkZplhXjZPFxL14HajCOhzaLfwhqFo;
Received: from [68.4.207.246] (port=2970 helo=HPPavilionElite) by host125.hostmonster.com with esmtpa (Exim 4.80) (envelope-from ) id 1U8GuP-0004Mf-Tx; Wed, 20 Feb 2013 14:08:58 -0700
From: "Donald F Coffin" 
To: "'Justin Richer'" , "'Mike Jones'" 
References: <00ac01ce0fa0$a1325f20$e3971d60$@reminetworks.com> <4E1F6AAD24975D4BA5B16804296739436747B862@TK5EX14MBXC284.redmond.corp.microsoft.com> <512528EE.8000303@mitre.org>
In-Reply-To: <512528EE.8000303@mitre.org>
Date: Wed, 20 Feb 2013 13:07:40 -0800
Message-ID: <00f301ce0fae$519ec990$f4dc5cb0$@reminetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F4_01CE0F6B.437DD380"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQE1OXACFOQN9aNJEkIF7iLiv9DvKwKF7FRdAkl7UGmZjm5zMA==
Content-Language: en-us
X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.4.207.246 authed with donald.coffin@reminetworks.com}
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Additional Oauth Dynamic Client Registration Protocol Information
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2013 21:09:45 -0000

This is a multipart message in MIME format.

------=_NextPart_000_00F4_01CE0F6B.437DD380
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Justin,

Thanks for the information.

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

Phone:      (949) 636-8571

Email:        
donald.coffin@reminetworks.com

From: Justin Richer [mailto:jricher@mitre.org] 
Sent: Wednesday, February 20, 2013 11:50 AM
To: Mike Jones
Cc: Donald F Coffin; oauth@ietf.org
Subject: Re: [OAUTH-WG] Additional Oauth Dynamic Client Registration
Protocol Information

Additionally, there is an individual draft that registers LRDD Link Types
for discovery using LRDD and HostMeta:

http://tools.ietf.org/html/draft-wmills-oauth-lrdd-07

 -- Justin

On 02/20/2013 02:37 PM, Mike Jones wrote:

Hi Don,

Discovery is a process that happens before Registration, and that's the
point at which you would return the AS (and registration!) endpoints to the
Client.  The OAuth WG considered doing its own discovery work but ultimately
decided to have that happen in the Apps Area WG instead, which is close to
completing the WebFinger discovery specification.

If you want to see how OpenID Connect is performing discovery using
WebFinger, including discovery of the AS endpoint, have a look at
http://openid.net/specs/openid-connect-discovery-1_0.html.

                                                                Best wishes,

                                                                -- Mike

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of
Donald F Coffin
Sent: Wednesday, February 20, 2013 11:30 AM
To: Justin Richer
Cc: oauth@ietf.org
Subject: [OAUTH-WG] Additional Oauth Dynamic Client Registration Protocol
Information

Justin,

I understand the current Client Registration request and response
information is based on the OPENID model for consistency, but has there been
any thought or discussion of adding the AS OAuth 2.0 endpoint URIs as part
of the registration response?  I believe the addition of the endpoint URIs
would make the dynamic client registration process truly a dynamic feature
of OAuth 2.0.

If the ability to discover the AS OAuth 2.0 endpoint URIs is being covered
by another IETF draft, I'd appreciate learning which current draft is being
worked on to achieve that result.

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

Phone:      (949) 636-8571

Email:       donald.coffin@reminetworks.com

------=_NextPart_000_00F4_01CE0F6B.437DD380
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Justin,

Thanks for the information.

Best =
regards,
Don
Donald F. =
Coffin
Founder/CTO=
 <=
p class=3DMsoNormal>REMI =
Networks
22751 El Prado Suite =
6216
Rancho Santa Margarita, =
CA  92688-3836
 <=
p class=3DMsoNormal>Phone:    =
;  (949) 636-8571
Email:    =
;   donald.coffin@reminetworks.com=

From: Justin Richer [mailto:jricher@mitre.org] 
Sent: =
Wednesday, February 20, 2013 11:50 AM
To: Mike =
Jones
Cc: Donald F Coffin; oauth@ietf.org
Subject: =
Re: [OAUTH-WG] Additional Oauth Dynamic Client Registration Protocol =
Information

Additionally, there is an individual =
draft that registers LRDD Link Types for discovery using LRDD and =
HostMeta:

http://too=
ls.ietf.org/html/draft-wmills-oauth-lrdd-07

 -- =
Justin
On 02/20/2013 02:37 PM, =
Mike Jones wrote:
Hi =
Don,

Discovery is a process =
that happens before Registration, and that’s the point at which =
you would return the AS (and registration!) endpoints to the =
Client.  The OAuth WG considered doing its own discovery work but =
ultimately decided to have that happen in the Apps Area WG instead, =
which is close to completing the WebFinger discovery =
specification.

If you want to see how =
OpenID Connect is performing discovery using WebFinger, including =
discovery of the AS endpoint, have a look at http:/=
/openid.net/specs/openid-connect-discovery-1_0.html.

        &=
nbsp;           &n=
bsp;           &nb=
sp;           &nbs=
p;            =
;       Best =
wishes,
        &=
nbsp;           &n=
bsp;           &nb=
sp;           &nbs=
p;            =
;       -- Mike

From:=
 =
oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=
 On Behalf Of Donald F Coffin
Sent: Wednesday, February =
20, 2013 11:30 AM
To: Justin Richer
Cc: oauth@ietf.org
Subject: =
[OAUTH-WG] Additional Oauth Dynamic Client Registration Protocol =
Information

Justin,

I understand =
the current Client Registration request and response information is =
based on the OPENID model for consistency, but has there been any =
thought or discussion of adding the AS OAuth 2.0 endpoint URIs as part =
of the registration response?  I believe the addition of the =
endpoint URIs would make the dynamic client registration process truly a =
dynamic feature of OAuth 2.0.

If the ability =
to discover the AS OAuth 2.0 endpoint URIs is being covered by another =
IETF draft, I’d appreciate learning which current draft is being =
worked on to achieve that result.

Best =
regards,
Don
Donald F. Coffin
Founder/CTO

REMI =
Networks
22751 El Prado Suite =
6216
Rancho Santa Margarita, CA  =
92688-3836

Phone:      (949) =
636-8571
Email:       donald.coffin@reminetworks=
.com

------=_NextPart_000_00F4_01CE0F6B.437DD380--

From donald.coffin@reminetworks.com  Wed Feb 20 16:11:14 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7460921F8CAA for ; Wed, 20 Feb 2013 16:11:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.646
X-Spam-Level: 
X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=0.952,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xll13+-faBoY for ; Wed, 20 Feb 2013 16:11:11 -0800 (PST)
Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 3687121E8053 for ; Wed, 20 Feb 2013 16:11:00 -0800 (PST)
Received: (qmail 17820 invoked by uid 0); 21 Feb 2013 00:10:38 -0000
Received: from unknown (HELO host125.hostmonster.com) (74.220.207.125) by oproxy12.bluehost.com with SMTP; 21 Feb 2013 00:10:38 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default;  h=Content-Type:MIME-Version:Message-ID:Date:Subject:Cc:To:From; bh=T1kNZbmwraymxAWQ9apwVWtWaJqUGrqSVOv1pW+3dzU=;  b=y/1ANA7lf2/A3sd8QhdrK/6ylvIWxjQUmeoScYtJFzpRsj4xkQwrGYJAWykKXTAc1M+MSVab4A2NmeGE8P9TrdCfCoU5blYARsGF87BIzVio5AMUhxIbcgBqkcu/3yL3;
Received: from [68.4.207.246] (port=6637 helo=HPPavilionElite) by host125.hostmonster.com with esmtpa (Exim 4.80) (envelope-from ) id 1U8JkE-0007dR-Lm; Wed, 20 Feb 2013 17:10:38 -0700
From: "Donald F Coffin" 
To: "Torsten Lodderstedt" 
Date: Wed, 20 Feb 2013 16:09:20 -0800
Message-ID: <013601ce0fc7$b2faea20$18f0be60$@reminetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0137_01CE0F84.A4D930C0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac4Px7IrfntWGndXSBWfWuqSAWEe0A==
Content-Language: en-us
X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.4.207.246 authed with donald.coffin@reminetworks.com}
Cc: John Adkins , Marty Burns , Scott Crowder , Dave Robin , John Teeter , pmadsen@pingidentity.com, Edward Denson , Jay Mitra , Uday Verma , Ray Perlner , Anne Hendry , Lynne Rodoni , oauth@ietf.org
Subject: [OAUTH-WG] draft-ietf-oauth-revocation-05 Questions
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Feb 2013 00:11:14 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0137_01CE0F84.A4D930C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Torsten,

A colleague of mine and I were discussing what should occur when a Retail
Customer desires to change the existing authorized access of a Third Party.
During our discussion they asked "How does the Retail Customer know the
Third Party actually issued a Token revocation request?  Isn't there a
potential trust issue with the current design"? 

The current draft provides a Third Party mechanism that "allows a client to
invalidate its tokens if the end-user logs out, changes identity, or
uninstalls the respective application (sic)." While none of these fit the
situation we were discussing they do seem to be based on the assumption a
Third Party application will be a good citizen and stop using access tokens.
Unfortunately, none of the addressed situations require the participation of
a AS for completion, therefore the risk exists that a Retail Customer may
believe they have removed a Third Party application from accessing their
protected data, but in reality there does not seem to be a mechanism to
either force or verify the Third Party can no longer have access to the
protected data.

A possible modification to the current draft that would correct this
potential security risk, is to treat a Token revocation using a message flow
similar to the existing authorization_code response type.  A Retail Customer
requesting a change to the Third Party authorized access would be redirected
to an AS endpoint that would allow the Retail Customer to either terminate a
relationship completely or modify the existing Third Party access
authorization.  The successful response from the AS would indicate the Third
Party needs to remove the current Token from its Token store.  In the event
the Retail Customer has changed the Third Party access authorization, the AS
response could include an optional "scope" element, which the Third Party
would then use to obtain a new access token utilizing an Authorization Code
request.

There are several other potential implementations that could be developed to
protect a Retail Customer from a "rogue" Third Party application that does
not inform the AS their authorization to access a Retail Customer's
protected data has been revoked, but the above suggestion meets the current
draft's view that Third Parties should be able to request Tokens be revoked.

I look forward to your comments on the above topic.

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

Phone:      (949) 636-8571

Email:       donald.coffin@reminetworks.com

------=_NextPart_000_0137_01CE0F84.A4D930C0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Torsten,

A colleague of =
mine and I were discussing what should occur when a Retail Customer =
desires to change the existing authorized access of a Third Party.  =
During our discussion they asked “How does the Retail Customer =
know the Third Party actually issued a Token revocation request?  =
Isn’t there a potential trust issue with the current =
design”? 

The current =
draft provides a Third Party mechanism that “allows a client to =
invalidate its tokens if the end-user logs out, changes identity, or =
uninstalls the respective application (sic).” While none of these =
fit the situation we were discussing they do seem to be based on the =
assumption a Third Party application will be a good citizen and stop =
using access tokens.  Unfortunately, none of the addressed =
situations require the participation of a AS for completion, therefore =
the risk exists that a Retail Customer may believe they have removed a =
Third Party application from accessing their protected data, but in =
reality there does not seem to be a mechanism to either force or verify =
the Third Party can no longer have access to the protected =
data.

A possible =
modification to the current draft that would correct this potential =
security risk, is to treat a Token revocation using a message flow =
similar to the existing authorization_code response type.  A Retail =
Customer requesting a change to the Third Party authorized access would =
be redirected to an AS endpoint that would allow the Retail Customer to =
either terminate a relationship completely or modify the existing Third =
Party access authorization.  The successful response from the AS =
would indicate the Third Party needs to remove the current Token from =
its Token store.  In the event the Retail Customer has changed the =
Third Party access authorization, the AS response could include an =
optional “scope” element, which the Third Party would then =
use to obtain a new access token utilizing an Authorization Code =
request.

There are =
several other potential implementations that could be developed to =
protect a Retail Customer from a “rogue” Third Party =
application that does not inform the AS their authorization to access a =
Retail Customer’s protected data has been revoked, but the above =
suggestion meets the current draft’s view that Third Parties =
should be able to request Tokens be revoked.

I look forward =
to your comments on the above topic.

Best =
regards,
Don
Donald F. Coffin
Founder/CTO

REMI =
Networks
22751 El Prado Suite =
6216
Rancho Santa Margarita, CA  =
92688-3836

Phone:      (949) =
636-8571
Email:       donald.coffin@reminetworks=
.com

------=_NextPart_000_0137_01CE0F84.A4D930C0--

From torsten@lodderstedt.net  Thu Feb 21 00:12:37 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF09F21F8E07 for ; Thu, 21 Feb 2013 00:12:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.569
X-Spam-Level: 
X-Spam-Status: No, score=-0.569 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYwufnVU8uec for ; Thu, 21 Feb 2013 00:12:37 -0800 (PST)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7146121F8AB8 for ; Thu, 21 Feb 2013 00:12:36 -0800 (PST)
Received: from [80.187.106.201] (helo=[192.168.43.3]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1U8RGZ-0005nC-Bt; Thu, 21 Feb 2013 09:12:31 +0100
References: <013601ce0fc7$b2faea20$18f0be60$@reminetworks.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <013601ce0fc7$b2faea20$18f0be60$@reminetworks.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-E90BEB38-6533-4127-963B-451BAB079AD2
Content-Transfer-Encoding: 7bit
Message-Id: 
X-Mailer: iPad Mail (10B141)
From: Torsten Lodderstedt 
Date: Thu, 21 Feb 2013 09:12:30 +0100
To: Donald F Coffin 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: John Adkins , Marty Burns , Scott Crowder , Dave Robin , John Teeter , "" , Edward Denson , Jay Mitra , Uday Verma , Ray Perlner , Anne Hendry , Lynne Rodoni , "" 
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-05 Questions
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Feb 2013 08:12:38 -0000

--Apple-Mail-E90BEB38-6533-4127-963B-451BAB079AD2
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Donald,

thank you for sharing your thoughts with us. I've never seen revocation as c=
hange of scope of the authorization, but it sounds reasonable. The current d=
esign handles the issues you raised differently.

The AS is involved in the revocation process as it exposes the revocation en=
dpoint. So if the token is revoked (from a technical perspective), it knows i=
t. If the user wants to check whether the application really sent the reques=
t, she is supposed to visit the respective portal belonging to the AS. There=
 the AS provides a list of all valid authorization grants in its database.=20=

Does this address your issues?

regards,
Torsten.

Am 21.02.2013 um 01:09 schrieb "Donald F Coffin" :

> Torsten,
> =20
> A colleague of mine and I were discussing what should occur when a Retail C=
ustomer desires to change the existing authorized access of a Third Party.  D=
uring our discussion they asked =E2=80=9CHow does the Retail Customer know t=
he Third Party actually issued a Token revocation request?  Isn=E2=80=99t th=
ere a potential trust issue with the current design=E2=80=9D?
> =20
> The current draft provides a Third Party mechanism that =E2=80=9Callows a c=
lient to invalidate its tokens if the end-user logs out, changes identity, o=
r uninstalls the respective application (sic).=E2=80=9D While none of these f=
it the situation we were discussing they do seem to be based on the assumpti=
on a Third Party application will be a good citizen and stop using access to=
kens.  Unfortunately, none of the addressed situations require the participa=
tion of a AS for completion, therefore the risk exists that a Retail Custome=
r may believe they have removed a Third Party application from accessing the=
ir protected data, but in reality there does not seem to be a mechanism to e=
ither force or verify the Third Party can no longer have access to the prote=
cted data.
> =20
> A possible modification to the current draft that would correct this poten=
tial security risk, is to treat a Token revocation using a message flow simi=
lar to the existing authorization_code response type.  A Retail Customer req=
uesting a change to the Third Party authorized access would be redirected to=
 an AS endpoint that would allow the Retail Customer to either terminate a r=
elationship completely or modify the existing Third Party access authorizati=
on.  The successful response from the AS would indicate the Third Party need=
s to remove the current Token from its Token store.  In the event the Retail=
 Customer has changed the Third Party access authorization, the AS response c=
ould include an optional =E2=80=9Cscope=E2=80=9D element, which the Third Pa=
rty would then use to obtain a new access token utilizing an Authorization C=
ode request.
> =20
> There are several other potential implementations that could be developed t=
o protect a Retail Customer from a =E2=80=9Crogue=E2=80=9D Third Party appli=
cation that does not inform the AS their authorization to access a Retail Cu=
stomer=E2=80=99s protected data has been revoked, but the above suggestion m=
eets the current draft=E2=80=99s view that Third Parties should be able to r=
equest Tokens be revoked.
> =20
> I look forward to your comments on the above topic.
> =20
> =20
> Best regards,
> Don
> Donald F. Coffin
> Founder/CTO
> =20
> REMI Networks
> 22751 El Prado Suite 6216
> Rancho Santa Margarita, CA  92688-3836
> =20
> Phone:      (949) 636-8571
> Email:       donald.coffin@reminetworks.com
> =20

--Apple-Mail-E90BEB38-6533-4127-963B-451BAB079AD2
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Donald,

th=
ank you for sharing your thoughts with us. I've never seen revocation as cha=
nge of scope of the authorization, but it sounds reasonable. The current des=
ign handles the issues you raised differently.

The A=
S is involved in the revocation process as it exposes the revocation endpoin=
t. So if the token is revoked (from a technical perspective), it knows it. I=
f the user wants to check whether the application really sent the request, s=
he is supposed to visit the respective portal belonging to the AS. There the=
 AS provides a list of all valid authorization grants in its database. =

Does this address your issues?

regards,
Torsten.

Am 21.02.2013 um 01:09 schri=
eb "Donald F Coffin" <d=
onald.coffin@reminetworks.com>:

Torsten,
=

A colleague of min=
e and I were discussing what should occur when a Retail Customer desires to c=
hange the existing authorized access of a Third Party.  During our disc=
ussion they asked =E2=80=9CHow does the Retail Customer know the Third Party=
 actually issued a Token revocation request?  Isn=E2=80=99t there a pot=
ential trust issue with the current design=E2=80=9D? <=
p class=3D"MsoNormal"> 
The current draft provides a Third Party mechanism that =E2=80=9C=
allows a client to invalidate its tokens if the end-user logs out, changes i=
dentity, or uninstalls the respective application (sic).=E2=80=9D While none=
 of these fit the situation we were discussing they do seem to be based on t=
he assumption a Third Party application will be a good citizen and stop usin=
g access tokens.  Unfortunately, none of the addressed situations requi=
re the participation of a AS for completion, therefore the risk exists that a=
 Retail Customer may believe they have removed a Third Party application fro=
m accessing their protected data, but in reality there does not seem to be a=
 mechanism to either force or verify the Third Party can no longer have acce=
ss to the protected data.
=

A possible modific=
ation to the current draft that would correct this potential security risk, i=
s to treat a Token revocation using a message flow similar to the existing a=
uthorization_code response type.  A Retail Customer requesting a change=
 to the Third Party authorized access would be redirected to an AS endpoint t=
hat would allow the Retail Customer to either terminate a relationship compl=
etely or modify the existing Third Party access authorization.  The suc=
cessful response from the AS would indicate the Third Party needs to remove t=
he current Token from its Token store.  In the event the Retail Custome=
r has changed the Third Party access authorization, the AS response could in=
clude an optional =E2=80=9Cscope=E2=80=9D element, which the Third Party wou=
ld then use to obtain a new access token utilizing an Authorization Code req=
uest.

There are several other potential imp=
lementations that could be developed to protect a Retail Customer from a =E2=
=80=9Crogue=E2=80=9D Third Party application that does not inform the AS the=
ir authorization to access a Retail Customer=E2=80=99s protected data has be=
en revoked, but the above suggestion meets the current draft=E2=80=99s view t=
hat Third Parties should be able to request Tokens be revoked.

I look forward to your comments on the above topic.<=
/o:p>

Best regards,
Don
Donald F. Coffin=
Founder/CTO
&n=
bsp;
REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA  9=
2688-3836

Phone:      (949) 636-8571<=
/o:p>
Emai=
l:       donald.coffin@reminetworks.com
 =

--Apple-Mail-E90BEB38-6533-4127-963B-451BAB079AD2--

From sberyozkin@gmail.com  Thu Feb 21 02:02:43 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F0421F8DF1 for ; Thu, 21 Feb 2013 02:02:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.471
X-Spam-Level: 
X-Spam-Status: No, score=-3.471 tagged_above=-999 required=5 tests=[AWL=0.128,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0eh4vfP7dC38 for ; Thu, 21 Feb 2013 02:02:40 -0800 (PST)
Received: from mail-ea0-f177.google.com (mail-ea0-f177.google.com [209.85.215.177]) by ietfa.amsl.com (Postfix) with ESMTP id B019721F8E38 for ; Thu, 21 Feb 2013 02:02:39 -0800 (PST)
Received: by mail-ea0-f177.google.com with SMTP id n13so3736239eaa.36 for ; Thu, 21 Feb 2013 02:02:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=H5/neoA5NswWX8i7+YnhuWo7cm745RO7QTAy2LjKhpA=; b=Vm+7rvDQ+oiCOR4M6irirXGkbu4uOCDxO5JjNqJvJDe5tbHd0GxcRhj3eEomeDyiS4 rs8YZ9tb8mn+gSmxGEXP5Bb2z1lKR0tAkyzANZoRaTmXqmWz/hoe4un9/Szbym5KGPTH IwMGVlcbloKvXB4DQ3v9GA9/fwh5LEOqAR+jAu+Zkz7m9DhLh3752BtyBvv0UjDGjnrL dqKWpInagPghJvqgzVyz5rCSeiJBHEzKH4BYoYugvXvRwT1BpJ8lPzXLxGrvg649cLov FYOuCeHOk5u/2gq9kQNkEvS7rFO76S2aXw8ZR/1YgDBXCOgGPm7HIKARtYWw/F1/h7AI YQUQ==
X-Received: by 10.14.205.68 with SMTP id i44mr78924635eeo.25.1361440958382; Thu, 21 Feb 2013 02:02:38 -0800 (PST)
Received: from [10.36.226.5] ([217.173.99.61]) by mx.google.com with ESMTPS id 44sm113994307eek.5.2013.02.21.02.02.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 02:02:37 -0800 (PST)
Message-ID: <5125F0A2.6070808@gmail.com>
Date: Thu, 21 Feb 2013 10:02:10 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: "" 
References: <51238410.8040705@gmail.com>  <5124B749.9050402@gmail.com>
In-Reply-To: <5124B749.9050402@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [OAUTH-WG] Using SAML2 Bearer for the authentication
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Feb 2013 10:02:44 -0000

On 20/02/13 11:45, Sergey Beryozkin wrote:
> On 19/02/13 14:27, Brian Campbell wrote:
>> The scope of assertion based client authentication is only in OAuth and
>> only for the client calling the AS's token endpoint. Defining a general
>> HTTP auth scheme for assertions would have a much broader scope and be
>> much more difficult to standardize.
> Understood, thanks.
>
> I'd like to ask another question related to the subject of this thread,
> though the same would likely be relevant for using JWT for authenticating.
>
> When the assertion is used for authenticating the client, a form
> "client_id" parameter is said to be optional.
> Next, section 6.1 [1] says that "Subject" of the assertion SHOULD be
> "client_id".
>
> I interpret it like this.
>
> If "Subject" is set to "client_id" then there the actual client_id must
> be available as "client_id" form parameter, which will be posted
> alongside the assertion.
>
> If not then the client_id is an actual Subject value and no "client_id"
> form parameter is expected to be available.
>
>
Continuing on this,

http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-15#section-3

says "For client authentication, the Subject MUST be the "client_id" of 
the OAuth client."

This makes me think I may've been wrong with my initial reading of both 
drafts, now I read like this:

"the Subject MUST be the "client_id" of the OAuth client." as per the 
Saml2 bearer draft, which is not the literal "client_id". Next, if 
"client_id" form parameter is available then it must be equal to Subject 
value, as is, or via an AS provided mapping, otherwise it is a 
validation fault.
This is probably in line with the answers to the similar question on the 
use of client_id and JWT grant, though I'm not sure.

I appreciate it is a work in progress, but IMHO some more clarifications 
in the text will help

Cheers, Sergey

> Is it correct ?
>
> Thanks, Sergey
>
> [1] http://tools.ietf.org/html/draft-ietf-oauth-assertions-10#section-6.1
>
>
>
>>
>>
>> On Tue, Feb 19, 2013 at 6:54 AM, Sergey Beryozkin > > wrote:
>>
>> Hi,
>>
>> Assertions like SAML2 Bearer can be used for authenticating the client.
>> Why a dedicated Authorization scheme can not be introduced, instead
>> of or in addition to "client_assertion" & "client_assertion_type"
>> parameters ?
>>
>> IMHO, the following
>>
>> Authorization: SAML "base64url-encoded assertion"
>>
>> grant_type=authorization_code&__code=123456
>>
>> is more in line with OAuth2 recommending not to prefer including
>> client id & secret in the body:
>>
>> "Including the client credentials in the request-body using the two
>> parameters is NOT RECOMMENDED and SHOULD be limited to clients unable
>> to directly utilize the HTTP Basic authentication scheme (or other
>> password-based HTTP authentication schemes)" - though it talks about
>> a password based scheme...
>>
>> similarly:
>>
>> Authorization: JWT "encoded jwt assertion"
>>
>> grant_type=authorization_code&__code=123456
>>
>> Just a thought.
>>
>> Cheers, Sergey
>>
>>
>> _________________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/__listinfo/oauth
>> 
>>
>>

From jricher@mitre.org  Thu Feb 21 06:05:45 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D620221F8ABC for ; Thu, 21 Feb 2013 06:05:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.575
X-Spam-Level: 
X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.023,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlfUA5EvPhM9 for ; Thu, 21 Feb 2013 06:05:42 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB9221F8AB6 for ; Thu, 21 Feb 2013 06:05:42 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9D6391F25F4; Thu, 21 Feb 2013 09:05:41 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7BF3C1F25F0; Thu, 21 Feb 2013 09:05:41 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 21 Feb 2013 09:05:41 -0500
Message-ID: <5126297F.7070904@mitre.org>
Date: Thu, 21 Feb 2013 09:04:47 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Mike Jones 
References: <20130215215423.23019.50224.idtracker@ietfa.amsl.com>   <4E1F6AAD24975D4BA5B16804296739436747A665@TK5EX14MBXC284.redmond.corp.microsoft.com> <63255CDA-E93F-4414-B471-B373C4B6F65E@ve7jtb.com>   <4E1F6AAD24975D4BA5B16804296739436747AD87@TK5EX14MBXC284.redmond.corp.microsoft.com>  <4E1F6AAD24975D4BA5B16804296739436747B12D@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436747B12D@TK5EX14MBXC284.redmond.corp.microsoft.com>
Content-Type: multipart/alternative; boundary="------------030606070303070907060102"
X-Originating-IP: [129.83.31.58]
Cc: "" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Feb 2013 14:05:46 -0000

--------------030606070303070907060102
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

With this in mind, we might want to change *all* of the _url parameters 
to _uri instead, not just this new one. Are folks in favor of this?

  -- Justin

On 02/20/2013 12:57 PM, Mike Jones wrote:
>
> OK, we should make the change then.  Thanks for the input.
>
> -- Mike
>
> *From:*Tim Bray [mailto:twbray@google.com]
> *Sent:* Wednesday, February 20, 2013 9:22 AM
> *To:* Mike Jones
> *Cc:* Nat Sakimura; 
> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
>
> Yes, "URL" is strongly and clearly deprecated in RFC3986 section 
> 1.1.3; one of the reasons is that the distinction between "locator" 
> and "identifier" which sounds like it should be easy, turns out to 
> lead to theological bikeshed discussions almost inevitably, and in 
> fact be shaky in practice.  -T
>
> On Wed, Feb 20, 2013 at 9:00 AM, Mike Jones 
> > wrote:
>
> Tim, as background, this came from the OpenID Connect specs, where we 
> tried to consistently use the convention that the locator for any 
> resource that can be retrieved from the specified location be called a 
> URL, whereas any identifier that may not be retrievable is called a 
> URI.  That was done as an aid to developer understanding of the 
> specifications.
>
> If the use of "URL" is deprecated by the IETF in favor of always just 
> using "URI", I suppose we could change that, but if it's going to 
> change, it should be soon.
>
> -- Mike
>
> *From:*oauth-bounces@ietf.org  
> [mailto:oauth-bounces@ietf.org ] *On 
> Behalf Of *Nat Sakimura
> *Sent:* Wednesday, February 20, 2013 8:57 AM
> *To:* Tim Bray
> *Cc:* >
> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
>
> You are right. I am in the camp recommending the use of URL when it is 
> a concrete endpoint and URI when it includes something that is only 
> abstract, but since OAuth standardized on "uri", we may as well do so 
> here.
>
> Nat
>
> 2013/2/20 Tim Bray >
>
> In OAuth, we have redirect_uri not redirect_url; should this be 
> registration_access_uri for consistency? -T
>
> On Wed, Feb 20, 2013 at 8:23 AM, John Bradley  > wrote:
>
> I think registration_access_url is OK.    I haven't heard any better 
> names yet.
>
> John B.
>
> On 2013-02-20, at 1:04 PM, Mike Jones  > wrote:
>
> For what it's worth, the name "registration_access_url" was chosen to 
> be parallel to "registration_access_token". It's the place you use the 
> access token.  And it's where you access an existing registration.  
> I'm against the name "client_metadata_url" because it's not metadata 
> you're accessing -- it's a registration you're accessing.  For the 
> same reason, I don't think the name "client_info_url" gives people the 
> right idea, because it doesn't say anything it being the registration 
> that you're accessing.
>
> If you really want us to change this, having read what's above, I 
> could live with "client_registration_url", but I don't think a change 
> is actually necessary.  (But if we are going to change it, let's do it 
> ASAP, before the OpenID Connect Implementer's Drafts are published.)
>
> -- Mike
>
> *From:*oauth-bounces@ietf.org  
> [mailto:oauth- bounces@ietf.org 
> ] *On Behalf Of *Nat Sakimura
> *Sent:* Wednesday, February 20, 2013 7:58 AM
> *To:* >; Richer, Justin P.; 
> John Bradley
> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
>
> Thanks Justin.
>
> Even if we go flat rather than doing JSON Structure, the "Client
> Registration Access Endpoint" is not a good representative name.
>
> What it represents is the client metadata/info.
> It is not representing "Client Registration Access".
>
> What does "Client Registration Access" mean?
>
> Does UPDATing "Cleint Registration Access" make sense?
>
> Something in the line of "Client Metadata Endpoint" and
> something like "client_metadata_url" or "client_info_url" is much better.
>
> Nat
>
> 2013/2/15 Richer, Justin P. >
>
> Everyone, there's a new draft of DynReg up on the tracker. This draft 
> tries to codify the discussions so far from this week into something 
> we can all read. There are still plenty of open discussion points and 
> items up for debate. Please read through this latest draft and see 
> what's changed and help assure that it properly captures the 
> conversations. If you have any inputs for the marked [[ Editor's Note 
> ]] sections, please send them to the list by next Thursday to give me 
> opportunity to get any necessary changes in by the cutoff date of 
> Monday the 22nd.
>
> Thanks for all of your hard work everyone, I think this is *really* 
> coming along now.
>
>  -- Justin
>
>
> On Feb 15, 2013, at 4:54 PM, internet-drafts@ietf.org 
>  wrote:
>
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> > This draft is a work item of the Web Authorization Protocol Working 
> Group of the IETF.
> >
> >       Title   : OAuth Dynamic Client Registration Protocol
> >       Author(s)   : Justin Richer
> >      John Bradley
> >      Michael B. Jones
> >      Maciej Machulak
> >       Filename    : draft-ietf-oauth-dyn-reg-06.txt
> >       Pages   : 21
> >       Date    : 2013-02-15
> >
> > Abstract:
> >   This specification defines an endpoint and protocol for dynamic
> >   registration of OAuth Clients at an Authorization Server.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-06
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > 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
>
>
>
> -- 
> Nat Sakimura (=nat)
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>
> _______________________________________________
> 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
>
>
>
> -- 
> Nat Sakimura (=nat)
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--------------030606070303070907060102
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

    With this in mind, we might want to change *all* of the _url
    parameters to _uri instead, not just this new one. Are folks in
    favor of this?

     -- Justin

    On 02/20/2013 12:57 PM, Mike Jones
      wrote:

        OK,
            we should make the change then.  Thanks for the input.

            -- Mike

        From:
            Tim Bray [mailto:twbray@google.com]

            Sent: Wednesday, February 20, 2013 9:22 AM

            To: Mike Jones

            Cc: Nat Sakimura; <oauth@ietf.org>

            Subject: Re: [OAUTH-WG] I-D Action:
            draft-ietf-oauth-dyn-reg-06.txt

        Yes, “URL” is
          strongly and clearly deprecated in RFC3986 section 1.1.3; one
          of the reasons is that the distinction between “locator” and
          “identifier” which sounds like it should be easy, turns out to
          lead to theological bikeshed discussions almost inevitably,
          and in fact be shaky in practice.  -T

          On Wed, Feb 20, 2013 at 9:00 AM, Mike
            Jones <Michael.Jones@microsoft.com>
            wrote:

              Tim,
                  as background, this came from the OpenID Connect
                  specs, where we tried to consistently use the
                  convention that the locator for any resource that can
                  be retrieved from the specified location be called a
                  URL, whereas any identifier that may not be
                  retrievable is called a URI.  That was done as an aid
                  to developer understanding of the specifications.

              If
                  the use of “URL” is deprecated by the IETF in favor of
                  always just using “URI”, I suppose we could change
                  that, but if it’s going to change, it should be soon.

                  -- Mike

              From:
                  oauth-bounces@ietf.org
                  [mailto:oauth-bounces@ietf.org]
                  On Behalf Of Nat Sakimura

                  Sent: Wednesday, February 20, 2013 8:57 AM

                  To: Tim Bray

                  Cc: <oauth@ietf.org>

                  Subject: Re: [OAUTH-WG] I-D Action:
                  draft-ietf-oauth-dyn-reg-06.txt

              You
                are right. I am in the camp recommending the use of URL
                when it is a concrete endpoint and URI when it includes
                something that is only abstract, but since OAuth
                standardized on "uri", we may as well do so here. 

                Nat

                  2013/2/20
                    Tim Bray <twbray@google.com>
                  In
                    OAuth, we have redirect_uri not redirect_url; should
                    this be registration_access_uri for consistency? -T

                        On
                          Wed, Feb 20, 2013 at 8:23 AM, John Bradley
                          <ve7jtb@ve7jtb.com>
                          wrote:

                          I
                            think registration_access_url is OK.    I
                            haven't heard any better names yet.

                            John
                              B.

                                    On
                                      2013-02-20, at 1:04 PM, Mike Jones
                                      <Michael.Jones@microsoft.com>
                                      wrote:

                                        For
                                            what it’s worth, the name
                                            “registration_access_url”
                                            was chosen to be parallel to
                                            “registration_access_token”.  

                                            It’s the place you use the
                                            access token.  And it’s
                                            where you access an existing
                                            registration.  I’m against
                                            the name
                                            “client_metadata_url”
                                            because it’s not metadata
                                            you’re accessing – it’s a
                                            registration you’re
                                            accessing.  For the same
                                            reason, I don’t think the
                                            name “client_info_url” gives
                                            people the right idea,
                                            because it doesn’t say
                                            anything it being the
                                            registration that you’re
                                            accessing.

                                        If
                                            you really want us to change
                                            this, having read what’s
                                            above, I could live with
                                            “client_registration_url”,
                                            but I don’t think a change
                                            is actually necessary.  (But
                                            if we are going to change
                                            it, let’s do it ASAP, before
                                            the OpenID Connect
                                            Implementer’s Drafts are
                                            published.)

                                            -- Mike

                                        From: oauth-bounces@ietf.org
                                            [mailto:oauth-bounces@ietf.org] On
                                              Behalf Of Nat Sakimura

                                            Sent: Wednesday,
                                            February 20, 2013 7:58 AM

                                            To: <oauth@ietf.org>;
                                            Richer, Justin P.; John
                                            Bradley

                                            Subject: Re:
                                            [OAUTH-WG] I-D Action:
                                            draft-ietf-oauth-dyn-reg-06.txt

                                        Thanks
                                            Justin.

                                            Even if we go flat rather
                                            than doing JSON Structure,
                                            the "Client

                                            Registration Access
                                            Endpoint" is not a good
                                            representative name.

                                            What it represents is the
                                            client metadata/info.

                                            It is not representing
                                            "Client Registration
                                            Access". 

                                          What
                                            does "Client Registration
                                            Access" mean? 

                                        Does
                                            UPDATing "Cleint
                                            Registration Access" make
                                            sense?

                                            Something in the line of
                                            "Client Metadata Endpoint"
                                            and

                                            something like
                                            "client_metadata_url"
                                            or "client_info_url" is much
                                            better.

                                            Nat

                                            2013/2/15
                                              Richer, Justin P. <jricher@mitre.org>

                                            Everyone,
                                              there's a new draft of
                                              DynReg up on the tracker.
                                              This draft tries to codify
                                              the discussions so far
                                              from this week into
                                              something we can all read.
                                              There are still plenty of
                                              open discussion points and
                                              items up for debate.
                                              Please read through this
                                              latest draft and see
                                              what's changed and help
                                              assure that it properly
                                              captures the
                                              conversations. If you have
                                              any inputs for the marked
                                              [[ Editor's Note ]]
                                              sections, please send them
                                              to the list by next
                                              Thursday to give me
                                              opportunity to get any
                                              necessary changes in by
                                              the cutoff date of Monday
                                              the 22nd.

                                              Thanks for all of your
                                              hard work everyone, I
                                              think this is *really*
                                              coming along now.

                                                 -- Justin

                                                On Feb 15, 2013, at 4:54
                                                PM, internet-drafts@ietf.org wrote:

                                                >

                                                > A New
                                                Internet-Draft is
                                                available from the
                                                on-line Internet-Drafts
                                                directories.

                                                > This draft is a
                                                work item of the Web
                                                Authorization Protocol
                                                Working Group of the
                                                IETF.

                                                >

                                                >       Title        
                                                  : OAuth Dynamic Client
                                                Registration Protocol

                                                >       Author(s)    
                                                  : Justin Richer

                                                >                    
                                                     John Bradley

                                                >                    
                                                     Michael B. Jones

                                                >                    
                                                     Maciej Machulak

                                                >       Filename    
                                                   :
                                                draft-ietf-oauth-dyn-reg-06.txt

                                                >       Pages        
                                                  : 21

                                                >       Date        
                                                   : 2013-02-15

                                                >

                                                > Abstract:

                                                >   This
                                                specification defines an
                                                endpoint and protocol
                                                for dynamic

                                                >   registration of
                                                OAuth Clients at an
                                                Authorization Server.

                                                >

                                                >

                                                > The IETF
                                                datatracker status page
                                                for this draft is:

                                                > https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg

                                                >

                                                > There's also a
                                                htmlized version
                                                available at:

                                                > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06

                                                >

                                                > A diff from the
                                                previous version is
                                                available at:

                                                > http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-06

                                                >

                                                >

                                                > Internet-Drafts are
                                                also available by
                                                anonymous FTP at:

                                                > ftp://ftp.ietf.org/internet-drafts/

                                                >

                                                >
                                                _______________________________________________

                                                > 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

                                          -- 

                                            Nat Sakimura (=nat)

                                            Chairman,
                                              OpenID Foundation

                                              http://nat.sakimura.org/

                                              @_nat_en

_______________________________________________

                          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

                --

                    Nat Sakimura (=nat)

                  Chairman, OpenID Foundation

                      http://nat.sakimura.org/

                      @_nat_en

      _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------030606070303070907060102--

From donald.coffin@reminetworks.com  Thu Feb 21 07:44:28 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3114A21F8E9B for ; Thu, 21 Feb 2013 07:44:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.047
X-Spam-Level: 
X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[AWL=0.217,  BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3wV7auVgqec for ; Thu, 21 Feb 2013 07:44:26 -0800 (PST)
Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 739CB21F8E97 for ; Thu, 21 Feb 2013 07:44:26 -0800 (PST)
Received: (qmail 11368 invoked by uid 0); 21 Feb 2013 15:43:58 -0000
Received: from unknown (HELO host125.hostmonster.com) (74.220.207.125) by oproxy7.bluehost.com with SMTP; 21 Feb 2013 15:43:58 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default;  h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=Q7rfQPszNmF9+InjZXGJigfKPVKK24ma1JSlvl09HJw=;  b=HGJNURGr00WeUeRNF8N2m8wtqrS82T1gBwWS6FaQ2CVh1BY0THgvslROWJ6G3PBIUkuo2hHEv496ajqRtRsWoxr0Rk/wAY1SuJRGau8slI0V2vUNya+YBCk/UTdRuMtE;
Received: from [68.4.207.246] (port=1155 helo=HPPavilionElite) by host125.hostmonster.com with esmtpa (Exim 4.80) (envelope-from ) id 1U8YJS-0000ht-9z; Thu, 21 Feb 2013 08:43:58 -0700
From: "Donald F Coffin" 
To: "'Torsten Lodderstedt'" 
References: <013601ce0fc7$b2faea20$18f0be60$@reminetworks.com> 
In-Reply-To: 
Date: Thu, 21 Feb 2013 07:42:20 -0800
Message-ID: <004f01ce104a$097c79e0$1c756da0$@reminetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0050_01CE1006.FB5BAAE0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJjjcb25qbAdii4kOnGObWIAqRIYwHsW6Rdl0oU45A=
Content-Language: en-us
X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.4.207.246 authed with donald.coffin@reminetworks.com}
Cc: 'John Adkins' , 'Marty Burns' , 'Scott Crowder' , 'Dave Robin' , 'John Teeter' , pmadsen@pingidentity.com, 'Edward Denson' , 'Jay Mitra' , 'Uday Verma' , 'Ray Perlner' , 'Anne Hendry' , 'Lynne Rodoni' , oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-05 Questions
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Feb 2013 15:44:28 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0050_01CE1006.FB5BAAE0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Torsten,

=20

Thanks for the response.  What is the =E2=80=9Crespective portal =
belonging to the AS=E2=80=9D?  I haven=E2=80=99t seen anything in the =
OAuth 2.0 Authorization Framework that describes a =
=E2=80=9Cportal=E2=80=9D on the AS a Resource Owner can log into to view =
a valid list of authorization grants.  Is this an out-of-band =
implementation suggestion?

=20

Best regards,

Don

Donald F. Coffin

Founder/CTO

=20

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

=20

Phone:      (949) 636-8571

Email:         =
donald.coffin@reminetworks.com

=20

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]=20
Sent: Thursday, February 21, 2013 12:13 AM
To: Donald F Coffin
Cc: ; Anne Hendry; Dave Robin; Edward Denson; Jay Mitra; =
John Adkins; John Teeter; Lynne Rodoni; Marty Burns; =
; Ray Perlner; Scott Crowder; Uday Verma
Subject: Re: draft-ietf-oauth-revocation-05 Questions

=20

Hi Donald,

=20

thank you for sharing your thoughts with us. I've never seen revocation =
as change of scope of the authorization, but it sounds reasonable. The =
current design handles the issues you raised differently.

=20

The AS is involved in the revocation process as it exposes the =
revocation endpoint. So if the token is revoked (from a technical =
perspective), it knows it. If the user wants to check whether the =
application really sent the request, she is supposed to visit the =
respective portal belonging to the AS. There the AS provides a list of =
all valid authorization grants in its database.=20

=20

Does this address your issues?

=20

regards,

Torsten.

Am 21.02.2013 um 01:09 schrieb "Donald F Coffin" =
:

Torsten,

=20

A colleague of mine and I were discussing what should occur when a =
Retail Customer desires to change the existing authorized access of a =
Third Party.  During our discussion they asked =E2=80=9CHow does the =
Retail Customer know the Third Party actually issued a Token revocation =
request?  Isn=E2=80=99t there a potential trust issue with the current =
design=E2=80=9D?=20

=20

The current draft provides a Third Party mechanism that =E2=80=9Callows =
a client to invalidate its tokens if the end-user logs out, changes =
identity, or uninstalls the respective application (sic).=E2=80=9D While =
none of these fit the situation we were discussing they do seem to be =
based on the assumption a Third Party application will be a good citizen =
and stop using access tokens.  Unfortunately, none of the addressed =
situations require the participation of a AS for completion, therefore =
the risk exists that a Retail Customer may believe they have removed a =
Third Party application from accessing their protected data, but in =
reality there does not seem to be a mechanism to either force or verify =
the Third Party can no longer have access to the protected data.

=20

A possible modification to the current draft that would correct this =
potential security risk, is to treat a Token revocation using a message =
flow similar to the existing authorization_code response type.  A Retail =
Customer requesting a change to the Third Party authorized access would =
be redirected to an AS endpoint that would allow the Retail Customer to =
either terminate a relationship completely or modify the existing Third =
Party access authorization.  The successful response from the AS would =
indicate the Third Party needs to remove the current Token from its =
Token store.  In the event the Retail Customer has changed the Third =
Party access authorization, the AS response could include an optional =
=E2=80=9Cscope=E2=80=9D element, which the Third Party would then use to =
obtain a new access token utilizing an Authorization Code request.

=20

There are several other potential implementations that could be =
developed to protect a Retail Customer from a =E2=80=9Crogue=E2=80=9D =
Third Party application that does not inform the AS their authorization =
to access a Retail Customer=E2=80=99s protected data has been revoked, =
but the above suggestion meets the current draft=E2=80=99s view that =
Third Parties should be able to request Tokens be revoked.

=20

I look forward to your comments on the above topic.

=20

=20

Best regards,

Don

Donald F. Coffin

Founder/CTO

=20

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

=20

Phone:      (949) 636-8571

Email:       donald.coffin@reminetworks.com

=20

------=_NextPart_000_0050_01CE1006.FB5BAAE0
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Torsten,

Thanks for the =
response.=C2=A0 What is the =E2=80=9Crespective portal belonging to the =
AS=E2=80=9D?=C2=A0 I haven=E2=80=99t seen anything in the OAuth 2.0 =
Authorization Framework that describes a =E2=80=9Cportal=E2=80=9D on the =
AS a Resource Owner can log into to view a valid list of authorization =
grants.=C2=A0 Is this an out-of-band implementation =
suggestion?

Best regards,
Don
Donald F. Coffin
Founder/CTO

REMI =
Networks
22751 El Prado Suite =
6216
Rancho Santa Margarita, CA=C2=A0 =
92688-3836

Phone:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (949) =
636-8571
Email:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 donald.coffin@reminetworks.com=

From:=
 =
Torsten Lodderstedt [mailto:torsten@lodderstedt.net] 
Sent: =
Thursday, February 21, 2013 12:13 AM
To: Donald F =
Coffin
Cc: <oauth@ietf.org>; Anne Hendry; Dave Robin; =
Edward Denson; Jay Mitra; John Adkins; John Teeter; Lynne Rodoni; Marty =
Burns; <pmadsen@pingidentity.com>; Ray Perlner; Scott Crowder; =
Uday Verma
Subject: Re: draft-ietf-oauth-revocation-05 =
Questions

Hi =
Donald,

thank you for sharing your thoughts with us. I've =
never seen revocation as change of scope of the authorization, but it =
sounds reasonable. The current design handles the issues you raised =
differently.

The AS is involved in the revocation process as it =
exposes the revocation endpoint. So if the token is revoked (from a =
technical perspective), it knows it. If the user wants to check whether =
the application really sent the request, she is supposed to visit the =
respective portal belonging to the AS. There the AS provides a list of =
all valid authorization grants in its =
database. 

Does this address your =
issues?

regards,
Torsten.

Am 21.02.2013 um 01:09 schrieb =
"Donald F Coffin" <donald.coffin@reminetworks=
.com>:
Torsten,<=
o:p>

A colleague of =
mine and I were discussing what should occur when a Retail Customer =
desires to change the existing authorized access of a Third Party.  =
During our discussion they asked =E2=80=9CHow does the Retail Customer =
know the Third Party actually issued a Token revocation request?  =
Isn=E2=80=99t there a potential trust issue with the current =
design=E2=80=9D? 

The current =
draft provides a Third Party mechanism that =E2=80=9Callows a client to =
invalidate its tokens if the end-user logs out, changes identity, or =
uninstalls the respective application (sic).=E2=80=9D While none of =
these fit the situation we were discussing they do seem to be based on =
the assumption a Third Party application will be a good citizen and stop =
using access tokens.  Unfortunately, none of the addressed =
situations require the participation of a AS for completion, therefore =
the risk exists that a Retail Customer may believe they have removed a =
Third Party application from accessing their protected data, but in =
reality there does not seem to be a mechanism to either force or verify =
the Third Party can no longer have access to the protected =
data.

A possible =
modification to the current draft that would correct this potential =
security risk, is to treat a Token revocation using a message flow =
similar to the existing authorization_code response type.  A Retail =
Customer requesting a change to the Third Party authorized access would =
be redirected to an AS endpoint that would allow the Retail Customer to =
either terminate a relationship completely or modify the existing Third =
Party access authorization.  The successful response from the AS =
would indicate the Third Party needs to remove the current Token from =
its Token store.  In the event the Retail Customer has changed the =
Third Party access authorization, the AS response could include an =
optional =E2=80=9Cscope=E2=80=9D element, which the Third Party would =
then use to obtain a new access token utilizing an Authorization Code =
request.

There are =
several other potential implementations that could be developed to =
protect a Retail Customer from a =E2=80=9Crogue=E2=80=9D Third Party =
application that does not inform the AS their authorization to access a =
Retail Customer=E2=80=99s protected data has been revoked, but the above =
suggestion meets the current draft=E2=80=99s view that Third Parties =
should be able to request Tokens be revoked.

I look forward =
to your comments on the above topic.

Best =
regards,
Don
Donald F. Coffin
Founder/CTO

REMI =
Networks
22751 El Prado Suite =
6216
Rancho Santa Margarita, CA  =
92688-3836

Phone:      (949) =
636-8571
Email:       donald.coffin@reminetworks=
.com

------=_NextPart_000_0050_01CE1006.FB5BAAE0--

From jricher@mitre.org  Thu Feb 21 08:03:01 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B2521F8EB3 for ; Thu, 21 Feb 2013 08:02:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.575
X-Spam-Level: 
X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.023,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHLAMZhsljq3 for ; Thu, 21 Feb 2013 08:02:52 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 149A621F8EB6 for ; Thu, 21 Feb 2013 08:02:52 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7C0DB1F1296; Thu, 21 Feb 2013 11:02:51 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 587621F1273; Thu, 21 Feb 2013 11:02:51 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 21 Feb 2013 11:02:50 -0500
Message-ID: <512644F5.9090505@mitre.org>
Date: Thu, 21 Feb 2013 11:01:57 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Donald F Coffin 
References: <013601ce0fc7$b2faea20$18f0be60$@reminetworks.com>  <004f01ce104a$097c79e0$1c756da0$@reminetworks.com>
In-Reply-To: <004f01ce104a$097c79e0$1c756da0$@reminetworks.com>
Content-Type: multipart/alternative; boundary="------------000200060200010804070508"
X-Originating-IP: [129.83.31.58]
Cc: 'John Adkins' , 'Marty Burns' , 'Scott Crowder' , 'Dave Robin' , 'John Teeter' , pmadsen@pingidentity.com, 'Edward Denson' , oauth@ietf.org, 'Jay Mitra' , 'Ray Perlner' , 'Anne Hendry' , 'Lynne Rodoni' , 'Uday Verma' 
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-05 Questions
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Feb 2013 16:03:01 -0000

--------------000200060200010804070508
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

OAuth doesn't get into the business of what the UI for managing grants 
is like. Having the user, admin, or resource owner revoke, downscope, or 
otherwise alter a grant needs to happen with user interactions that are 
going to be different depending on the provider and use case.

  -- Justin

On 02/21/2013 10:42 AM, Donald F Coffin wrote:
>
> Torsten,
>
> Thanks for the response.  What is the "respective portal belonging to 
> the AS"?  I haven't seen anything in the OAuth 2.0 Authorization 
> Framework that describes a "portal" on the AS a Resource Owner can log 
> into to view a valid list of authorization grants.  Is this an 
> out-of-band implementation suggestion?
>
> Best regards,
>
> Don
>
> Donald F. Coffin
>
> Founder/CTO
>
> REMI Networks
>
> 22751 El Prado Suite 6216
>
> Rancho Santa Margarita, CA  92688-3836
>
> Phone: (949) 636-8571
>
> Email: donald.coffin@reminetworks.com 
> 
>
> *From:*Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
> *Sent:* Thursday, February 21, 2013 12:13 AM
> *To:* Donald F Coffin
> *Cc:* ; Anne Hendry; Dave Robin; Edward Denson; Jay 
> Mitra; John Adkins; John Teeter; Lynne Rodoni; Marty Burns; 
> ; Ray Perlner; Scott Crowder; Uday Verma
> *Subject:* Re: draft-ietf-oauth-revocation-05 Questions
>
> Hi Donald,
>
> thank you for sharing your thoughts with us. I've never seen 
> revocation as change of scope of the authorization, but it sounds 
> reasonable. The current design handles the issues you raised differently.
>
> The AS is involved in the revocation process as it exposes the 
> revocation endpoint. So if the token is revoked (from a technical 
> perspective), it knows it. If the user wants to check whether the 
> application really sent the request, she is supposed to visit the 
> respective portal belonging to the AS. There the AS provides a list of 
> all valid authorization grants in its database.
>
> Does this address your issues?
>
> regards,
>
> Torsten.
>
>
> Am 21.02.2013 um 01:09 schrieb "Donald F Coffin" 
> >:
>
>     Torsten,
>
>     A colleague of mine and I were discussing what should occur when a
>     Retail Customer desires to change the existing authorized access
>     of a Third Party.  During our discussion they asked "How does the
>     Retail Customer know the Third Party actually issued a Token
>     revocation request?  Isn't there a potential trust issue with the
>     current design"?
>
>     The current draft provides a Third Party mechanism that "allows a
>     client to invalidate its tokens if the end-user logs out, changes
>     identity, or uninstalls the respective application (sic)." While
>     none of these fit the situation we were discussing they do seem to
>     be based on the assumption a Third Party application will be a
>     good citizen and stop using access tokens. Unfortunately, none of
>     the addressed situations require the participation of a AS for
>     completion, therefore the risk exists that a Retail Customer may
>     believe they have removed a Third Party application from accessing
>     their protected data, but in reality there does not seem to be a
>     mechanism to either force or verify the Third Party can no longer
>     have access to the protected data.
>
>     A possible modification to the current draft that would correct
>     this potential security risk, is to treat a Token revocation using
>     a message flow similar to the existing authorization_code response
>     type.  A Retail Customer requesting a change to the Third Party
>     authorized access would be redirected to an AS endpoint that would
>     allow the Retail Customer to either terminate a relationship
>     completely or modify the existing Third Party access
>     authorization.  The successful response from the AS would indicate
>     the Third Party needs to remove the current Token from its Token
>     store.  In the event the Retail Customer has changed the Third
>     Party access authorization, the AS response could include an
>     optional "scope" element, which the Third Party would then use to
>     obtain a new access token utilizing an Authorization Code request.
>
>     There are several other potential implementations that could be
>     developed to protect a Retail Customer from a "rogue" Third Party
>     application that does not inform the AS their authorization to
>     access a Retail Customer's protected data has been revoked, but
>     the above suggestion meets the current draft's view that Third
>     Parties should be able to request Tokens be revoked.
>
>     I look forward to your comments on the above topic.
>
>     Best regards,
>
>     Don
>
>     Donald F. Coffin
>
>     Founder/CTO
>
>     REMI Networks
>
>     22751 El Prado Suite 6216
>
>     Rancho Santa Margarita, CA  92688-3836
>
>     Phone: (949) 636-8571
>
>     Email: donald.coffin@reminetworks.com
>     
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--------------000200060200010804070508
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

    OAuth doesn't get into the business of what the UI for managing
    grants is like. Having the user, admin, or resource owner revoke,
    downscope, or otherwise alter a grant needs to happen with user
    interactions that are going to be different depending on the
    provider and use case. 

     -- Justin

    On 02/21/2013 10:42 AM, Donald F Coffin
      wrote:

        Torsten,

        Thanks
            for the response.  What is the “respective portal belonging
            to the AS”?  I haven’t seen anything in the OAuth 2.0
            Authorization Framework that describes a “portal” on the AS
            a Resource Owner can log into to view a valid list of
            authorization grants.  Is this an out-of-band implementation
            suggestion?

          Best
              regards,
          Don
          Donald F.
              Coffin
          Founder/CTO

          REMI
              Networks
          22751 El
              Prado Suite 6216
          Rancho
              Santa Margarita, CA  92688-3836

          Phone:     
              (949) 636-8571
          Email:      
              donald.coffin@reminetworks.com

            From:
                Torsten Lodderstedt [mailto:torsten@lodderstedt.net] 

                Sent: Thursday, February 21, 2013 12:13 AM

                To: Donald F Coffin

                Cc: <oauth@ietf.org>; Anne Hendry; Dave
                Robin; Edward Denson; Jay Mitra; John Adkins; John
                Teeter; Lynne Rodoni; Marty Burns;
                <pmadsen@pingidentity.com>; Ray Perlner; Scott
                Crowder; Uday Verma

                Subject: Re: draft-ietf-oauth-revocation-05
                Questions

          Hi Donald,

          thank you for sharing your thoughts with
            us. I've never seen revocation as change of scope of the
            authorization, but it sounds reasonable. The current design
            handles the issues you raised differently.

          The AS is involved in the revocation
            process as it exposes the revocation endpoint. So if the
            token is revoked (from a technical perspective), it knows
            it. If the user wants to check whether the application
            really sent the request, she is supposed to visit the
            respective portal belonging to the AS. There the AS provides
            a list of all valid authorization grants in its database. 

          Does this address your issues?

          regards,

          Torsten.

            Am 21.02.2013 um 01:09 schrieb "Donald F Coffin" <donald.coffin@reminetworks.com>:

            Torsten,

            A
                colleague of mine and I were discussing what should
                occur when a Retail Customer desires to change the
                existing authorized access of a Third Party.  During our
                discussion they asked “How does the Retail Customer know
                the Third Party actually issued a Token revocation
                request?  Isn’t there a potential trust issue with the
                current design”? 

            The
                current draft provides a Third Party mechanism that
                “allows a client to invalidate its tokens if the
                end-user logs out, changes identity, or uninstalls the
                respective application (sic).” While none of these fit
                the situation we were discussing they do seem to be
                based on the assumption a Third Party application will
                be a good citizen and stop using access tokens. 
                Unfortunately, none of the addressed situations require
                the participation of a AS for completion, therefore the
                risk exists that a Retail Customer may believe they have
                removed a Third Party application from accessing their
                protected data, but in reality there does not seem to be
                a mechanism to either force or verify the Third Party
                can no longer have access to the protected data.

            A
                possible modification to the current draft that would
                correct this potential security risk, is to treat a
                Token revocation using a message flow similar to the
                existing authorization_code response type.  A Retail
                Customer requesting a change to the Third Party
                authorized access would be redirected to an AS endpoint
                that would allow the Retail Customer to either terminate
                a relationship completely or modify the existing Third
                Party access authorization.  The successful response
                from the AS would indicate the Third Party needs to
                remove the current Token from its Token store.  In the
                event the Retail Customer has changed the Third Party
                access authorization, the AS response could include an
                optional “scope” element, which the Third Party would
                then use to obtain a new access token utilizing an
                Authorization Code request.

            There
                are several other potential implementations that could
                be developed to protect a Retail Customer from a “rogue”
                Third Party application that does not inform the AS
                their authorization to access a Retail Customer’s
                protected data has been revoked, but the above
                suggestion meets the current draft’s view that Third
                Parties should be able to request Tokens be revoked.

            I
                look forward to your comments on the above topic.

            Best
                regards,
            Don
            Donald
                F. Coffin
            Founder/CTO

            REMI
                Networks
            22751 El
                Prado Suite 6216
            Rancho
                Santa Margarita, CA  92688-3836

            Phone:     
                (949) 636-8571
            Email:      
                donald.coffin@reminetworks.com

      _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------000200060200010804070508--

From donald.coffin@reminetworks.com  Thu Feb 21 08:23:38 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5AE21F84D5 for ; Thu, 21 Feb 2013 08:23:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.062
X-Spam-Level: 
X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[AWL=0.202,  BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vowAGXFaSeKD for ; Thu, 21 Feb 2013 08:23:34 -0800 (PST)
Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 30E2621F87C5 for ; Thu, 21 Feb 2013 08:23:32 -0800 (PST)
Received: (qmail 21672 invoked by uid 0); 21 Feb 2013 16:23:06 -0000
Received: from unknown (HELO host125.hostmonster.com) (74.220.207.125) by cpoproxy3.bluehost.com with SMTP; 21 Feb 2013 16:23:06 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default;  h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=qJh/X6q4xj8CYZPowmD8Ime0PMIqQtZQFAPM1saFGiE=;  b=aYb68gzfuFX8fXBZOw8/KG22Yx0vgcmMjtMYAOsBSMZkGH0ePJu/mPSQNOY0NLO3zS7S5uS8xlSYDef7KEUEE396MKrMfb00CbwUF+MVvPRRxudTQoz9PUu7TfMTeQJE;
Received: from [68.4.207.246] (port=1271 helo=HPPavilionElite) by host125.hostmonster.com with esmtpa (Exim 4.80) (envelope-from ) id 1U8YvJ-0008Fr-LS; Thu, 21 Feb 2013 09:23:05 -0700
From: "Donald F Coffin" 
To: "'Justin Richer'" 
References: <013601ce0fc7$b2faea20$18f0be60$@reminetworks.com>  <004f01ce104a$097c79e0$1c756da0$@reminetworks.com> <512644F5.9090505@mitre.org>
In-Reply-To: <512644F5.9090505@mitre.org>
Date: Thu, 21 Feb 2013 08:21:27 -0800
Message-ID: <006201ce104f$809df760$81d9e620$@reminetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0063_01CE100C.727F7250"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJjjcb25qbAdii4kOnGObWIAqRIYwHsW6RdAjUcDecCseN0aJci50dQ
Content-Language: en-us
X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.4.207.246 authed with donald.coffin@reminetworks.com}
Cc: 'John Adkins' , 'Marty Burns' , 'Scott Crowder' , 'Dave Robin' , 'John Teeter' , pmadsen@pingidentity.com, 'Edward Denson' , oauth@ietf.org, 'Jay Mitra' , 'Ray Perlner' , 'Anne Hendry' , 'Lynne Rodoni' , 'Uday Verma' 
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-05 Questions
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Feb 2013 16:23:38 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0063_01CE100C.727F7250
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Justin,

My response was not meant to ask the UI of the "respective portal belonging
to the AS".  The question was where in the various OAuth 2.0 Authorization
Framework is such a portal even discussed?  Clearly if it is NOT discussed
in any existing OAuth 2.0 Authorization Framework RFC or existing draft,
then it must be an out-of-band customized implementation.

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

Phone:      (949) 636-8571

Email:        
donald.coffin@reminetworks.com

From: Justin Richer [mailto:jricher@mitre.org] 
Sent: Thursday, February 21, 2013 8:02 AM
To: Donald F Coffin
Cc: 'Torsten Lodderstedt'; 'John Adkins'; 'Marty Burns'; 'Scott Crowder';
'Dave Robin'; 'John Teeter'; pmadsen@pingidentity.com; 'Edward Denson'; 'Jay
Mitra'; 'Uday Verma'; 'Ray Perlner'; 'Anne Hendry'; 'Lynne Rodoni';
oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-05 Questions

OAuth doesn't get into the business of what the UI for managing grants is
like. Having the user, admin, or resource owner revoke, downscope, or
otherwise alter a grant needs to happen with user interactions that are
going to be different depending on the provider and use case. 

 -- Justin

On 02/21/2013 10:42 AM, Donald F Coffin wrote:

Torsten,

Thanks for the response.  What is the "respective portal belonging to the
AS"?  I haven't seen anything in the OAuth 2.0 Authorization Framework that
describes a "portal" on the AS a Resource Owner can log into to view a valid
list of authorization grants.  Is this an out-of-band implementation
suggestion?

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

Phone:      (949) 636-8571

Email:       donald.coffin@reminetworks.com

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] 
Sent: Thursday, February 21, 2013 12:13 AM
To: Donald F Coffin
Cc:   ; Anne Hendry; Dave Robin;
Edward Denson; Jay Mitra; John Adkins; John Teeter; Lynne Rodoni; Marty
Burns;   ; Ray
Perlner; Scott Crowder; Uday Verma
Subject: Re: draft-ietf-oauth-revocation-05 Questions

Hi Donald,

thank you for sharing your thoughts with us. I've never seen revocation as
change of scope of the authorization, but it sounds reasonable. The current
design handles the issues you raised differently.

The AS is involved in the revocation process as it exposes the revocation
endpoint. So if the token is revoked (from a technical perspective), it
knows it. If the user wants to check whether the application really sent the
request, she is supposed to visit the respective portal belonging to the AS.
There the AS provides a list of all valid authorization grants in its
database. 

Does this address your issues?

regards,

Torsten.

Am 21.02.2013 um 01:09 schrieb "Donald F Coffin"
:

Torsten,

A colleague of mine and I were discussing what should occur when a Retail
Customer desires to change the existing authorized access of a Third Party.
During our discussion they asked "How does the Retail Customer know the
Third Party actually issued a Token revocation request?  Isn't there a
potential trust issue with the current design"? 

The current draft provides a Third Party mechanism that "allows a client to
invalidate its tokens if the end-user logs out, changes identity, or
uninstalls the respective application (sic)." While none of these fit the
situation we were discussing they do seem to be based on the assumption a
Third Party application will be a good citizen and stop using access tokens.
Unfortunately, none of the addressed situations require the participation of
a AS for completion, therefore the risk exists that a Retail Customer may
believe they have removed a Third Party application from accessing their
protected data, but in reality there does not seem to be a mechanism to
either force or verify the Third Party can no longer have access to the
protected data.

A possible modification to the current draft that would correct this
potential security risk, is to treat a Token revocation using a message flow
similar to the existing authorization_code response type.  A Retail Customer
requesting a change to the Third Party authorized access would be redirected
to an AS endpoint that would allow the Retail Customer to either terminate a
relationship completely or modify the existing Third Party access
authorization.  The successful response from the AS would indicate the Third
Party needs to remove the current Token from its Token store.  In the event
the Retail Customer has changed the Third Party access authorization, the AS
response could include an optional "scope" element, which the Third Party
would then use to obtain a new access token utilizing an Authorization Code
request.

There are several other potential implementations that could be developed to
protect a Retail Customer from a "rogue" Third Party application that does
not inform the AS their authorization to access a Retail Customer's
protected data has been revoked, but the above suggestion meets the current
draft's view that Third Parties should be able to request Tokens be revoked.

I look forward to your comments on the above topic.

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

Phone:      (949) 636-8571

Email:       donald.coffin@reminetworks.com

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

------=_NextPart_000_0063_01CE100C.727F7250
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Justin,

My response was not meant to ask the UI of the “respective portal =
belonging to the AS”.  The question was where in the various =
OAuth 2.0 Authorization Framework is such a portal even discussed?  =
Clearly if it is NOT discussed in any existing OAuth 2.0 Authorization =
Framework RFC or existing draft, then it must be an out-of-band =
customized implementation.

Best =
regards,
Don
Donald F. =
Coffin
Founder/CTO=
 <=
p class=3DMsoNormal>REMI =
Networks
22751 El Prado Suite =
6216
Rancho Santa Margarita, =
CA  92688-3836
 <=
p class=3DMsoNormal>Phone:    =
;  (949) 636-8571
Email:    =
;   donald.coffin@reminetworks.com=

From: Justin Richer [mailto:jricher@mitre.org] 
Sent: =
Thursday, February 21, 2013 8:02 AM
To: Donald F =
Coffin
Cc: 'Torsten Lodderstedt'; 'John Adkins'; 'Marty =
Burns'; 'Scott Crowder'; 'Dave Robin'; 'John Teeter'; =
pmadsen@pingidentity.com; 'Edward Denson'; 'Jay Mitra'; 'Uday Verma'; =
'Ray Perlner'; 'Anne Hendry'; 'Lynne Rodoni'; =
oauth@ietf.org
Subject: Re: [OAUTH-WG] =
draft-ietf-oauth-revocation-05 =
Questions

OAuth doesn't get into the business of =
what the UI for managing grants is like. Having the user, admin, or =
resource owner revoke, downscope, or otherwise alter a grant needs to =
happen with user interactions that are going to be different depending =
on the provider and use case. 

 -- =
Justin
On 02/21/2013 10:42 AM, =
Donald F Coffin wrote:
Torsten,<=
o:p>

Thanks for the =
response.  What is the “respective portal belonging to the =
AS”?  I haven’t seen anything in the OAuth 2.0 =
Authorization Framework that describes a “portal” on the AS =
a Resource Owner can log into to view a valid list of authorization =
grants.  Is this an out-of-band implementation =
suggestion?

Best regards,
Don
Donald F. Coffin
Founder/CTO

REMI =
Networks
22751 El Prado Suite =
6216
Rancho Santa Margarita, CA  =
92688-3836

Phone:      (949) =
636-8571
Email:       donald.coffin@reminetworks=
.com

From:=
 =
Torsten Lodderstedt [mailto:torsten@lodderstedt.net] 
Sent: Thursday, February 21, 2013 12:13 AM
To: =
Donald F Coffin
Cc: <oauth@ietf.org>; Anne Hendry; =
Dave Robin; Edward Denson; Jay Mitra; John Adkins; John Teeter; Lynne =
Rodoni; Marty Burns; <pmadsen@pingidentity.com>=
; Ray Perlner; Scott Crowder; Uday Verma
Subject: Re: =
draft-ietf-oauth-revocation-05 =
Questions

Hi =
Donald,

thank you for sharing your thoughts with us. I've =
never seen revocation as change of scope of the authorization, but it =
sounds reasonable. The current design handles the issues you raised =
differently.

The AS is involved in the revocation process as it =
exposes the revocation endpoint. So if the token is revoked (from a =
technical perspective), it knows it. If the user wants to check whether =
the application really sent the request, she is supposed to visit the =
respective portal belonging to the AS. There the AS provides a list of =
all valid authorization grants in its =
database. 

Does this address your =
issues?

regards,
Torsten.

Am 21.02.2013 um 01:09 schrieb =
"Donald F Coffin" <donald.coffin@reminetworks=
.com>:
Torsten,<=
o:p>

A colleague of =
mine and I were discussing what should occur when a Retail Customer =
desires to change the existing authorized access of a Third Party.  =
During our discussion they asked “How does the Retail Customer =
know the Third Party actually issued a Token revocation request?  =
Isn’t there a potential trust issue with the current =
design”? 

The current =
draft provides a Third Party mechanism that “allows a client to =
invalidate its tokens if the end-user logs out, changes identity, or =
uninstalls the respective application (sic).” While none of these =
fit the situation we were discussing they do seem to be based on the =
assumption a Third Party application will be a good citizen and stop =
using access tokens.  Unfortunately, none of the addressed =
situations require the participation of a AS for completion, therefore =
the risk exists that a Retail Customer may believe they have removed a =
Third Party application from accessing their protected data, but in =
reality there does not seem to be a mechanism to either force or verify =
the Third Party can no longer have access to the protected =
data.

A possible =
modification to the current draft that would correct this potential =
security risk, is to treat a Token revocation using a message flow =
similar to the existing authorization_code response type.  A Retail =
Customer requesting a change to the Third Party authorized access would =
be redirected to an AS endpoint that would allow the Retail Customer to =
either terminate a relationship completely or modify the existing Third =
Party access authorization.  The successful response from the AS =
would indicate the Third Party needs to remove the current Token from =
its Token store.  In the event the Retail Customer has changed the =
Third Party access authorization, the AS response could include an =
optional “scope” element, which the Third Party would then =
use to obtain a new access token utilizing an Authorization Code =
request.

There are =
several other potential implementations that could be developed to =
protect a Retail Customer from a “rogue” Third Party =
application that does not inform the AS their authorization to access a =
Retail Customer’s protected data has been revoked, but the above =
suggestion meets the current draft’s view that Third Parties =
should be able to request Tokens be revoked.

I look forward =
to your comments on the above topic.

Best =
regards,
Don
Donald F. Coffin
Founder/CTO

REMI =
Networks
22751 El Prado Suite =
6216
Rancho Santa Margarita, CA  =
92688-3836

Phone:      (949) =
636-8571
Email:       donald.coffin@reminetworks=
.com

__________________=
_____________________________
OAuth mailing =
list
OAuth@ietf.org
https://www.ietf.org=
/mailman/listinfo/oauth

------=_NextPart_000_0063_01CE100C.727F7250--

From jricher@mitre.org  Thu Feb 21 08:41:16 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D28521F8EA5 for ; Thu, 21 Feb 2013 08:41:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.575
X-Spam-Level: 
X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.023,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ndy1oLDKBSq for ; Thu, 21 Feb 2013 08:41:13 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 24EE021F8E97 for ; Thu, 21 Feb 2013 08:41:13 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5B6151F2C3F; Thu, 21 Feb 2013 11:41:12 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 281764390239; Thu, 21 Feb 2013 11:41:09 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 21 Feb 2013 11:41:03 -0500
Message-ID: <51264DEA.6080808@mitre.org>
Date: Thu, 21 Feb 2013 11:40:10 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Donald F Coffin 
References: <013601ce0fc7$b2faea20$18f0be60$@reminetworks.com>  <004f01ce104a$097c79e0$1c756da0$@reminetworks.com> <512644F5.9090505@mitre.org> <006201ce104f$809df760$81d9e620$@reminetworks.com>
In-Reply-To: <006201ce104f$809df760$81d9e620$@reminetworks.com>
Content-Type: multipart/alternative; boundary="------------060401020109030309010204"
X-Originating-IP: [129.83.31.58]
Cc: 'John Adkins' , 'Marty Burns' , 'Scott Crowder' , 'Dave Robin' , 'John Teeter' , pmadsen@pingidentity.com, 'Edward Denson' , oauth@ietf.org, 'Jay Mitra' , 'Ray Perlner' , 'Anne Hendry' , 'Lynne Rodoni' , 'Uday Verma' 
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-05 Questions
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Feb 2013 16:41:16 -0000

--------------060401020109030309010204
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Yes, that's correct, the actions you've described and the "portal/UI" 
components are of band as far as the OAuth 2 protocol is concerned. In 
fact, you don't *have* to have anything of the sort, though many 
deployments and implementations do have it in some fashion.

To bring it back to the original question: the token revocation endpoint 
is meant to service well-meaning clients who want to clean up any tokens 
they have in the wild. It's not meant for something end-users or 
resource owners would be dealing with directly.

  -- Justin

On 02/21/2013 11:21 AM, Donald F Coffin wrote:
>
> Justin,
>
> My response was not meant to ask the UI of the "respective portal 
> belonging to the AS".  The question was where in the various OAuth 2.0 
> Authorization Framework is such a portal even discussed?  Clearly if 
> it is NOT discussed in any existing OAuth 2.0 Authorization Framework 
> RFC or existing draft, then it must be an out-of-band customized 
> implementation.
>
> Best regards,
>
> Don
>
> Donald F. Coffin
>
> Founder/CTO
>
> REMI Networks
>
> 22751 El Prado Suite 6216
>
> Rancho Santa Margarita, CA  92688-3836
>
> Phone: (949) 636-8571
>
> Email: donald.coffin@reminetworks.com 
> 
>
> *From:*Justin Richer [mailto:jricher@mitre.org]
> *Sent:* Thursday, February 21, 2013 8:02 AM
> *To:* Donald F Coffin
> *Cc:* 'Torsten Lodderstedt'; 'John Adkins'; 'Marty Burns'; 'Scott 
> Crowder'; 'Dave Robin'; 'John Teeter'; pmadsen@pingidentity.com; 
> 'Edward Denson'; 'Jay Mitra'; 'Uday Verma'; 'Ray Perlner'; 'Anne 
> Hendry'; 'Lynne Rodoni'; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] draft-ietf-oauth-revocation-05 Questions
>
> OAuth doesn't get into the business of what the UI for managing grants 
> is like. Having the user, admin, or resource owner revoke, downscope, 
> or otherwise alter a grant needs to happen with user interactions that 
> are going to be different depending on the provider and use case.
>
>  -- Justin
>
> On 02/21/2013 10:42 AM, Donald F Coffin wrote:
>
>     Torsten,
>
>     Thanks for the response.  What is the "respective portal belonging
>     to the AS"?  I haven't seen anything in the OAuth 2.0
>     Authorization Framework that describes a "portal" on the AS a
>     Resource Owner can log into to view a valid list of authorization
>     grants.  Is this an out-of-band implementation suggestion?
>
>     Best regards,
>
>     Don
>
>     Donald F. Coffin
>
>     Founder/CTO
>
>     REMI Networks
>
>     22751 El Prado Suite 6216
>
>     Rancho Santa Margarita, CA  92688-3836
>
>     Phone: (949) 636-8571
>
>     Email: donald.coffin@reminetworks.com
>     
>
>     *From:*Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
>     *Sent:* Thursday, February 21, 2013 12:13 AM
>     *To:* Donald F Coffin
>     *Cc:*  ; Anne Hendry; Dave
>     Robin; Edward Denson; Jay Mitra; John Adkins; John Teeter; Lynne
>     Rodoni; Marty Burns; 
>     ; Ray Perlner; Scott Crowder;
>     Uday Verma
>     *Subject:* Re: draft-ietf-oauth-revocation-05 Questions
>
>     Hi Donald,
>
>     thank you for sharing your thoughts with us. I've never seen
>     revocation as change of scope of the authorization, but it sounds
>     reasonable. The current design handles the issues you raised
>     differently.
>
>     The AS is involved in the revocation process as it exposes the
>     revocation endpoint. So if the token is revoked (from a technical
>     perspective), it knows it. If the user wants to check whether the
>     application really sent the request, she is supposed to visit the
>     respective portal belonging to the AS. There the AS provides a
>     list of all valid authorization grants in its database.
>
>     Does this address your issues?
>
>     regards,
>
>     Torsten.
>
>
>     Am 21.02.2013 um 01:09 schrieb "Donald F Coffin"
>          >:
>
>         Torsten,
>
>         A colleague of mine and I were discussing what should occur
>         when a Retail Customer desires to change the existing
>         authorized access of a Third Party.  During our discussion
>         they asked "How does the Retail Customer know the Third Party
>         actually issued a Token revocation request?  Isn't there a
>         potential trust issue with the current design"?
>
>         The current draft provides a Third Party mechanism that
>         "allows a client to invalidate its tokens if the end-user logs
>         out, changes identity, or uninstalls the respective
>         application (sic)." While none of these fit the situation we
>         were discussing they do seem to be based on the assumption a
>         Third Party application will be a good citizen and stop using
>         access tokens. Unfortunately, none of the addressed situations
>         require the participation of a AS for completion, therefore
>         the risk exists that a Retail Customer may believe they have
>         removed a Third Party application from accessing their
>         protected data, but in reality there does not seem to be a
>         mechanism to either force or verify the Third Party can no
>         longer have access to the protected data.
>
>         A possible modification to the current draft that would
>         correct this potential security risk, is to treat a Token
>         revocation using a message flow similar to the existing
>         authorization_code response type.  A Retail Customer
>         requesting a change to the Third Party authorized access would
>         be redirected to an AS endpoint that would allow the Retail
>         Customer to either terminate a relationship completely or
>         modify the existing Third Party access authorization.  The
>         successful response from the AS would indicate the Third Party
>         needs to remove the current Token from its Token store.  In
>         the event the Retail Customer has changed the Third Party
>         access authorization, the AS response could include an
>         optional "scope" element, which the Third Party would then use
>         to obtain a new access token utilizing an Authorization Code
>         request.
>
>         There are several other potential implementations that could
>         be developed to protect a Retail Customer from a "rogue" Third
>         Party application that does not inform the AS their
>         authorization to access a Retail Customer's protected data has
>         been revoked, but the above suggestion meets the current
>         draft's view that Third Parties should be able to request
>         Tokens be revoked.
>
>         I look forward to your comments on the above topic.
>
>         Best regards,
>
>         Don
>
>         Donald F. Coffin
>
>         Founder/CTO
>
>         REMI Networks
>
>         22751 El Prado Suite 6216
>
>         Rancho Santa Margarita, CA  92688-3836
>
>         Phone: (949) 636-8571
>
>         Email: donald.coffin@reminetworks.com
>         
>
>
>
>
>     _______________________________________________
>
>     OAuth mailing list
>
>     OAuth@ietf.org  
>
>     https://www.ietf.org/mailman/listinfo/oauth
>

--------------060401020109030309010204
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

    Yes, that's correct, the actions you've described and the
    "portal/UI" components are of band as far as the OAuth 2 protocol is
    concerned. In fact, you don't *have* to have anything of the sort,
    though many deployments and implementations do have it in some
    fashion. 

    To bring it back to the original question: the token revocation
    endpoint is meant to service well-meaning clients who want to clean
    up any tokens they have in the wild. It's not meant for something
    end-users or resource owners would be dealing with directly. 

     -- Justin

    On 02/21/2013 11:21 AM, Donald F Coffin
      wrote:

        Justin,

        My
            response was not meant to ask the UI of the “respective
            portal belonging to the AS”.  The question was where in the
            various OAuth 2.0 Authorization Framework is such a portal
            even discussed?  Clearly if it is NOT discussed in any
            existing OAuth 2.0 Authorization Framework RFC or existing
            draft, then it must be an out-of-band customized
            implementation.

          Best regards,
          Don
          Donald F. Coffin
          Founder/CTO

          REMI Networks
          22751 El Prado
              Suite 6216
          Rancho Santa
              Margarita, CA  92688-3836

          Phone:     
              (949) 636-8571
          Email:       donald.coffin@reminetworks.com

            From:
                Justin Richer [mailto:jricher@mitre.org] 

                Sent: Thursday, February 21, 2013 8:02 AM

                To: Donald F Coffin

                Cc: 'Torsten Lodderstedt'; 'John Adkins'; 'Marty
                Burns'; 'Scott Crowder'; 'Dave Robin'; 'John Teeter';
                pmadsen@pingidentity.com; 'Edward Denson'; 'Jay Mitra';
                'Uday Verma'; 'Ray Perlner'; 'Anne Hendry'; 'Lynne
                Rodoni'; oauth@ietf.org

                Subject: Re: [OAUTH-WG]
                draft-ietf-oauth-revocation-05 Questions

        OAuth doesn't
          get into the business of what the UI for managing grants is
          like. Having the user, admin, or resource owner revoke,
          downscope, or otherwise alter a grant needs to happen with
          user interactions that are going to be different depending on
          the provider and use case. 

           -- Justin

          On 02/21/2013 10:42 AM, Donald F Coffin
            wrote:

          Torsten,

          Thanks
              for the response.  What is the “respective portal
              belonging to the AS”?  I haven’t seen anything in the
              OAuth 2.0 Authorization Framework that describes a
              “portal” on the AS a Resource Owner can log into to view a
              valid list of authorization grants.  Is this an
              out-of-band implementation suggestion?

            Best
                regards,
            Don
            Donald
                F. Coffin
            Founder/CTO

            REMI
                Networks
            22751 El
                Prado Suite 6216
            Rancho
                Santa Margarita, CA  92688-3836

            Phone:     
                (949) 636-8571
            Email:      
                donald.coffin@reminetworks.com

              From:
                  Torsten Lodderstedt [mailto:torsten@lodderstedt.net]

                  Sent: Thursday, February 21, 2013 12:13 AM

                  To: Donald F Coffin

                  Cc: <oauth@ietf.org>;
                  Anne Hendry; Dave Robin; Edward Denson; Jay Mitra;
                  John Adkins; John Teeter; Lynne Rodoni; Marty Burns; <pmadsen@pingidentity.com>;
                  Ray Perlner; Scott Crowder; Uday Verma

                  Subject: Re: draft-ietf-oauth-revocation-05
                  Questions

            Hi Donald,

            thank you for sharing your thoughts
              with us. I've never seen revocation as change of scope of
              the authorization, but it sounds reasonable. The current
              design handles the issues you raised differently.

            The AS is involved in the revocation
              process as it exposes the revocation endpoint. So if the
              token is revoked (from a technical perspective), it knows
              it. If the user wants to check whether the application
              really sent the request, she is supposed to visit the
              respective portal belonging to the AS. There the AS
              provides a list of all valid authorization grants in its
              database. 

            Does this address your issues?

            regards,

            Torsten.

              Am 21.02.2013 um 01:09 schrieb "Donald F Coffin" <donald.coffin@reminetworks.com>:

              Torsten,

              A
                  colleague of mine and I were discussing what should
                  occur when a Retail Customer desires to change the
                  existing authorized access of a Third Party.  During
                  our discussion they asked “How does the Retail
                  Customer know the Third Party actually issued a Token
                  revocation request?  Isn’t there a potential trust
                  issue with the current design”? 

              The
                  current draft provides a Third Party mechanism that
                  “allows a client to invalidate its tokens if the
                  end-user logs out, changes identity, or uninstalls the
                  respective application (sic).” While none of these fit
                  the situation we were discussing they do seem to be
                  based on the assumption a Third Party application will
                  be a good citizen and stop using access tokens. 
                  Unfortunately, none of the addressed situations
                  require the participation of a AS for completion,
                  therefore the risk exists that a Retail Customer may
                  believe they have removed a Third Party application
                  from accessing their protected data, but in reality
                  there does not seem to be a mechanism to either force
                  or verify the Third Party can no longer have access to
                  the protected data.

              A
                  possible modification to the current draft that would
                  correct this potential security risk, is to treat a
                  Token revocation using a message flow similar to the
                  existing authorization_code response type.  A Retail
                  Customer requesting a change to the Third Party
                  authorized access would be redirected to an AS
                  endpoint that would allow the Retail Customer to
                  either terminate a relationship completely or modify
                  the existing Third Party access authorization.  The
                  successful response from the AS would indicate the
                  Third Party needs to remove the current Token from its
                  Token store.  In the event the Retail Customer has
                  changed the Third Party access authorization, the AS
                  response could include an optional “scope” element,
                  which the Third Party would then use to obtain a new
                  access token utilizing an Authorization Code request.

              There
                  are several other potential implementations that could
                  be developed to protect a Retail Customer from a
                  “rogue” Third Party application that does not inform
                  the AS their authorization to access a Retail
                  Customer’s protected data has been revoked, but the
                  above suggestion meets the current draft’s view that
                  Third Parties should be able to request Tokens be
                  revoked.

              I
                  look forward to your comments on the above topic.

              Best
                  regards,
              Don
              Donald
                  F. Coffin
              Founder/CTO

              REMI
                  Networks
              22751
                  El Prado Suite 6216
              Rancho
                  Santa Margarita, CA  92688-3836

              Phone:     
                  (949) 636-8571
              Email:      
                  donald.coffin@reminetworks.com

          _______________________________________________
          OAuth mailing list
          OAuth@ietf.org
          https://www.ietf.org/mailman/listinfo/oauth

--------------060401020109030309010204--

From Michael.Jones@microsoft.com  Thu Feb 21 09:32:13 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6771B21F8EDE for ; Thu, 21 Feb 2013 09:32:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.585
X-Spam-Level: 
X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.013,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tw9sKnsZhzIE for ; Thu, 21 Feb 2013 09:32:08 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.24]) by ietfa.amsl.com (Postfix) with ESMTP id 26C1921F8EC3 for ; Thu, 21 Feb 2013 09:32:08 -0800 (PST)
Received: from BY2FFO11FD010.protection.gbl (10.1.15.204) by BY2FFO11HUB008.protection.gbl (10.1.14.166) with Microsoft SMTP Server (TLS) id 15.0.620.12; Thu, 21 Feb 2013 17:32:04 +0000
Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD010.mail.protection.outlook.com (10.1.14.74) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Thu, 21 Feb 2013 17:32:04 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.96]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Thu, 21 Feb 2013 17:31:22 +0000
From: Mike Jones 
To: Justin Richer 
Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
Thread-Index: AQHOC8cMkbohP5vU0EO7eTLi/U/hMJh7eCuAgAd2gACAAAA6MIAABsiAgAADAoCAAAZKgIAAAIEAgAAGaQCAAAoJgIABUVWAgAA5XrA=
Date: Thu, 21 Feb 2013 17:31:21 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943674800D6@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <20130215215423.23019.50224.idtracker@ietfa.amsl.com>   <4E1F6AAD24975D4BA5B16804296739436747A665@TK5EX14MBXC284.redmond.corp.microsoft.com> <63255CDA-E93F-4414-B471-B373C4B6F65E@ve7jtb.com>   <4E1F6AAD24975D4BA5B16804296739436747AD87@TK5EX14MBXC284.redmond.corp.microsoft.com>  <4E1F6AAD24975D4BA5B16804296739436747B12D@TK5EX14MBXC284.redmond.corp.microsoft.com> <5126297F.7070904@mitre.org>
In-Reply-To: <5126297F.7070904@mitre.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.35]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943674800D6TK5EX14MBXC284r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(69234002)(479174001)(65554002)(377424002)(377454001)(199002)(189002)(69224001)(51704002)(51914002)(24454001)(53806001)(16406001)(16236675001)(4396001)(65816001)(54356001)(47976001)(15202345001)(31966008)(47736001)(56816002)(74662001)(5343635001)(46102001)(33656001)(5343655001)(47446002)(74502001)(80022001)(66066001)(50986001)(55846006)(20776003)(49866001)(63696002)(79102001)(76482001)(56776001)(77982001)(44976002)(512954001)(59766001)(54316002)(51856001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB008; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0764C4A8CD
Cc: "" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Feb 2013 17:32:13 -0000

--_000_4E1F6AAD24975D4BA5B1680429673943674800D6TK5EX14MBXC284r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Yes - per Tim's reference, we'll likely be required to do this at some poin=
t before achieving RFC status, so better to do it now than later.

FYI, OpenID Connect Registration just made these changes, for exactly this =
reason.

                                                            Cheers,
                                                            -- Mike

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Thursday, February 21, 2013 6:05 AM
To: Mike Jones
Cc: Tim Bray; 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

With this in mind, we might want to change *all* of the _url parameters to =
_uri instead, not just this new one. Are folks in favor of this?

 -- Justin
On 02/20/2013 12:57 PM, Mike Jones wrote:
OK, we should make the change then.  Thanks for the input.

                                                            -- Mike

From: Tim Bray [mailto:twbray@google.com]
Sent: Wednesday, February 20, 2013 9:22 AM
To: Mike Jones
Cc: Nat Sakimura; 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

Yes, "URL" is strongly and clearly deprecated in RFC3986 section 1.1.3; one=
 of the reasons is that the distinction between "locator" and "identifier" =
which sounds like it should be easy, turns out to lead to theological bikes=
hed discussions almost inevitably, and in fact be shaky in practice.  -T
On Wed, Feb 20, 2013 at 9:00 AM, Mike Jones > wrote:
Tim, as background, this came from the OpenID Connect specs, where we tried=
 to consistently use the convention that the locator for any resource that =
can be retrieved from the specified location be called a URL, whereas any i=
dentifier that may not be retrievable is called a URI.  That was done as an=
 aid to developer understanding of the specifications.

If the use of "URL" is deprecated by the IETF in favor of always just using=
 "URI", I suppose we could change that, but if it's going to change, it sho=
uld be soon.

                                                            -- Mike

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Nat Sakimura
Sent: Wednesday, February 20, 2013 8:57 AM
To: Tim Bray
Cc: >
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

You are right. I am in the camp recommending the use of URL when it is a co=
ncrete endpoint and URI when it includes something that is only abstract, b=
ut since OAuth standardized on "uri", we may as well do so here.

Nat
2013/2/20 Tim Bray >
In OAuth, we have redirect_uri not redirect_url; should this be registratio=
n_access_uri for consistency? -T

On Wed, Feb 20, 2013 at 8:23 AM, John Bradley > wrote:
I think registration_access_url is OK.    I haven't heard any better names =
yet.

John B.

On 2013-02-20, at 1:04 PM, Mike Jones > wrote:

For what it's worth, the name "registration_access_url" was chosen to be pa=
rallel to "registration_access_token".   It's the place you use the access =
token.  And it's where you access an existing registration.  I'm against th=
e name "client_metadata_url" because it's not metadata you're accessing - i=
t's a registration you're accessing.  For the same reason, I don't think th=
e name "client_info_url" gives people the right idea, because it doesn't sa=
y anything it being the registration that you're accessing.

If you really want us to change this, having read what's above, I could liv=
e with "client_registration_url", but I don't think a change is actually ne=
cessary.  (But if we are going to change it, let's do it ASAP, before the O=
penID Connect Implementer's Drafts are published.)

                                                            -- Mike

From: oauth-bounces@ietf.org [mailto:oauth-<=
mailto:oauth->bounces@ietf.org] On Behalf Of Nat S=
akimura
Sent: Wednesday, February 20, 2013 7:58 AM
To: >; Richer, Justin P.; John Bradle=
y
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt

Thanks Justin.

Even if we go flat rather than doing JSON Structure, the "Client
Registration Access Endpoint" is not a good representative name.

What it represents is the client metadata/info.
It is not representing "Client Registration Access".
What does "Client Registration Access" mean?
Does UPDATing "Cleint Registration Access" make sense?

Something in the line of "Client Metadata Endpoint" and
something like "client_metadata_url" or "client_info_url" is much better.

Nat
2013/2/15 Richer, Justin P. >
Everyone, there's a new draft of DynReg up on the tracker. This draft tries=
 to codify the discussions so far from this week into something we can all =
read. There are still plenty of open discussion points and items up for deb=
ate. Please read through this latest draft and see what's changed and help =
assure that it properly captures the conversations. If you have any inputs =
for the marked [[ Editor's Note ]] sections, please send them to the list b=
y next Thursday to give me opportunity to get any necessary changes in by t=
he cutoff date of Monday the 22nd.

Thanks for all of your hard work everyone, I think this is *really* coming =
along now.

 -- Justin

On Feb 15, 2013, at 4:54 PM, internet-drafts@ietf.org wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
> This draft is a work item of the Web Authorization Protocol Working Group=
 of the IETF.
>
>       Title           : OAuth Dynamic Client Registration Protocol
>       Author(s)       : Justin Richer
>                          John Bradley
>                          Michael B. Jones
>                          Maciej Machulak
>       Filename        : draft-ietf-oauth-dyn-reg-06.txt
>       Pages           : 21
>       Date            : 2013-02-15
>
> Abstract:
>   This specification defines an endpoint and protocol for dynamic
>   registration of OAuth Clients at an Authorization Server.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-06
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> 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

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

_______________________________________________
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

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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

--_000_4E1F6AAD24975D4BA5B1680429673943674800D6TK5EX14MBXC284r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Yes – per Tim’=
;s reference, we’ll likely be required to do this at some point befor=
e achieving RFC status, so better to do it now than later.
 <=
/p>
FYI, OpenID Connect Regis=
tration just made these changes, for exactly this reason.=

 <=
/p>
    &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;     Cheers,
    &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;     -- Mike
 <=
/p>

From: Justin Richer [mailto:jricher@mitre.org]

Sent: Thursday, February 21, 2013 6:05 AM

To: Mike Jones

Cc: Tim Bray; <oauth@ietf.org>

Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt<=
o:p>

With this in mind, we=
 might want to change *all* of the _url parameters to _uri instead, not jus=
t this new one. Are folks in favor of this?

 -- Justin

On 02/20/2013 12:57 PM, Mike Jones wrote:=

OK, we should make the ch=
ange then.  Thanks for the input.
 <=
/p>
    &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;     -- Mike
 <=
/p>
From: Tim Bray=
 [mailto:twbray@google.com]

Sent: Wednesday, February 20, 2013 9:22 AM

To: Mike Jones

Cc: Nat Sakimura; <oauth@ietf.o=
rg>

Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt<=
/span>

Yes, “URL”=
; is strongly and clearly deprecated in RFC3986 section 1.1.3; one of the r=
easons is that the distinction between “locator” and “ide=
ntifier” which sounds like it should be easy, turns out to lead to
 theological bikeshed discussions almost inevitably, and in fact be shaky i=
n practice.  -T

On Wed, Feb 20, 2013 at 9:00 AM, Mike Jones <Michael.Jones@=
microsoft.com> wrote:

Tim, as background, this came from the =
OpenID Connect specs, where we tried to consistently use the
 convention that the locator for any resource that can be retrieved from th=
e specified location be called a URL, whereas any identifier that may not b=
e retrievable is called a URI.  That was done as an aid to developer u=
nderstanding of the specifications.

If the use of “URL” is depr=
ecated by the IETF in favor of always just using “URI”, I suppo=
se we could
 change that, but if it’s going to change, it should be soon.<=
o:p>

      &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;   -- Mike

From:
oauth-bounces@i=
etf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Nat Sakimura

Sent: Wednesday, February 20, 2013 8:57 AM

To: Tim Bray

Cc: <oauth@ie=
tf.org>

Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt<=
/span>

You are right. I am in the camp recommending the use of URL when i=
t is a concrete endpoint and URI when it includes something that is only ab=
stract, but since OAuth standardized
 on "uri", we may as well do so here. 

Nat

2013/2/20 Tim Bray <twbray@google.com>
In OAuth, we have redirect_uri not redirect_url; should this be re=
gistration_access_uri for consistency? -T

On Wed, Feb 20, 2013 at 8:23 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

I think registration_access_url is OK.    I haven't hear=
d any better names yet.

John B.

On 2013-02-20, at 1:04 PM, Mike Jones <Michael.Jones@microsoft.com>=
; wrote:

For what it’s worth, the name =
220;registration_access_url” was chosen to be parallel to “regi=
stration_access_token”.  
 It’s the place you use the access token.  And it’s where =
you access an existing registration.  I’m against the name ̶=
0;client_metadata_url” because it’s not metadata you’re a=
ccessing – it’s a registration you’re accessing.  Fo=
r the same reason, I don’t think
 the name “client_info_url” gives people the right idea, becaus=
e it doesn’t say anything it being the registration that you’re=
 accessing.

If you really want us to change this, h=
aving read what’s above, I could live with “client_registration=
_url”,
 but I don’t think a change is actually necessary.  (But if we a=
re going to change it, let’s do it ASAP, before the OpenID Connect Im=
plementer’s Drafts are published.)

      &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;   -- Mike

From: oauth-bounces@ietf.org
 [mailto:oauth-bounces@ietf.org] On =
Behalf Of Nat Sakimura

Sent: Wednesday, February 20, 2013 7:58 AM

To: <oau=
th@ietf.org>; Richer, Justin P.; John Bradley

Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06=
.txt

Thanks Justin.

Even if we go flat rather than doing JSON Structure, the "Client

Registration Access Endpoint" is not a good representative name.

What it represents is the client metadata/info.

It is not representing "Client Registration Access". =

What does "Client Registration Access" mean? <=
/o:p>

Does UPDATing "Cleint Registration Access&=
quot; make sense?

Something in the line of "Client Metadata Endpoint" and

something like "client_metadata_url" or "client_info_ur=
l" is much better.

Nat

2013/2/15 Richer, Justin P. <jricher@mitre.org<=
/a>>

Everyone, there's a new draft of DynReg up on the tracker. This dr=
aft tries to codify the discussions so far from this week into something we=
 can all read. There are still plenty
 of open discussion points and items up for debate. Please read through thi=
s latest draft and see what's changed and help assure that it properly capt=
ures the conversations. If you have any inputs for the marked [[ Editor's N=
ote ]] sections, please send them
 to the list by next Thursday to give me opportunity to get any necessary c=
hanges in by the cutoff date of Monday the 22nd.

Thanks for all of your hard work everyone, I think this is *really* coming =
along now.

 -- Justin

On Feb 15, 2013, at 4:54 PM, internet-drafts@ietf.org<=
/span> wrote:

>

> A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.

> This draft is a work item of the Web Authorization Protocol Working Gr=
oup of the IETF.

>

>       Title           : OAuth =
Dynamic Client Registration Protocol

>       Author(s)       : Justin Richer
>                     =
     John Bradley

>                     =
     Michael B. Jones

>                     =
     Maciej Machulak

>       Filename        : draft-ietf-=
oauth-dyn-reg-06.txt

>       Pages           : 21

>       Date            : 2=
013-02-15

>

> Abstract:

>   This specification defines an endpoint and protocol for dynamic=

>   registration of OAuth Clients at an Authorization Server.

>

>

> The IETF datatracker status page for this draft is:

> https://datatracker.iet=
f.org/doc/draft-ietf-oauth-dyn-reg

>

> There's also a htmlized version available at:

> http://tools.ietf.org/html=
/draft-ietf-oauth-dyn-reg-06

>

> A diff from the previous version is available at:

> http://www.ietf.or=
g/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-06

>

>

> Internet-Drafts are also available by anonymous FTP at:

> ftp://ftp.ietf.org/internet-drafts/

>

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org

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

_______________________________________________

OAuth mailing list

OAuth@ietf.org

<=
span style=3D"color:purple">https://www.ietf.org/mailman/listinfo/oauth

-- 

Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation

http://nat.sakimura.org/

@_nat_en

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

--

Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation

http://nat.sakimura.=
org/

@_nat_en

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ie=
tf.org/mailman/listinfo/oauth

--_000_4E1F6AAD24975D4BA5B1680429673943674800D6TK5EX14MBXC284r_--

From donald.coffin@reminetworks.com  Thu Feb 21 10:04:16 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6424B21F8EBC for ; Thu, 21 Feb 2013 10:04:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.074
X-Spam-Level: 
X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.190,  BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPO8eibAzZJn for ; Thu, 21 Feb 2013 10:04:11 -0800 (PST)
Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id B301D21F8EA1 for ; Thu, 21 Feb 2013 10:04:11 -0800 (PST)
Received: (qmail 3193 invoked by uid 0); 21 Feb 2013 18:03:50 -0000
Received: from unknown (HELO host125.hostmonster.com) (74.220.207.125) by oproxy13.unifiedlayer.com with SMTP; 21 Feb 2013 18:03:50 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default;  h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=kJA8bRhM2TVYEo7uahjOVulRUOp/PgTxJ/r/jtOjm1Q=;  b=IsH530CIrMYYxAwTpaC4GQzjaUb1255lFXwj68hETdzMfE89so4yy2KzdAFibYjzTXygzXbBKyPXYNSNKiy0XLyL6yWicswIFT9k9VAaz33i8HygyFtTg3JsctwUfe03;
Received: from [68.4.207.246] (port=3146 helo=HPPavilionElite) by host125.hostmonster.com with esmtpa (Exim 4.80) (envelope-from ) id 1U8aUo-0001vC-25; Thu, 21 Feb 2013 11:03:50 -0700
From: "Donald F Coffin" 
To: "'Justin Richer'" 
References: <013601ce0fc7$b2faea20$18f0be60$@reminetworks.com>  <004f01ce104a$097c79e0$1c756da0$@reminetworks.com> <512644F5.9090505@mitre.org> <006201ce104f$809df760$81d9e620$@reminetworks.com> <51264DEA.6080808@mitre.org>
In-Reply-To: <51264DEA.6080808@mitre.org>
Date: Thu, 21 Feb 2013 10:02:12 -0800
Message-ID: <008d01ce105d$935ef580$ba1ce080$@reminetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_008E_01CE101A.853FD430"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJjjcb25qbAdii4kOnGObWIAqRIYwHsW6RdAjUcDecCseN0aAINAa9SAZV6NViXBeGoAA==
Content-Language: en-us
X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 68.4.207.246 authed with donald.coffin@reminetworks.com}
Cc: 'John Adkins' , 'Marty Burns' , 'Scott Crowder' , 'Dave Robin' , 'John Teeter' , pmadsen@pingidentity.com, 'Edward Denson' , oauth@ietf.org, 'Jay Mitra' , 'Ray Perlner' , 'Anne Hendry' , 'Lynne Rodoni' , 'Uday Verma' 
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-05 Questions
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Feb 2013 18:04:16 -0000

This is a multipart message in MIME format.

------=_NextPart_000_008E_01CE101A.853FD430
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Thanks for the clarification.

I was not envisioning the end-user directly referencing the token revocation
endpoint.  The question is how does the end-user know the client did in fact
revoke a token using the token revocation endpoint. 

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

Phone:      (949) 636-8571

Email:        
donald.coffin@reminetworks.com

From: Justin Richer [mailto:jricher@mitre.org] 
Sent: Thursday, February 21, 2013 8:40 AM
To: Donald F Coffin
Cc: 'Torsten Lodderstedt'; 'John Adkins'; 'Marty Burns'; 'Scott Crowder';
'Dave Robin'; 'John Teeter'; pmadsen@pingidentity.com; 'Edward Denson'; 'Jay
Mitra'; 'Uday Verma'; 'Ray Perlner'; 'Anne Hendry'; 'Lynne Rodoni';
oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-05 Questions

Yes, that's correct, the actions you've described and the "portal/UI"
components are of band as far as the OAuth 2 protocol is concerned. In fact,
you don't *have* to have anything of the sort, though many deployments and
implementations do have it in some fashion. 

To bring it back to the original question: the token revocation endpoint is
meant to service well-meaning clients who want to clean up any tokens they
have in the wild. It's not meant for something end-users or resource owners
would be dealing with directly. 

 -- Justin

On 02/21/2013 11:21 AM, Donald F Coffin wrote:

Justin,

My response was not meant to ask the UI of the "respective portal belonging
to the AS".  The question was where in the various OAuth 2.0 Authorization
Framework is such a portal even discussed?  Clearly if it is NOT discussed
in any existing OAuth 2.0 Authorization Framework RFC or existing draft,
then it must be an out-of-band customized implementation.

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

Phone:      (949) 636-8571

Email:       donald.coffin@reminetworks.com

From: Justin Richer [mailto:jricher@mitre.org] 
Sent: Thursday, February 21, 2013 8:02 AM
To: Donald F Coffin
Cc: 'Torsten Lodderstedt'; 'John Adkins'; 'Marty Burns'; 'Scott Crowder';
'Dave Robin'; 'John Teeter'; pmadsen@pingidentity.com; 'Edward Denson'; 'Jay
Mitra'; 'Uday Verma'; 'Ray Perlner'; 'Anne Hendry'; 'Lynne Rodoni';
oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-05 Questions

OAuth doesn't get into the business of what the UI for managing grants is
like. Having the user, admin, or resource owner revoke, downscope, or
otherwise alter a grant needs to happen with user interactions that are
going to be different depending on the provider and use case. 

 -- Justin

On 02/21/2013 10:42 AM, Donald F Coffin wrote:

Torsten,

Thanks for the response.  What is the "respective portal belonging to the
AS"?  I haven't seen anything in the OAuth 2.0 Authorization Framework that
describes a "portal" on the AS a Resource Owner can log into to view a valid
list of authorization grants.  Is this an out-of-band implementation
suggestion?

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

Phone:      (949) 636-8571

Email:       donald.coffin@reminetworks.com

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] 
Sent: Thursday, February 21, 2013 12:13 AM
To: Donald F Coffin
Cc:   ; Anne Hendry; Dave Robin;
Edward Denson; Jay Mitra; John Adkins; John Teeter; Lynne Rodoni; Marty
Burns;   ; Ray
Perlner; Scott Crowder; Uday Verma
Subject: Re: draft-ietf-oauth-revocation-05 Questions

Hi Donald,

thank you for sharing your thoughts with us. I've never seen revocation as
change of scope of the authorization, but it sounds reasonable. The current
design handles the issues you raised differently.

The AS is involved in the revocation process as it exposes the revocation
endpoint. So if the token is revoked (from a technical perspective), it
knows it. If the user wants to check whether the application really sent the
request, she is supposed to visit the respective portal belonging to the AS.
There the AS provides a list of all valid authorization grants in its
database. 

Does this address your issues?

regards,

Torsten.

Am 21.02.2013 um 01:09 schrieb "Donald F Coffin"
:

Torsten,

A colleague of mine and I were discussing what should occur when a Retail
Customer desires to change the existing authorized access of a Third Party.
During our discussion they asked "How does the Retail Customer know the
Third Party actually issued a Token revocation request?  Isn't there a
potential trust issue with the current design"? 

The current draft provides a Third Party mechanism that "allows a client to
invalidate its tokens if the end-user logs out, changes identity, or
uninstalls the respective application (sic)." While none of these fit the
situation we were discussing they do seem to be based on the assumption a
Third Party application will be a good citizen and stop using access tokens.
Unfortunately, none of the addressed situations require the participation of
a AS for completion, therefore the risk exists that a Retail Customer may
believe they have removed a Third Party application from accessing their
protected data, but in reality there does not seem to be a mechanism to
either force or verify the Third Party can no longer have access to the
protected data.

A possible modification to the current draft that would correct this
potential security risk, is to treat a Token revocation using a message flow
similar to the existing authorization_code response type.  A Retail Customer
requesting a change to the Third Party authorized access would be redirected
to an AS endpoint that would allow the Retail Customer to either terminate a
relationship completely or modify the existing Third Party access
authorization.  The successful response from the AS would indicate the Third
Party needs to remove the current Token from its Token store.  In the event
the Retail Customer has changed the Third Party access authorization, the AS
response could include an optional "scope" element, which the Third Party
would then use to obtain a new access token utilizing an Authorization Code
request.

There are several other potential implementations that could be developed to
protect a Retail Customer from a "rogue" Third Party application that does
not inform the AS their authorization to access a Retail Customer's
protected data has been revoked, but the above suggestion meets the current
draft's view that Third Parties should be able to request Tokens be revoked.

I look forward to your comments on the above topic.

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

Phone:      (949) 636-8571

Email:       donald.coffin@reminetworks.com

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

------=_NextPart_000_008E_01CE101A.853FD430
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thanks for the clarification.

I was not envisioning the end-user directly referencing the token =
revocation endpoint.  The question is how does the end-user know =
the client did in fact revoke a token using the token revocation =
endpoint. 

Best =
regards,
Don
Donald F. =
Coffin
Founder/CTO=
 <=
p class=3DMsoNormal>REMI =
Networks
22751 El Prado Suite =
6216
Rancho Santa Margarita, =
CA  92688-3836
 <=
p class=3DMsoNormal>Phone:    =
;  (949) 636-8571
Email:    =
;   donald.coffin@reminetworks.com=

From: Justin Richer [mailto:jricher@mitre.org] 
Sent: =
Thursday, February 21, 2013 8:40 AM
To: Donald F =
Coffin
Cc: 'Torsten Lodderstedt'; 'John Adkins'; 'Marty =
Burns'; 'Scott Crowder'; 'Dave Robin'; 'John Teeter'; =
pmadsen@pingidentity.com; 'Edward Denson'; 'Jay Mitra'; 'Uday Verma'; =
'Ray Perlner'; 'Anne Hendry'; 'Lynne Rodoni'; =
oauth@ietf.org
Subject: Re: [OAUTH-WG] =
draft-ietf-oauth-revocation-05 =
Questions

Yes, that's correct, the actions you've =
described and the "portal/UI" components are of band as far as =
the OAuth 2 protocol is concerned. In fact, you don't *have* to have =
anything of the sort, though many deployments and implementations do =
have it in some fashion. 

To bring it back to the original =
question: the token revocation endpoint is meant to service well-meaning =
clients who want to clean up any tokens they have in the wild. It's not =
meant for something end-users or resource owners would be dealing with =
directly. 

 -- Justin
On 02/21/2013 11:21 AM, Donald F Coffin =
wrote:
Justin,

My response was not meant to ask the UI of the “respective portal =
belonging to the AS”.  The question was where in the various =
OAuth 2.0 Authorization Framework is such a portal even discussed?  =
Clearly if it is NOT discussed in any existing OAuth 2.0 Authorization =
Framework RFC or existing draft, then it must be an out-of-band =
customized implementation.

Best =
regards,
Don
Donald F. =
Coffin
Founder/CTO=
 <=
p class=3DMsoNormal>REMI =
Networks
22751 El Prado Suite =
6216
Rancho Santa Margarita, =
CA  92688-3836
 <=
p class=3DMsoNormal>Phone:    =
;  (949) 636-8571
Email:    =
;   donald.coffin@reminetworks=
.com

From: Justin Richer [mailto:jricher@mitre.org] =

Sent: Thursday, February 21, 2013 8:02 AM
To: =
Donald F Coffin
Cc: 'Torsten Lodderstedt'; 'John Adkins'; =
'Marty Burns'; 'Scott Crowder'; 'Dave Robin'; 'John Teeter'; pmadsen@pingidentity.com; =
'Edward Denson'; 'Jay Mitra'; 'Uday Verma'; 'Ray Perlner'; 'Anne =
Hendry'; 'Lynne Rodoni'; oauth@ietf.org
Subject: Re: =
[OAUTH-WG] draft-ietf-oauth-revocation-05 =
Questions

OAuth doesn't get into the business of =
what the UI for managing grants is like. Having the user, admin, or =
resource owner revoke, downscope, or otherwise alter a grant needs to =
happen with user interactions that are going to be different depending =
on the provider and use case. 

 -- =
Justin
On 02/21/2013 10:42 AM, =
Donald F Coffin wrote:
Torsten,<=
o:p>

Thanks for the =
response.  What is the “respective portal belonging to the =
AS”?  I haven’t seen anything in the OAuth 2.0 =
Authorization Framework that describes a “portal” on the AS =
a Resource Owner can log into to view a valid list of authorization =
grants.  Is this an out-of-band implementation =
suggestion?

Best regards,
Don
Donald F. =
Coffin
Founder/CTO

REMI =
Networks
22751 El Prado Suite =
6216
Rancho Santa Margarita, CA  =
92688-3836

Phone:      (949) =
636-8571
Email:       donald.coffin@reminetworks=
.com

From:=
 =
Torsten Lodderstedt [mailto:torsten@lodderstedt.net] 
Sent: Thursday, February 21, 2013 12:13 AM
To: =
Donald F Coffin
Cc: <oauth@ietf.org>; Anne Hendry; =
Dave Robin; Edward Denson; Jay Mitra; John Adkins; John Teeter; Lynne =
Rodoni; Marty Burns; <pmadsen@pingidentity.com>=
; Ray Perlner; Scott Crowder; Uday Verma
Subject: Re: =
draft-ietf-oauth-revocation-05 =
Questions

Hi =
Donald,

thank you for sharing your thoughts with us. I've =
never seen revocation as change of scope of the authorization, but it =
sounds reasonable. The current design handles the issues you raised =
differently.

The AS is involved in the revocation process as it =
exposes the revocation endpoint. So if the token is revoked (from a =
technical perspective), it knows it. If the user wants to check whether =
the application really sent the request, she is supposed to visit the =
respective portal belonging to the AS. There the AS provides a list of =
all valid authorization grants in its =
database. 

Does this address your =
issues?

regards,
Torsten.

Am 21.02.2013 um 01:09 schrieb =
"Donald F Coffin" <donald.coffin@reminetworks=
.com>:
Torsten,<=
o:p>

A colleague of =
mine and I were discussing what should occur when a Retail Customer =
desires to change the existing authorized access of a Third Party.  =
During our discussion they asked “How does the Retail Customer =
know the Third Party actually issued a Token revocation request?  =
Isn’t there a potential trust issue with the current =
design”? 

The current =
draft provides a Third Party mechanism that “allows a client to =
invalidate its tokens if the end-user logs out, changes identity, or =
uninstalls the respective application (sic).” While none of these =
fit the situation we were discussing they do seem to be based on the =
assumption a Third Party application will be a good citizen and stop =
using access tokens.  Unfortunately, none of the addressed =
situations require the participation of a AS for completion, therefore =
the risk exists that a Retail Customer may believe they have removed a =
Third Party application from accessing their protected data, but in =
reality there does not seem to be a mechanism to either force or verify =
the Third Party can no longer have access to the protected =
data.

A possible =
modification to the current draft that would correct this potential =
security risk, is to treat a Token revocation using a message flow =
similar to the existing authorization_code response type.  A Retail =
Customer requesting a change to the Third Party authorized access would =
be redirected to an AS endpoint that would allow the Retail Customer to =
either terminate a relationship completely or modify the existing Third =
Party access authorization.  The successful response from the AS =
would indicate the Third Party needs to remove the current Token from =
its Token store.  In the event the Retail Customer has changed the =
Third Party access authorization, the AS response could include an =
optional “scope” element, which the Third Party would then =
use to obtain a new access token utilizing an Authorization Code =
request.

There are =
several other potential implementations that could be developed to =
protect a Retail Customer from a “rogue” Third Party =
application that does not inform the AS their authorization to access a =
Retail Customer’s protected data has been revoked, but the above =
suggestion meets the current draft’s view that Third Parties =
should be able to request Tokens be revoked.

I look forward =
to your comments on the above topic.

Best =
regards,
Don
Donald F. Coffin
Founder/CTO

REMI =
Networks
22751 El Prado Suite =
6216
Rancho Santa Margarita, CA  =
92688-3836

Phone:      (949) =
636-8571
Email:       donald.coffin@reminetworks=
.com

______________=
_________________________________
OAuth mailing =
list
OAuth@ietf.org
https://www.ietf.org=
/mailman/listinfo/oauth

------=_NextPart_000_008E_01CE101A.853FD430--

From bcampbell@pingidentity.com  Thu Feb 21 10:31:12 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16F221F8F41 for ; Thu, 21 Feb 2013 10:31:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.121
X-Spam-Level: 
X-Spam-Status: No, score=-5.121 tagged_above=-999 required=5 tests=[AWL=-0.811, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2w-yoPPj-UN for ; Thu, 21 Feb 2013 10:31:12 -0800 (PST)
Received: from na3sys009aog115.obsmtp.com (na3sys009aog115.obsmtp.com [74.125.149.238]) by ietfa.amsl.com (Postfix) with ESMTP id B2C0B21F8F31 for ; Thu, 21 Feb 2013 10:31:11 -0800 (PST)
Received: from mail-ob0-f200.google.com ([209.85.214.200]) (using TLSv1) by na3sys009aob115.postini.com ([74.125.148.12]) with SMTP ID DSNKUSZn72qGhMI1g79ynuYy3VM1cTtp1DzT@postini.com; Thu, 21 Feb 2013 10:31:11 PST
Received: by mail-ob0-f200.google.com with SMTP id un3so45949329obb.3 for ; Thu, 21 Feb 2013 10:31:10 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=mEDHTO+trjoDRLuF707RsJei3EknRs1hIeP77KF1O8w=; b=oo0MxNEbRjAYf/BV3x6zRqQYX3fKvX2TIInahUDBBvWJP4GfVx96yppf3UUkzYWom2 hleTTMRg+fJn0euWFzGcooz4QCuSHXUeX6fvLqaZAWNjfB3/QFfVGnOpNsaqaT8WUtcE UqK/VguTBRsH7fA624+BmG/9I2WJr4GUZ1cJHM4qJ28RHgCfqkdWu8B1V3c0DotlPQ2H W/pNA1dwSvnVxaT4QfvvRQ0txdCN18nuDhekjRqnCOYg6roxcw90d39VHdkaPKc/IDHI 5Z0+Am4+y3Et2xAObBtCOS04vi4eXaJiYtkBzDS1pmsvRTVm8TrQXg9UdfwnLNr58LWf ae/A==
X-Received: by 10.50.193.129 with SMTP id ho1mr6788142igc.94.1361471470876; Thu, 21 Feb 2013 10:31:10 -0800 (PST)
X-Received: by 10.50.193.129 with SMTP id ho1mr6788139igc.94.1361471470752; Thu, 21 Feb 2013 10:31:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.63.3 with HTTP; Thu, 21 Feb 2013 10:30:39 -0800 (PST)
In-Reply-To: <5125F0A2.6070808@gmail.com>
References: <51238410.8040705@gmail.com>  <5124B749.9050402@gmail.com> <5125F0A2.6070808@gmail.com>
From: Brian Campbell 
Date: Thu, 21 Feb 2013 11:30:39 -0700
Message-ID: 
To: Sergey Beryozkin 
Content-Type: multipart/alternative; boundary=14dae934108962d3f704d640476d
X-Gm-Message-State: ALoCoQk58WxnkxE1ug/2ambHDaMId2nmbjtIZKN5YX+ufmVilYhozhXBarQK5oRcPpSM/GSb1t6TZLNszVVVJ4IXENsLfr1m57gEP8eMkJga0wQYyH9F7IvthqaIGckQ24vkL2WC1NXv
Cc: "" 
Subject: Re: [OAUTH-WG] Using SAML2 Bearer for the authentication
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Feb 2013 18:31:13 -0000

--14dae934108962d3f704d640476d
Content-Type: text/plain; charset=ISO-8859-1

Yeah Sergey, your second interpretation is more along the lines of what the
draft(s) intended to convey.

The drafts are all due (overdue really) for an update and I'll try and and
some clarifications around this when I get to doing the edits.

Thanks for the feedback.

On Thu, Feb 21, 2013 at 3:02 AM, Sergey Beryozkin wrote:

> On 20/02/13 11:45, Sergey Beryozkin wrote:
>
>> On 19/02/13 14:27, Brian Campbell wrote:
>>
>>> The scope of assertion based client authentication is only in OAuth and
>>> only for the client calling the AS's token endpoint. Defining a general
>>> HTTP auth scheme for assertions would have a much broader scope and be
>>> much more difficult to standardize.
>>>
>> Understood, thanks.
>>
>> I'd like to ask another question related to the subject of this thread,
>> though the same would likely be relevant for using JWT for authenticating.
>>
>> When the assertion is used for authenticating the client, a form
>> "client_id" parameter is said to be optional.
>> Next, section 6.1 [1] says that "Subject" of the assertion SHOULD be
>> "client_id".
>>
>> I interpret it like this.
>>
>> If "Subject" is set to "client_id" then there the actual client_id must
>> be available as "client_id" form parameter, which will be posted
>> alongside the assertion.
>>
>> If not then the client_id is an actual Subject value and no "client_id"
>> form parameter is expected to be available.
>>
>>
>>  Continuing on this,
>
> http://tools.ietf.org/html/**draft-ietf-oauth-saml2-bearer-**15#section-3
>
> says "For client authentication, the Subject MUST be the "client_id" of
> the OAuth client."
>
> This makes me think I may've been wrong with my initial reading of both
> drafts, now I read like this:
>
> "the Subject MUST be the "client_id" of the OAuth client." as per the
> Saml2 bearer draft, which is not the literal "client_id". Next, if
> "client_id" form parameter is available then it must be equal to Subject
> value, as is, or via an AS provided mapping, otherwise it is a validation
> fault.
> This is probably in line with the answers to the similar question on the
> use of client_id and JWT grant, though I'm not sure.
>
> I appreciate it is a work in progress, but IMHO some more clarifications
> in the text will help
>
> Cheers, Sergey
>
>
>  Is it correct ?
>>
>> Thanks, Sergey
>>
>> [1] http://tools.ietf.org/html/**draft-ietf-oauth-assertions-**
>> 10#section-6.1
>>
>>
>>
>>
>>>
>>> On Tue, Feb 19, 2013 at 6:54 AM, Sergey Beryozkin >> > wrote:
>>>
>>> Hi,
>>>
>>> Assertions like SAML2 Bearer can be used for authenticating the client.
>>> Why a dedicated Authorization scheme can not be introduced, instead
>>> of or in addition to "client_assertion" & "client_assertion_type"
>>> parameters ?
>>>
>>> IMHO, the following
>>>
>>> Authorization: SAML "base64url-encoded assertion"
>>>
>>> grant_type=authorization_code&**__code=123456
>>>
>>> is more in line with OAuth2 recommending not to prefer including
>>> client id & secret in the body:
>>>
>>> "Including the client credentials in the request-body using the two
>>> parameters is NOT RECOMMENDED and SHOULD be limited to clients unable
>>> to directly utilize the HTTP Basic authentication scheme (or other
>>> password-based HTTP authentication schemes)" - though it talks about
>>> a password based scheme...
>>>
>>> similarly:
>>>
>>> Authorization: JWT "encoded jwt assertion"
>>>
>>> grant_type=authorization_code&**__code=123456
>>>
>>> Just a thought.
>>>
>>> Cheers, Sergey
>>>
>>>
>>> ______________________________**___________________
>>> 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
>

--14dae934108962d3f704d640476d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Yeah Sergey, your second interpretation is more along=
 the lines of what the draft(s) intended to convey. 

The draft=
s are all due (overdue really) for an update and I'll try and and some =
clarifications around this when I get to doing the edits.

Thanks for the feedback.

On Thu, Feb 21, 2013 at 3:02 AM, Sergey Be=
ryozkin <sberyozkin@gmail.com> wrote:

On 20/02/13 11:45, Sergey =
Beryozkin wrote:

On 19/02/13 14:27, Brian Campbell wrote:

The scope of assertion based client authentication is only in OAuth and

only for the client calling the AS's token endpoint. Defining a general=

HTTP auth scheme for assertions would have a much broader scope and be

much more difficult to standardize.

Understood, thanks.

I'd like to ask another question related to the subject of this thread,=

though the same would likely be relevant for using JWT for authenticating.<=
br>

When the assertion is used for authenticating the client, a form

"client_id" parameter is said to be optional.

Next, section 6.1 [1] says that "Subject" of the assertion SHOULD=
 be

"client_id".

I interpret it like this.

If "Subject" is set to "client_id" then there the actua=
l client_id must

be available as "client_id" form parameter, which will be posted<=
br>
alongside the assertion.

If not then the client_id is an actual Subject value and no "client_id=
"

form parameter is expected to be available.

Continuing on this,

http://tools.ietf.org/html/draft-ietf-oauth=
-saml2-bearer-15#section-3

says "For client authentication, the Subject MUST be the "client_=
id" of the OAuth client."

This makes me think I may've been wrong with my initial reading of both=
 drafts, now I read like this:

"the Subject MUST be the "client_id" of the OAuth client.&qu=
ot; as per the Saml2 bearer draft, which is not the literal "client_id=
". Next, if "client_id" form parameter is available then it =
must be equal to Subject value, as is, or via an AS provided mapping, other=
wise it is a validation fault.

This is probably in line with the answers to the similar question on the us=
e of client_id and JWT grant, though I'm not sure.

I appreciate it is a work in progress, but IMHO some more clarifications in=
 the text will help

Cheers, Sergey

Is it correct ?

Thanks, Sergey

[1] http://tools.ietf.org/html/draft-ietf-o=
auth-assertions-10#section-6.1

On Tue, Feb 19, 2013 at 6:54 AM, Sergey Beryozkin <sberyozkin@gmail.com

<mailto:sberyo=
zkin@gmail.com>> wrote:

Hi,

Assertions like SAML2 Bearer can be used for authenticating the client.

Why a dedicated Authorization scheme can not be introduced, instead

of or in addition to "client_assertion" & "client_assert=
ion_type"

parameters ?

IMHO, the following

Authorization: SAML "base64url-encoded assertion"

grant_type=3Dauthorization_code&__code=3D123456

is more in line with OAuth2 recommending not to prefer including

client id & secret in the body:

"Including the client credentials in the request-body using the two
parameters is NOT RECOMMENDED and SHOULD be limited to clients unable

to directly utilize the HTTP Basic authentication scheme (or other

password-based HTTP authentication schemes)" - though it talks about
a password based scheme...

similarly:

Authorization: JWT "encoded jwt assertion"

grant_type=3Dauthorization_code&__code=3D123456

Just a thought.

Cheers, Sergey

_________________________________________________

OAuth mailing list

OAuth@ietf.org <=
mailto:OAuth@ietf.org>

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

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

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

--14dae934108962d3f704d640476d--

From jricher@mitre.org  Thu Feb 21 12:34:52 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB7021F8ED4 for ; Thu, 21 Feb 2013 12:34:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.576
X-Spam-Level: 
X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.022,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpIEFamRR71f for ; Thu, 21 Feb 2013 12:34:51 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5F01E21F8EC6 for ; Thu, 21 Feb 2013 12:34:51 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9432543900B1 for ; Thu, 21 Feb 2013 15:34:50 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7F65343900A6 for ; Thu, 21 Feb 2013 15:34:50 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 21 Feb 2013 15:34:50 -0500
Message-ID: <512684B4.2050407@mitre.org>
Date: Thu, 21 Feb 2013 15:33:56 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: "oauth@ietf.org" 
References: <20130221184415.2302.42295.idtracker@ietfa.amsl.com>
In-Reply-To: <20130221184415.2302.42295.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20130221184415.2302.42295.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------090202070809000803060509"
X-Originating-IP: [129.83.31.58]
Subject: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Feb 2013 20:34:52 -0000

--------------090202070809000803060509
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit

New version of the introspection draft is up. Only change here is 
changing the "valid" parameter to "active", due to the former term being 
confused for whether or not the token was used in a valid manner at the 
RP (which introspection can't directly tell you).

  -- Justin

-------- Original Message --------
Subject: 	New Version Notification for 
draft-richer-oauth-introspection-03.txt
Date: 	Thu, 21 Feb 2013 10:44:15 -0800
From: 	
To: 	

A new version of I-D, draft-richer-oauth-introspection-03.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 03
Title:		 OAuth Token Introspection
Creation date:	 2013-02-21
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-03.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-03
Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-03

Abstract:
    This specification defines a method for a client or protected
    resource to query an OAuth authorization server to determine meta-
    information about an OAuth token.

The IETF Secretariat

--------------090202070809000803060509
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 8bit

    New version of the introspection draft is up. Only change here is
    changing the "valid" parameter to "active", due to the former term
    being confused for whether or not the token was used in a valid
    manner at the RP (which introspection can't directly tell you).

     -- Justin

      -------- Original Message --------

            Subject:

            New Version Notification for
              draft-richer-oauth-introspection-03.txt

            Date: 
            Thu, 21 Feb 2013 10:44:15 -0800

            From: 
            <internet-drafts@ietf.org>

            To: 
            <jricher@mitre.org>

      A new version of I-D, draft-richer-oauth-introspection-03.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-introspection
Revision:	 03
Title:		 OAuth Token Introspection
Creation date:	 2013-02-21
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-03.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-03
Diff:            http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-03

Abstract:
   This specification defines a method for a client or protected
   resource to query an OAuth authorization server to determine meta-
   information about an OAuth token.

The IETF Secretariat

--------------090202070809000803060509--

From internet-drafts@ietf.org  Thu Feb 21 12:35:01 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D8B21F8F47; Thu, 21 Feb 2013 12:35:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.554
X-Spam-Level: 
X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ia9aP8YQyNvU; Thu, 21 Feb 2013 12:35:01 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7ED121F8F4B; Thu, 21 Feb 2013 12:35:00 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.40
Message-ID: <20130221203500.30877.85502.idtracker@ietfa.amsl.com>
Date: Thu, 21 Feb 2013 12:35:00 -0800
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-07.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Feb 2013 20:35:01 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Web Authorization Protocol Working Group =
of the IETF.

	Title           : OAuth Dynamic Client Registration Protocol
	Author(s)       : Justin Richer
                          John Bradley
                          Michael B. Jones
                          Maciej Machulak
	Filename        : draft-ietf-oauth-dyn-reg-07.txt
	Pages           : 21
	Date            : 2013-02-21

Abstract:
   This specification defines an endpoint and protocol for dynamic
   registration of OAuth Clients at an Authorization Server.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-07

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

From jricher@mitre.org  Thu Feb 21 12:50:20 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C08321F8F51 for ; Thu, 21 Feb 2013 12:50:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.576
X-Spam-Level: 
X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHncj3O4-3kT for ; Thu, 21 Feb 2013 12:50:17 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 78AA321F8F35 for ; Thu, 21 Feb 2013 12:50:15 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 108F91F13C3 for ; Thu, 21 Feb 2013 15:50:15 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id E2BA11F14D3 for ; Thu, 21 Feb 2013 15:50:14 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 21 Feb 2013 15:50:14 -0500
Message-ID: <51268850.4020305@mitre.org>
Date: Thu, 21 Feb 2013 15:49:20 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: 
References: <20130221203500.30877.85502.idtracker@ietfa.amsl.com>
In-Reply-To: <20130221203500.30877.85502.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.58]
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-07.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Feb 2013 20:50:20 -0000

New version of Dynamic Registration, just in time for IETF86's 
submission deadline.

Changes to the document reflect conversation over the last week, and 
include:

    o  Changed registration_access_url to registration_client_uri
    o  Fixed missing text in 5.1
    o  Added Pragma: no-cache to examples
    o  Changed "no such client" error to 403
    o  Renamed Client Registration Access Endpoint to Client
       Configuration Endpoint
    o  Changed all the parameter names containing "_url" to instead use
       "_uri"
    o  Updated example text for forming Client Configuration Endpoint URL

Please take a look, both over the change sets and the document as a 
whole. If there's anything drastic that needs patching prior to Monday, 
I'll try to do that, but I'm assuming that this will be the last update 
prior to IETF86. In my personal opinion, I think this is getting close 
to a final form.

My group plans to update our dynamic registration server implementation 
to reflect this new spec in the coming weeks, and I'd encourage other 
implementors to do the same so we can try some honest-to-goodness 
interop testing.

  -- Justin

On 02/21/2013 03:35 PM, internet-drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the Web Authorization Protocol Working Group of the IETF.
>
> 	Title           : OAuth Dynamic Client Registration Protocol
> 	Author(s)       : Justin Richer
>                            John Bradley
>                            Michael B. Jones
>                            Maciej Machulak
> 	Filename        : draft-ietf-oauth-dyn-reg-07.txt
> 	Pages           : 21
> 	Date            : 2013-02-21
>
> Abstract:
>     This specification defines an endpoint and protocol for dynamic
>     registration of OAuth Clients at an Authorization Server.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-07
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-07
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From sakimura@gmail.com  Fri Feb 22 14:56:29 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D908121E804B for ; Fri, 22 Feb 2013 14:56:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.471
X-Spam-Level: 
X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=-0.539, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVwieW51X2hV for ; Fri, 22 Feb 2013 14:56:28 -0800 (PST)
Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by ietfa.amsl.com (Postfix) with ESMTP id 647D721E8047 for ; Fri, 22 Feb 2013 14:56:28 -0800 (PST)
Received: by mail-lb0-f182.google.com with SMTP id gg6so913492lbb.41 for ; Fri, 22 Feb 2013 14:56:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=PPz5d41d3HIFiO8hDRxp39UQGGHSu9bIEMZIoT9Tnko=; b=Blp4wwvpEVOdF1m3aceRbtwdKF8VT6+XGNgKJ1+u/9bzHrUYgFonb21givKsYbACQO gbrt2h956cX5RWPh33cw1AqEceRYs3TaulktmGPqwXD9nJpEIh2DwRgkh7R8aReSokzd LOzP7A94xX/D+fh2L42U8b9WIGX6JWRs6UQu/FDz7qmfm+W5aabyZEzCfxvv/Poj6EaZ 03nt+NXofoQcC2FMBfJ+e5mMxvdKzGA+Qe/SBEElokBWOREkjEe2D/FTNYyoVwDmUyi9 6Mbp57R41hanaEhek3wS7CIsNCnPyjYVSI2bLFliuQ+46A9o3jbwZQUyy700atDJjPaY rKqQ==
MIME-Version: 1.0
X-Received: by 10.152.105.38 with SMTP id gj6mr3161205lab.25.1361573787258; Fri, 22 Feb 2013 14:56:27 -0800 (PST)
Received: by 10.112.14.44 with HTTP; Fri, 22 Feb 2013 14:56:27 -0800 (PST)
In-Reply-To: <5122391E.9030500@mitre.org>
References: <51195F36.6040705@mitre.org> <780F8C26-19A4-4301-B350-307D9FFF69CD@ve7jtb.com> <511BAA8B.8030309@mitre.org>  <-4554688250617930935@unknownmsgid>   <4687F290-4855-49DE-892F-F9694BB211D4@ve7jtb.com> <511CF2C9.9040604@mitre.org>   <4E1F6AAD24975D4BA5B1680429673943674691FB@TK5EX14MBXC284.redmond.corp.microsoft.com> <5122391E.9030500@mitre.org>
Date: Sat, 23 Feb 2013 07:56:27 +0900
Message-ID: 
From: Nat Sakimura 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=f46d0408d3f7eccfb204d65819e4
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Feb 2013 22:56:30 -0000

--f46d0408d3f7eccfb204d65819e4
Content-Type: text/plain; charset=ISO-8859-1

Agreed with the security consideration.

Just for the record:
The life cycle as I understand would include the following.

   1. registration (creation)
   2. activation
   3. de-activation
   4. re-activation
   5. archival
   6. deletion

In the above thread, I was talking more about "3. archive".
We do not have to have the full life-cycle model here, but it may be a good
idea to document why we would not.

Nat

2013/2/18 Justin Richer 

> Nat's attack vector presumes lack of logging on the server side, where
> doing a "delete" means that you can no longer see anything about who did
> what. You could make the same argument if you have a system where users can
> register themselves and delete their accounts at will -- someone creates a
> fly-by-night account, does bad things, deletes the account. If the site
> doesn't have detailed logs in both of these cases, yes, they'll be in the
> dark about the bad things that happened when the account/client was active.
> It's a valuable security consideration, but I don't think that it's enough
> to say that delete is no longer a valid operation.
>
> I think it's up to the server what "delete" means under the hood, but the
> important bit for the protocol is that as far as the client is concerned,
> that client_id is dead now. I don't think it's worthwhile to specify it as
> a "suspend" operation, because to me "suspend" implies an ability to
> "unsuspend", and I really don't think we want to get into the complicated
> zombie OAuth client business. But whether on the server side "delete"
> translates to "delete everything from the database immediately and burn all
> records of it" or instead "set a flag on that client and all of its
> outstanding grants so that it can't be used but administrators can still
> poke it with a stick" is completely up to the implementation and its
> security considerations.
>
> That said, I think it would make sense to at least describe this potential
> problem in the security considerations, and note that the client MUST NOT
> use the client_id again.
>
>  -- Justin
>
>
> On 02/17/2013 01:11 AM, Mike Jones wrote:
>
>> I agree.  If we have it at all, DELETE should be a declaration by the
>> Client that requests by it should no longer be honored.  It should be up to
>> the Server whether to implement this as suspension or deletion.  At most, I
>> believe it should be an optional operation, which MAY be supported.
>>
>>                                 -- Mike
>>
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org**] On Behalf
>> Of Nat Sakimura
>> Sent: Saturday, February 16, 2013 10:04 PM
>> To: John Bradley
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
>>
>>  When sending an update, a client MUST send all metadata fields
>>> returned from the server in its initial registration or previous read
>>> or update call, including its client_id. A server MAY replace any
>>> missing or invalid fields with default values, or it MAY return an
>>> error as described in the Error Response section. A server MUST return
>>> all provisioned fields in its response. A server MUST NOT change the
>>> client_id field. A server MAY change the client_secret and/or
>>> refresh_access_token fields.
>>>
>> Say the client registered some value. Sometime later, the server changed
>> a value due to some policy or security reasons etc. The client when UPDATES
>> with the previously registered value, what is going to happen to the
>> changed value?
>>
>>  DELETE to be used correctly is I think going to delete the client_id and
>>>> all associated tokens and cause a ripple effect in removing grants
>>>> associated with that client_id.
>>>>
>>> This is how I would interpret it as well. It's de-provisioning the
>>> client, not resetting it.
>>>
>> For DELETE, I can think of an attack such that
>>
>> 1. Register as a client.
>> 2. Send spam links to random users.
>> 3. When user "authorizes", suck the user data such as contacts out.
>> 4. DELETE the registration and disappear.
>>
>> To prevent something like this, it should probably be something more akin
>> to "suspend" rather than completely de-provisioning.
>> ______________________________**_________________
>> 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
>>
>
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--f46d0408d3f7eccfb204d65819e4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Agreed with the security consideration.=A0

Just fo=
r the record:=A0The life cycle as I understand would include the follo=
wing.=A0
registration (creation)
activation<=
li>
de-activationre-activation
archival=A0
deletion
In the above thread, I was talking more about "3. ar=
chive".=A0
We do not have to have the full life-cycle model =
here, but it may be a good idea to document why we would not.=A0

Nat

2013/2=
/18 Justin Richer <jricher@mitre.org>

Nat's attack vector presumes lack of logging on the server side, where =
doing a "delete" means that you can no longer see anything about =
who did what. You could make the same argument if you have a system where u=
sers can register themselves and delete their accounts at will -- someone c=
reates a fly-by-night account, does bad things, deletes the account. If the=
 site doesn't have detailed logs in both of these cases, yes, they'=
ll be in the dark about the bad things that happened when the account/clien=
t was active. It's a valuable security consideration, but I don't t=
hink that it's enough to say that delete is no longer a valid operation=
.

I think it's up to the server what "delete" means under the h=
ood, but the important bit for the protocol is that as far as the client is=
 concerned, that client_id is dead now. I don't think it's worthwhi=
le to specify it as a "suspend" operation, because to me "su=
spend" implies an ability to "unsuspend", and I really don&#=
39;t think we want to get into the complicated zombie OAuth client business=
. But whether on the server side "delete" translates to "del=
ete everything from the database immediately and burn all records of it&quo=
t; or instead "set a flag on that client and all of its outstanding gr=
ants so that it can't be used but administrators can still poke it with=
 a stick" is completely up to the implementation and its security cons=
iderations.

That said, I think it would make sense to at least describe this potential =
problem in the security considerations, and note that the client MUST NOT u=
se the client_id again.

=A0-- Justin

On 02/17/2013 01:11 AM, Mike Jones wrote:

I agree. =A0If we have it at all, DELETE should be a declaration by the Cli=
ent that requests by it should no longer be honored. =A0It should be up to =
the Server whether to implement this as suspension or deletion. =A0At most,=
 I believe it should be an optional operation, which MAY be supported.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike

-----Original Message-----

From: oauth-bou=
nces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura
Sent: Saturday, February 16, 2013 10:04 PM

To: John Bradley

Cc: oauth@ietf.org<=
br>
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management

When sending an update, a client MUST send all metadata fields

returned from the server in its initial registration or previous read

or update call, including its client_id. A server MAY replace any

missing or invalid fields with default values, or it MAY return an

error as described in the Error Response section. A server MUST return

all provisioned fields in its response. A server MUST NOT change the

client_id field. A server MAY change the client_secret and/or

refresh_access_token fields.

Say the client registered some value. Sometime later, the server changed a =
value due to some policy or security reasons etc. The client when UPDATES w=
ith the previously registered value, what is going to happen to the changed=
 value?

DELETE to be used correctly is I think going to delete the client_id and al=
l associated tokens and cause a ripple effect in removing grants associated=
 with that client_id.

This is how I would interpret it as well. It's de-provisioning the

client, not resetting it.

For DELETE, I can think of an attack such that

1. Register as a client.

2. Send spam links to random users.

3. When user "authorizes", suck the user data such as contacts ou=
t.

4. DELETE the registration and disappear.

To prevent something like this, it should probably be something more akin t=
o "suspend" rather than completely de-provisioning.

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

-- 
=
Nat Sakimura (=3Dnat)Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_=
en

--f46d0408d3f7eccfb204d65819e4--

From internet-drafts@ietf.org  Mon Feb 25 04:46:43 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3658E21F9305; Mon, 25 Feb 2013 04:46:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.504
X-Spam-Level: 
X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJ1GZwYqlu1q; Mon, 25 Feb 2013 04:46:42 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 810CD21F9308; Mon, 25 Feb 2013 04:46:42 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.40
Message-ID: <20130225124642.7425.65145.idtracker@ietfa.amsl.com>
Date: Mon, 25 Feb 2013 04:46:42 -0800
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Feb 2013 12:46:43 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Web Authorization Protocol Working Group =
of the IETF.

	Title           : OAuth 2.0 Message Authentication Code (MAC) Tokens
	Author(s)       : Justin Richer
                          William Mills
                          Hannes Tschofenig
	Filename        : draft-ietf-oauth-v2-http-mac-03.txt
	Pages           : 26
	Date            : 2013-02-25

Abstract:
   This specification describes how to use MAC Tokens in HTTP requests
   to access OAuth 2.0 protected resources.  An OAuth client willing to
   access a protected resource needs to demonstrate possession of a
   crytographic key by using it with a keyed message digest function to
   the request.

   The document also defines a key distribution protocol for obtaining a
   fresh session key.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-v2-http-mac-03

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

From hannes.tschofenig@gmx.net  Mon Feb 25 04:47:30 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2881521F9316 for ; Mon, 25 Feb 2013 04:47:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.532
X-Spam-Level: 
X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHQbQFgH1kjU for ; Mon, 25 Feb 2013 04:47:29 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2407221F9317 for ; Mon, 25 Feb 2013 04:47:26 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.32]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0LqGSs-1Unfyg3dbM-00dlm6 for ; Mon, 25 Feb 2013 13:46:22 +0100
Received: (qmail invoked by alias); 25 Feb 2013 12:46:22 -0000
Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.100]) [88.115.219.140] by mail.gmx.net (mp032) with SMTP; 25 Feb 2013 13:46:22 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+1lpYQFQa1WpbMXbG9lhAtBjXnsc1+XwUHFNT94O rwVethJpw7V65e
From: Hannes Tschofenig 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Mon, 25 Feb 2013 14:46:19 +0200
Message-Id: 
To: IETF oauth WG 
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Subject: [OAUTH-WG] draft-ietf-oauth-v2-http-mac and draft-tschofenig-oauth-hotk re-submitted
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Feb 2013 12:47:30 -0000

Hi all,=20

I just submitted an updated version of the =
draft-ietf-oauth-v2-http-mac-03.txt.=20

I would like to point out that this is **discussion input** -- not =
agreed content. Anything in the document is subject to change!
You also may notice that there are a few questions in the writeup.=20

I was trying to more specific about some of the design aspects that =
folks had proposed during the last few months.=20
I have also re-submitted the draft-tschofenig-oauth-hotk, which includes =
a TLS and a JSON-based solution approach.=20

In general, the open questions still seem to be related to=20
* Key distribution: What should be described in a document? What is =
mandatory to implement?=20
* Selective header field protection: This is something that was brought =
forward in discussions and I have included a proposal of how this could =
look like.
* Channel Binding: Functionality is also included to deal with =
man-in-the-middle attacks against TLS. There are, however, two types of =
channel bindings defined in RFC 5929. Are both needed? If not, which one =
should be selected?=20
* Integrity protection and data origin authentication in both =
directions: The current writeup allows the protection to be extended to =
messages beyond the initial request. This also offers key confirmation =
by the server and protection of any responses. =20

Writing the text I also noticed that I do not quite understand how =
nested JWT documents are supposed to look like. For example, how do I =
encrypt the mac_key carried inside the JWT plus add a signature of all =
other fields? Currently, I have just encrypted the entire payload.=20

I hope to have some discussions prior to the IETF meeting so that we =
have a more fruitful discussion at the face-to-face meeting.

Ciao
Hannes

From wmills_92105@yahoo.com  Mon Feb 25 14:22:42 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9747C21E80FA for ; Mon, 25 Feb 2013 14:22:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.054
X-Spam-Level: 
X-Spam-Status: No, score=-1.054 tagged_above=-999 required=5 tests=[AWL=-1.056, BAYES_50=0.001, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60quMqtvx8Pn for ; Mon, 25 Feb 2013 14:22:42 -0800 (PST)
Received: from nm19.bullet.mail.ne1.yahoo.com (nm19.bullet.mail.ne1.yahoo.com [98.138.90.82]) by ietfa.amsl.com (Postfix) with ESMTP id 65F1521E80F6 for ; Mon, 25 Feb 2013 14:22:29 -0800 (PST)
Received: from [98.138.226.180] by nm19.bullet.mail.ne1.yahoo.com with NNFMP; 25 Feb 2013 22:22:25 -0000
Received: from [98.138.87.8] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 25 Feb 2013 22:22:25 -0000
Received: from [127.0.0.1] by omp1008.mail.ne1.yahoo.com with NNFMP; 25 Feb 2013 22:22:25 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 190259.53793.bm@omp1008.mail.ne1.yahoo.com
Received: (qmail 23725 invoked by uid 60001); 25 Feb 2013 22:22:24 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1361830944; bh=QO7T0D/i8NQRKUFueX46qmtTNtDae6rJfaC5v+ho65I=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=r6S0aV76pw2acfTqNyEjD2PeD43+Kw6oZVy4vXev9H+fsXBIztue2SUqSr0MPqnH3w3bVIPuTG2Q8SEITuatP/cBnABDWiIvx0wWi7YRNM5VMHFh3o5LpGq9Z2QYUEIEGcl35yzPGU5iWL8hy6LeKzDS+mgj9S65B4Y+bB9mQUQ=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=fenGg/5K8eRTidbdQTJjihaz2J2vwyQY7Mge+pHBSERoxjiui0s29Vc3sbOl/gbAFCC1TV/2fdSNjXBFmCjxs9EHJmF4IDh3wSaBBdnQ5BNLD5nelTCoa+AUZ1BM2nS+n7bKl4eY/HMSitSslgr2e6j23jH82Onuh083MJY7+cU=;
X-YMail-OSG: EqjgQGkVM1nHCxWQek5tJHJKKgr9AwxBnf_ygSnsQ0toxg2 Tvow0QnP.2EVuYA.yB1wzxPn229vCZce_YiCqjG8pxJ55G19A2EeAfz6yjJv Gn6Bkws.tylEvO908Kc4bMX76YbqeBYD2fIkKstiRHJkgZthDtJX3LaccCSu FjjsiFAY0Kv7aPjhHg.kJtZgJwhgkdWEULy1jvWmgo4iBZ2XqEt1Eu7vIfYK t3rRNWtv7jBSPJlomBJ7lDkELz.NHhXORQEsz5O.wi2RBgtfYE._Lpe7_arZ EBxEy01E7eOVVYUtCeYYuAGFc151.gJEmyTMBRvl09eZu7C0l5pM47fJUxEe qk9WCdfBaa_jbLtq8lGsHPaa.m63l6YVheCrg8k2TC2cwVNqWEdhY9jrTHu5 cG9KniIL4TKv7z1oYQElJhl2Au1pa5X1a06HxxdZm8LCYbdWmCp575goStKv 5ETvgKC7SRIcRpuXnIsSLOlFjbEjgH2DvCeXTEeD7UiKzhEWw6cjawb94k_U w5slz56I2DFHfdZ82ky9pCW0-
Received: from [209.131.62.113] by web31812.mail.mud.yahoo.com via HTTP; Mon, 25 Feb 2013 14:22:24 PST
X-Rocket-MIMEInfo: 001.001, SSB0aGluayB0aGlzIGlzIHdvcnRoIGEgcmVhZCwgSSBkb24ndCBoYXZlIHRpbWUgdG8gZGl2ZSBpbnRvIHRoaXMgOigBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.135.514
Message-ID: <1361830944.13340.YahooMailNeo@web31812.mail.mud.yahoo.com>
Date: Mon, 25 Feb 2013 14:22:24 -0800 (PST)
From: William Mills 
To: O Auth WG 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="1458549034-398514229-1361830944=:13340"
Subject: [OAUTH-WG] OAuth2 attack surface....
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Feb 2013 22:22:42 -0000

--1458549034-398514229-1361830944=:13340
Content-Type: text/plain; charset=us-ascii

I think this is worth a read, I don't have time to dive into this :(
--1458549034-398514229-1361830944=:13340
Content-Type: text/html; charset=us-ascii

I think this is worth a read, I don't have time to dive into this :(
--1458549034-398514229-1361830944=:13340--

From wmills_92105@yahoo.com  Mon Feb 25 14:42:15 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F24121E80FE for ; Mon, 25 Feb 2013 14:42:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.304
X-Spam-Level: 
X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=0.294,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2IP-sc8l2lE for ; Mon, 25 Feb 2013 14:42:15 -0800 (PST)
Received: from nm21-vm1.bullet.mail.ne1.yahoo.com (nm21-vm1.bullet.mail.ne1.yahoo.com [98.138.91.46]) by ietfa.amsl.com (Postfix) with ESMTP id E6EC821E8104 for ; Mon, 25 Feb 2013 14:42:14 -0800 (PST)
Received: from [98.138.226.180] by nm21.bullet.mail.ne1.yahoo.com with NNFMP; 25 Feb 2013 22:42:14 -0000
Received: from [98.138.88.237] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 25 Feb 2013 22:42:14 -0000
Received: from [127.0.0.1] by omp1037.mail.ne1.yahoo.com with NNFMP; 25 Feb 2013 22:42:14 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 365688.98898.bm@omp1037.mail.ne1.yahoo.com
Received: (qmail 3143 invoked by uid 60001); 25 Feb 2013 22:42:14 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1361832133; bh=QSxzc1ronDdTL5FkazdSoaxqpQ8BAqbiNmyjs9vshkM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=hF9sb2A2qclUmKumGuCp3lgiquigVEyrbMjt8ITDFiCEaxJqDOT7QqT+OpV7PooxWglF+gP6rkdqK3BHXBHyMdpcVGRuLACUNA60GvzWMlmZOs+QAbkTqyyEFOhhYwUbHgm99ySNojxMMwPAwTLwGbyeT5giIq0SbUy7+d7kzL8=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=nXH6NmEb3oEtbgZhrBKm2M7YnfNMw3sOaj9TIBUPoe1Zv5NOi01DbjbrJld/PaNgqsvfBf5wzZVoCYgD0Hgs2fMwa3cwTC7kbeOG2DaOoBGdv8H88ChJ21zcjigZ0dS633mSFAFczEWLUVHovap6FUw4/1bJiZAqYZQdeje0Pbg=;
X-YMail-OSG: FhrYC54VM1njfTm1DqhVqb.m5PLtUK86UZVb5TuwJy7zq58 dOOb9_jdf89EvjSt4RgvV10hhmbQ_L9KCmV1ApVMcz3DHQvKF_VsQPqEgGz8 HKt2cbsjoYu_W4fR4fvZVhUc46ae5aH.87zpD00D6T1ETUGZzAb7owTzoEfp j.SAIjBckiNpzqx8WOoQ8ohAL_uHeHs7gyjoyU4D1vMq90bWW8EY9AGWw56P RTcLdC5aEZZItuT1JZdoip2jBrCtmaQxWT9AS680pLu8FTAiJjyCJcRvZimD eqyCRs61gKJeI.9k04Sc8sI6zlmsRXdX_h8HcsYijeIqLSkHn0cDQLOSkW_B XujS9..YtX1MEO91u_6OhDU4BACLBSJA1SIdlXd3hhRPWr7l.RCb5zAlvub4 y29bcTF1y0M2eTMJm8MTuW8AAfYTR3ecqlKoFgtKHY_T921sfcIO_KKov6PD lCVKw72fxqOiaV7mV0ppRVp.Z3lnSk8QQj1KijW89Z9zlUthct8hpT5_RFkQ Vvy0wSUQqoDHJxquLqpzsTieWLeTIT_VPb662qRZT8wL_YifYAhsIXJ5zb1A 3RJygv55JJQ4LmTI9czWG0P.FnlszcSSRdNI76ZC338.ZffWjFBFtRJirogy Wv20w.Lz8KgEovDwJ7JffawKUjTuXZwemIVmwhNDrt37KfBMDyxyFBHW6XRd BIJzMDFXXi8DgqnXQr43SZjFnhQHyvXuZnl_yxN_rpSHUmH2W.SY-
Received: from [209.131.62.145] by web31816.mail.mud.yahoo.com via HTTP; Mon, 25 Feb 2013 14:42:13 PST
X-Rocket-MIMEInfo: 001.001, CgoKCkRPSCEhISDCoGh0dHA6Ly9ob21ha292LmJsb2dzcG90LmNvLnVrLzIwMTMvMDIvaGFja2luZy1mYWNlYm9vay13aXRoLW9hdXRoMi1hbmQtY2hyb21lLmh0bWwKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRnJvbTogUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbT4KVG86IFdpbGxpYW0gTWlsbHMgPHdtaWxsc185MjEwNUB5YWhvby5jb20.IApTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDI1LCAyMDEzIDI6MjggUE0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gT0F1dGgyIGF0dGEBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.135.514
References: <1361830944.13340.YahooMailNeo@web31812.mail.mud.yahoo.com>  <1361831644.50183.YahooMailNeo@web31801.mail.mud.yahoo.com>
Message-ID: <1361832133.97884.YahooMailNeo@web31816.mail.mud.yahoo.com>
Date: Mon, 25 Feb 2013 14:42:13 -0800 (PST)
From: William Mills 
To: Phil Hunt , O Auth WG 
In-Reply-To: <1361831644.50183.YahooMailNeo@web31801.mail.mud.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-1238014912-1521137038-1361832133=:97884"
Subject: Re: [OAUTH-WG] OAuth2 attack surface....
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Feb 2013 22:42:15 -0000

---1238014912-1521137038-1361832133=:97884
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

=0A=0A=0A=0ADOH!!! =A0http://homakov.blogspot.co.uk/2013/02/hacking-faceboo=
k-with-oauth2-and-chrome.html=0A=0A=0A________________________________=0A F=
rom: Phil Hunt =0ATo: William Mills  =0ASent: Monday, February 25, 2013 2:28 PM=0ASubject: Re: [OAUTH-WG=
] OAuth2 attack surface....=0A =0A=0AWhats the link?=0A=0APhil=0A=0ASent fr=
om my phone.=0A=0AOn 2013-02-25, at 14:22, William Mills  wrote:=0A=0A=0AI think this is worth a read, I don't have time to di=
ve into this :(=0A_______________________________________________=0A>OAuth =
mailing list=0A>OAuth@ietf.org=0A>https://www.ietf.org/mailman/listinfo/oau=
th=0A>
---1238014912-1521137038-1361832133=:97884
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

=

=
=0ADOH!!!  http://homakov.blogspot.co.uk/2013/02/hacking-facebook-with-oauth2-and-=
chrome.html

        <=
b>From: Phil Hunt <phil.hun=
t@oracle.com>
 To: Wi=
lliam Mills <wmills_92105@yahoo.com> 
 Sent:
 Monday, February 25, 2013 2:28 PM
=0A Subject: Re: [OAUTH-WG] OAuth2 attack surface....

=0AWhats the link?

P=
hil
Sent from my phone.

On 2013-02-2=
5, at 14:22, William Mills <=
wmills_92105@yahoo.com> wrote:

I think this is worth a read, I don't have time to div=
e into this :(
_______________________________________________
OAut=
h mailing list
OAuth@ietf.org
https://www.ietf.org/=
mailman/listinfo/oauth

---1238014912-1521137038-1361832133=:97884--

From jricher@mitre.org  Mon Feb 25 14:58:50 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4557A21E8140 for ; Mon, 25 Feb 2013 14:58:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.576
X-Spam-Level: 
X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.022,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbcv2-ipsCjx for ; Mon, 25 Feb 2013 14:58:49 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 63A6321E80FE for ; Mon, 25 Feb 2013 14:58:49 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B4F97531022A; Mon, 25 Feb 2013 17:58:48 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A4402531022B; Mon, 25 Feb 2013 17:58:48 -0500 (EST)
Received: from IMCMBX01.MITRE.ORG ([169.254.1.25]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0318.004; Mon, 25 Feb 2013 17:58:48 -0500
From: "Richer, Justin P." 
To: William Mills 
Thread-Topic: [OAUTH-WG] OAuth2 attack surface....
Thread-Index: AQHOE6ur3a6hedYEIU2GnoIHTEpY3A==
Date: Mon, 25 Feb 2013 22:58:48 +0000
Message-ID: 
References: <1361830944.13340.YahooMailNeo@web31812.mail.mud.yahoo.com>  <1361831644.50183.YahooMailNeo@web31801.mail.mud.yahoo.com> <1361832133.97884.YahooMailNeo@web31816.mail.mud.yahoo.com>
In-Reply-To: <1361832133.97884.YahooMailNeo@web31816.mail.mud.yahoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.18.27]
Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E068A104FIMCMBX01MITREOR_"
MIME-Version: 1.0
Cc: O Auth WG 
Subject: Re: [OAUTH-WG] OAuth2 attack surface....
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Feb 2013 22:58:50 -0000

--_000_B33BFB58CCC8BE4998958016839DE27E068A104FIMCMBX01MITREOR_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

>From my read, it's a combination of browser bugs (it only affects Chrome) a=
nd Facebook's insistence on using the Implicit flow for everything.

While I don't at all care for the "sky is falling" rhetoric that seems to f=
ollow OAuth2, the author has some good suggestions for implementations: bin=
ding redirect URIs to particular flows, preference for the code flow, not u=
sing a default redirect_uri on a hosted domain with user-generated content.

But all of these are implementation issues that the OAuth2 protocol can't r=
eally address directly.

-- Justin

On Feb 25, 2013, at 5:42 PM, William Mills > wrote:

DOH!!!  http://homakov.blogspot.co.uk/2013/02/hacking-facebook-with-oauth2-=
and-chrome.html

________________________________
From: Phil Hunt >
To: William Mills >
Sent: Monday, February 25, 2013 2:28 PM
Subject: Re: [OAUTH-WG] OAuth2 attack surface....

Whats the link?

Phil

Sent from my phone.

On 2013-02-25, at 14:22, William Mills > wrote:

I think this is worth a read, I don't have time to dive into this :(
_______________________________________________
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

--_000_B33BFB58CCC8BE4998958016839DE27E068A104FIMCMBX01MITREOR_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable

>From my read, it's a combination of browser bugs (it only affects Chrome) a=
nd Facebook's insistence on using the Implicit flow for everything. 

While I don't at all care for the "sky is falling" rhetoric =
that seems to follow OAuth2, the author has some good suggestions for imple=
mentations: binding redirect URIs to particular flows, preference for the c=
ode flow, not using a default redirect_uri
 on a hosted domain with user-generated content.

But all of these are implementation issues that the OAuth2 protocol ca=
n't really address directly.

-- Justin

On Feb 25, 2013, at 5:42 PM, William Mills <wmills_92105@yahoo.com> wrote:

DOH!!!  http://homakov.blogspot.co.uk/2013/0=
2/hacking-facebook-with-oauth2-and-chrome.html

From: Phil Hunt <phil.hunt@oracle.com>

To: William Mills <wmills_92105@yahoo.com>

Sent: Monday, February 25, =
2013 2:28 PM

Subject: Re: [OAUTH-WG] OAu=
th2 attack surface....

Whats the link?

Phil

Sent from my phone.

On 2013-02-25, at 14:22, William Mills <wmills_92105@yahoo.com> wrote:

I think this is worth a read, I don't have time to dive into this :(

___________________________________________=
____

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

--_000_B33BFB58CCC8BE4998958016839DE27E068A104FIMCMBX01MITREOR_--

From ve7jtb@ve7jtb.com  Mon Feb 25 15:18:34 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADC821E80DA for ; Mon, 25 Feb 2013 15:18:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCXPRdeUHPdO for ; Mon, 25 Feb 2013 15:18:32 -0800 (PST)
Received: from mail-da0-f42.google.com (mail-da0-f42.google.com [209.85.210.42]) by ietfa.amsl.com (Postfix) with ESMTP id 746CF21E80E2 for ; Mon, 25 Feb 2013 15:18:32 -0800 (PST)
Received: by mail-da0-f42.google.com with SMTP id z17so1692975dal.15 for ; Mon, 25 Feb 2013 15:18:32 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=G/IhSTdcyjgd4yJBzzCnn1JpPm0zu6VV0a+oQ2sDjL4=; b=UH7lYCmaGbdt0qoyszERt1GLvqSN9FcrR4xAAdqAoioAnuUnDDLCaw9ch6743BzWvU yGReD/B6tJnpYFgslq/hHaBlCx9X1PWLrZf+L/qR42ovDwknE0vev7tBmwVTLDAmX/Xb Y2+NJTvdqmG1aZx5CEBj0x/CVjEkh2nlFcQXFeL8+yJVkeqo+4ZrDR1P+9sjGEonIfCo jPFGAgD/ArMBjH+h8O6yJQyJW/Zao1z11aSz2g8MkaTEgxtsvl8zcv7xTqmrbfZjHaKS sKS3D9EXalyudzEnhZOxnni5gD6L7boN4CCNfX1CyA4br7Zkpf/3Wi2jaNFJjDfwnKH/ 6IFg==
X-Received: by 10.68.237.165 with SMTP id vd5mr20883678pbc.52.1361834311657; Mon, 25 Feb 2013 15:18:31 -0800 (PST)
Received: from [10.10.2.32] ([12.144.179.211]) by mx.google.com with ESMTPS id 1sm14131082pba.32.2013.02.25.15.18.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Feb 2013 15:18:29 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_413CF6BC-6713-4A55-8B56-68250B2605F3"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$)
From: John Bradley 
In-Reply-To: 
Date: Mon, 25 Feb 2013 15:18:26 -0800
Message-Id: 
References: <1361830944.13340.YahooMailNeo@web31812.mail.mud.yahoo.com>  <1361831644.50183.YahooMailNeo@web31801.mail.mud.yahoo.com> <1361832133.97884.YahooMailNeo@web31816.mail.mud.yahoo.com> 
To: "Richer, Justin P." 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQnVwe5T3gaDgyF9IZMbjVSMKeVFw3cQ5J83tShNBSszWB5tf8NL/Pw8QDR+61BEbtGOB9hu
Cc: O Auth WG 
Subject: Re: [OAUTH-WG] OAuth2 attack surface....
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Feb 2013 23:18:34 -0000

--Apple-Mail=_413CF6BC-6713-4A55-8B56-68250B2605F3
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_63E32935-8AB5-4B87-BC35-D76F9100757B"

--Apple-Mail=_63E32935-8AB5-4B87-BC35-D76F9100757B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Agreed, though we can't assume that there won't be other browser bugs =
that can be exploited in similar ways.=20

Facebook automatically adding there debug page to the redirect URI of =
every client was...

We need to reenforce care around redirect URI, Connect is much more =
restrictive than OAuth.=20

I think client registering it's response types is a good idea,  I see it =
is already in the IETF registration spec.

John B.

On 2013-02-25, at 2:58 PM, "Richer, Justin P."  =
wrote:

> =46rom my read, it's a combination of browser bugs (it only affects =
Chrome) and Facebook's insistence on using the Implicit flow for =
everything.=20
>=20
> While I don't at all care for the "sky is falling" rhetoric that seems =
to follow OAuth2, the author has some good suggestions for =
implementations: binding redirect URIs to particular flows, preference =
for the code flow, not using a default redirect_uri on a hosted domain =
with user-generated content.
>=20
> But all of these are implementation issues that the OAuth2 protocol =
can't really address directly.
>=20
> -- Justin
>=20
>=20
> On Feb 25, 2013, at 5:42 PM, William Mills  =
wrote:
>=20
>>=20
>>=20
>> DOH!!!  =
http://homakov.blogspot.co.uk/2013/02/hacking-facebook-with-oauth2-and-chr=
ome.html
>>=20
>> From: Phil Hunt 
>> To: William Mills =20
>> Sent: Monday, February 25, 2013 2:28 PM
>> Subject: Re: [OAUTH-WG] OAuth2 attack surface....
>>=20
>> Whats the link?
>>=20
>> Phil
>>=20
>> Sent from my phone.
>>=20
>> On 2013-02-25, at 14:22, William Mills  =
wrote:
>>=20
>>> I think this is worth a read, I don't have time to dive into this :(
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail=_63E32935-8AB5-4B87-BC35-D76F9100757B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

jricher@mitre.org> =
wrote:

=46rom my read, it's a combination of browser bugs (it only affects =
Chrome) and Facebook's insistence on using the Implicit flow for =
everything. 

While I don't at all care for the "sky is falling" rhetoric that =
seems to follow OAuth2, the author has some good suggestions for =
implementations: binding redirect URIs to particular flows, preference =
for the code flow, not using a default redirect_uri
 on a hosted domain with user-generated content.

But all of these are implementation issues that the OAuth2 protocol =
can't really address directly.

-- Justin

On Feb 25, 2013, at 5:42 PM, William Mills <wmills_92105@yahoo.com> =
wrote:

http://homakov.blogspot.co.uk/2013/02/hacking-fa=
cebook-with-oauth2-and-chrome.html

From: Phil Hunt <phil.hunt@oracle.com>

To: William Mills <wmills_92105@yahoo.com>

Sent: Monday, February =
25, 2013 2:28 PM

Subject: Re: [OAUTH-WG] =
OAuth2 attack surface....

Whats the link?

Phil

Sent from my phone.

On 2013-02-25, at 14:22, William Mills <wmills_92105@yahoo.com> =
wrote:

_______________________________________________=

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

=

--Apple-Mail=_63E32935-8AB5-4B87-BC35-D76F9100757B--

--Apple-Mail=_413CF6BC-6713-4A55-8B56-68250B2605F3
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMjI1MjMxODI3WjAjBgkqhkiG9w0BCQQxFgQU7y8U3Qkb
YmrqVHM0BH8MYefP+ZswgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAsAuSa+TzhdhYlD7SNX1abTZJ67KdEU6YFvgMSa5E
AHqUU+2atA3laAz5Pq8mhLPYzlVA4KwcA1iP58/BjHF9hMmXHDTssPkesWH/us1+p4cQQuwhcYKN
wH+0/crO6V+zXCZlun9gveMpxaZani3ruNFNW1Y9iGCfdzvU2zEmr1D09HrxePCFjteYV0CnqpbJ
KIpcB5aZ3Osw/11dY+8JbfkcuJ+O2LwoSXayHi6pEuuXjsXJklmtCLOa3CA+Hrlrc6YfdqArg6l4
RRAOUUIRTdyjczj4+eT7WI1kc5tkGxlww05CKyVjK/JZlIPnDqww6HdVvi62p/0cNbxwBG0CwwAA
AAAAAA==

--Apple-Mail=_413CF6BC-6713-4A55-8B56-68250B2605F3--

From dick.hardt@gmail.com  Mon Feb 25 17:42:58 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF241F0D11 for ; Mon, 25 Feb 2013 17:42:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guw-2LCZYqRO for ; Mon, 25 Feb 2013 17:42:53 -0800 (PST)
Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by ietfa.amsl.com (Postfix) with ESMTP id A337E21E8127 for ; Mon, 25 Feb 2013 17:42:53 -0800 (PST)
Received: by mail-pa0-f48.google.com with SMTP id hz10so2082036pad.21 for ; Mon, 25 Feb 2013 17:42:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=/i9NJNFSHSW3tctsvCu2EbAjv6tsYPOuOl79/KKHmGU=; b=NVOx96ZtbwrqAME0Z676EdLCFR4d2vF2+ouyH2kBQB17oKzb+RIZzMZAAtbPlBi2jO /GLejbMw/lvHXtXyESzcLHkIKL7E9tEWAloLZQXyTayCy1RpJfTrKpyw5HFc/hBuUBAQ 4njoiAo+PXMsIGVyVzzK5LTf/lmPudNB85PofCAlUbnVzxApNYZXvjPTzXwRQT2I69IP dyDK3rWyyCm8eF4I+mtLxVU4U5EbPGPqA1T8k1irTt2Y03sPiZfhsgO4wXabrRHJMOYc Y55EMyBNrEMPSJZoMBvJDrTNI9I5wb+EavIbjsC5vWnfFN1FAq0r6mFW738Q6p5wIc1w sUcA==
X-Received: by 10.66.251.162 with SMTP id zl2mr22398866pac.36.1361842973487; Mon, 25 Feb 2013 17:42:53 -0800 (PST)
Received: from airstream.lan (S01061caff7df80fa.vc.shawcable.net. [24.85.86.234]) by mx.google.com with ESMTPS id hs8sm14505549pbc.27.2013.02.25.17.42.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Feb 2013 17:42:51 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_E7673573-BBBD-4563-8472-742E32E336EA"
Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$)
From: Dick Hardt 
In-Reply-To: 
Date: Mon, 25 Feb 2013 17:42:05 -0800
Message-Id: <535B0BAF-DA71-4B8E-914C-1523714EF0C6@gmail.com>
References: <1361830944.13340.YahooMailNeo@web31812.mail.mud.yahoo.com>  <1361831644.50183.YahooMailNeo@web31801.mail.mud.yahoo.com> <1361832133.97884.YahooMailNeo@web31816.mail.mud.yahoo.com> 
To: "Richer, Justin P." 
X-Mailer: Apple Mail (2.1499)
Cc: O Auth WG 
Subject: Re: [OAUTH-WG] OAuth2 attack surface....
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Feb 2013 01:42:58 -0000

--Apple-Mail=_E7673573-BBBD-4563-8472-742E32E336EA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I once again kick myself for not noticing the implicit flow was inserted =
into the spec =85 hopefully the warning labels keep others from =
supporting the implicit flow =85 but additional messaging about not =
supporting implicit flow would be useful.

I can see why Facebook wanted it for the content merging it provides, =
but it should likely have been a different API and authorization =
process.

On Feb 25, 2013, at 2:58 PM, "Richer, Justin P."  =
wrote:

> =46rom my read, it's a combination of browser bugs (it only affects =
Chrome) and Facebook's insistence on using the Implicit flow for =
everything.=20
>=20
> While I don't at all care for the "sky is falling" rhetoric that seems =
to follow OAuth2, the author has some good suggestions for =
implementations: binding redirect URIs to particular flows, preference =
for the code flow, not using a default redirect_uri on a hosted domain =
with user-generated content.
>=20
> But all of these are implementation issues that the OAuth2 protocol =
can't really address directly.
>=20
> -- Justin
>=20
>=20
> On Feb 25, 2013, at 5:42 PM, William Mills  =
wrote:
>=20
>>=20
>>=20
>> DOH!!!  =
http://homakov.blogspot.co.uk/2013/02/hacking-facebook-with-oauth2-and-chr=
ome.html
>>=20
>> From: Phil Hunt 
>> To: William Mills =20
>> Sent: Monday, February 25, 2013 2:28 PM
>> Subject: Re: [OAUTH-WG] OAuth2 attack surface....
>>=20
>> Whats the link?
>>=20
>> Phil
>>=20
>> Sent from my phone.
>>=20
>> On 2013-02-25, at 14:22, William Mills  =
wrote:
>>=20
>>> I think this is worth a read, I don't have time to dive into this :(
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail=_E7673573-BBBD-4563-8472-742E32E336EA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

I =
once again kick myself for not noticing the implicit flow was inserted =
into the spec =85 hopefully the warning labels keep others from =
supporting the implicit flow =85 but additional messaging about not =
supporting implicit flow would be useful.
I can see =
why Facebook wanted it for the content merging it provides, but it =
should likely have been a different API and authorization =
process.

On Feb 25, 2013, at 2:58 PM, "Richer, =
Justin P." <jricher@mitre.org> =
wrote:

=46rom my read, it's a combination of browser bugs (it only affects =
Chrome) and Facebook's insistence on using the Implicit flow for =
everything. 

While I don't at all care for the "sky is falling" rhetoric that =
seems to follow OAuth2, the author has some good suggestions for =
implementations: binding redirect URIs to particular flows, preference =
for the code flow, not using a default redirect_uri
 on a hosted domain with user-generated content.

But all of these are implementation issues that the OAuth2 protocol =
can't really address directly.

-- Justin

On Feb 25, 2013, at 5:42 PM, William Mills <wmills_92105@yahoo.com> =
wrote:

http://homakov.blogspot.co.uk/2013/02/hacking-fa=
cebook-with-oauth2-and-chrome.html

From: Phil Hunt <phil.hunt@oracle.com>

To: William Mills <wmills_92105@yahoo.com>

Sent: Monday, February =
25, 2013 2:28 PM

Subject: Re: [OAUTH-WG] =
OAuth2 attack surface....

Whats the link?

Phil

Sent from my phone.

On 2013-02-25, at 14:22, William Mills <wmills_92105@yahoo.com> =
wrote:

_______________________________________________=

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

=

--Apple-Mail=_E7673573-BBBD-4563-8472-742E32E336EA--

From asanso@adobe.com  Mon Feb 25 23:23:11 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90D021F9048 for ; Mon, 25 Feb 2013 23:23:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.598
X-Spam-Level: 
X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdkdTnUZBMQs for ; Mon, 25 Feb 2013 23:23:10 -0800 (PST)
Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id C3A5121F8202 for ; Mon, 25 Feb 2013 23:22:56 -0800 (PST)
Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKUSxi0HAKOKgAQGj4lSPpQNq6XnUTnHHZ@postini.com; Mon, 25 Feb 2013 23:22:57 PST
Received: from inner-relay-4.eur.adobe.com (inner-relay-4.adobe.com [193.104.215.14]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r1Q7Jp1v009739; Mon, 25 Feb 2013 23:19:52 -0800 (PST)
Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id r1Q7MrXL008650; Mon, 25 Feb 2013 23:22:54 -0800 (PST)
Received: from eurhub01.eur.adobe.com (10.128.4.30) by nahub02.corp.adobe.com (10.8.189.98) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 25 Feb 2013 23:22:53 -0800
Received: from eurmbx01.eur.adobe.com ([10.128.4.32]) by eurhub01.eur.adobe.com ([10.128.4.30]) with mapi; Tue, 26 Feb 2013 07:22:51 +0000
From: Antonio Sanso 
To: William Mills 
Date: Tue, 26 Feb 2013 07:22:43 +0000
Thread-Topic: [OAUTH-WG] OAuth2 attack surface....
Thread-Index: Ac4T8hX+ornJ06p4Q/GOM6EBidUikg==
Message-ID: <140EEABC-2787-4D9A-A1C5-6C973FED5BC8@adobe.com>
References: <1361830944.13340.YahooMailNeo@web31812.mail.mud.yahoo.com>  <1361831644.50183.YahooMailNeo@web31801.mail.mud.yahoo.com> <1361832133.97884.YahooMailNeo@web31816.mail.mud.yahoo.com>
In-Reply-To: <1361832133.97884.YahooMailNeo@web31816.mail.mud.yahoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_140EEABC27874D9AA1C56C973FED5BC8adobecom_"
MIME-Version: 1.0
Cc: O Auth WG 
Subject: Re: [OAUTH-WG] OAuth2 attack surface....
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Feb 2013 07:23:11 -0000

--_000_140EEABC27874D9AA1C56C973FED5BC8adobecom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

And a different one (still exploiting redirection and still implementation =
mistake) http://www.nirgoldshlager.com/2013/02/how-i-hacked-facebook-oauth-=
to-get-full.html

Regards

Antonio

On Feb 25, 2013, at 11:42 PM, William Mills wrote:

DOH!!!  http://homakov.blogspot.co.uk/2013/02/hacking-facebook-with-oauth2-=
and-chrome.html

________________________________
From: Phil Hunt >
To: William Mills >
Sent: Monday, February 25, 2013 2:28 PM
Subject: Re: [OAUTH-WG] OAuth2 attack surface....

Whats the link?

Phil

Sent from my phone.

On 2013-02-25, at 14:22, William Mills > wrote:

I think this is worth a read, I don't have time to dive into this :(
_______________________________________________
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

--_000_140EEABC27874D9AA1C56C973FED5BC8adobecom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

And a different one (still=
 exploiting redirection and still implementation mistake) http://www.nirgoldshlager.com/2013/02/how-i-hacked-facebook-oauth-t=
o-get-full.html
Regards

Ant=
onio

On Feb 25, 2013, at 11:42 PM, Willi=
am Mills wrote:

 =

DOH!!!  http://homakov.blogspot.co.uk/2013/02/hacking-facebook-with-oauth2-and-chr=
ome.html

  From: Phil Hunt <phil.hunt@oracle.com>
 To: William Mills <wmills_92105@yahoo.com> 
 Sent:
 Monday, February 25, 2013 2:28 PM

 Subject: Re: [OAUTH-WG] OA=
uth2 attack surface....

Whats the link?

Phil
Sent from my phone.

On 2013-02-25, at 14:22, Wil=
liam Mills <wmills_92105@yah=
oo.com> wrote:

=
I think this is worth a read, I don't have time to dive into this :(
_________=
______________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

  =

  _______________________________________=
________
OAuth mailing list
OAuth@i=
etf.org
https://www.ietf.org/mailman/listinfo/oauth
=

=

--_000_140EEABC27874D9AA1C56C973FED5BC8adobecom_--

From sberyozkin@gmail.com  Tue Feb 26 04:36:29 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5609121F8921 for ; Tue, 26 Feb 2013 04:36:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.883
X-Spam-Level: 
X-Spam-Status: No, score=-2.883 tagged_above=-999 required=5 tests=[AWL=-0.484, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdMkO6HyFTA3 for ; Tue, 26 Feb 2013 04:36:28 -0800 (PST)
Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by ietfa.amsl.com (Postfix) with ESMTP id E421C21F8821 for ; Tue, 26 Feb 2013 04:36:27 -0800 (PST)
Received: by mail-ee0-f48.google.com with SMTP id t10so2322209eei.21 for ; Tue, 26 Feb 2013 04:36:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=2N+sUPYNTjrofbOg4L4q5DZLIb4kXuJPbCLH8QQ7jIA=; b=IHPEkg0MPu3de+hhFey94iOsclDxUHFaxR0g6jEQ22xl9Xfoqj/9SkX8UaMKA+6k1F sX953R46aldL2G34XOUC1U404kTzlBOckx0q6mRM/MdOWsshr0ifOg4Xpvrkvw8EG/Ps uoy/+SdVGn4/nCp6+1Y0MaHfWuxfLPaQQWlB649hSZQD6s3eF4thejM1FNdwy7HhpwhU N//JwkSuQ2uq5drjn4CyQxm+B8bhrj8KoXQqxWhQe+v1lA5kPNkZpq9UHZkafkaE0nmy kTxXncd5HoZyDZBmhqmK5EWQQYOouC22jlq1c35aEcvl2eQ0eoQA72+mI2y1xE0+W7NL YdKg==
X-Received: by 10.14.194.198 with SMTP id m46mr49404552een.8.1361882184709; Tue, 26 Feb 2013 04:36:24 -0800 (PST)
Received: from [10.36.226.5] ([217.173.99.61]) by mx.google.com with ESMTPS id o3sm1252248eem.15.2013.02.26.04.36.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Feb 2013 04:36:23 -0800 (PST)
Message-ID: <512CAC45.9070501@gmail.com>
Date: Tue, 26 Feb 2013 12:36:21 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: oauth@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-http-mac and draft-tschofenig-oauth-hotk re-submitted
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Feb 2013 12:36:29 -0000

Hi Hannes
On 25/02/13 12:46, Hannes Tschofenig wrote:
> Hi all,
>
> I just submitted an updated version of the draft-ietf-oauth-v2-http-mac-03.txt.
>

It definitely has more interesting content (about architecture, session 
keys, etc) - this is really useful IMHO.

What I'm not really understanding is why a 2-way TLS transport for the 
session key is not even considered.
Instead this uber-complex (in the context of this spec, IMHO) JWT thing 
is there once again. I appreciate why it may be the case, primarily to 
do with reusing the work done around JWT and having some 
common/recommended access token representation, but disallowing a basic 
bearer token be 'enhanced' with MAC over two-way TLS seems like not 
ideal at all IMHO.
To be honest, I'm not sure why would anyone use JWT+MAC instead of just 
JWE, in cases when people are really comfortable with doing JWT. I guess 
we may be talking now about better security characteristics, but this 
will help a very limited audience as compared to a wider one which can 
use Bearer+MAC over 2-way TLS, straightforward, very cheap effort to get 
started.

just my 2c
Thanks, Sergey

> I would like to point out that this is **discussion input** -- not agreed content. Anything in the document is subject to change!
> You also may notice that there are a few questions in the writeup.
>
> I was trying to more specific about some of the design aspects that folks had proposed during the last few months.
> I have also re-submitted the draft-tschofenig-oauth-hotk, which includes a TLS and a JSON-based solution approach.
>
> In general, the open questions still seem to be related to
> * Key distribution: What should be described in a document? What is mandatory to implement?
> * Selective header field protection: This is something that was brought forward in discussions and I have included a proposal of how this could look like.
> * Channel Binding: Functionality is also included to deal with man-in-the-middle attacks against TLS. There are, however, two types of channel bindings defined in RFC 5929. Are both needed? If not, which one should be selected?
> * Integrity protection and data origin authentication in both directions: The current writeup allows the protection to be extended to messages beyond the initial request. This also offers key confirmation by the server and protection of any responses.
>
> Writing the text I also noticed that I do not quite understand how nested JWT documents are supposed to look like. For example, how do I encrypt the mac_key carried inside the JWT plus add a signature of all other fields? Currently, I have just encrypted the entire payload.
>
> I hope to have some discussions prior to the IETF meeting so that we have a more fruitful discussion at the face-to-face meeting.
>
> Ciao
> Hannes
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From sberyozkin@gmail.com  Tue Feb 26 04:49:29 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA7921F858E for ; Tue, 26 Feb 2013 04:49:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.843
X-Spam-Level: 
X-Spam-Status: No, score=-2.843 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GD3H2L9ydveS for ; Tue, 26 Feb 2013 04:49:28 -0800 (PST)
Received: from mail-ee0-f51.google.com (mail-ee0-f51.google.com [74.125.83.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE4D21F8552 for ; Tue, 26 Feb 2013 04:49:28 -0800 (PST)
Received: by mail-ee0-f51.google.com with SMTP id d17so2234826eek.38 for ; Tue, 26 Feb 2013 04:49:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=f8CUZNTqHZwethf2IhylAv2omjG8TTBVYZO3ODagqcY=; b=EV2OJvDQN3ZD+KI2mnwtkfMjGRRdS81VpY4iQIz7P6vPu4GEW89A/cNPXOYVbtu/Wm 9q5egOYT+wjzE6P6WTTWtFfrTi3/3Txc4FAPwPkDDF300StMzMyEKd0sy96f6/wLzpcS VXnXiyedWEOsmG1ByHeY5tCy0HnnWfiwUCvIHG4MIq51WIc59vsX+x7g9YcPC9B+DpcZ tLmdti+3WUeIcqZCkjDLT7dDmTIJ6tGnPOCPyHIx1d/fsJeedEeX4sYB0+R+JzsjpMCp 6SaGaYaWLxV9gl+npemK1z7J1X2BPf8z8I3EFlm/5oLqA/YPnmtUsZ7n/KFn991QZvnS ndXw==
X-Received: by 10.14.184.68 with SMTP id r44mr49373204eem.40.1361882967539; Tue, 26 Feb 2013 04:49:27 -0800 (PST)
Received: from [10.36.226.5] ([217.173.99.61]) by mx.google.com with ESMTPS id u44sm1332824eel.7.2013.02.26.04.49.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Feb 2013 04:49:26 -0800 (PST)
Message-ID: <512CAF54.1060204@gmail.com>
Date: Tue, 26 Feb 2013 12:49:24 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: oauth@ietf.org
References:  <512CAC45.9070501@gmail.com>
In-Reply-To: <512CAC45.9070501@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-http-mac and draft-tschofenig-oauth-hotk re-submitted
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Feb 2013 12:49:29 -0000

Hi Again
On 26/02/13 12:36, Sergey Beryozkin wrote:
> Hi Hannes
> On 25/02/13 12:46, Hannes Tschofenig wrote:
>> Hi all,
>>
>> I just submitted an updated version of the
>> draft-ietf-oauth-v2-http-mac-03.txt.
>>
>
> It definitely has more interesting content (about architecture, session
> keys, etc) - this is really useful IMHO.
>
> What I'm not really understanding is why a 2-way TLS transport for the
> session key is not even considered.
> Instead this uber-complex (in the context of this spec, IMHO) JWT thing
> is there once again. I appreciate why it may be the case, primarily to
> do with reusing the work done around JWT and having some
> common/recommended access token representation, but disallowing a basic
> bearer token be 'enhanced' with MAC over two-way TLS seems like not
> ideal at all IMHO.
> To be honest, I'm not sure why would anyone use JWT+MAC instead of just
> JWE, in cases when people are really comfortable with doing JWT. I guess
> we may be talking now about better security characteristics, but this
> will help a very limited audience as compared to a wider one which can
> use Bearer+MAC over 2-way TLS, straightforward, very cheap effort to get
> started.
>
Oops, I've misread, I think I did, I was reading a Session Key Transport 
to Resource Server section [1] where using JWT seems just OK, while a 
transport to the client section [2] does not enforce the use of JWT.

Sorry for a noise :-)

By the way, should the server be able to enforce the use of MAC as 
opposed to having a client preferring it with its audience info ? If the 
client does not understand it then it does not have the capabilities to 
work with this specific server.

Thanks, Sergey

[1] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03#section-4.2
[2] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03#section-4.1

> just my 2c
> Thanks, Sergey
>
>> I would like to point out that this is **discussion input** -- not
>> agreed content. Anything in the document is subject to change!
>> You also may notice that there are a few questions in the writeup.
>>
>> I was trying to more specific about some of the design aspects that
>> folks had proposed during the last few months.
>> I have also re-submitted the draft-tschofenig-oauth-hotk, which
>> includes a TLS and a JSON-based solution approach.
>>
>> In general, the open questions still seem to be related to
>> * Key distribution: What should be described in a document? What is
>> mandatory to implement?
>> * Selective header field protection: This is something that was
>> brought forward in discussions and I have included a proposal of how
>> this could look like.
>> * Channel Binding: Functionality is also included to deal with
>> man-in-the-middle attacks against TLS. There are, however, two types
>> of channel bindings defined in RFC 5929. Are both needed? If not,
>> which one should be selected?
>> * Integrity protection and data origin authentication in both
>> directions: The current writeup allows the protection to be extended
>> to messages beyond the initial request. This also offers key
>> confirmation by the server and protection of any responses.
>>
>> Writing the text I also noticed that I do not quite understand how
>> nested JWT documents are supposed to look like. For example, how do I
>> encrypt the mac_key carried inside the JWT plus add a signature of all
>> other fields? Currently, I have just encrypted the entire payload.
>>
>> I hope to have some discussions prior to the IETF meeting so that we
>> have a more fruitful discussion at the face-to-face meeting.
>>
>> Ciao
>> Hannes
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>

From hannes.tschofenig@gmx.net  Tue Feb 26 05:16:39 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E64621F88BE for ; Tue, 26 Feb 2013 05:16:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.775
X-Spam-Level: 
X-Spam-Status: No, score=-100.775 tagged_above=-999 required=5 tests=[AWL=-0.755, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMKJthN00c42 for ; Tue, 26 Feb 2013 05:16:38 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9C72321F8A8B for ; Tue, 26 Feb 2013 05:16:21 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.19]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MNfCm-1UD4TP2Vi6-007CGk for ; Tue, 26 Feb 2013 14:16:13 +0100
Received: (qmail invoked by alias); 26 Feb 2013 13:16:13 -0000
Received: from unknown (EHLO [10.255.131.117]) [194.251.119.201] by mail.gmx.net (mp019) with SMTP; 26 Feb 2013 14:16:13 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+oNt884NuoDoxVCHspMukMPjGEPLIrTukqwcxjIS mnoZXYoPwk72mM
From: Hannes Tschofenig 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Tue, 26 Feb 2013 15:16:11 +0200
Message-Id: <1959D58A-1463-4368-B306-CCCD00FFBC09@gmx.net>
To: IETF oauth WG 
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Subject: [OAUTH-WG] IETF#86 OAuth Agenda -- First Strawman Proposal
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Feb 2013 13:16:40 -0000

Hi guys,=20

please see the agenda proposal for the IETF#86 meeting. Let us know =
whether you have additional items or changes for existing items. =20

Ciao
Hannes & Derek

---

Web Authorization Protocol (oauth)

1540-1710 	Monday Afternoon Session II=20
Room: Boca 2

1. Assertions
30 min
Mike Jones?/Brian Campbell?

Relevant document:
http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/
http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/
http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/

2. Dynamic Registration
30 min
Justin Richer

Relevant document:
http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/

2. Interoperability Testing of OAuth 2.0 Specifications=20
30 min
Roland Hedberg

Relevant document:
https://github.com/andreassolberg/oictest

1730-1830 	Thursday Afternoon Session III
Room: Boca 1=09

3. OAuth Security
60 min
Phil Hunt

Relevant documents:
http://datatracker.ietf.org/doc/draft-tschofenig-oauth-security/
http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac/
http://datatracker.ietf.org/doc/draft-tschofenig-oauth-audience/
http://datatracker.ietf.org/doc/draft-tschofenig-oauth-hotk/

From hannes.tschofenig@gmx.net  Tue Feb 26 05:35:44 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6840321F8A48 for ; Tue, 26 Feb 2013 05:35:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.745
X-Spam-Level: 
X-Spam-Status: No, score=-100.745 tagged_above=-999 required=5 tests=[AWL=-0.725, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKGFYr4UgqMh for ; Tue, 26 Feb 2013 05:35:43 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 79B0521F8A55 for ; Tue, 26 Feb 2013 05:35:43 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.27]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LmQuq-1UjwQW2G1K-00a19X for ; Tue, 26 Feb 2013 14:35:42 +0100
Received: (qmail invoked by alias); 26 Feb 2013 13:35:42 -0000
Received: from unknown (EHLO [10.255.131.117]) [194.251.119.201] by mail.gmx.net (mp027) with SMTP; 26 Feb 2013 14:35:42 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/TQJFlZZLTzNakzHiKzzOSuzytZJBjriqJHoU6rS JcaiRazOO9C3kR
From: Hannes Tschofenig 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Tue, 26 Feb 2013 15:35:40 +0200
Message-Id: <0220BD89-A928-437B-907B-E36FB8843698@gmx.net>
To: IETF oauth WG 
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Subject: [OAUTH-WG] OAuth WG Milestone Update
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Feb 2013 13:35:44 -0000

Hi all,=20

we would like to submit an update of the milestones.=20

Here is the current milestone list:=20

---------

Done	Submit 'OAuth 2.0 Threat Model and Security Considerations' as a =
working group item
Done	Submit 'HTTP Authentication: MAC Authentication' as a working =
group item
Done	Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for =
consideration as a Proposed Standard
Done	Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for =
consideration as a Proposed Standard
May 2012	Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth =
2.0' to the IESG for consideration as a Proposed Standard
May 2012	Submit 'OAuth 2.0 Assertion Profile' to the IESG for =
consideration as a Proposed Standard
May 2012	Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG =
for consideration as a Proposed Standard
May 2012	Submit 'OAuth 2.0 Threat Model and Security =
Considerations' to the IESG for consideration as an Informational RFC
Aug 2012	Submit 'Token Revocation' to the IESG for consideration =
as a Proposed Standard [Starting point for the work will be =
http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]
Nov 2012	Submit 'JSON Web Token (JWT)' to the IESG for =
consideration as a Proposed Standard [Starting point for the work will =
be http://tools.ietf.org/html/draft-jones-json-web-token]
Nov 2012	Submit 'JSON Web Token (JWT) Bearer Token Profiles for =
OAuth 2.0' to the IESG for consideration as a Proposed Standard =
[Starting point for the work will be =
http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer]
Dec 2012	Submit 'HTTP Authentication: MAC Authentication' to the =
IESG for consideration as a Proposed Standard
Dec 2012	Submit 'OAuth Use Cases' to the IESG for consideration =
as an Informational RFC [Starting point for the work will be =
http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases] =20
Jul 2013	Submit 'OAuth Dynamic Client Registration Protocol' to =
the IESG for consideration as a Proposed Standard [Starting point for =
the work will be http://tools.ietf.org/html/draft-hardjono-oauth-dynreg]

---------

Here is our proposal

---------

Done	Submit 'OAuth 2.0 Threat Model and Security Considerations' as a =
working group item
Done	Submit 'HTTP Authentication: MAC Authentication' as a working =
group item
Done	Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for =
consideration as a Proposed Standard
Done	Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for =
consideration as a Proposed Standard
Done	Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for =
consideration as a Proposed Standard
Done	Submit 'OAuth 2.0 Threat Model and Security Considerations' to =
the IESG for consideration as an Informational RFC
Mar 2013	Submit 'Token Revocation' to the IESG for consideration =
as a Proposed Standard
Apr 2013	Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth =
2.0' to the IESG for consideration as a Proposed Standard
Apr 2013	Submit 'OAuth 2.0 Assertion Profile' to the IESG for =
consideration as a Proposed Standard
Aug 2013	Submit 'JSON Web Token (JWT) Bearer Token Profiles for =
OAuth 2.0' to the IESG for consideration as a Proposed Standard
Aug 2013	Submit 'JSON Web Token (JWT)' to the IESG for =
consideration as a Proposed Standard
Jul 2013		Submit 'HTTP Authentication: MAC Authentication' =
to the IESG for consideration as a Proposed Standard

???	Submit 'OAuth Use Cases' to the IESG for consideration as an =
Informational RFC
???	Submit 'OAuth Dynamic Client Registration Protocol' to the IESG =
for consideration as a Proposed Standard

---------

As you can see your input is needed.=20

Ciao
Hannes & Derek

From jricher@mitre.org  Tue Feb 26 07:06:23 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9815B21F8880 for ; Tue, 26 Feb 2013 07:06:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.577
X-Spam-Level: 
X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Na7RZC47qYbP for ; Tue, 26 Feb 2013 07:06:23 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2816621F887D for ; Tue, 26 Feb 2013 07:06:23 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8FD4C1F25B3 for ; Tue, 26 Feb 2013 10:06:22 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 828511F2497 for ; Tue, 26 Feb 2013 10:06:22 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 26 Feb 2013 10:06:22 -0500
Message-ID: <512CCF33.1090207@mitre.org>
Date: Tue, 26 Feb 2013 10:05:23 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: "oauth@ietf.org" 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.58]
Subject: [OAUTH-WG] Registration: JWK Urls
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Feb 2013 15:06:23 -0000

Right now, the Dynamic Registration draft has four URLs that deal with 
registering public keys for the client:

jwk_uri
jwk_encryption_uri
x509_uri
x509_encryption_uri

These are for use in things like JWK-based assertions for client 
authentication and signing/encryption with higher-level protocols.

Recent and impending changes in the JWK specification allow it to 
specify what a given key can be used for, and provide different formats 
for the keys including an x509 encoded certificate. These changes seem 
to get rid of the need for specifying for separate URLs for each format 
and function in registration.

It's been proposed, from the OIDC working group, to collapse all of 
these into a single, new parameter:

jwks_uri

Which would point specifically to a "JWK Set" as defined in the JWK draft.

I'm in favor of this simplifying change, and OIDC has already adopted it 
on their end. Thoughts?

  -- Justin

From bcampbell@pingidentity.com  Tue Feb 26 07:11:36 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E264321F8815 for ; Tue, 26 Feb 2013 07:11:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.095
X-Spam-Level: 
X-Spam-Status: No, score=-5.095 tagged_above=-999 required=5 tests=[AWL=-0.785, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLcSpKJpOuHn for ; Tue, 26 Feb 2013 07:11:36 -0800 (PST)
Received: from na3sys009aog138.obsmtp.com (na3sys009aog138.obsmtp.com [74.125.149.19]) by ietfa.amsl.com (Postfix) with ESMTP id F23EC21F8735 for ; Tue, 26 Feb 2013 07:11:35 -0800 (PST)
Received: from mail-ia0-f200.google.com ([209.85.210.200]) (using TLSv1) by na3sys009aob138.postini.com ([74.125.148.12]) with SMTP ID DSNKUSzQp/26zH+7eSWQKj9O2dVQ1vJ+Kjqq@postini.com; Tue, 26 Feb 2013 07:11:36 PST
Received: by mail-ia0-f200.google.com with SMTP id u20so14857302iag.3 for ; Tue, 26 Feb 2013 07:11:35 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=KMCj8hd7Tu4FDc30ECb1sdvVCr9vxGCTDJSX41HQE4I=; b=B8SisZxp4Hb45hCCZwR1MveGGxN53czURIQpeYxKDQUPOVOUopA4H81EnX0y3Pga1D fMKKC9nF2jF/HruxqcEeKiuw4ABvW3dPMz2t5Y+l9cSzpXBiwqMGT8Ow6OuovJpe95kQ 3eyeAK40gsaWCJAfBpxr8HwOfJHCqfa1m6dMiWPRnUrGaI5es/3spF/Jqwgukayl7w2m EYzvi4s4r9/0PwONrZz8o+AELXtHCEi+FhSGRFPyATfRAEgDTa2mxhUy4dmgrkkzrqGo QmIp6KWRgUQD2k62o1EYYa/mDVG7mcIHkADsmagNDdrfKIbTlujJ4tJwH4hqj6wyM9Xo Quog==
X-Received: by 10.50.184.226 with SMTP id ex2mr5796770igc.24.1361891495206; Tue, 26 Feb 2013 07:11:35 -0800 (PST)
X-Received: by 10.50.184.226 with SMTP id ex2mr5796766igc.24.1361891495107; Tue, 26 Feb 2013 07:11:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.63.3 with HTTP; Tue, 26 Feb 2013 07:11:05 -0800 (PST)
In-Reply-To: <512CCF33.1090207@mitre.org>
References: <512CCF33.1090207@mitre.org>
From: Brian Campbell 
Date: Tue, 26 Feb 2013 08:11:05 -0700
Message-ID: 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=14dae9340dadc9fbf104d6a212e1
X-Gm-Message-State: ALoCoQlbT9c325SCRplmDjW9L6X5xTu1tH4ys+P3d0Wq/msqpYoZPPA+8eS6e7hZTPpA1TWRhCUYrQ2s+d60Gm+C//+PFHL4DX4BFAdpwU40bJnPI3Ya4FHwmtQw6BpbcdLPqT22028C
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: JWK Urls
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Feb 2013 15:11:37 -0000

--14dae9340dadc9fbf104d6a212e1
Content-Type: text/plain; charset=ISO-8859-1

+1

On Tue, Feb 26, 2013 at 8:05 AM, Justin Richer  wrote:

> Right now, the Dynamic Registration draft has four URLs that deal with
> registering public keys for the client:
>
> jwk_uri
> jwk_encryption_uri
> x509_uri
> x509_encryption_uri
>
> These are for use in things like JWK-based assertions for client
> authentication and signing/encryption with higher-level protocols.
>
> Recent and impending changes in the JWK specification allow it to specify
> what a given key can be used for, and provide different formats for the
> keys including an x509 encoded certificate. These changes seem to get rid
> of the need for specifying for separate URLs for each format and function
> in registration.
>
> It's been proposed, from the OIDC working group, to collapse all of these
> into a single, new parameter:
>
> jwks_uri
>
> Which would point specifically to a "JWK Set" as defined in the JWK draft.
>
> I'm in favor of this simplifying change, and OIDC has already adopted it
> on their end. Thoughts?
>
>  -- Justin
> ______________________________**_________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/**listinfo/oauth
>

--14dae9340dadc9fbf104d6a212e1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+1

On Tue, Feb 26, 2013 at 8:05 AM, Justin Richer <jricher=
@mitre.org> wrote:

Right now, the Dynamic Registration draft ha=
s four URLs that deal with registering public keys for the client:

jwk_uri

jwk_encryption_uri

x509_uri

x509_encryption_uri

These are for use in things like JWK-based assertions for client authentica=
tion and signing/encryption with higher-level protocols.

Recent and impending changes in the JWK specification allow it to specify w=
hat a given key can be used for, and provide different formats for the keys=
 including an x509 encoded certificate. These changes seem to get rid of th=
e need for specifying for separate URLs for each format and function in reg=
istration.

It's been proposed, from the OIDC working group, to collapse all of the=
se into a single, new parameter:

jwks_uri

Which would point specifically to a "JWK Set" as defined in the J=
WK draft.

I'm in favor of this simplifying change, and OIDC has already adopted i=
t on their end. Thoughts?

=A0-- Justin

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

--14dae9340dadc9fbf104d6a212e1--

From ve7jtb@ve7jtb.com  Tue Feb 26 07:23:31 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A8F21F86FB for ; Tue, 26 Feb 2013 07:23:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIKy4Tn0ijO9 for ; Tue, 26 Feb 2013 07:23:30 -0800 (PST)
Received: from mail-da0-f42.google.com (mail-da0-f42.google.com [209.85.210.42]) by ietfa.amsl.com (Postfix) with ESMTP id 75E3621F86DD for ; Tue, 26 Feb 2013 07:23:30 -0800 (PST)
Received: by mail-da0-f42.google.com with SMTP id z17so2065158dal.15 for ; Tue, 26 Feb 2013 07:23:30 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=X2iFNol2VoYR411B/zzUj6SN+zAMnpGP6MpXOIX7UkU=; b=TtjeqoCXzz+fIgZcxkpwm31wZjdKYvzIumQjhP4lpnOTvijkxTlmFbSgSxjNIp9Q3m PT10XkbUOmWxtL4uvLKfwLkUkXNCHcDtBUhuFJKl2bja8c995KT4Pm3evNi77zJczpLc iBNfZDwe6rUSt4mWAFVgjZJJ26XlpnTpV7vytJnaSbVUa2g0nW6SQo07Yu/SVVtixXHc IYk2pFuOG4XjPTRezLpBY1Jfeo0OpjfWJVH1TI//nOB39iVyDRZCUSCprv7+tBKugvf/ 1NLvO0Zfuugs3MstRS5t14lV4gTbpMU+jxM9KMjEttzPQY7tHSnQ1lZ5C2360USksiqQ 8D3A==
X-Received: by 10.68.204.97 with SMTP id kx1mr24408509pbc.117.1361892210092; Tue, 26 Feb 2013 07:23:30 -0800 (PST)
Received: from [192.168.11.96] (ip-64-134-220-185.public.wayport.net. [64.134.220.185]) by mx.google.com with ESMTPS id 1sm1230487pba.32.2013.02.26.07.23.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Feb 2013 07:23:28 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_BBB53384-18C7-4C6E-8CA6-BE48FEFC76BC"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <512CCF33.1090207@mitre.org>
Date: Tue, 26 Feb 2013 07:23:15 -0800
Message-Id: 
References: <512CCF33.1090207@mitre.org>
To: Justin Richer 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQllNsZ5MIzkDCL12MRqbE7uLuNML5biq7XcDFNAZPoJyhGwT7i+zEAyL5Ii9EqEMvSP5uuR
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: JWK Urls
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Feb 2013 15:23:31 -0000

--Apple-Mail=_BBB53384-18C7-4C6E-8CA6-BE48FEFC76BC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

One of the goals on the JWK side was to be able to simplify it.

I support the change.

John B.
On 2013-02-26, at 7:05 AM, Justin Richer  wrote:

> Right now, the Dynamic Registration draft has four URLs that deal with =
registering public keys for the client:
>=20
> jwk_uri
> jwk_encryption_uri
> x509_uri
> x509_encryption_uri
>=20
> These are for use in things like JWK-based assertions for client =
authentication and signing/encryption with higher-level protocols.
>=20
> Recent and impending changes in the JWK specification allow it to =
specify what a given key can be used for, and provide different formats =
for the keys including an x509 encoded certificate. These changes seem =
to get rid of the need for specifying for separate URLs for each format =
and function in registration.
>=20
> It's been proposed, from the OIDC working group, to collapse all of =
these into a single, new parameter:
>=20
> jwks_uri
>=20
> Which would point specifically to a "JWK Set" as defined in the JWK =
draft.
>=20
> I'm in favor of this simplifying change, and OIDC has already adopted =
it on their end. Thoughts?
>=20
> -- Justin
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail=_BBB53384-18C7-4C6E-8CA6-BE48FEFC76BC
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMjI2MTUyMzE1WjAjBgkqhkiG9w0BCQQxFgQUrR9MqEn3
8KzBxOXTBubuqmMOxWEwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAepcEC9bWFJZiTS0HfcKQF9PGRUJ3HcNfhmig4B8l
008/Ozv3mlSb4nROPGjzDJ1xHRkUwtaT4GrUtblIsDtu2Ue7xq3BUHhkt/zBOJdjJcX1ZfO7ndyh
j0exdfneTw+gnNzNlplc2pHEQZRhJxzK0gHo41bSg5dG8UsDsFQCQG4Mj0fFc2BB1/zj5tNrJ4Nw
B8p9DQzeeZa5z9YUkdxNGl+1wLfBTtKET9gmkOTHQtjbeOzWuTQs6zYQKWtGg5ZSX+DKYAXEEHoT
r/PaHM1ARqR2K8dsEX6kjnw8dsSJe7fXQbcpieHQMF8nNAYer4VoXhFAJTTvNo+5RMKTBN9GjgAA
AAAAAA==

--Apple-Mail=_BBB53384-18C7-4C6E-8CA6-BE48FEFC76BC--

From wwwrun@rfc-editor.org  Tue Feb 26 09:08:25 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170F121F8704 for ; Tue, 26 Feb 2013 09:08:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.326
X-Spam-Level: 
X-Spam-Status: No, score=-102.326 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrEcZ8qdZA1G for ; Tue, 26 Feb 2013 09:08:24 -0800 (PST)
Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 110C621F8700 for ; Tue, 26 Feb 2013 09:08:24 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 9FB6072E12F; Tue, 26 Feb 2013 09:07:11 -0800 (PST)
To: dick.hardt@gmail.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, Hannes.Tschofenig@gmx.net, derek@ihtfp.com
From: RFC Errata System 
Message-Id: <20130226170711.9FB6072E12F@rfc-editor.org>
Date: Tue, 26 Feb 2013 09:07:11 -0800 (PST)
Cc: johnp.field@emc.com, oauth@ietf.org, rfc-editor@rfc-editor.org
Subject: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (3500)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Feb 2013 17:08:25 -0000

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=3500

--------------------------------------
Type: Editorial
Reported by: John Field 

Section: 4.1

Original Text
-------------
(E)  The authorization server authenticates the client, validates the
     authorization code, and ensures that the redirection URI
     received matches the URI used to redirect the client in
     step (C).  If valid, the authorization server responds back with
     an access token and, optionally, a refresh token.

Corrected Text
--------------
(E)  The authorization server authenticates the client, validates the
     authorization code, and ensures that the redirection URI
     received matches the URI used to redirect (the resource owner's user-agent) 
     to the client in step (C).  If valid, the authorization server 
     responds back with an access token and, optionally, a refresh token.

Notes
-----
The URI in question is the URI that was used to redirect the resource owner's user-agent back to the client to deliver the code.  The original text in step (E) seems to say that this URI was used to redirect the client, but I think this is an ambiguous/imprecise use of the word "client."  It was not the OAuth client that was redirected using that URI, it was the resource owner's user-agent that was redirected, *to* the client.

The parenthetical (the resource owner's user-agent) is more precise but may perhaps be too verbose.  I think, at minimum, we must say "....the URI used to redirect *to* the client in step (C)."

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6749 (draft-ietf-oauth-v2-31)
--------------------------------------
Title               : The OAuth 2.0 Authorization Framework
Publication Date    : October 2012
Author(s)           : D. Hardt, Ed.
Category            : PROPOSED STANDARD
Source              : Web Authorization Protocol
Area                : Security
Stream              : IETF
Verifying Party     : IESG

From hannes.tschofenig@gmx.net  Wed Feb 27 00:46:37 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AEFB21F850C for ; Wed, 27 Feb 2013 00:46:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.117
X-Spam-Level: 
X-Spam-Status: No, score=-100.117 tagged_above=-999 required=5 tests=[AWL=-1.297, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_63=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YNe1FPIFj6Y for ; Wed, 27 Feb 2013 00:46:36 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 95E1B21F8506 for ; Wed, 27 Feb 2013 00:46:36 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.29]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LxIqi-1UvDiz2ABu-0170zh for ; Wed, 27 Feb 2013 09:46:35 +0100
Received: (qmail invoked by alias); 27 Feb 2013 08:46:35 -0000
Received: from unknown (EHLO [10.255.128.80]) [194.251.119.201] by mail.gmx.net (mp029) with SMTP; 27 Feb 2013 09:46:35 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/ycJpiBhXyyKdZqNsuFdOko0jIUYA5wtwv/aqS7G SkPu+Br37N06x6
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Hannes Tschofenig 
In-Reply-To: <512CAC45.9070501@gmail.com>
Date: Wed, 27 Feb 2013 10:46:30 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7E351B5A-5609-46B0-A15A-CF3FA1D97D56@gmx.net>
References:  <512CAC45.9070501@gmail.com>
To: Sergey Beryozkin 
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-http-mac and draft-tschofenig-oauth-hotk re-submitted
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Feb 2013 08:46:37 -0000

Hi Sergey,=20

thanks for your input.=20

On Feb 26, 2013, at 2:36 PM, Sergey Beryozkin wrote:

> Hi Hannes
> On 25/02/13 12:46, Hannes Tschofenig wrote:
>> Hi all,
>>=20
>> I just submitted an updated version of the =
draft-ietf-oauth-v2-http-mac-03.txt.
>>=20
>=20
> It definitely has more interesting content (about architecture, =
session keys, etc) - this is really useful IMHO.
>=20
> What I'm not really understanding is why a 2-way TLS transport for the =
session key is not even considered.

Could you explain how this would look like?=20

> Instead this uber-complex (in the context of this spec, IMHO) JWT =
thing is there once again. I appreciate why it may be the case, =
primarily to do with reusing the work done around JWT and having some =
common/recommended access token representation, but disallowing a basic =
bearer token be 'enhanced' with MAC over two-way TLS seems like not =
ideal at all IMHO.

Note that JWT is used only for the access token encoding.=20

> To be honest, I'm not sure why would anyone use JWT+MAC instead of =
just JWE,

Actually, the authorization server encrypts the access token using JWE =
and the client uses MAC.=20
So, using JWT + MAC is actually not possible since the security =
mechanisms are used by different entities: the MAC is used by the client =
and the access token protection is accomplished by the authorization =
server.=20

> in cases when people are really comfortable with doing JWT. I guess we =
may be talking now about better security characteristics, but this will =
help a very limited audience as compared to a wider one which can use =
Bearer+MAC over 2-way TLS, straightforward, very cheap effort to get =
started.
>=20

Ciao
Hannes

> just my 2c
> Thanks, Sergey
>=20
>> I would like to point out that this is **discussion input** -- not =
agreed content. Anything in the document is subject to change!
>> You also may notice that there are a few questions in the writeup.
>>=20
>> I was trying to more specific about some of the design aspects that =
folks had proposed during the last few months.
>> I have also re-submitted the draft-tschofenig-oauth-hotk, which =
includes a TLS and a JSON-based solution approach.
>>=20
>> In general, the open questions still seem to be related to
>> * Key distribution: What should be described in a document? What is =
mandatory to implement?
>> * Selective header field protection: This is something that was =
brought forward in discussions and I have included a proposal of how =
this could look like.
>> * Channel Binding: Functionality is also included to deal with =
man-in-the-middle attacks against TLS. There are, however, two types of =
channel bindings defined in RFC 5929. Are both needed? If not, which one =
should be selected?
>> * Integrity protection and data origin authentication in both =
directions: The current writeup allows the protection to be extended to =
messages beyond the initial request. This also offers key confirmation =
by the server and protection of any responses.
>>=20
>> Writing the text I also noticed that I do not quite understand how =
nested JWT documents are supposed to look like. For example, how do I =
encrypt the mac_key carried inside the JWT plus add a signature of all =
other fields? Currently, I have just encrypted the entire payload.
>>=20
>> I hope to have some discussions prior to the IETF meeting so that we =
have a more fruitful discussion at the face-to-face meeting.
>>=20
>> Ciao
>> Hannes
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From hannes.tschofenig@gmx.net  Wed Feb 27 00:58:01 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00AB321F85D6 for ; Wed, 27 Feb 2013 00:58:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.069
X-Spam-Level: 
X-Spam-Status: No, score=-100.069 tagged_above=-999 required=5 tests=[AWL=-1.249, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_63=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ploQgRBvqzwK for ; Wed, 27 Feb 2013 00:58:00 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1707E21F85EB for ; Wed, 27 Feb 2013 00:57:59 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.27]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LrXxT-1UosA749an-013Q9E for ; Wed, 27 Feb 2013 09:57:59 +0100
Received: (qmail invoked by alias); 27 Feb 2013 08:57:58 -0000
Received: from unknown (EHLO [10.255.128.80]) [194.251.119.201] by mail.gmx.net (mp027) with SMTP; 27 Feb 2013 09:57:58 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19ouNkj7YtomCMNYVJTHKtor4Iam1D1sK2D3ZTc2D mqYoAPspn7XPDK
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Hannes Tschofenig 
In-Reply-To: <512CAF54.1060204@gmail.com>
Date: Wed, 27 Feb 2013 10:54:42 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1EE69E99-6051-4078-8CDE-63558075FE16@gmx.net>
References:  <512CAC45.9070501@gmail.com> <512CAF54.1060204@gmail.com>
To: Sergey Beryozkin 
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-http-mac and draft-tschofenig-oauth-hotk re-submitted
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Feb 2013 08:58:01 -0000

Hi Sergey,=20

good that this issue got clarified.=20

Regarding:=20

> By the way, should the server be able to enforce the use of MAC as =
opposed to having a client preferring it with its audience info ? If the =
client does not understand it then it does not have the capabilities to =
work with this specific server.

Currently, the authorization server decides about the use of a certain =
token type. The audience field is used to allow the client to tell the =
server which resource  server it wants to talk to. This is of value not =
only for this specification but also for the bearer token specification. =
In this specification the resource server uses this audience field for =
selecting the appropriate key to encrypt the access token. If the client =
is tricked in sending the access token to a different resource server =
then that server will not be able to decrypt the access token and will =
not be able to retrieve the session key. Consequently, it will not be =
able to impersonate the client towards another resource server.=20

Ciao
Hannes

On Feb 26, 2013, at 2:49 PM, Sergey Beryozkin wrote:

> Hi Again
> On 26/02/13 12:36, Sergey Beryozkin wrote:
>> Hi Hannes
>> On 25/02/13 12:46, Hannes Tschofenig wrote:
>>> Hi all,
>>>=20
>>> I just submitted an updated version of the
>>> draft-ietf-oauth-v2-http-mac-03.txt.
>>>=20
>>=20
>> It definitely has more interesting content (about architecture, =
session
>> keys, etc) - this is really useful IMHO.
>>=20
>> What I'm not really understanding is why a 2-way TLS transport for =
the
>> session key is not even considered.
>> Instead this uber-complex (in the context of this spec, IMHO) JWT =
thing
>> is there once again. I appreciate why it may be the case, primarily =
to
>> do with reusing the work done around JWT and having some
>> common/recommended access token representation, but disallowing a =
basic
>> bearer token be 'enhanced' with MAC over two-way TLS seems like not
>> ideal at all IMHO.
>> To be honest, I'm not sure why would anyone use JWT+MAC instead of =
just
>> JWE, in cases when people are really comfortable with doing JWT. I =
guess
>> we may be talking now about better security characteristics, but this
>> will help a very limited audience as compared to a wider one which =
can
>> use Bearer+MAC over 2-way TLS, straightforward, very cheap effort to =
get
>> started.
>>=20
> Oops, I've misread, I think I did, I was reading a Session Key =
Transport to Resource Server section [1] where using JWT seems just OK, =
while a transport to the client section [2] does not enforce the use of =
JWT.
>=20
> Sorry for a noise :-)
>=20
> By the way, should the server be able to enforce the use of MAC as =
opposed to having a client preferring it with its audience info ? If the =
client does not understand it then it does not have the capabilities to =
work with this specific server.
>=20
> Thanks, Sergey
>=20
> [1] =
http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03#section-4.2
> [2] =
http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03#section-4.1
>=20
>> just my 2c
>> Thanks, Sergey
>>=20
>>> I would like to point out that this is **discussion input** -- not
>>> agreed content. Anything in the document is subject to change!
>>> You also may notice that there are a few questions in the writeup.
>>>=20
>>> I was trying to more specific about some of the design aspects that
>>> folks had proposed during the last few months.
>>> I have also re-submitted the draft-tschofenig-oauth-hotk, which
>>> includes a TLS and a JSON-based solution approach.
>>>=20
>>> In general, the open questions still seem to be related to
>>> * Key distribution: What should be described in a document? What is
>>> mandatory to implement?
>>> * Selective header field protection: This is something that was
>>> brought forward in discussions and I have included a proposal of how
>>> this could look like.
>>> * Channel Binding: Functionality is also included to deal with
>>> man-in-the-middle attacks against TLS. There are, however, two types
>>> of channel bindings defined in RFC 5929. Are both needed? If not,
>>> which one should be selected?
>>> * Integrity protection and data origin authentication in both
>>> directions: The current writeup allows the protection to be extended
>>> to messages beyond the initial request. This also offers key
>>> confirmation by the server and protection of any responses.
>>>=20
>>> Writing the text I also noticed that I do not quite understand how
>>> nested JWT documents are supposed to look like. For example, how do =
I
>>> encrypt the mac_key carried inside the JWT plus add a signature of =
all
>>> other fields? Currently, I have just encrypted the entire payload.
>>>=20
>>> I hope to have some discussions prior to the IETF meeting so that we
>>> have a more fruitful discussion at the face-to-face meeting.
>>>=20
>>> Ciao
>>> Hannes
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From wmills_92105@yahoo.com  Wed Feb 27 01:12:56 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBFC721F85F5 for ; Wed, 27 Feb 2013 01:12:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.318
X-Spam-Level: 
X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=0.280,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMz-Xf6bk9HK for ; Wed, 27 Feb 2013 01:12:56 -0800 (PST)
Received: from nm37.bullet.mail.bf1.yahoo.com (nm37.bullet.mail.bf1.yahoo.com [72.30.239.57]) by ietfa.amsl.com (Postfix) with ESMTP id B14E221F85FC for ; Wed, 27 Feb 2013 01:12:55 -0800 (PST)
Received: from [98.139.212.147] by nm37.bullet.mail.bf1.yahoo.com with NNFMP; 27 Feb 2013 09:12:55 -0000
Received: from [98.139.212.211] by tm4.bullet.mail.bf1.yahoo.com with NNFMP; 27 Feb 2013 09:12:55 -0000
Received: from [127.0.0.1] by omp1020.mail.bf1.yahoo.com with NNFMP; 27 Feb 2013 09:12:55 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 26450.59172.bm@omp1020.mail.bf1.yahoo.com
Received: (qmail 14502 invoked by uid 60001); 27 Feb 2013 09:12:54 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1361956374; bh=p2ZwHfjuBl1zmun2uVOdtNAuhfGD6TBBfTFP4EnuZaU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=hs/8wmGV42lxczLviTQEfiM0tvl+eB4w6TU4+J4E3xZSSl/L7wMZxb/fSJ/cT90rff7LqbjPOWTFl1T4JAWXNO6sIlZFTgbLv6OJo6FcwtOxuxII0CBsLDrV9URqUXZVPR7ukHqFawhy6FpiroU7vjtDI3jV5tbqRM4VVcIPJbU=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=45NZveOZWiAcnBD0zRrJblflQHn2rebOMGEcvzMb7TYJGDklf3o16CNZtQPk7zUlZ7kZBqFv3Hb9YKQN86LkWf4pZ/lNP4ekO7CNjSHpgkJ6DKgnnkk4S1VqZBKv/j5lKtgg1tWdoEEwu4+6IKmMo1+LZMqD2ZAmTGSsK1UwTGM=;
X-YMail-OSG: X1KNjWsVM1n6doj7Lw6rC66liX8jGGoCkn5fR.K3c2jESGK 8A2.N92wGUWIqkYo.fIup5Ye7_fNH49Ge_u2apjscYwafJ8W2ZZyRadPNsNo xUv.R0360jyLW7Kp9cRXEvto0oyjiCPc9K33SlAawWdSi4Hez6HNf.mmisG8 yLwJfLaBipa64DBdZK.mNlYyLxodJJ7ibWEOxx88OsnRgzJNlpKYcTIUJ52k o2SegfgQ6AI9DtOeYD.zt_3svpFcebzGIIBN1mFDWvUYAUM5PBQLme6UPABC Ln2.q_qiXrlRejJ3nLzMWWHG.rDgevW85PywuYGa80xXzFmvbo9LLROwPLAN 8xbBVukU4mYKRoOjF2v6XVsJTElOrFaNG1oR2UXhf3drYUcouMofNVl4UNa0 ev2xnqdFY2JHYyCGFDEed6v5oTizuWk4PBGbpOmm.i0vC.leexgupruNIPRb C7kqEdoVWeg88SM.Kg0pmxYDsYhiECwcbG87XXrAlq72OtnOiSIUZ75c0baU 93LxXG_ipBjTejFFz8KHA7wAfad5mufSJegeIb4IetXHD_R0bCRyVTq0eFOJ x
Received: from [209.131.62.115] by web31807.mail.mud.yahoo.com via HTTP; Wed, 27 Feb 2013 01:12:53 PST
X-Rocket-MIMEInfo: 001.001, SnVzdCByZWFkIHRoZSBkcmFmdCBxdWlja2x5LiDCoAoKU2luY2Ugd2UncmUgbm93IGxlYW5pbmcgb24gSldUIGRvIHdlIG5lZWQgdG8gaW5jbHVkZSB0aGUgdG9rZW4gaW4gdGhpcz8gwqBXaHkgbm90IGp1c3QgbWFrZSBhbiBhZGRpdGlvbmFsICJFbnZlbG9wZSBNQUMiIHRoaW5nIGFuZCBoYXZlIHRoZSBzaWduYXR1cmUgaW5jbHVkZSB0aGUgMyBKV1QgcGFydHMgaW4gdGhlIHNpZ25hdHVyZSBiYXNlIHN0cmluZz8gwqBUaGF0IG9iamVjdCB0aGVuIGp1c3QgYmVjb21lcyBhIEpTT04gY29udGFpbmVyIGZvciABMAEBAQE-
X-Mailer: YahooMailWebService/0.8.135.514
References: <20130225124642.7425.65145.idtracker@ietfa.amsl.com>
Message-ID: <1361956373.9883.YahooMailNeo@web31807.mail.mud.yahoo.com>
Date: Wed, 27 Feb 2013 01:12:53 -0800 (PST)
From: William Mills 
To: "oauth@ietf.org" , Hannes Tschofenig 
In-Reply-To: <20130225124642.7425.65145.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-125733401-455653446-1361956373=:9883"
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Feb 2013 09:12:56 -0000

---125733401-455653446-1361956373=:9883
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Just read the draft quickly. =A0=0A=0ASince we're now leaning on JWT do we =
need to include the token in this? =A0Why not just make an additional "Enve=
lope MAC" thing and have the signature include the 3 JWT parts in the signa=
ture base string? =A0That object then just becomes a JSON container for the=
 kid, timestamp, signature method, signature etc. That thing then is a 4th =
base64 encoded JSON thing in the auth header.=0A=0AHow header fields get in=
cluded in the signature needs definition.=0A=0AWhy did you kill the port nu=
mber, nonce, and extension parameter out of the signature base string?=0A=
=0AThe BNF appears to have no separators between values.=0A=0A-bill=0A=0A=
=0A=0A________________________________=0A From: "internet-drafts@ietf.org" =
=0ATo: i-d-announce@ietf.org =0ACc: oauth@ietf.or=
g =0ASent: Monday, February 25, 2013 4:46 AM=0ASubject: [OAUTH-WG] I-D Acti=
on: draft-ietf-oauth-v2-http-mac-03.txt=0A =0A=0AA New Internet-Draft is av=
ailable from the on-line Internet-Drafts directories.=0AThis draft is a wor=
k item of the Web Authorization Protocol Working Group of the IETF.=0A=0A=
=A0=A0=A0 Title=A0 =A0 =A0 =A0 =A0  : OAuth 2.0 Message Authentication Code=
 (MAC) Tokens=0A=A0=A0=A0 Author(s)=A0 =A0 =A0  : Justin Richer=0A=A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 William Mills=0A=A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hannes Tschofenig=0A=A0=A0=A0 Filename=
=A0 =A0 =A0 =A0 : draft-ietf-oauth-v2-http-mac-03.txt=0A=A0=A0=A0 Pages=A0 =
=A0 =A0 =A0 =A0  : 26=0A=A0=A0=A0 Date=A0 =A0 =A0 =A0 =A0 =A0 : 2013-02-25=
=0A=0AAbstract:=0A=A0  This specification describes how to use MAC Tokens i=
n HTTP requests=0A=A0  to access OAuth 2.0 protected resources.=A0 An OAuth=
 client willing to=0A=A0  access a protected resource needs to demonstrate =
possession of a=0A=A0  crytographic key by using it with a keyed message di=
gest function to=0A=A0  the request.=0A=0A=A0  The document also defines a =
key distribution protocol for obtaining a=0A=A0  fresh session key.=0A=0A=
=0AThe IETF datatracker status page for this draft is:=0Ahttps://datatracke=
r.ietf.org/doc/draft-ietf-oauth-v2-http-mac=0A=0AThere's also a htmlized ve=
rsion available at:=0Ahttp://tools.ietf.org/html/draft-ietf-oauth-v2-http-m=
ac-03=0A=0AA diff from the previous version is available at:=0Ahttp://www.i=
etf.org/rfcdiff?url2=3Ddraft-ietf-oauth-v2-http-mac-03=0A=0A=0AInternet-Dra=
fts are also available by anonymous FTP at:=0Aftp://ftp.ietf.org/internet-d=
rafts/=0A=0A_______________________________________________=0AOAuth mailing=
 list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth
---125733401-455653446-1361956373=:9883
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Just read the draft quickly.  

Since we're now leaning on =
JWT do we need to include the token in this?  Why not just make an add=
itional "Envelope MAC" thing and have the signature include the 3 JWT parts=
 in the signature base string?  That object then just becomes a JSON c=
ontainer for the kid, timestamp, signature method, signature etc. That thin=
g then is a 4th base64 encoded JSON thing in the auth
 header.

How header fields get included in the signature needs de=
finition.

Why did you kill the port number, nonce, and extension =
parameter out of the signature base string?
The BNF appears to hav=
e no separators between values.
-bill

  =

  From: "internet-d=
rafts@ietf.org" <internet-drafts@ietf.org>
 To: i-d-announce@ietf.org 
Cc: oauth@ietf.org 
 Sent: Monday, February 25, 2013 4:46 AM
 Subject: [OAUTH-WG] I-D Acti=
on: draft-ietf-oauth-v2-http-mac-03.txt

=0A
A New=
 Internet-Draft is available from the on-line Internet-Drafts directories.<=
br> This draft is a work item of the Web Authorization Protocol Working Gro=
up of the IETF.

    Title        =
   : OAuth 2.0 Message Authentication Code (MAC) Tokens
  =
;  Author(s)       : Justin Richer
    &nb=
sp;                     W=
illiam Mills
                &nb=
sp;         Hannes Tschofenig
    Fil=
ename        : draft-ietf-oauth-v2-http-mac-03.txt
&=
nbsp;   Pages           : 26
 &n=
bsp;  Date            : 2013-02-25
Abstract:
   This specification describes how to use MAC Tokens i=
n HTTP requests
   to access OAuth 2.0 protected
 resources.  An OAuth client willing to
   access a protected =
resource needs to demonstrate possession of a
   crytographic key b=
y using it with a keyed message digest function to
   the request.<=
br>
   The document also defines a key distribution protocol for ob=
taining a
   fresh session key.

The IETF datatracker sta=
tus page for this draft is:
https://datatracker.ietf.or=
g/doc/draft-ietf-oauth-v2-http-mac

There's also a htmlized versi=
on available at:
http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac=
-03

A diff from the previous version is available at:
http://www.=
ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-v2-http-mac-03

Internet=
-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_________=
______________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

---125733401-455653446-1361956373=:9883--

From wmills_92105@yahoo.com  Wed Feb 27 01:18:56 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9173221F84C9 for ; Wed, 27 Feb 2013 01:18:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.33
X-Spam-Level: 
X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[AWL=0.268,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXyNH0NiqlBY for ; Wed, 27 Feb 2013 01:18:55 -0800 (PST)
Received: from nm5-vm1.bullet.mail.ne1.yahoo.com (nm5-vm1.bullet.mail.ne1.yahoo.com [98.138.91.32]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9FB21F8491 for ; Wed, 27 Feb 2013 01:18:55 -0800 (PST)
Received: from [98.138.90.54] by nm5.bullet.mail.ne1.yahoo.com with NNFMP; 27 Feb 2013 09:18:55 -0000
Received: from [98.138.89.252] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 27 Feb 2013 09:18:55 -0000
Received: from [127.0.0.1] by omp1044.mail.ne1.yahoo.com with NNFMP; 27 Feb 2013 09:18:55 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 7401.43848.bm@omp1044.mail.ne1.yahoo.com
Received: (qmail 77804 invoked by uid 60001); 27 Feb 2013 09:18:54 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1361956734; bh=N6/wP1/O5is5HBfl3sHIFMrVxAz0t/2uqvqkQrrXhuc=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=QTkTrDw4RoWzSlAzcB+jubU8GcXcZQ8B8eFQz0ihwSHc+ZGXylJdW80faPQWyD+vl/1QRvGXGj74eMYKYhTLgPQuv3i5PjaTRoZxXygS7Fib0FEHEUJHXaVM6kC0cc4zSCU9LIcDWDVCC1zq+LhJ5yOPeSrxnm7tE/h9m3pbU3k=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=WXcKRAjKp+muO5cTOwdNfe6uCrOf70sz9P8ls7PlaQR6ODvnodsY2j5rYtDEqlF0/00Hss0lDjqNEPu8N9ZqwAuskMYTlBgypowYiVMP8CbG+uPksL5mViCK8jQL+GtIIATrrAO3xcUzws7TxqiFXlGauDXEk/7JcCX+uow2fxo=;
X-YMail-OSG: XdtjHh0VM1lJNyxfEJgWKU9JSziyWNRVDxbK7kOR4B07V2u bDDyKl9VwuIrcVZ1dmrVl6eM6tpRWpSAOTVFymoQtV_zNcdbBd7UtWx8aXaT ptLsRaU7faZORmq4_kLUARhk2FquIa_bmjCowhS36HBSEq6mZ529yaxCd3is m7..1bVCUUVNQKrhFW7R58F4sUa8roIpNWCeMv3ZyoQ0XlJKVhdDqZGEc50k zRqoUwGcw29u8YZQ1e7o5zUHe8ZvrYtTvKi5iowe.lC3.iIyF.._GpN.UrRu 2lBacfMsexjWu7a_jNeu8Ku.oit28vQCdRJCSn9lzdBGyh23.fghIoMIdG4a pFlpRRFSnil1JtuyUzAa7Zul3sIHoFcnnHmu9kqsLLrn79WjOiaYvolK1Y5w fEaLhUITSTyu_vXez5_F4X4jjxcaRpVnFul3PakoXpm04o7QNvVWTSD9iTZn 0QRnXtxm3wkTfYJv775hwqOc_WZotrROujnm3LqID3.pRIuxD3u12aQvtQ2B mx_G6dCKTjQ5cVT5s3ds0PJrO4uB47MrDmzcNBNTJ.Q--
Received: from [209.131.62.115] by web31802.mail.mud.yahoo.com via HTTP; Wed, 27 Feb 2013 01:18:54 PST
X-Rocket-MIMEInfo: 001.001, QW5kIGFsc28uLi4KCkhvdyB3b3VsZCB0aGUgc2VydmVyIG1hbmRhdGUgYSBzZXQgb2YgaGVhZGVyIGZpZWxkcyByZXF1aXJpbmcgc2lnbmF0dXJlPyDCoEhvdyBjYW4gdGhlIHNlcnZlciBtYW5kYXRlIGEgc2lnbmF0dXJlIG1ldGhvZCBvciBkbyB3ZSBqdXN0IHN0YXkgd2l0aCB0aGUgdHdvIG9wdGlvbnMgYW5kIGFsbG93IGVpdGhlcj8gwqBJdCBtaWdodCB3YW50IHRvIGVuZm9yY2UgU0EtMjU2PwoKLWJpbGwKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRnJvbTogV2lsbGlhbSBNaWxscyABMAEBAQE-
X-Mailer: YahooMailWebService/0.8.135.514
References: <20130225124642.7425.65145.idtracker@ietfa.amsl.com> <1361956373.9883.YahooMailNeo@web31807.mail.mud.yahoo.com>
Message-ID: <1361956734.73841.YahooMailNeo@web31802.mail.mud.yahoo.com>
Date: Wed, 27 Feb 2013 01:18:54 -0800 (PST)
From: William Mills 
To: "oauth@ietf.org" , Hannes Tschofenig 
In-Reply-To: <1361956373.9883.YahooMailNeo@web31807.mail.mud.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-1036955950-403965553-1361956734=:73841"
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Feb 2013 09:18:56 -0000

---1036955950-403965553-1361956734=:73841
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

And also...=0A=0AHow would the server mandate a set of header fields requir=
ing signature? =A0How can the server mandate a signature method or do we ju=
st stay with the two options and allow either? =A0It might want to enforce =
SA-256?=0A=0A-bill=0A=0A=0A________________________________=0A From: Willia=
m Mills =0ATo: "oauth@ietf.org" ; H=
annes Tschofenig  =0ASent: Wednesday, February 2=
7, 2013 1:12 AM=0ASubject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-h=
ttp-mac-03.txt=0A =0A=0AJust read the draft quickly. =A0=0A=0ASince we're n=
ow leaning on JWT do we need to include the token in this? =A0Why not just =
make an additional "Envelope MAC" thing and have the signature include the =
3 JWT parts in the signature base string? =A0That object then just becomes =
a JSON container for the kid, timestamp, signature method, signature etc. T=
hat thing then is a 4th base64 encoded JSON thing in the auth header.=0A=0A=
How header fields get included in the signature needs definition.=0A=0AWhy =
did you kill the port number, nonce, and extension parameter out of the sig=
nature base string?=0A=0AThe BNF appears to have no separators between valu=
es.=0A=0A-bill=0A=0A=0A=0A________________________________=0A From: "intern=
et-drafts@ietf.org" =0ATo: i-d-announce@ietf.org =
=0ACc: oauth@ietf.org =0ASent: Monday, February 25, 2013 4:46 AM=0ASubject:=
 [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt=0A =0A=0AA New =
Internet-Draft is available from the on-line Internet-Drafts directories.=
=0AThis draft is a work item of the Web Authorization Protocol Working Grou=
p of the IETF.=0A=0A=A0=A0=A0 Title=A0 =A0 =A0 =A0 =A0  : OAuth 2.0 Message=
 Authentication Code (MAC) Tokens=0A=A0=A0=A0 Author(s)=A0 =A0 =A0  : Justi=
n Richer=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 William Mill=
s=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hannes Tschofenig=
=0A=A0=A0=A0 Filename=A0 =A0 =A0 =A0 : draft-ietf-oauth-v2-http-mac-03.txt=
=0A=A0=A0=A0 Pages=A0 =A0 =A0 =A0 =A0  : 26=0A=A0=A0=A0 Date=A0 =A0 =A0 =A0=
 =A0 =A0 : 2013-02-25=0A=0AAbstract:=0A=A0  This specification describes ho=
w to use MAC Tokens in HTTP requests=0A=A0  to access OAuth 2.0 protected=
=0A resources.=A0 An OAuth client willing to=0A=A0  access a protected reso=
urce needs to demonstrate possession of a=0A=A0  crytographic key by using =
it with a keyed message digest function to=0A=A0  the request.=0A=0A=A0  Th=
e document also defines a key distribution protocol for obtaining a=0A=A0  =
fresh session key.=0A=0A=0AThe IETF datatracker status page for this draft =
is:=0Ahttps://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac=0A=0ATh=
ere's also a htmlized version available at:=0Ahttp://tools.ietf.org/html/dr=
aft-ietf-oauth-v2-http-mac-03=0A=0AA diff from the previous version is avai=
lable at:=0Ahttp://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-v2-http-mac=
-03=0A=0A=0AInternet-Drafts are also available by anonymous FTP at:=0Aftp:/=
/ftp.ietf.org/internet-drafts/=0A=0A_______________________________________=
________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailm=
an/listinfo/oauth
---1036955950-403965553-1361956734=:73841
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

And also...

How would the server mandate a set of header fields requi=
ring signature?  How can the server mandate a signature method or do w=
e just stay with the two options and allow either?  It might want to e=
nforce SA-256?

  From: William Mills <wmills_92105@=
yahoo.com>
 To: "oau=
th@ietf.org" <oauth@ietf.org>; Hannes Tschofenig <hannes.tschofeni=
g@gmx.net> 
 Sent: W=
ednesday, February 27, 2013 1:12 AM
 Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-=
mac-03.txt

=0AJust read the draft quickly.  

Since we're now l=
eaning on JWT do we need to include the token in this?  Why not just m=
ake an additional "Envelope MAC" thing and have the signature include the 3=
 JWT parts in the signature base string?  That object then just become=
s a JSON container for the kid, timestamp, signature method, signature etc.=
 That thing then is a 4th base64
 encoded JSON thing in the auth=0A header.
How header fields get =
included in the signature needs definition.

Why did you kill the =
port number, nonce, and extension parameter out of the signature base strin=
g?
The BNF appears to hav=
e no separators between values.
-bill

  =

  From: "internet-d=
rafts@ietf.org" <internet-drafts@ietf.org>
 To: i-d-announce@ietf.org 
Cc: oauth@ietf.org 
 Sent: Monday, February 25, 2013 4:46 AM
 Subject: [OAUTH-WG] I-D Action: =
draft-ietf-oauth-v2-http-mac-03.txt

=0A
A New Int=
ernet-Draft is available from the on-line Internet-Drafts directories.
 =
This draft is a work item of the Web Authorization Protocol Working Group o=
f the IETF.

    Title        &nbs=
p;  : OAuth 2.0 Message Authentication Code (MAC) Tokens
  &nb=
sp; Author(s)       : Justin Richer
      =
                    Willi=
am Mills
                  =
        Hannes Tschofenig
    Filenam=
e        : draft-ietf-oauth-v2-http-mac-03.txt
 =
;   Pages           : 26
  =
  Date            : 2013-02-25

Ab=
stract:
   This specification describes how to use MAC Tokens in HT=
TP requests
   to access OAuth 2.0 protected=0A resources.  An=
 OAuth client willing to
   access a protected resource needs to de=
monstrate possession of a
   crytographic key by using it with a ke=
yed message digest function to
   the request.

   The d=
ocument also defines a key distribution protocol for obtaining a
  =
 fresh session key.

The IETF datatracker status page for this dr=
aft is:
https://datatracker.ietf.org/d=
oc/draft-ietf-oauth-v2-http-mac

There's also a htmlized version =
available at:
http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03=

A diff from the previous version is available at:
http://www.iet=
f.org/rfcdiff?url2=3Ddraft-ietf-oauth-v2-http-mac-03

Internet-Dr=
afts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-d=
rafts/

_______________________________________________
OAuth =
mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

  <=
/div>  

---1036955950-403965553-1361956734=:73841--

From jricher@mitre.org  Wed Feb 27 08:01:08 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2DA21F859D for ; Wed, 27 Feb 2013 08:01:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.577
X-Spam-Level: 
X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.021,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iu-ZlZfW5hsd for ; Wed, 27 Feb 2013 08:01:08 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C0E4721F858A for ; Wed, 27 Feb 2013 08:01:07 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 98854531147A for ; Wed, 27 Feb 2013 11:01:02 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 66E4F5311477 for ; Wed, 27 Feb 2013 11:01:00 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 27 Feb 2013 11:00:59 -0500
Message-ID: <512E2D7F.6060903@mitre.org>
Date: Wed, 27 Feb 2013 10:59:59 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="------------090205020200050509060703"
X-Originating-IP: [129.83.31.58]
Subject: [OAUTH-WG] Registration: grant_types and response_types
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Feb 2013 16:01:08 -0000

--------------090205020200050509060703
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

There has been some press lately about clients being able to use an 
implicit flow to get tokens when they really ought to only use a code 
flow, since the security considerations and protections for both are 
very different. With this in mind, it makes sense that a dynamically 
registered client should be limited to use only certain flows, if at all 
possible.

The dynamic registration document currently handles this using the 
grant_type parameter (introduced in draft -03), which is defined in 
section 2 as follows:

    grant_type
       OPTIONAL.  Array of grant types that a client may use.  These
       grant types are defined as follows:

       *  "authorization_code": The Authorization Code Grant described in
          OAuth2Section 4.1  .

       *  "implicit": The Implicit Grant described in OAuth2Section 4.2  .

       *  "password": The Resource Owner Password Credentials Grant
          described in OAuth2Section 4.3  

       *  "client_credentials": The Client Credentials Grant described in
          OAuth2Section 4.4  

       *  "refresh_token": The Refresh Token Grant described in OAuth2
          Section 6  .

       Authorization Servers MAY allow for other values as defined in
       grant type extensions to OAuth2.  The extension process is
       described in OAuth2Section 2.5  , and the value of this parameter
       MUST be the same as the value of the "grant_type" parameter
       defined in the extension.

This allows the client to specify which flows it wants to be able to use 
(including any extensions), and allows the server to to tell the client 
in the client configuration response what flows it can expect to work.

OpenID Connect's registration has recently introduced the use of a 
different parameter, response_type, for a similar but slightly different 
purpose. The parameter is defined in the latest draft in source control as:

    response_types
        OPTIONAL. JSON array containing a list of the OAuth 2.0
        response_type
        values that this Client uses. If omitted, the default is that
        the Client
        uses only the coderesponse type. 

OIDC makes use of response_types beyond just "code" and "token", 
defining several new ones including combinations like "code idtoken".

So my question to the group is this: Should we incorporate the OIDC 
response_types parameter? Do we need both parameters specified in the 
registration or is one sufficient? They're defined separately in the 
OAuth2 protocol (one is on the Auth endpoint and one is on the Token 
endpoint), but can only be used legally in particular combinations so 
there would have to be normative text around particular values.

In my opinion, I don't think we can get rid of grant_type, since that's 
the only way to specify things like client_credentials flows and most 
extensions. There might be value in also specifying response_type, but I 
don't want to add extra fields unless there's a clearly defined need for it.

  -- Justin

--------------090205020200050509060703
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

    There has been some press lately about clients being able to use an
    implicit flow to get tokens when they really ought to only use a
    code flow, since the security considerations and protections for
    both are very different. With this in mind, it makes sense that a
    dynamically registered client should be limited to use only certain
    flows, if at all possible. 

    The dynamic registration document currently handles this using the
    grant_type parameter (introduced in draft -03), which is defined in
    section 2 as follows:

       grant_type
      OPTIONAL.  Array of grant types that a client may use.  These
      grant types are defined as follows:

      *  "authorization_code": The Authorization Code Grant described in
         OAuth2 Section 4.1.

      *  "implicit": The Implicit Grant described in OAuth2 Section 4.2.

      *  "password": The Resource Owner Password Credentials Grant
         described in OAuth2 Section 4.3

      *  "client_credentials": The Client Credentials Grant described in
         OAuth2 Section 4.4

      *  "refresh_token": The Refresh Token Grant described in OAuth2
         Section 6.

      Authorization Servers MAY allow for other values as defined in
      grant type extensions to OAuth2.  The extension process is
      described in OAuth2 Section 2.5, and the value of this parameter
      MUST be the same as the value of the "grant_type" parameter
      defined in the extension.

    This allows the client to specify which flows it wants to be able to
    use (including any extensions), and allows the server to to tell the
    client in the client configuration response what flows it can expect
    to work. 

    OpenID Connect's registration has recently introduced the use of a
    different parameter, response_type, for a similar but slightly
    different purpose. The parameter is defined in the latest draft in
    source control as:

        response_types
         OPTIONAL. JSON array containing a list of the OAuth 2.0
          response_type 

        values that this Client uses. If omitted, the default is
            that the Client 

        uses only the code response type.

      OIDC makes use of response_types beyond just "code" and "token",
      defining several new ones including combinations like "code
      idtoken". 

    So my question to the group is this: Should we incorporate the OIDC
    response_types parameter? Do we need both parameters specified in
    the registration or is one sufficient? They're defined separately in
    the OAuth2 protocol (one is on the Auth endpoint and one is on the
    Token endpoint), but can only be used legally in particular
    combinations so there would have to be normative text around
    particular values.

    In my opinion, I don't think we can get rid of grant_type, since
    that's the only way to specify things like client_credentials flows
    and most extensions. There might be value in also specifying
    response_type, but I don't want to add extra fields unless there's a
    clearly defined need for it.

     -- Justin

--------------090205020200050509060703--

From ve7jtb@ve7jtb.com  Wed Feb 27 08:47:59 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFC421F868B for ; Wed, 27 Feb 2013 08:47:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.9
X-Spam-Level: 
X-Spam-Status: No, score=-2.9 tagged_above=-999 required=5 tests=[AWL=-0.698,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ew1ZjdRnNZo for ; Wed, 27 Feb 2013 08:47:58 -0800 (PST)
Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by ietfa.amsl.com (Postfix) with ESMTP id AB1CE21F8667 for ; Wed, 27 Feb 2013 08:47:58 -0800 (PST)
Received: by mail-pa0-f52.google.com with SMTP id fb1so532265pad.39 for ; Wed, 27 Feb 2013 08:47:58 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=4XuMK9Y0bTB2ql2fQmw82hfRpUWrDnwhP7JtWFnulik=; b=ZRaRIHoj3kOBISpPnKWo073++Hq8wID837qwYlsZCEugeqEIaXe+5lAElOya6xWd5D g0an9XMXmDgmJlrEpH9HvGOUcbNdcr1oCKHXvwHn6Ka6YzLcSJy+rJji3klKW8O9RsUV iNsxeZfQ+7yGcYuiPBXU+YzIMkut8+UnvmO1Zsh2bBH3tqVwfgIBaQeTGjI2XKHFTA94 Vq+a1fTHQMUBf7D2/cXcifnJv88sIdev80ySsoa92SSn0gvdou9z4pHQnlad9fgE3UTd cyxWs3p0BBZPOBO7pfmpaT/FsLOlYiqpVwjkaF35n3gP5Fmo1xd3YoN9MZNMTvUjEGh+ 0E9A==
X-Received: by 10.66.218.131 with SMTP id pg3mr8488899pac.89.1361983678362; Wed, 27 Feb 2013 08:47:58 -0800 (PST)
Received: from [192.168.43.229] (mobile-166-137-184-219.mycingular.net. [166.137.184.219]) by mx.google.com with ESMTPS id i6sm5902979paw.19.2013.02.27.08.47.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 08:47:56 -0800 (PST)
References: <512E2D7F.6060903@mitre.org>
Mime-Version: 1.0 (1.0)
In-Reply-To: <512E2D7F.6060903@mitre.org>
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1919B7D6-B725-40E8-8067-9CA2D70F5512; protocol="application/pkcs7-signature"
Content-Transfer-Encoding: 7bit
Message-Id: 
X-Mailer: iPhone Mail (10B146)
From: John Bradley 
Date: Wed, 27 Feb 2013 08:47:50 -0800
To: Justin Richer 
X-Gm-Message-State: ALoCoQnX+xpNnJbSxcX8rnExAYMJPJNCI34DZngDt+fL4+BGxN9AzrJvPRo0haFJpygXcVxtD4sr
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: grant_types and response_types
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Feb 2013 16:47:59 -0000

--Apple-Mail-1919B7D6-B725-40E8-8067-9CA2D70F5512
Content-Type: multipart/alternative;
	boundary=Apple-Mail-B67756A7-03AD-49C8-9A56-128B03E96ED1
Content-Transfer-Encoding: 7bit

--Apple-Mail-B67756A7-03AD-49C8-9A56-128B03E96ED1
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

For grant_type you have to make up implicit as a grant_type.=20

They are sort of separate things and are both extendable in the case of asse=
rtions for the token endpoint, and new response types like "code id_token" o=
r "token code" for response type.=20

Both could be used to not allow implicit but also have other value.=20

I would like to combine them, but that may be more confusing than directly m=
apping them to the OAuth functionality.=20

It may be sufficient to have response_type and grant_type in discovery but o=
nly grant_type in registration.=20

We need to agree on what grant_type/s are required for a response_type of "c=
ode id_token" that is returned in a fragment but uses the token endpoint.=20=

John B.=20

Sent from my iPhone

On 2013-02-27, at 7:59 AM, Justin Richer  wrote:

> There has been some press lately about clients being able to use an implic=
it flow to get tokens when they really ought to only use a code flow, since t=
he security considerations and protections for both are very different. With=
 this in mind, it makes sense that a dynamically registered client should be=
 limited to use only certain flows, if at all possible.=20
>=20
> The dynamic registration document currently handles this using the grant_t=
ype parameter (introduced in draft -03), which is defined in section 2 as fo=
llows:
>=20
>    grant_type
>       OPTIONAL.  Array of grant types that a client may use.  These
>       grant types are defined as follows:
>=20
>       *  "authorization_code": The Authorization Code Grant described in
>          OAuth2 Section 4.1.
>=20
>       *  "implicit": The Implicit Grant described in OAuth2 Section 4.2.
>=20
>       *  "password": The Resource Owner Password Credentials Grant
>          described in OAuth2 Section 4.3
>=20
>       *  "client_credentials": The Client Credentials Grant described in
>          OAuth2 Section 4.4
>=20
>       *  "refresh_token": The Refresh Token Grant described in OAuth2
>          Section 6.
>=20
>       Authorization Servers MAY allow for other values as defined in
>       grant type extensions to OAuth2.  The extension process is
>       described in OAuth2 Section 2.5, and the value of this parameter
>       MUST be the same as the value of the "grant_type" parameter
>       defined in the extension.
>=20
> This allows the client to specify which flows it wants to be able to use (=
including any extensions), and allows the server to to tell the client in th=
e client configuration response what flows it can expect to work.=20
>=20
> OpenID Connect's registration has recently introduced the use of a differe=
nt parameter, response_type, for a similar but slightly different purpose. T=
he parameter is defined in the latest draft in source control as:
>=20
> response_types
> OPTIONAL. JSON array containing a list of the OAuth 2.0 response_type=20
> values that this Client uses. If omitted, the default is that the Client=20=

> uses only the code response type.
>=20
> OIDC makes use of response_types beyond just "code" and "token", defining s=
everal new ones including combinations like "code idtoken".=20
> So my question to the group is this: Should we incorporate the OIDC respon=
se_types parameter? Do we need both parameters specified in the registration=
 or is one sufficient? They're defined separately in the OAuth2 protocol (on=
e is on the Auth endpoint and one is on the Token endpoint), but can only be=
 used legally in particular combinations so there would have to be normative=
 text around particular values.
>=20
> In my opinion, I don't think we can get rid of grant_type, since that's th=
e only way to specify things like client_credentials flows and most extensio=
ns. There might be value in also specifying response_type, but I don't want t=
o add extra fields unless there's a clearly defined need for it.
>=20
>  -- Justin
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-B67756A7-03AD-49C8-9A56-128B03E96ED1
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

For grant_type you have to make up imp=
licit as a grant_type. 

They are sort of separ=
ate things and are both extendable in the case of assertions for the token e=
ndpoint, and new response types like "code id_token" or "token code" for res=
ponse type. 

Both could be used to not allow i=
mplicit but also have other value. 

I would li=
ke to combine them, but that may be more confusing than directly mapping the=
m to the OAuth functionality. 

It may be suffi=
cient to have response_type and grant_type in discovery but only grant_type i=
n registration. 

We need to agree on what gran=
t_type/s are required for a response_type of "code id_token" that is returne=
d in a fragment but uses the token endpoint. 

=
John B. 

Sent from my iPhone

On 2013-02-27, at 7:5=
9 AM, Justin Richer <jricher@mitre.o=
rg> wrote:

 =20

 =20
 =20
    There has been some press lately about clients being able to use an
    implicit flow to get tokens when they really ought to only use a
    code flow, since the security considerations and protections for
    both are very different. With this in mind, it makes sense that a
    dynamically registered client should be limited to use only certain
    flows, if at all possible. 

    The dynamic registration document currently handles this using the
    grant_type parameter (introduced in draft -03), which is defined in
    section 2 as follows:

       grant_type
      OPTIONAL.  Array of grant types that a client may use.  These
      grant types are defined as follows:

      *  "authorization_code": The Authorization Code Grant described in
         OAuth2 Section 4.1.

      *  "implicit": The Implicit Grant described in OAuth2 Section 4.2.

      *  "password": The Resource Owner Password Credentials Grant
         described in OAuth2 Section 4.3

      *  "client_credentials": The Client Credentials Grant described in
         OAuth2 Section 4.4

      *  "refresh_token": The Refresh Token Grant described in OAuth2
         Section 6.

      Authorization Servers MAY allow for other values as defined in
      grant type extensions to OAuth2.  The extension process is
      described in OAuth2 Section 2.5, and the value of this paramete=
r
      MUST be the same as the value of the "grant_type" parameter
      defined in the extension.

    This allows the client to specify which flows it wants to be able to
    use (including any extensions), and allows the server to to tell the
    client in the client configuration response what flows it can expect
    to work. 

    OpenID Connect's registration has recently introduced the use of a
    different parameter, response_type, for a similar but slightly
    different purpose. The parameter is defined in the latest draft in
    source control as:

        response_types
         OPTIONAL. JSON array containing a list of the OAuth 2.0
          response_type 

        values that this Client uses. If omitted, the default is
            that the Client 

        uses only the code response type.

      OIDC makes use of response_types beyond just "code" and "token",
      defining several new ones including combinations like "code
      idtoken". 

    So my question to the group is this: Should we incorporate the OIDC
    response_types parameter? Do we need both parameters specified in
    the registration or is one sufficient? They're defined separately in
    the OAuth2 protocol (one is on the Auth endpoint and one is on the
    Token endpoint), but can only be used legally in particular
    combinations so there would have to be normative text around
    particular values.

    In my opinion, I don't think we can get rid of grant_type, since
    that's the only way to specify things like client_credentials flows
    and most extensions. There might be value in also specifying
    response_type, but I don't want to add extra fields unless there's a
    clearly defined need for it.

     -- Justin

 =20

____________________=
___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai=
lman/listinfo/oauth
=

--Apple-Mail-B67756A7-03AD-49C8-9A56-128B03E96ED1--

--Apple-Mail-1919B7D6-B725-40E8-8067-9CA2D70F5512
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHuTCCB7Uw
ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3
NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU
BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ
ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93
rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe
nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa
hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw
26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc
ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz
9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh
ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl
N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC
IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj
b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu
IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC
AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg
YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh
dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu
Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc
0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d
NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT
0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC
Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDGCA2wwggNoAgEBMIGTMIGMMQswCQYD
VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg
Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IElu
dGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsOAwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkq
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDIyNzE2NDc1NFowIwYJKoZIhvcNAQkEMRYEFFYd
7qAKTnYKxnn2HnMtiUmo2A/wMIGkBgkrBgEEAYI3EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYw
FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl
IENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQG
A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg
U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBD
bGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIBACXxrLxp46iC5T+QBOnm9+jgwBk/s3CdT/Bp
XORDH9oAsrmAuL49/7GjwGSF/UzfZnUWaIh87kazLHUaYFSNkPMgLcYOMj/NRP4VKrwiujT7RvDu
zISD7WGMy1b95lXZnmFkyjoUQdARLYEZAknMCzQzfzUkKTNrhK0rPl4MvKW3xlnIg832aUTwLa24
E6gmOHcMkBKep9kYe5qz4POx1ekf9SqNfZ2IYgUSg3TfTrTGXFJWlRWlVrIvw0LD7pzqwOPYSXLy
HnoBZ4/yima7F2s2gCbVtPXok1uXQGDBNU7ZZfrxvxPOaLnkXw+esLR2IKRx2az0tcNwEJ75G0oI
7esAAAAAAAA=

--Apple-Mail-1919B7D6-B725-40E8-8067-9CA2D70F5512--

From ietf-ipr@ietf.org  Wed Feb 27 13:16:38 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E6121F88EE; Wed, 27 Feb 2013 13:16:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.409
X-Spam-Level: 
X-Spam-Status: No, score=-102.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmfWdzO6uwEO; Wed, 27 Feb 2013 13:16:36 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4AE721F867A; Wed, 27 Feb 2013 13:16:36 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: IETF Secretariat 
To: mbj@microsoft.com, ve7jtb@ve7jtb.com, n-sakimura@nri.co.jp
X-Test-IDTracker: no
X-IETF-IDTracker: 4.40p1
Message-ID: <20130227211636.16096.19408.idtracker@ietfa.amsl.com>
Date: Wed, 27 Feb 2013 13:16:36 -0800
Cc: derek@ihtfp.com, oauth@ietf.org, ipr-announce@ietf.org
Subject: [OAUTH-WG] IPR Disclosure: Certicom Corporation's Statement about IPR related to	draft-ietf-oauth-json-web-token-06 (2)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Feb 2013 21:16:38 -0000

Dear Michael Jones, John Bradley, Nat Sakimura:

 An IPR disclosure that pertains to your Internet-Draft entitled "JSON Web =
Token
(JWT)" (draft-ietf-oauth-json-web-token) was submitted to the IETF Secretar=
iat
on 2013-02-20 and has been posted on the "IETF Page of Intellectual Property
Rights Disclosures" (https://datatracker.ietf.org/ipr/1968/). The title of =
the
IPR disclosure is "Certicom Corporation's Statement about IPR related to dr=
aft-
ietf-oauth-json-web-token-06 (2)."");

The IETF Secretariat

From Michael.Jones@microsoft.com  Wed Feb 27 14:52:47 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8311821F87D5 for ; Wed, 27 Feb 2013 14:52:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.587
X-Spam-Level: 
X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.011,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1o7BJMTBKhI for ; Wed, 27 Feb 2013 14:52:44 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.26]) by ietfa.amsl.com (Postfix) with ESMTP id 76D4421F87D2 for ; Wed, 27 Feb 2013 14:52:44 -0800 (PST)
Received: from BY2FFO11FD026.protection.gbl (10.1.15.201) by BY2FFO11HUB012.protection.gbl (10.1.14.83) with Microsoft SMTP Server (TLS) id 15.0.620.12; Wed, 27 Feb 2013 22:52:41 +0000
Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD026.mail.protection.outlook.com (10.1.15.215) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Wed, 27 Feb 2013 22:52:41 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Wed, 27 Feb 2013 22:52:17 +0000
From: Mike Jones 
To: Justin Richer , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Registration: grant_types and response_types
Thread-Index: AQHOFQO5d+0IWPQvz0CRM0gUCtYnPJiOSukw
Date: Wed, 27 Feb 2013 22:52:16 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943674BC644@TK5EX14MBXC283.redmond.corp.microsoft.com>
References: <512E2D7F.6060903@mitre.org>
In-Reply-To: <512E2D7F.6060903@mitre.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.70]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943674BC644TK5EX14MBXC283r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(55885001)(189002)(57704001)(377454001)(54356001)(63696002)(79102001)(51856001)(31966008)(5343645001)(16236675001)(20776003)(44976002)(54316002)(16297215001)(56776001)(551544001)(56816002)(5343655001)(74662001)(5343635001)(50986001)(47976001)(16406001)(47446002)(46102001)(15395725002)(55846006)(74502001)(47736001)(49866001)(65816001)(53806001)(512954001)(66066001)(4396001)(15202345001)(76482001)(80022001)(33656001)(77982001)(59766001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB012; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0770F75EA9
Subject: Re: [OAUTH-WG] Registration: grant_types and response_types
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Feb 2013 22:52:47 -0000

--_000_4E1F6AAD24975D4BA5B1680429673943674BC644TK5EX14MBXC283r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

John Bradley and I just talked about this during a side meeting at RSA.  We=
 think that this is the mapping of grant types and defined response types. =
 (The additional response_type values are registered with IANA and defined =
in http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html.)

response_type value

grant_types

code

authorization_code

token

implicit

id_token

implicit

token id_token

implicit

code token

authorization_code implicit

code id_token

authorization_code implicit

code token id_token

authorization_code implicit

none

none

If people agree that this is the mapping, and that it conveys sufficient in=
formation, then conceivably OpenID Connect could drop the response_types re=
gistration parameter and instead just use the OAuth Registration "grant_typ=
es" parameter.

What do others think?

                                                            -- Mike

P.S.  There's a typo in the OAuth Registration spec section quoted below.  =
The name "grant_type" should have been "grant_types", since the value is a =
list.  We should correct that in the next version of the spec.

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J=
ustin Richer
Sent: Wednesday, February 27, 2013 8:00 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Registration: grant_types and response_types

There has been some press lately about clients being able to use an implici=
t flow to get tokens when they really ought to only use a code flow, since =
the security considerations and protections for both are very different. Wi=
th this in mind, it makes sense that a dynamically registered client should=
 be limited to use only certain flows, if at all possible.

The dynamic registration document currently handles this using the grant_ty=
pe parameter (introduced in draft -03), which is defined in section 2 as fo=
llows:

   grant_type

      OPTIONAL.  Array of grant types that a client may use.  These

      grant types are defined as follows:

      *  "authorization_code": The Authorization Code Grant described in

         OAuth2 Section 4.1.

      *  "implicit": The Implicit Grant described in OAuth2 Section 4.2.

      *  "password": The Resource Owner Password Credentials Grant

         described in OAuth2 Section 4.3

      *  "client_credentials": The Client Credentials Grant described in

         OAuth2 Section 4.4

      *  "refresh_token": The Refresh Token Grant described in OAuth2

         Section 6.

      Authorization Servers MAY allow for other values as defined in

      grant type extensions to OAuth2.  The extension process is

      described in OAuth2 Section 2.5, and the value of this parameter

      MUST be the same as the value of the "grant_type" parameter

      defined in the extension.

This allows the client to specify which flows it wants to be able to use (i=
ncluding any extensions), and allows the server to to tell the client in th=
e client configuration response what flows it can expect to work.

OpenID Connect's registration has recently introduced the use of a differen=
t parameter, response_type, for a similar but slightly different purpose. T=
he parameter is defined in the latest draft in source control as:
response_types
OPTIONAL. JSON array containing a list of the OAuth 2.0 response_type
values that this Client uses. If omitted, the default is that the Client
uses only the code response type.

OIDC makes use of response_types beyond just "code" and "token", defining s=
everal new ones including combinations like "code idtoken".
So my question to the group is this: Should we incorporate the OIDC respons=
e_types parameter? Do we need both parameters specified in the registration=
 or is one sufficient? They're defined separately in the OAuth2 protocol (o=
ne is on the Auth endpoint and one is on the Token endpoint), but can only =
be used legally in particular combinations so there would have to be normat=
ive text around particular values.

In my opinion, I don't think we can get rid of grant_type, since that's the=
 only way to specify things like client_credentials flows and most extensio=
ns. There might be value in also specifying response_type, but I don't want=
 to add extra fields unless there's a clearly defined need for it.

 -- Justin

--_000_4E1F6AAD24975D4BA5B1680429673943674BC644TK5EX14MBXC283r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

John Bradley and I just t=
alked about this during a side meeting at RSA.  We think that this is =
the mapping of grant types and defined response types.  (The
 additional response_type values are registered with IANA and defined in 
http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html.)
 <=
/p>

response_type value

grant_types=

code

authorization_code

token

implicit

id_token

implicit

token id_token=

implicit

code token

authorization_code implic=
it

code id_token<=
/span>

authorization_code implic=
it

code token id_token<=
/o:p>

authorization_code implic=
it

none

none

 <=
/p>
If people agree that this=
 is the mapping, and that it conveys sufficient information, then conceivab=
ly OpenID Connect could drop the response_types registration
 parameter and instead just use the OAuth Registration “grant_types&#=
8221; parameter.
 <=
/p>
What do others think?
 <=
/p>
    &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;     -- Mike
 <=
/p>
P.S.  There’s =
a typo in the OAuth Registration spec section quoted below.  The name =
“grant_type” should have been “grant_types”, since =
the value is a list. 
 We should correct that in the next version of the spec.<=
/p>
 <=
/p>

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf=
.org]
On Behalf Of Justin Richer

Sent: Wednesday, February 27, 2013 8:00 AM

To: oauth@ietf.org

Subject: [OAUTH-WG] Registration: grant_types and response_types

There has been some p=
ress lately about clients being able to use an implicit flow to get tokens =
when they really ought to only use a code flow, since the security consider=
ations and protections for both are
 very different. With this in mind, it makes sense that a dynamically regis=
tered client should be limited to use only certain flows, if at all possibl=
e.

The dynamic registration document currently handles this using the grant_ty=
pe parameter (introduced in draft -03), which is defined in section 2 as fo=
llows:
   grant_type
      OPTIONAL.  Array of grant types th=
at a client may use.  These
      grant types are defined as follows:

      *  "authorization_code":=
 The Authorization Code Grant described in
         OAuth2 Section 4.=
1.

      *  "implicit": The Impli=
cit Grant described in OAuth2 Section 4.2.

      *  "password": The Resou=
rce Owner Password Credentials Grant
         described in OAuth2 <=
a href=3D"http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-07#section-4.=
3">Section 4.3

      *  "client_credentials":=
 The Client Credentials Grant described in
         OAuth2 Section 4.=
4

      *  "refresh_token": The =
Refresh Token Grant described in OAuth2
         Section 6.=

      Authorization Servers MAY allow for oth=
er values as defined in
      grant type extensions to OAuth2.  =
The extension process is
      described in OAuth2 Section 2.5=
, and the value of this parameter
      MUST be the same as the value of the &q=
uot;grant_type" parameter
      defined in the extension.

This allows the client to specify which flows it wants to be able to use (i=
ncluding any extensions), and allows the server to to tell the client in th=
e client configuration response what flows it can expect to work.

OpenID Connect's registration has recently introduced the use of a differen=
t parameter, response_type, for a similar but slightly different purpose. T=
he parameter is defined in the latest draft in source control as:
response_types<=
/span>
OPTIONAL. JSON array containing a list of the OAuth 2.0 respons=
e_type

values that this Client uses. If omitted, the default is that t=
he Client

uses only the code response type.

OIDC makes use of response_types beyond just "code" and "tok=
en", defining several new ones including combinations like "code =
idtoken".

So my question to the group is this: Should we incor=
porate the OIDC response_types parameter? Do we need both parameters specif=
ied in the registration or is one sufficient? They're defined separately in=
 the OAuth2 protocol (one is on the
 Auth endpoint and one is on the Token endpoint), but can only be used lega=
lly in particular combinations so there would have to be normative text aro=
und particular values.

In my opinion, I don't think we can get rid of grant_type, since that's the=
 only way to specify things like client_credentials flows and most extensio=
ns. There might be value in also specifying response_type, but I don't want=
 to add extra fields unless there's
 a clearly defined need for it.

 -- Justin

--_000_4E1F6AAD24975D4BA5B1680429673943674BC644TK5EX14MBXC283r_--

From hannes.tschofenig@gmx.net  Thu Feb 28 02:28:22 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC8421F8B8D for ; Thu, 28 Feb 2013 02:28:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.604
X-Spam-Level: 
X-Spam-Status: No, score=-101.604 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWaaqqL83+tL for ; Thu, 28 Feb 2013 02:28:22 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id BF89921F8B6D for ; Thu, 28 Feb 2013 02:28:21 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.32]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MTdbK-1UJqPU1HCy-00QULq for ; Thu, 28 Feb 2013 11:28:20 +0100
Received: (qmail invoked by alias); 28 Feb 2013 10:28:20 -0000
Received: from unknown (EHLO [10.255.133.93]) [194.251.119.201] by mail.gmx.net (mp032) with SMTP; 28 Feb 2013 11:28:20 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/DiyML8+zDw/M53m40zSy2LtfzUprwRJSJPSlet9 dt69aZKUOFwrth
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Hannes Tschofenig 
In-Reply-To: <1361956373.9883.YahooMailNeo@web31807.mail.mud.yahoo.com>
Date: Thu, 28 Feb 2013 12:28:18 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <21030204-8EA7-4FB0-9DD3-2B6C8CA57E02@gmx.net>
References: <20130225124642.7425.65145.idtracker@ietfa.amsl.com> <1361956373.9883.YahooMailNeo@web31807.mail.mud.yahoo.com>
To: William Mills 
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 10:28:22 -0000

Hi Bill,=20

I believe you are misreading the document. In =
draft-ietf-oauth-v2-http-mac the client still uses the MAC when it =
accesses a protected resource.=20
The only place where the JWT comes into the picture is with the =
description of the access token. This matters from a key distribution =
point of view. The session key for the MAC is included in the encrypted =
JWT. The JWT is encrypted by the authorization server and decrypted by =
the resource server.=20

Information about how header fields get included in the MAC is described =
in Section 5.

The nonce isn't killed it is just called differently: seq-nr. The stuff =
in the original MAC specification actually wasn't a nonce (from the =
semantic point of view).=20
The extension parameter is there implicitly by allowing additional =
header fields to be included in the MAC computation.

I need to look at the port number field again.=20

Ciao
Hannes

On Feb 27, 2013, at 11:12 AM, William Mills wrote:

> Just read the draft quickly. =20
>=20
> Since we're now leaning on JWT do we need to include the token in =
this?  Why not just make an additional "Envelope MAC" thing and have the =
signature include the 3 JWT parts in the signature base string?  That =
object then just becomes a JSON container for the kid, timestamp, =
signature method, signature etc. That thing then is a 4th base64 encoded =
JSON thing in the auth header.
>=20
> How header fields get included in the signature needs definition.
>=20
> Why did you kill the port number, nonce, and extension parameter out =
of the signature base string?
>=20
> The BNF appears to have no separators between values.
>=20
> -bill
>=20
>=20
> From: "internet-drafts@ietf.org" 
> To: i-d-announce@ietf.org=20
> Cc: oauth@ietf.org=20
> Sent: Monday, February 25, 2013 4:46 AM
> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the Web Authorization Protocol Working =
Group of the IETF.
>=20
>     Title          : OAuth 2.0 Message Authentication Code (MAC) =
Tokens
>     Author(s)      : Justin Richer
>                           William Mills
>                           Hannes Tschofenig
>     Filename        : draft-ietf-oauth-v2-http-mac-03.txt
>     Pages          : 26
>     Date            : 2013-02-25
>=20
> Abstract:
>   This specification describes how to use MAC Tokens in HTTP requests
>   to access OAuth 2.0 protected resources.  An OAuth client willing to
>   access a protected resource needs to demonstrate possession of a
>   crytographic key by using it with a keyed message digest function to
>   the request.
>=20
>   The document also defines a key distribution protocol for obtaining =
a
>   fresh session key.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03
>=20
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-v2-http-mac-03
>=20
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20

From hannes.tschofenig@gmx.net  Thu Feb 28 02:29:41 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E763221F8B6D for ; Thu, 28 Feb 2013 02:29:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.617
X-Spam-Level: 
X-Spam-Status: No, score=-101.617 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpZ6rGLDEK2k for ; Thu, 28 Feb 2013 02:29:41 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 447B021F84C9 for ; Thu, 28 Feb 2013 02:29:41 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.16]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M7WX3-1V4Tbf2CRj-00xLi8 for ; Thu, 28 Feb 2013 11:29:40 +0100
Received: (qmail invoked by alias); 28 Feb 2013 10:29:40 -0000
Received: from unknown (EHLO [10.255.133.93]) [194.251.119.201] by mail.gmx.net (mp016) with SMTP; 28 Feb 2013 11:29:40 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18Oy75qg+UO6539fxxI/Gg8CVugeBBC/axwChRCLB wcjxzHqJZsnxXS
From: Hannes Tschofenig 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Thu, 28 Feb 2013 12:29:38 +0200
Message-Id: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net>
To: "oauth@ietf.org WG" 
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Subject: [OAUTH-WG] JWT - scope claim missing
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 10:29:42 -0000

Hi Mike,=20

when I worked on the MAC specification I noticed that the JWT does not =
have a claim for the scope. I believe that this would be needed to allow =
the resource server to verify whether the scope the authorization server =
authorized is indeed what the client is asking for.=20

Ciao
Hannes

From hannes.tschofenig@gmx.net  Thu Feb 28 02:37:48 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6914721F8ADC for ; Thu, 28 Feb 2013 02:37:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.629
X-Spam-Level: 
X-Spam-Status: No, score=-101.629 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gc5PKKAU7J6q for ; Thu, 28 Feb 2013 02:37:47 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id E0C6021F8AB4 for ; Thu, 28 Feb 2013 02:37:46 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.4]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Ltkst-1UroJY4Bef-011E82 for ; Thu, 28 Feb 2013 11:37:46 +0100
Received: (qmail invoked by alias); 28 Feb 2013 10:37:45 -0000
Received: from unknown (EHLO [10.255.133.93]) [194.251.119.201] by mail.gmx.net (mp004) with SMTP; 28 Feb 2013 11:37:45 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19FAdc1bGhFWXKLO5jiZ5Ym3mAR7S47s2ifkATtDl Fco9oQRCzv91Ks
From: Hannes Tschofenig 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Thu, 28 Feb 2013 12:37:44 +0200
Message-Id: 
To: "oauth@ietf.org WG" 
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Subject: [OAUTH-WG] JWT & Token Introspection Relationship
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 10:37:48 -0000

Hi Mike, Hi Justin,=20

when I looked at the JWT and the draft-richer-oauth-introspection =
documents I noticed that the two are not aligned (neither from the =
fields that are supported nor from the way how the fields are defined).=20=

IMHO  draft-richer-oauth-introspection must not define new elements =
since those are already defined in the JWT.=20

You could compare the relationship between the JWT and the =
draft-richer-oauth-introspection in the following way:

The JWT passes the content per value from the AS via the client to the =
RS.=20
The draft-richer-oauth-introspection passes a reference to the content =
from the AS via the client to the RS and since the RS ultimately needs =
to know the content it has to resolve the reference so that it gets the =
content.=20

Therefore, the content (the different JSON encoded structures) should =
only be defined once and could then be used in both specs.=20

Ciao
Hannes

From asanso@adobe.com  Thu Feb 28 02:37:55 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA94821F8B7D for ; Thu, 28 Feb 2013 02:37:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j60VtvZ8lBHO for ; Thu, 28 Feb 2013 02:37:55 -0800 (PST)
Received: from exprod6og121.obsmtp.com (exprod6og121.obsmtp.com [64.18.1.237]) by ietfa.amsl.com (Postfix) with ESMTP id E9F5721F8AB4 for ; Thu, 28 Feb 2013 02:37:48 -0800 (PST)
Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob121.postini.com ([64.18.5.12]) with SMTP ID DSNKUS8zfJ7Bz9AJWMYWvNFockZHxVuXAkLR@postini.com; Thu, 28 Feb 2013 02:37:54 PST
Received: from inner-relay-1.corp.adobe.com (inner-relay-1.sea.adobe.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r1SAbknT019876; Thu, 28 Feb 2013 02:37:47 -0800 (PST)
Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r1SAbkAV016733; Thu, 28 Feb 2013 02:37:46 -0800 (PST)
Received: from eurhub01.eur.adobe.com (10.128.4.30) by nahub01.corp.adobe.com (10.8.189.97) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 28 Feb 2013 02:37:46 -0800
Received: from eurmbx01.eur.adobe.com ([10.128.4.32]) by eurhub01.eur.adobe.com ([10.128.4.30]) with mapi; Thu, 28 Feb 2013 10:37:44 +0000
From: Antonio Sanso 
To: Hannes Tschofenig 
Date: Thu, 28 Feb 2013 10:37:44 +0000
Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
Thread-Index: Ac4Vn6RT73QpgH4KReGKXzvRaa9TYA==
Message-ID: <98272BAD-131B-4151-BBB8-0937E8D6781A@adobe.com>
References: <20130225124642.7425.65145.idtracker@ietfa.amsl.com> <1361956373.9883.YahooMailNeo@web31807.mail.mud.yahoo.com> <21030204-8EA7-4FB0-9DD3-2B6C8CA57E02@gmx.net>
In-Reply-To: <21030204-8EA7-4FB0-9DD3-2B6C8CA57E02@gmx.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 10:37:55 -0000

Hi Hannes,

apologies if I do the same question again but there is still one point that=
 is a little obscure to me.

As long I did understand the situation for MAC is the following one.

The communication between the client and the authentication server must be =
https but this is not true for the communication between authentication ser=
ver and resource server.
Hence the need of this key exchange.

Is it correct? Should be the case why we do not have the same problem in th=
e JWT Bearer case? Is because in that case https is as well mandatory betwe=
en authentication server and resource server?

Thanks a lot and regards

Antonio

On Feb 28, 2013, at 11:28 AM, Hannes Tschofenig wrote:

> Hi Bill,=20
>=20
> I believe you are misreading the document. In draft-ietf-oauth-v2-http-ma=
c the client still uses the MAC when it accesses a protected resource.=20
> The only place where the JWT comes into the picture is with the descripti=
on of the access token. This matters from a key distribution point of view.=
 The session key for the MAC is included in the encrypted JWT. The JWT is e=
ncrypted by the authorization server and decrypted by the resource server.=
=20
>=20
> Information about how header fields get included in the MAC is described =
in Section 5.
>=20
> The nonce isn't killed it is just called differently: seq-nr. The stuff i=
n the original MAC specification actually wasn't a nonce (from the semantic=
 point of view).=20
> The extension parameter is there implicitly by allowing additional header=
 fields to be included in the MAC computation.
>=20
> I need to look at the port number field again.=20
>=20
> Ciao
> Hannes
>=20
> On Feb 27, 2013, at 11:12 AM, William Mills wrote:
>=20
>> Just read the draft quickly. =20
>>=20
>> Since we're now leaning on JWT do we need to include the token in this? =
 Why not just make an additional "Envelope MAC" thing and have the signatur=
e include the 3 JWT parts in the signature base string?  That object then j=
ust becomes a JSON container for the kid, timestamp, signature method, sign=
ature etc. That thing then is a 4th base64 encoded JSON thing in the auth h=
eader.
>>=20
>> How header fields get included in the signature needs definition.
>>=20
>> Why did you kill the port number, nonce, and extension parameter out of =
the signature base string?
>>=20
>> The BNF appears to have no separators between values.
>>=20
>> -bill
>>=20
>>=20
>> From: "internet-drafts@ietf.org" 
>> To: i-d-announce@ietf.org=20
>> Cc: oauth@ietf.org=20
>> Sent: Monday, February 25, 2013 4:46 AM
>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
>>=20
>>=20
>> A New Internet-Draft is available from the on-line Internet-Drafts direc=
tories.
>> This draft is a work item of the Web Authorization Protocol Working Grou=
p of the IETF.
>>=20
>>    Title          : OAuth 2.0 Message Authentication Code (MAC) Tokens
>>    Author(s)      : Justin Richer
>>                          William Mills
>>                          Hannes Tschofenig
>>    Filename        : draft-ietf-oauth-v2-http-mac-03.txt
>>    Pages          : 26
>>    Date            : 2013-02-25
>>=20
>> Abstract:
>>  This specification describes how to use MAC Tokens in HTTP requests
>>  to access OAuth 2.0 protected resources.  An OAuth client willing to
>>  access a protected resource needs to demonstrate possession of a
>>  crytographic key by using it with a keyed message digest function to
>>  the request.
>>=20
>>  The document also defines a key distribution protocol for obtaining a
>>  fresh session key.
>>=20
>>=20
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac
>>=20
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03
>>=20
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-v2-http-mac-03
>>=20
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From wmills_92105@yahoo.com  Thu Feb 28 05:15:04 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F059F21F8439 for ; Thu, 28 Feb 2013 05:15:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.227
X-Spam-Level: 
X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.371,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVW-Jcw1Lu-t for ; Thu, 28 Feb 2013 05:15:03 -0800 (PST)
Received: from nm7-vm1.bullet.mail.ne1.yahoo.com (nm7-vm1.bullet.mail.ne1.yahoo.com [98.138.90.250]) by ietfa.amsl.com (Postfix) with ESMTP id BAA6921F8496 for ; Thu, 28 Feb 2013 05:14:56 -0800 (PST)
Received: from [98.138.90.55] by nm7.bullet.mail.ne1.yahoo.com with NNFMP; 28 Feb 2013 13:14:56 -0000
Received: from [98.138.89.249] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 28 Feb 2013 13:14:56 -0000
Received: from [127.0.0.1] by omp1041.mail.ne1.yahoo.com with NNFMP; 28 Feb 2013 13:14:56 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 131801.79837.bm@omp1041.mail.ne1.yahoo.com
Received: (qmail 52212 invoked by uid 60001); 28 Feb 2013 13:14:55 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1362057295; bh=t7ejJTdHy+s/rKgcXizHr0euT1IwzdKiKuSrXx2IzrM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=VErfqpGhr81EfZOzsZv85kMG8fAaOu1nqZm2tifYLUBIl9f2xrEGz1gOsx7qxD7dcx63oXIw49wIKtOWgJC44NmohIvFHpJPqwLc85t2x++C/BcZdC2ko3UotArK4bpBbTzcY2ngyis3vZI3i8/PD8WSW5ZMdqpBj/j3OeFD4nQ=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=fG+lYTSQvTvtoD79hpkOaPgZvnrXuRu64/CGGTG7bTBpBfU/IPuZWPbpuJBdw3suIYrsLMgLv86nJxUK5YsSaItU7zfga7YmOn5oYYJYCYvb+s05imhPWuW3exdK8hQfnv4KFU13kOP/kcd48q7k7RqI6wzYXgI2RMEgZvYNHkQ=;
X-YMail-OSG: yyRsn4QVM1l0U5LXcF07Vt0YRU_X.rbvgqV4z5kPWU6ZKaz zXgZ_iUooBmsSJXEzbjnJBnxkOogzSMAb_n6gG_OekHMw_BzveA0Y7lhvb8l cSY2D0lNETvwPnJ3Kyz7DbqiMCld3iRSly2dVMwDWcirMOhRbd0Fsvk1UJ7_ EiiuXTblwf7GYJc9LPa1GFnO0dInCad51nUxFczMe9dA6QRTraSYL72JlFCW SXhiLYEYSeVjnSLkm4jr8kbDnJjdjLvUcl6bToZ6zKEdhlG5dOacRtjIwbvT SEPqh9NNhxLuM4AJbGBurpVwsU2h_m2GGHHh86wC3VYFrGmPxHNNlEl1ytNd xTCAWFM_1lqDzCorMJrNwH53ZlIM.5DOD5ZrVwlhMTqmcPq3ylTy.Vkg_l45 QYEU1LRgBvR.vmB5kgxaC.tqmk719CYXd3LI9LnzsYkPqDfjXW6BKd8DIsc. AGQso1agnO50Eocsm1DDk7mBuFo.hiVoeht67k5GWshVSA.8w2NxKq9secAl 6r2STVLicXTeYxAehIPE-
Received: from [99.31.212.42] by web31809.mail.mud.yahoo.com via HTTP; Thu, 28 Feb 2013 05:14:55 PST
X-Rocket-MIMEInfo: 001.001, SSdtIGFjdHVhbGx5IGFkdm9jYXRpbmcgdGhhdCB3ZSBjaGFuZ2UgTUFDIHRvIGJlIGEgSldUIGV4dGVuc2lvbi4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRnJvbTogSGFubmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ.ClRvOiBXaWxsaWFtIE1pbGxzIDx3bWlsbHNfOTIxMDVAeWFob28uY29tPiAKQ2M6IEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PjsgIm9hdXRoQGlldGYub3JnIiA8b2F1dGhAaWV0Zi5vcmc.IApTZW50OiABMAEBAQE-
X-Mailer: YahooMailWebService/0.8.135.514
References: <20130225124642.7425.65145.idtracker@ietfa.amsl.com> <1361956373.9883.YahooMailNeo@web31807.mail.mud.yahoo.com> <21030204-8EA7-4FB0-9DD3-2B6C8CA57E02@gmx.net>
Message-ID: <1362057295.36069.YahooMailNeo@web31809.mail.mud.yahoo.com>
Date: Thu, 28 Feb 2013 05:14:55 -0800 (PST)
From: William Mills 
To: Hannes Tschofenig 
In-Reply-To: <21030204-8EA7-4FB0-9DD3-2B6C8CA57E02@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-1395015409-141367223-1362057295=:36069"
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 13:15:05 -0000

---1395015409-141367223-1362057295=:36069
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I'm actually advocating that we change MAC to be a JWT extension.=0A=0A=0A_=
_______________________________=0A From: Hannes Tschofenig =0ATo: William Mills  =0ACc: Hannes Tsch=
ofenig ; "oauth@ietf.org"  =0ASe=
nt: Thursday, February 28, 2013 2:28 AM=0ASubject: Re: [OAUTH-WG] I-D Actio=
n: draft-ietf-oauth-v2-http-mac-03.txt=0A =0AHi Bill, =0A=0AI believe you a=
re misreading the document. In draft-ietf-oauth-v2-http-mac the client stil=
l uses the MAC when it accesses a protected resource. =0AThe only place whe=
re the JWT comes into the picture is with the description of the access tok=
en. This matters from a key distribution point of view. The session key for=
 the MAC is included in the encrypted JWT. The JWT is encrypted by the auth=
orization server and decrypted by the resource server. =0A=0AInformation ab=
out how header fields get included in the MAC is described in Section 5.=0A=
=0AThe nonce isn't killed it is just called differently: seq-nr. The stuff =
in the original MAC specification actually wasn't a nonce (from the semanti=
c point of view). =0AThe extension parameter is there implicitly by allowin=
g additional header fields to be included in the MAC computation.=0A=0AI ne=
ed to look at the port number field again. =0A=0ACiao=0AHannes=0A=0AOn Feb =
27, 2013, at 11:12 AM, William Mills wrote:=0A=0A> Just read the draft quic=
kly.=A0 =0A> =0A> Since we're now leaning on JWT do we need to include the =
token in this?=A0 Why not just make an additional "Envelope MAC" thing and =
have the signature include the 3 JWT parts in the signature base string?=A0=
 That object then just becomes a JSON container for the kid, timestamp, sig=
nature method, signature etc. That thing then is a 4th base64 encoded JSON =
thing in the auth header.=0A> =0A> How header fields get included in the si=
gnature needs definition.=0A> =0A> Why did you kill the port number, nonce,=
 and extension parameter out of the signature base string?=0A> =0A> The BNF=
 appears to have no separators between values.=0A> =0A> -bill=0A> =0A> =0A>=
 From: "internet-drafts@ietf.org" =0A> To: i-d-an=
nounce@ietf.org =0A> Cc: oauth@ietf.org =0A> Sent: Monday, February 25, 201=
3 4:46 AM=0A> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-=
03.txt=0A> =0A> =0A> A New Internet-Draft is available from the on-line Int=
ernet-Drafts directories.=0A> This draft is a work item of the Web Authoriz=
ation Protocol Working Group of the IETF.=0A> =0A>=A0 =A0  Title=A0 =A0 =A0=
 =A0 =A0 : OAuth 2.0 Message Authentication Code (MAC) Tokens=0A>=A0 =A0  A=
uthor(s)=A0 =A0 =A0 : Justin Richer=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0  William Mills=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0  Hannes Tschofenig=0A>=A0 =A0  Filename=A0 =A0 =A0 =A0 : draft-=
ietf-oauth-v2-http-mac-03.txt=0A>=A0 =A0  Pages=A0 =A0 =A0 =A0 =A0 : 26=0A>=
=A0 =A0  Date=A0 =A0 =A0 =A0 =A0 =A0 : 2013-02-25=0A> =0A> Abstract:=0A>=A0=
  This specification describes how to use MAC Tokens in HTTP requests=0A>=
=A0  to access OAuth 2.0 protected resources.=A0 An OAuth client willing to=
=0A>=A0  access a protected resource needs to demonstrate possession of a=
=0A>=A0  crytographic key by using it with a keyed message digest function =
to=0A>=A0  the request.=0A> =0A>=A0  The document also defines a key distri=
bution protocol for obtaining a=0A>=A0  fresh session key.=0A> =0A> =0A> Th=
e IETF datatracker status page for this draft is:=0A> https://datatracker.i=
etf.org/doc/draft-ietf-oauth-v2-http-mac=0A> =0A> There's also a htmlized v=
ersion available at:=0A> http://tools.ietf.org/html/draft-ietf-oauth-v2-htt=
p-mac-03=0A> =0A> A diff from the previous version is available at:=0A> htt=
p://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-v2-http-mac-03=0A> =0A> =
=0A> Internet-Drafts are also available by anonymous FTP at:=0A> ftp://ftp.=
ietf.org/internet-drafts/=0A> =0A> ________________________________________=
_______=0A> OAuth mailing list=0A> OAuth@ietf.org=0A> https://www.ietf.org/=
mailman/listinfo/oauth=0A> =0A> 
---1395015409-141367223-1362057295=:36069
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I'm actually advocating that we change MAC to be a JWT extension.<=
/div>

  From: Hannes Tschofenig <hannes.tschofenig=
@gmx.net>
 To: Willi=
am Mills <wmills_92105@yahoo.com> 
Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>; =
"oauth@ietf.org" <oauth@ietf.org> 
 Sent: Thursday, February 28, 2013 2:28 AM
 Subject: Re: [OAUTH-WG] I-D Action=
: draft-ietf-oauth-v2-http-mac-03.txt

=0AHi Bill, 
I believe you are misreading the document. In draft-ietf-oauth-v2-htt=
p-mac the client still uses the MAC when it accesses a protected resource. =

The only place where the JWT comes into the picture is with the descrip=
tion of the access token. This matters from a key distribution point of vie=
w. The session key for the MAC is included in the encrypted JWT. The JWT is=
 encrypted by the authorization server and decrypted by the resource server=
. 

Information about how header fields get included in the MAC is de=
scribed in Section 5.

The nonce isn't killed it is just called diffe=
rently: seq-nr. The stuff in the original MAC specification actually wasn't=
 a nonce (from the semantic point of view). 
The extension parameter is =
there implicitly by allowing additional header fields to be included in the=
 MAC computation.

I need to look at the port number field again. 
Ciao
Hannes

On Feb 27, 2013, at 11:12 AM,
 William Mills wrote:

> Just read the draft quickly.  
&g=
t; 
> Since we're now leaning on JWT do we need to include the token =
in this?  Why not just make an additional "Envelope MAC" thing and hav=
e the signature include the 3 JWT parts in the signature base string? =
 That object then just becomes a JSON container for the kid, timestamp, sig=
nature method, signature etc. That thing then is a 4th base64 encoded JSON =
thing in the auth header.
> 
> How header fields get included i=
n the signature needs definition.
> 
> Why did you kill the por=
t number, nonce, and extension parameter out of the signature base string?<=
br>> 
> The BNF appears to have no separators between values.
&=
gt; 
> -bill
> 
> 
> From: "internet-d=
rafts@ietf.org" <internet-drafts@ietf.org><=
br>> To: i-d-announce@ietf.org 
> Cc: oauth@ietf.org 
&=
gt; Sent: Monday, February 25, 2013 4:46 AM
> Subject: [OAUTH-WG] I-D=
 Action: draft-ietf-oauth-v2-http-mac-03.txt
> 
> 
> A Ne=
w Internet-Draft is available from the on-line Internet-Drafts directories.=

> This draft is a work item of the Web Authorization Protocol Workin=
g Group of the IETF.
> 
>     Title    &nbs=
p;     : OAuth 2.0 Message Authentication Code (MAC) Tokens
&g=
t;     Author(s)      : Justin Richer
> =
;                     &nb=
sp;    William Mills
>           
                Hannes Tschofenig
>=
;     Filename        : draft-ietf-oauth-v2-h=
ttp-mac-03.txt
>     Pages         =
; : 26
>     Date            =
: 2013-02-25
> 
> Abstract:
>   This specification d=
escribes how to use MAC Tokens in HTTP requests
>   to access OA=
uth 2.0 protected resources.  An OAuth client willing to
> =
  access a protected resource needs to demonstrate possession of a
>&=
nbsp;  crytographic key by using it with a keyed message digest function to=

>   the request.
> 
>   The document also defi=
nes a key distribution protocol for obtaining a
>   fresh sessio=
n key.
> 
> 
> The IETF datatracker status page for this =
draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-ma=
c
> 
> There's also a htmlized version available at:
>=
; http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03
> 
&g=
t; A diff from the previous version is available at:
> http://www.iet=
f.org/rfcdiff?url2=3Ddraft-ietf-oauth-v2-http-mac-03
> 
> 
&=
gt; Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.o=
rg/internet-drafts/
> 
> __________________________________=
_____________
> OAuth mailing list
> OAuth@ietf.org
> https:/=
/www.ietf.org/mailman/listinfo/oauth
> 
> 

 =

---1395015409-141367223-1362057295=:36069--

From jricher@mitre.org  Thu Feb 28 07:42:50 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561C021F8738 for ; Thu, 28 Feb 2013 07:42:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.577
X-Spam-Level: 
X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.021,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QF5Yyl4hcroR for ; Thu, 28 Feb 2013 07:42:47 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 80D3221F85DF for ; Thu, 28 Feb 2013 07:42:47 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DABC15311B24; Thu, 28 Feb 2013 10:42:46 -0500 (EST)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C6AFC5311B43; Thu, 28 Feb 2013 10:42:46 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 28 Feb 2013 10:42:46 -0500
Message-ID: <512F7AB8.7080109@mitre.org>
Date: Thu, 28 Feb 2013 10:41:44 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Mike Jones 
References: <512E2D7F.6060903@mitre.org> <4E1F6AAD24975D4BA5B1680429673943674BC644@TK5EX14MBXC283.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943674BC644@TK5EX14MBXC283.redmond.corp.microsoft.com>
Content-Type: multipart/alternative; boundary="------------060300080802060605070906"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Registration: grant_types and response_types
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 15:42:50 -0000

--------------060300080802060605070906
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

The good thing about having two fields is that they map to the two 
different parameter names directly. The trouble is that you could get in 
a situation where a client can't actually do anything, say if you 
register response type "token" and grant type "authorization_code". With 
a table like the one below, we can help developers see what the right 
mappings should be and help servers to enforce this.

Thoughts?

  -- Justin

On 02/27/2013 05:52 PM, Mike Jones wrote:
>
> John Bradley and I just talked about this during a side meeting at 
> RSA.  We think that this is the mapping of grant types and defined 
> response types.  (The additional response_type values are registered 
> with IANA and defined in 
> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html.)
>
> *response_type value*
>
> 	
>
> *grant_types*
>
> code
>
> 	
>
> authorization_code
>
> token
>
> 	
>
> implicit
>
> id_token
>
> 	
>
> implicit
>
> token id_token
>
> 	
>
> implicit
>
> code token
>
> 	
>
> authorization_code implicit
>
> code id_token
>
> 	
>
> authorization_code implicit
>
> code token id_token
>
> 	
>
> authorization_code implicit
>
> none
>
> 	
>
> none
>
> If people agree that this is the mapping, and that it conveys 
> sufficient information, then conceivably OpenID Connect could drop the 
> response_types registration parameter and instead just use the OAuth 
> Registration "grant_types" parameter.
>
> What do others think?
>
> -- Mike
>
> P.S. There's a typo in the OAuth Registration spec section quoted 
> below.  The name "grant_type" should have been "grant_types", since 
> the value is a list.  We should correct that in the next version of 
> the spec.
>
> *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On 
> Behalf Of *Justin Richer
> *Sent:* Wednesday, February 27, 2013 8:00 AM
> *To:* oauth@ietf.org
> *Subject:* [OAUTH-WG] Registration: grant_types and response_types
>
> There has been some press lately about clients being able to use an 
> implicit flow to get tokens when they really ought to only use a code 
> flow, since the security considerations and protections for both are 
> very different. With this in mind, it makes sense that a dynamically 
> registered client should be limited to use only certain flows, if at 
> all possible.
>
> The dynamic registration document currently handles this using the 
> grant_type parameter (introduced in draft -03), which is defined in 
> section 2 as follows:
>
>     grant_type
>        OPTIONAL.  Array of grant types that a client may use.  These
>        grant types are defined as follows:
>   
>        *  "authorization_code": The Authorization Code Grant described in
>           OAuth2Section 4.1  .
>   
>        *  "implicit": The Implicit Grant described in OAuth2Section 4.2  .
>   
>        *  "password": The Resource Owner Password Credentials Grant
>           described in OAuth2Section 4.3  
>   
>        *  "client_credentials": The Client Credentials Grant described in
>           OAuth2Section 4.4  
>   
>        *  "refresh_token": The Refresh Token Grant described in OAuth2
>           Section 6  .
>   
>        Authorization Servers MAY allow for other values as defined in
>        grant type extensions to OAuth2.  The extension process is
>        described in OAuth2Section 2.5  , and the value of this parameter
>        MUST be the same as the value of the "grant_type" parameter
>        defined in the extension.
>
>
> This allows the client to specify which flows it wants to be able to 
> use (including any extensions), and allows the server to to tell the 
> client in the client configuration response what flows it can expect 
> to work.
>
> OpenID Connect's registration has recently introduced the use of a 
> different parameter, response_type, for a similar but slightly 
> different purpose. The parameter is defined in the latest draft in 
> source control as:
>
> response_types
>
> OPTIONAL. JSON array containing a list of the OAuth 2.0 response_type
>
> values that this Client uses. If omitted, the default is that the Client
>
> uses only the code response type.
>
>
> OIDC makes use of response_types beyond just "code" and "token", 
> defining several new ones including combinations like "code idtoken".
>
> So my question to the group is this: Should we incorporate the OIDC 
> response_types parameter? Do we need both parameters specified in the 
> registration or is one sufficient? They're defined separately in the 
> OAuth2 protocol (one is on the Auth endpoint and one is on the Token 
> endpoint), but can only be used legally in particular combinations so 
> there would have to be normative text around particular values.
>
> In my opinion, I don't think we can get rid of grant_type, since 
> that's the only way to specify things like client_credentials flows 
> and most extensions. There might be value in also specifying 
> response_type, but I don't want to add extra fields unless there's a 
> clearly defined need for it.
>
>  -- Justin
>

--------------060300080802060605070906
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

    The good thing about having two fields is that they map to the two
    different parameter names directly. The trouble is that you could
    get in a situation where a client can't actually do anything, say if
    you register response type "token" and grant type
    "authorization_code". With a table like the one below, we can help
    developers see what the right mappings should be and help servers to
    enforce this.

    Thoughts?

     -- Justin

    On 02/27/2013 05:52 PM, Mike Jones
      wrote:

        John
            Bradley and I just talked about this during a side meeting
            at RSA.  We think that this is the mapping of grant types
            and defined response types.  (The additional response_type
            values are registered with IANA and defined in 
http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html.)

                response_type
                      value

                grant_types

                code

                authorization_code

                token

                implicit

                id_token

                implicit

                token
                    id_token

                implicit

                code
                    token

                authorization_code
                    implicit

                code
                    id_token

                authorization_code
                    implicit

                code
                    token id_token

                authorization_code
                    implicit

                none

                none

        If
            people agree that this is the mapping, and that it conveys
            sufficient information, then conceivably OpenID Connect
            could drop the response_types registration parameter and
            instead just use the OAuth Registration “grant_types”
            parameter.

        What
            do others think?

            -- Mike

        P.S. 
            There’s a typo in the OAuth Registration spec section quoted
            below.  The name “grant_type” should have been
            “grant_types”, since the value is a list.  We should correct
            that in the next version of the spec.

            From:
                oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]
                On Behalf Of Justin Richer

                Sent: Wednesday, February 27, 2013 8:00 AM

                To: oauth@ietf.org

                Subject: [OAUTH-WG] Registration: grant_types and
                response_types

        There has been
          some press lately about clients being able to use an implicit
          flow to get tokens when they really ought to only use a code
          flow, since the security considerations and protections for
          both are very different. With this in mind, it makes sense
          that a dynamically registered client should be limited to use
          only certain flows, if at all possible.

          The dynamic registration document currently handles this using
          the grant_type parameter (introduced in draft -03), which is
          defined in section 2 as follows:
           grant_type
              OPTIONAL.  Array of grant types that a client may use.  These
              grant types are defined as follows:

              *  "authorization_code": The Authorization Code Grant described in
                 OAuth2 Section 4.1.

              *  "implicit": The Implicit Grant described in OAuth2 Section 4.2.

              *  "password": The Resource Owner Password Credentials Grant
                 described in OAuth2 Section 4.3

              *  "client_credentials": The Client Credentials Grant described in
                 OAuth2 Section 4.4

              *  "refresh_token": The Refresh Token Grant described in OAuth2
                 Section 6.

              Authorization Servers MAY allow for other values as defined in
              grant type extensions to OAuth2.  The extension process is
              described in OAuth2 Section 2.5, and the value of this parameter
              MUST be the same as the value of the "grant_type" parameter
              defined in the extension.

          This allows the client to specify which flows it wants to be
          able to use (including any extensions), and allows the server
          to to tell the client in the client configuration response
          what flows it can expect to work.

          OpenID Connect's registration has recently introduced the use
          of a different parameter, response_type, for a similar but
          slightly different purpose. The parameter is defined in the
          latest draft in source control as:
        response_types
        OPTIONAL. JSON array containing a
              list of the OAuth 2.0 response_type

        values that this Client uses. If
              omitted, the default is that the Client

        uses only the code response type.

          OIDC makes use of response_types beyond just "code" and
          "token", defining several new ones including combinations like
          "code idtoken".

        So my question to the group is this: Should
          we incorporate the OIDC response_types parameter? Do we need
          both parameters specified in the registration or is one
          sufficient? They're defined separately in the OAuth2 protocol
          (one is on the Auth endpoint and one is on the Token
          endpoint), but can only be used legally in particular
          combinations so there would have to be normative text around
          particular values.

          In my opinion, I don't think we can get rid of grant_type,
          since that's the only way to specify things like
          client_credentials flows and most extensions. There might be
          value in also specifying response_type, but I don't want to
          add extra fields unless there's a clearly defined need for it.

           -- Justin

--------------060300080802060605070906--

From ve7jtb@ve7jtb.com  Thu Feb 28 08:17:52 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAFC21F8A7B for ; Thu, 28 Feb 2013 08:17:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDAfvuFQupGF for ; Thu, 28 Feb 2013 08:17:52 -0800 (PST)
Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) by ietfa.amsl.com (Postfix) with ESMTP id 065A821F8ABC for ; Thu, 28 Feb 2013 08:17:51 -0800 (PST)
Received: by mail-pb0-f48.google.com with SMTP id wy12so1149744pbc.21 for ; Thu, 28 Feb 2013 08:17:49 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=KymjLGuOuzNFx6+PdevK03325chDIJKQG6qFPJNMaK4=; b=LjahNJFks0qVUKXqsDnys4uGAMtNQ+UUhTtfjU7frfRtEBCh0i8cA+SFmB3zQSEnI7 82AknQFqXqBB33ocpbInFZ1EPNIec7wqfVCN1u5phN9lfn8rPrHFkESkwOXX41tLF20R WA1TcrIkja29hFGWKtXC0dxlk8czVhiyBEyYP3pNH0mQgVdk/Zq2Tg3DiJHXcJlEeH6f zcw2LhQWvgcCrx82Q2WkDw/bcg/4PR5Bo5SBUDE+sgsIJ6DSKNqY/S5QYFLnTHFbxyEL l4FDr4nHqYUJemHIgNZqbkZyYKZVvyeciz8VTtYc2Kg3L1r37+c24xs73sDJg7VIOT9l No4g==
X-Received: by 10.66.147.137 with SMTP id tk9mr14070231pab.106.1362068269195;  Thu, 28 Feb 2013 08:17:49 -0800 (PST)
Received: from [192.168.41.99] (ip-64-134-220-138.public.wayport.net. [64.134.220.138]) by mx.google.com with ESMTPS id zv5sm7976062pab.2.2013.02.28.08.17.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Feb 2013 08:17:47 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_13F3981D-CB3C-4E89-BA41-1074262C1707"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net>
Date: Thu, 28 Feb 2013 08:17:44 -0800
Message-Id: 
References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net>
To: Hannes Tschofenig 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQnUO6rLjT3DZNonKtNrPo78a33rmfiEHAwERoiFKOEDGOGWggi0pZ8B53i+leZeDupkbVAz
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] JWT - scope claim missing
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 16:17:52 -0000

--Apple-Mail=_13F3981D-CB3C-4E89-BA41-1074262C1707
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

While scope is one method that a AS could communicate authorization to a =
RS, it is not the only or perhaps even the most likely one.
Using scope requires a relatively tight binding between the RS and AS,  =
UMA uses a different mechanism that describes finer grained operations. =20=

The AS may include roles, user, or other more abstract claims that the =
the client may (god help them) pass on to EXCML for processing.

While having a scopes claim is possible, like any other claim it is not =
part of the JWT core security processing claims, and needs to be defined =
by extension.

John B.
On 2013-02-28, at 2:29 AM, Hannes Tschofenig  =
wrote:

> Hi Mike,=20
>=20
> when I worked on the MAC specification I noticed that the JWT does not =
have a claim for the scope. I believe that this would be needed to allow =
the resource server to verify whether the scope the authorization server =
authorized is indeed what the client is asking for.=20
>=20
> Ciao
> Hannes
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail=_13F3981D-CB3C-4E89-BA41-1074262C1707
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMjI4MTYxNzQ1WjAjBgkqhkiG9w0BCQQxFgQUcYuNv7K+
AN3J36Ue0aYoUd8MJY0wgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAoelMfWdQhhjiBjS+p+6yhxEBRu/sEHnL7cHlIsXZ
xe2S8BHGqwglYH1PnwHHzFl48qd5VrOe2AAxzLylumdQfkPvPP8CBMN4IBsvsByYpuzuyk0bkQO5
1cc+WH2s6+SOYX2u0aNfYhK9HYOrcMztuQ4MXcKpxdmkIvnZlSDXIibAzQjZi8YiOTMAneIsECIO
bCI9+0Lsf/D/CMjY+gWsu0kC1AsuQjt7bf1eUX5KWXoKND6tAsZVBhc84nW6KL/2WjOKdaTaKSPA
+ne93VQGIzRaav0uIvk2rga5k/2hJYNbKOq8AM0hQANQJJCztGYrWNPOqTsteiGQhJmQDssxWAAA
AAAAAA==

--Apple-Mail=_13F3981D-CB3C-4E89-BA41-1074262C1707--

From phil.hunt@oracle.com  Thu Feb 28 08:24:49 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5194F21F85F5 for ; Thu, 28 Feb 2013 08:24:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.538
X-Spam-Level: 
X-Spam-Status: No, score=-5.538 tagged_above=-999 required=5 tests=[AWL=-0.335, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpKWwISNJ83m for ; Thu, 28 Feb 2013 08:24:48 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 82ADC21F854F for ; Thu, 28 Feb 2013 08:24:46 -0800 (PST)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1SGOcot020620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Feb 2013 16:24:39 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1SGObg3018557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2013 16:24:38 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1SGOZSE018410; Thu, 28 Feb 2013 10:24:37 -0600
Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 28 Feb 2013 08:24:35 -0800
References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net> 
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: 
X-Mailer: iPhone Mail (10B146)
From: Phil Hunt 
Date: Thu, 28 Feb 2013 08:24:32 -0800
To: John Bradley 
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] JWT - scope claim missing
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 16:24:50 -0000

Are you advocating TWO systems? That seems like a bad choice.=20

I would rather fix scope than go to a two system approach.

Phil

Sent from my phone.

On 2013-02-28, at 8:17, John Bradley  wrote:

> While scope is one method that a AS could communicate authorization to a R=
S, it is not the only or perhaps even the most likely one.
> Using scope requires a relatively tight binding between the RS and AS,  UM=
A uses a different mechanism that describes finer grained operations. =20
> The AS may include roles, user, or other more abstract claims that the the=
 client may (god help them) pass on to EXCML for processing.
>=20
> While having a scopes claim is possible, like any other claim it is not pa=
rt of the JWT core security processing claims, and needs to be defined by ex=
tension.
>=20
> John B.
> On 2013-02-28, at 2:29 AM, Hannes Tschofenig  w=
rote:
>=20
>> Hi Mike,=20
>>=20
>> when I worked on the MAC specification I noticed that the JWT does not ha=
ve a claim for the scope. I believe that this would be needed to allow the r=
esource server to verify whether the scope the authorization server authoriz=
ed is indeed what the client is asking for.=20
>>=20
>> Ciao
>> Hannes
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From phil.hunt@oracle.com  Thu Feb 28 08:29:45 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DADCD21F8C0C for ; Thu, 28 Feb 2013 08:29:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.517
X-Spam-Level: 
X-Spam-Status: No, score=-5.517 tagged_above=-999 required=5 tests=[AWL=-0.314, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fanGIlsBD5cd for ; Thu, 28 Feb 2013 08:29:44 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 900EA21F8C09 for ; Thu, 28 Feb 2013 08:29:43 -0800 (PST)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1SGTbYU006116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Feb 2013 16:29:38 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1SGTaqY012856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2013 16:29:36 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1SGTaQn004001; Thu, 28 Feb 2013 10:29:36 -0600
Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 28 Feb 2013 08:29:36 -0800
References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net> 
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <117150EA-E7D6-47EF-A8DB-BF07962B6E11@oracle.com>
X-Mailer: iPhone Mail (10B146)
From: Phil Hunt 
Date: Thu, 28 Feb 2013 08:29:34 -0800
To: John Bradley 
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] JWT - scope claim missing
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 16:29:46 -0000

Personally I am starting to feel strongly that access tokens should be highl=
y contextual and therefore tightly bound to specific resources.=20

It seems to me trust will get incredibly complex if we start federating acce=
ss tokens. My belief is that uma needs to still chain to local authorization=
 servers and should never expect a federated token to be accepted directly.=20=

I hope to blog on this in more detail. But i wanted to express concerns abou=
t trust with federated authorization vs federated authn.=20

Scope is just the tip of the iceberg.=20

Phil

Sent from my phone.

On 2013-02-28, at 8:17, John Bradley  wrote:

> While scope is one method that a AS could communicate authorization to a R=
S, it is not the only or perhaps even the most likely one.
> Using scope requires a relatively tight binding between the RS and AS,  UM=
A uses a different mechanism that describes finer grained operations. =20
> The AS may include roles, user, or other more abstract claims that the the=
 client may (god help them) pass on to EXCML for processing.
>=20
> While having a scopes claim is possible, like any other claim it is not pa=
rt of the JWT core security processing claims, and needs to be defined by ex=
tension.
>=20
> John B.
> On 2013-02-28, at 2:29 AM, Hannes Tschofenig  w=
rote:
>=20
>> Hi Mike,=20
>>=20
>> when I worked on the MAC specification I noticed that the JWT does not ha=
ve a claim for the scope. I believe that this would be needed to allow the r=
esource server to verify whether the scope the authorization server authoriz=
ed is indeed what the client is asking for.=20
>>=20
>> Ciao
>> Hannes
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From bcampbell@pingidentity.com  Thu Feb 28 08:45:11 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42F821F8996 for ; Thu, 28 Feb 2013 08:45:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.903
X-Spam-Level: 
X-Spam-Status: No, score=-5.903 tagged_above=-999 required=5 tests=[AWL=0.073,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3gBswWXDB8C for ; Thu, 28 Feb 2013 08:45:02 -0800 (PST)
Received: from na3sys009aog133.obsmtp.com (na3sys009aog133.obsmtp.com [74.125.149.82]) by ietfa.amsl.com (Postfix) with ESMTP id C84F521F886A for ; Thu, 28 Feb 2013 08:44:52 -0800 (PST)
Received: from mail-ie0-f199.google.com ([209.85.223.199]) (using TLSv1) by na3sys009aob133.postini.com ([74.125.148.12]) with SMTP ID DSNKUS+JhEy4pqJq3WkgpyFR4Vj8VqO540Se@postini.com; Thu, 28 Feb 2013 08:44:52 PST
Received: by mail-ie0-f199.google.com with SMTP id c13so12605736ieb.2 for ; Thu, 28 Feb 2013 08:44:51 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=w4xU3WDta08Wu7itTzvqp+4weI7hczo1UQ5ra0S0zas=; b=euEB6rtFqhbh0sYCwXc6tXu82ElmOlM8WbwZxOV9N9wCnn/bp2m4P6DzUoeX059GQB RC3PE9YRSHDd5iUabLHakWrBx8EbK0JIgPPFQTOHFUKzXUoMbhyNLfqgWCw1lygIeMdD m5vwr9jknlVhpy6HIG1CK1u2GgwCJ258y8HAHz8hdngH0M888jLprlvuhkQREHqVPqU+ WNIQPfq3isVL17x8YBv5z1Db4JlCwKJvuTe9AFgrKmE59yuXPiEkOnR28N9ualGkNOpy TKZj+yLDZiukeztUFwjHwAshFwnTb/tb1mIugD4+gdtzr+0fHUjlhAlMPtBLihwHEuhb tyIA==
X-Received: by 10.42.30.132 with SMTP id v4mr3687424icc.34.1362069891576; Thu, 28 Feb 2013 08:44:51 -0800 (PST)
X-Received: by 10.42.30.132 with SMTP id v4mr3687415icc.34.1362069891435; Thu, 28 Feb 2013 08:44:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.32.106 with HTTP; Thu, 28 Feb 2013 08:44:21 -0800 (PST)
In-Reply-To: 
References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net>  
From: Brian Campbell 
Date: Thu, 28 Feb 2013 09:44:21 -0700
Message-ID: 
To: Phil Hunt 
Content-Type: multipart/alternative; boundary=20cf301d420e09fbbf04d6cb9c9d
X-Gm-Message-State: ALoCoQk3QYqSBmpM4AUGCTLWPGyzvSo84tkW4wWNjMv1/V9h+ZY5KYtSqww5Sk0YYxKuSgt1soOtdd5ZOiIIs6zWSpMrfxqFHXc0Agl0lX6gnzIzJKvMslgtigApTk2XUkxt+5bdCMDC
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] JWT - scope claim missing
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 16:45:11 -0000

--20cf301d420e09fbbf04d6cb9c9d
Content-Type: text/plain; charset=ISO-8859-1

I think John's point was more that scope is something rather specific to an
OAuth access token and, while JWT is can be used to represent an access
token, it's not the only application of JWT. The 'standard' claims in JWT
are those that are believed (right or wrong) to be widely applicable across
different applications of JWT. One could argue about it but scope is
probably not one of those.

It would probably make sense to try and build a profile of JWT specifically
for OAuth access tokens (though I suspect there are some turtles and
dragons in there), which might be the appropriate place to define/register
a scope claim.

On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt  wrote:

> Are you advocating TWO systems? That seems like a bad choice.
>
> I would rather fix scope than go to a two system approach.
>
> Phil
>
> Sent from my phone.
>
> On 2013-02-28, at 8:17, John Bradley  wrote:
>
> > While scope is one method that a AS could communicate authorization to a
> RS, it is not the only or perhaps even the most likely one.
> > Using scope requires a relatively tight binding between the RS and AS,
>  UMA uses a different mechanism that describes finer grained operations.
> > The AS may include roles, user, or other more abstract claims that the
> the client may (god help them) pass on to EXCML for processing.
> >
> > While having a scopes claim is possible, like any other claim it is not
> part of the JWT core security processing claims, and needs to be defined by
> extension.
> >
> > John B.
> > On 2013-02-28, at 2:29 AM, Hannes Tschofenig 
> wrote:
> >
> >> Hi Mike,
> >>
> >> when I worked on the MAC specification I noticed that the JWT does not
> have a claim for the scope. I believe that this would be needed to allow
> the resource server to verify whether the scope the authorization server
> authorized is indeed what the client is asking for.
> >>
> >> 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
>

--20cf301d420e09fbbf04d6cb9c9d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I think John's point was more that scope is somet=
hing rather specific to an OAuth access token and, while JWT is can be used=
 to represent an access token, it's not the only application of JWT. Th=
e 'standard' claims in JWT are those that are believed (right or wr=
ong) to be widely applicable across different applications of JWT. One coul=
d argue about it but scope is probably not one of those.

It would probably make sense to try and build a profile of JWT sp=
ecifically for OAuth access tokens (though I suspect there are some turtles=
 and dragons in there), which might be the appropriate place to define/regi=
ster a scope claim.

On Thu,=
 Feb 28, 2013 at 9:24 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

Are you advocating TWO systems? That seems l=
ike a bad choice.

I would rather fix scope than go to a two system approach.

Phil

Sent from my phone.

On 2013-02-28, at 8:17, John Bradley <ve7jtb@ve7jtb.com> wrote:

> While scope is one method that a AS could communicate authorization to=
 a RS, it is not the only or perhaps even the most likely one.

> Using scope requires a relatively tight binding between the RS and AS,=
 =A0UMA uses a different mechanism that describes finer grained operations.=

> The AS may include roles, user, or other more abstract claims that the=
 the client may (god help them) pass on to EXCML for processing.

>

> While having a scopes claim is possible, like any other claim it is no=
t part of the JWT core security processing claims, and needs to be defined =
by extension.

>

> John B.

> On 2013-02-28, at 2:29 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

>

>> Hi Mike,

>>

>> when I worked on the MAC specification I noticed that the JWT does=
 not have a claim for the scope. I believe that this would be needed to all=
ow the resource server to verify whether the scope the authorization server=
 authorized is indeed what the client is asking for.

>>

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

h=
ttps://www.ietf.org/mailman/listinfo/oauth

--20cf301d420e09fbbf04d6cb9c9d--

From sberyozkin@gmail.com  Thu Feb 28 08:52:39 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26B521F8C12 for ; Thu, 28 Feb 2013 08:52:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.499
X-Spam-Level: 
X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUE8RO6p4n3Y for ; Thu, 28 Feb 2013 08:52:38 -0800 (PST)
Received: from mail-ee0-f50.google.com (mail-ee0-f50.google.com [74.125.83.50]) by ietfa.amsl.com (Postfix) with ESMTP id BF67B21F8C1E for ; Thu, 28 Feb 2013 08:52:37 -0800 (PST)
Received: by mail-ee0-f50.google.com with SMTP id e51so1710852eek.23 for ; Thu, 28 Feb 2013 08:52:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=UaGQ2ctUg1Esx+a2I3agQMwa1DVO8/sDAFBR7HQxc7s=; b=EwmsTNqdPzEhNa2Zt1pe99OPDj1CAQ0TPqSBpghc7tWW7M8hGEHgmXjQ890vzqDH8W 2OITYb9l0Yqq1W3ZR5xA9lOXbtA7VhM3HlyrcFrSo7Uuzahfi2VsvRH3WX382UXEo5by wp863ZdAVcBnPG/I843EWzdJePELhHcsf3WgNidp0pGv6YF+cE/mFQDMj/my5lWbn/Ea 0vKbu/w2c2tJDF+RFZRHcLxb3kExUFrAwudizdP/HTWdfAqJEF64+I4MKrTxJNzEq99N PhjsQ23kPcyAABUSkT4f1AV3LHypPSRZOjTSEpY7iHZa53ne83TBMHxK4xsEJXdg+r9X zBWw==
X-Received: by 10.14.200.137 with SMTP id z9mr18455256een.20.1362070352155; Thu, 28 Feb 2013 08:52:32 -0800 (PST)
Received: from [192.168.2.5] ([79.97.76.201]) by mx.google.com with ESMTPS id r4sm12747826eeo.12.2013.02.28.08.52.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Feb 2013 08:52:31 -0800 (PST)
Message-ID: <512F8B4D.60102@gmail.com>
Date: Thu, 28 Feb 2013 16:52:29 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Hannes Tschofenig 
References:  <512CAC45.9070501@gmail.com> <512CAF54.1060204@gmail.com> <1EE69E99-6051-4078-8CDE-63558075FE16@gmx.net>
In-Reply-To: <1EE69E99-6051-4078-8CDE-63558075FE16@gmx.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-http-mac and draft-tschofenig-oauth-hotk re-submitted
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 16:52:39 -0000

Hi Hannes

On 27/02/13 08:54, Hannes Tschofenig wrote:
> Hi Sergey,
>
> good that this issue got clarified.
>
> Regarding:
>
>> By the way, should the server be able to enforce the use of MAC as opposed to having a client preferring it with its audience info ? If the client does not understand it then it does not have the capabilities to work with this specific server.
>
> Currently, the authorization server decides about the use of a certain token type. The audience field is used to allow the client to tell the server which resource  server it wants to talk to. This is of value not only for this specification but also for the bearer token specification. In this specification the resource server uses this audience field for selecting the appropriate key to encrypt the access token. If the client is tricked in sending the access token to a different resource server then that server will not be able to decrypt the access token and will not be able to retrieve the session key. Consequently, it will not be able to impersonate the client towards another resource server.
Thanks for the explanation, I should've read better, 'audience' is a 
useful attribute.

What confused me was this text: "Authorization servers issue MAC Tokens 
based on requests from clients." - it kind of reads to me that the 
clients drive whether it is MAC or some other token type is issued in 
exchange for a grant while I'd expect the AS administrators deciding on 
what sort of token type is used.

As for "MUST" and audience - might it make sense to replace it with 
SHOULD or RECOMMENDED ? I wonder if some issues like port number of 
individual resource servers comprising the bigger resource server 
application, etc, might make it difficult to use 'audience' - not sure 
if it of real concern or not :-)

Thanks, Sergey

>
> Ciao
> Hannes
>
> On Feb 26, 2013, at 2:49 PM, Sergey Beryozkin wrote:
>
>> Hi Again
>> On 26/02/13 12:36, Sergey Beryozkin wrote:
>>> Hi Hannes
>>> On 25/02/13 12:46, Hannes Tschofenig wrote:
>>>> Hi all,
>>>>
>>>> I just submitted an updated version of the
>>>> draft-ietf-oauth-v2-http-mac-03.txt.
>>>>
>>>
>>> It definitely has more interesting content (about architecture, session
>>> keys, etc) - this is really useful IMHO.
>>>
>>> What I'm not really understanding is why a 2-way TLS transport for the
>>> session key is not even considered.
>>> Instead this uber-complex (in the context of this spec, IMHO) JWT thing
>>> is there once again. I appreciate why it may be the case, primarily to
>>> do with reusing the work done around JWT and having some
>>> common/recommended access token representation, but disallowing a basic
>>> bearer token be 'enhanced' with MAC over two-way TLS seems like not
>>> ideal at all IMHO.
>>> To be honest, I'm not sure why would anyone use JWT+MAC instead of just
>>> JWE, in cases when people are really comfortable with doing JWT. I guess
>>> we may be talking now about better security characteristics, but this
>>> will help a very limited audience as compared to a wider one which can
>>> use Bearer+MAC over 2-way TLS, straightforward, very cheap effort to get
>>> started.
>>>
>> Oops, I've misread, I think I did, I was reading a Session Key Transport to Resource Server section [1] where using JWT seems just OK, while a transport to the client section [2] does not enforce the use of JWT.
>>
>> Sorry for a noise :-)
>>
>> By the way, should the server be able to enforce the use of MAC as opposed to having a client preferring it with its audience info ? If the client does not understand it then it does not have the capabilities to work with this specific server.
>>
>> Thanks, Sergey
>>
>> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03#section-4.2
>> [2] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03#section-4.1
>>
>>> just my 2c
>>> Thanks, Sergey
>>>
>>>> I would like to point out that this is **discussion input** -- not
>>>> agreed content. Anything in the document is subject to change!
>>>> You also may notice that there are a few questions in the writeup.
>>>>
>>>> I was trying to more specific about some of the design aspects that
>>>> folks had proposed during the last few months.
>>>> I have also re-submitted the draft-tschofenig-oauth-hotk, which
>>>> includes a TLS and a JSON-based solution approach.
>>>>
>>>> In general, the open questions still seem to be related to
>>>> * Key distribution: What should be described in a document? What is
>>>> mandatory to implement?
>>>> * Selective header field protection: This is something that was
>>>> brought forward in discussions and I have included a proposal of how
>>>> this could look like.
>>>> * Channel Binding: Functionality is also included to deal with
>>>> man-in-the-middle attacks against TLS. There are, however, two types
>>>> of channel bindings defined in RFC 5929. Are both needed? If not,
>>>> which one should be selected?
>>>> * Integrity protection and data origin authentication in both
>>>> directions: The current writeup allows the protection to be extended
>>>> to messages beyond the initial request. This also offers key
>>>> confirmation by the server and protection of any responses.
>>>>
>>>> Writing the text I also noticed that I do not quite understand how
>>>> nested JWT documents are supposed to look like. For example, how do I
>>>> encrypt the mac_key carried inside the JWT plus add a signature of all
>>>> other fields? Currently, I have just encrypted the entire payload.
>>>>
>>>> I hope to have some discussions prior to the IETF meeting so that we
>>>> have a more fruitful discussion at the face-to-face meeting.
>>>>
>>>> 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
>

From jricher@mitre.org  Thu Feb 28 08:58:11 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB4F21F8BB6 for ; Thu, 28 Feb 2013 08:58:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.578
X-Spam-Level: 
X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5T5NyXdpGCp for ; Thu, 28 Feb 2013 08:58:10 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8DD21F8C08 for ; Thu, 28 Feb 2013 08:57:59 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9B37D1F1B66; Thu, 28 Feb 2013 11:57:58 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7D9B51F1B31; Thu, 28 Feb 2013 11:57:58 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 28 Feb 2013 11:57:58 -0500
Message-ID: <512F8C57.2000901@mitre.org>
Date: Thu, 28 Feb 2013 11:56:55 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Hannes Tschofenig 
References: 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] JWT & Token Introspection Relationship
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 16:58:11 -0000

Hannes,

The main issue here is that JWT has been built to be used for things 
other than OAuth tokens (assertions, for instance), and that the 
introspection endpoint is very specifically tied to OAuth. At Torsten's 
suggestion, I've tried to align the output of the introspection endpoint 
to the appropriate claims from a JWT field, but this is a case of making 
the syntax match and not a normative tie in. JWT has no place for 
"client_id" or "scope", which I think are vital for the token 
introspection.

This endpoint is not simply about unpacking information that's already 
contained in a token for clients that don't want to parse the token 
themselves, it's about providing metadata that the server has about the 
token and its surrounding grant/session to the requestor. The normal 
requestor, in my view, is going to be an RS, but it can really be anyone 
who has the permission to do so.

  -- Justin

On 02/28/2013 05:37 AM, Hannes Tschofenig wrote:
> Hi Mike, Hi Justin,
>
> when I looked at the JWT and the draft-richer-oauth-introspection documents I noticed that the two are not aligned (neither from the fields that are supported nor from the way how the fields are defined).
>
> IMHO  draft-richer-oauth-introspection must not define new elements since those are already defined in the JWT.
>
> You could compare the relationship between the JWT and the draft-richer-oauth-introspection in the following way:
>
> The JWT passes the content per value from the AS via the client to the RS.
> The draft-richer-oauth-introspection passes a reference to the content from the AS via the client to the RS and since the RS ultimately needs to know the content it has to resolve the reference so that it gets the content.
>
> Therefore, the content (the different JSON encoded structures) should only be defined once and could then be used in both specs.
>
> Ciao
> Hannes
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From ve7jtb@ve7jtb.com  Thu Feb 28 08:58:56 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F31C21F8C08 for ; Thu, 28 Feb 2013 08:58:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StWkK-aanb7i for ; Thu, 28 Feb 2013 08:58:48 -0800 (PST)
Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by ietfa.amsl.com (Postfix) with ESMTP id C188721F8A09 for ; Thu, 28 Feb 2013 08:58:48 -0800 (PST)
Received: by mail-pb0-f45.google.com with SMTP id ro8so1181799pbb.18 for ; Thu, 28 Feb 2013 08:58:48 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=hk3crOGbvC6Nsy71SR2vv93kllcVyVjGmEvwLwUtAkk=; b=M31hkgpBeNCHjNAjkzWS43orQA5T9F2r/YlnpSI04NTL/tStn/72dGAHn3fbzJHSkr bBpwPYJOjDUYeup2AuwU/VXLaMDzy2mXIf0+lHmfZmKfAkQ3LiYvcf/l2yNE8ouZl3qO 241xD2LwZJl69E4FhOq9Lrq+1mPZPlLAyNI6x6pkgoeZ7H5q+bPWpFBMjeUtqdJSF9jd BoUfqFBXzFWM1cvvrSQT1tXgoB4GtKdjbUSiKgtkGIVOccsd5hBgmbzItC4yzi79t7+p J3QcuVyhA6b/aJ2Mw2wT/QVqCzeg1WBaXKqEwCQCNb2J4+l6g6WLnXcN2Mh4Ex/ntOAr /Dpw==
X-Received: by 10.68.194.37 with SMTP id ht5mr9783166pbc.194.1362070727850; Thu, 28 Feb 2013 08:58:47 -0800 (PST)
Received: from [192.168.41.99] (ip-64-134-220-138.public.wayport.net. [64.134.220.138]) by mx.google.com with ESMTPS id t6sm9820423paz.11.2013.02.28.08.58.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Feb 2013 08:58:46 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_71F7F8CC-D00C-4DAE-89A1-EBE7F79F3E78"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: 
Date: Thu, 28 Feb 2013 08:58:42 -0800
Message-Id: 
References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net>   
To: Brian Campbell 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQnQ2uI3veQZGvWQhX6IDfGEq8+/oG+d1tyvno+TU3obOsGCjL502kqauoJjncE/zdZPD4x4
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] JWT - scope claim missing
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 16:58:56 -0000

--Apple-Mail=_71F7F8CC-D00C-4DAE-89A1-EBE7F79F3E78
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_96588381-45ED-4309-B59F-01C748193BD9"

--Apple-Mail=_96588381-45ED-4309-B59F-01C748193BD9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Yes, defining scope in JWT is the wrong place.   JWT needs to stick to =
the security claims needed to process JWT.

I also don't know how far you get requiring a specific authorization =
format for JWT, some AS will wan to use a opaque reference, some might =
want to use a user claim or role claim, others may use scopes,  =
combining scopes and claims is also possible.

Right now it is up to a AS RS pair to agree on how to communicate =
authorization.   I don't want MAC to be more restrictive than bearer =
when it comes to authorization between AS and RS.

Hannes wanted to know why JWT didn't define scope.  The simple answer is =
that it is out of scope for JWT itself.   It might be defined in a OAuth =
access token profile for JWT but it should not be specific to MAC.

John B.
On 2013-02-28, at 8:44 AM, Brian Campbell  =
wrote:

> I think John's point was more that scope is something rather specific =
to an OAuth access token and, while JWT is can be used to represent an =
access token, it's not the only application of JWT. The 'standard' =
claims in JWT are those that are believed (right or wrong) to be widely =
applicable across different applications of JWT. One could argue about =
it but scope is probably not one of those.
>=20
> It would probably make sense to try and build a profile of JWT =
specifically for OAuth access tokens (though I suspect there are some =
turtles and dragons in there), which might be the appropriate place to =
define/register a scope claim.
>=20
>=20
> On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt  =
wrote:
> Are you advocating TWO systems? That seems like a bad choice.
>=20
> I would rather fix scope than go to a two system approach.
>=20
> Phil
>=20
> Sent from my phone.
>=20
> On 2013-02-28, at 8:17, John Bradley  wrote:
>=20
> > While scope is one method that a AS could communicate authorization =
to a RS, it is not the only or perhaps even the most likely one.
> > Using scope requires a relatively tight binding between the RS and =
AS,  UMA uses a different mechanism that describes finer grained =
operations.
> > The AS may include roles, user, or other more abstract claims that =
the the client may (god help them) pass on to EXCML for processing.
> >
> > While having a scopes claim is possible, like any other claim it is =
not part of the JWT core security processing claims, and needs to be =
defined by extension.
> >
> > John B.
> > On 2013-02-28, at 2:29 AM, Hannes Tschofenig =
 wrote:
> >
> >> Hi Mike,
> >>
> >> when I worked on the MAC specification I noticed that the JWT does =
not have a claim for the scope. I believe that this would be needed to =
allow the resource server to verify whether the scope the authorization =
server authorized is indeed what the client is asking for.
> >>
> >> 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
>=20

--Apple-Mail=_96588381-45ED-4309-B59F-01C748193BD9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

Yes, =
defining scope in JWT is the wrong place.   JWT needs to stick to =
the security claims needed to process JWT.
I also =
don't know how far you get requiring a specific authorization format for =
JWT, some AS will wan to use a opaque reference, some might want to use =
a user claim or role claim, others may use scopes,  combining =
scopes and claims is also possible.

Right now =
it is up to a AS RS pair to agree on how to communicate authorization. =
  I don't want MAC to be more restrictive than bearer when it comes =
to authorization between AS and RS.

Hannes wanted =
to know why JWT didn't define scope.  The simple answer is that it =
is out of scope for JWT itself.   It might be defined in a OAuth =
access token profile for JWT but it should not be specific to =
MAC.

John B.
On 2013-02-28, =
at 8:44 AM, Brian Campbell <bcampbell@pingidentity.com&=
gt; wrote:

I think John's point was more that =
scope is something rather specific to an OAuth access token and, while =
JWT is can be used to represent an access token, it's not the only =
application of JWT. The 'standard' claims in JWT are those that are =
believed (right or wrong) to be widely applicable across different =
applications of JWT. One could argue about it but scope is probably not =
one of those.

It would probably make sense to try and build a profile of JWT =
specifically for OAuth access tokens (though I suspect there are some =
turtles and dragons in there), which might be the appropriate place to =
define/register a scope claim.

On =
Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

Are you advocating TWO =
systems? That seems like a bad choice.

I would rather fix scope than go to a two system approach.

Phil

Sent from my phone.

On 2013-02-28, at 8:17, John Bradley <ve7jtb@ve7jtb.com> wrote:

> While scope is one method that a AS could communicate authorization =
to a RS, it is not the only or perhaps even the most likely one.

> Using scope requires a relatively tight binding between the RS and =
AS,  UMA uses a different mechanism that describes finer grained =
operations.

> The AS may include roles, user, or other more abstract claims that =
the the client may (god help them) pass on to EXCML for processing.

>

> While having a scopes claim is possible, like any other claim it is =
not part of the JWT core security processing claims, and needs to be =
defined by extension.

>

> John B.

> On 2013-02-28, at 2:29 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net>=
; wrote:

>

>> Hi Mike,

>>

>> when I worked on the MAC specification I noticed that the JWT =
does not have a claim for the scope. I believe that this would be needed =
to allow the resource server to verify whether the scope the =
authorization server authorized is indeed what the client is asking =
for.

>>

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

=

--Apple-Mail=_96588381-45ED-4309-B59F-01C748193BD9--

--Apple-Mail=_71F7F8CC-D00C-4DAE-89A1-EBE7F79F3E78
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMjI4MTY1ODQzWjAjBgkqhkiG9w0BCQQxFgQUS2vKhLP8
Qb8X6W+YwIjzC0Bz3lwwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAVkeW8WYTp/c09uvC3MBgT35GxhKU2A8MMqFeu/QR
7joyu0pMSdsQgI204F/ZY3fcGwXWay7TaM0VUzyxPu+4gwIE6UsI8J5HFxl8ebYIVC5HsrivGKEK
qsFc0KdmRjdCqdX/Ja2pe+i/nJ+B+w1eOedOhuuhuZNa9xJep7A3Pph32NWlA9PkOEXZt5Eu4Uzi
V+5FwWoPizR+Jb+FYqs6BHc9EK7q87ag/j15VecPwz4lF3klXNdnLfw40wKOCrI7kGPuyoUqf66D
zNSadHF1pbe7fM80a/urH1CBzshM5Y1jbSOp0ylYRi+m0irejz8yxo1Ety/5U2a+0aCNjhWgkgAA
AAAAAA==

--Apple-Mail=_71F7F8CC-D00C-4DAE-89A1-EBE7F79F3E78--

From sberyozkin@gmail.com  Thu Feb 28 09:00:32 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92EBB21F8860 for ; Thu, 28 Feb 2013 09:00:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.132
X-Spam-Level: 
X-Spam-Status: No, score=-3.132 tagged_above=-999 required=5 tests=[AWL=-0.733, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRUhP5i7BGLA for ; Thu, 28 Feb 2013 09:00:31 -0800 (PST)
Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by ietfa.amsl.com (Postfix) with ESMTP id D1A6021F84A4 for ; Thu, 28 Feb 2013 09:00:30 -0800 (PST)
Received: by mail-ee0-f45.google.com with SMTP id b57so1642085eek.4 for ; Thu, 28 Feb 2013 09:00:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pqSoO6ao0e9yKoVFXwk8KmOoB95O7RQtMtx0TS699JI=; b=TKIbgD2MReSYoDiuYi0cN86J+78RI8cwWH9Zp5hNNu6fBWVm1+r5+gVEglw5XExPm3 y/PBNB4xznjnK6zbA5QXukeh3VaBbuzHCR9q81clD347eSRnSHp2Vol4igy+bJdAnCzH I3AqIuLKgj+RHj+u1GlzFkhaTOUxF+9C9y6rvD6PtBLLqVe1rQRYe4sMtv3bROx0U5yA 0PLDBN0EOtKPCQTIq7IHYdpRs5FnGGWpeafuH/yZLEShOBtdxr+3UNlaxdDH+LjX7B5H quc6meQosspaXsinYMTML8fRnD78q+sqdjzzEgHcAmMLqqMRfZwUNvQJ21Fb/CRlxtJd sPTw==
X-Received: by 10.14.216.198 with SMTP id g46mr18449568eep.30.1362070830015; Thu, 28 Feb 2013 09:00:30 -0800 (PST)
Received: from [192.168.2.5] ([79.97.76.201]) by mx.google.com with ESMTPS id o3sm12780800eem.15.2013.02.28.09.00.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Feb 2013 09:00:29 -0800 (PST)
Message-ID: <512F8D24.8020303@gmail.com>
Date: Thu, 28 Feb 2013 17:00:20 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Hannes Tschofenig 
References:  <512CAC45.9070501@gmail.com> <7E351B5A-5609-46B0-A15A-CF3FA1D97D56@gmx.net>
In-Reply-To: <7E351B5A-5609-46B0-A15A-CF3FA1D97D56@gmx.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-http-mac and draft-tschofenig-oauth-hotk re-submitted
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 17:00:33 -0000

Hi Hannes
On 27/02/13 08:46, Hannes Tschofenig wrote:
> Hi Sergey,
>
> thanks for your input.
>
> On Feb 26, 2013, at 2:36 PM, Sergey Beryozkin wrote:
>
>> Hi Hannes
>> On 25/02/13 12:46, Hannes Tschofenig wrote:
>>> Hi all,
>>>
>>> I just submitted an updated version of the draft-ietf-oauth-v2-http-mac-03.txt.
>>>
>>
>> It definitely has more interesting content (about architecture, session keys, etc) - this is really useful IMHO.
>>
>> What I'm not really understanding is why a 2-way TLS transport for the session key is not even considered.
>
> Could you explain how this would look like?
>
Given my earlier confusion, and knowing it is a path between AS and RS, 
what would prevent RS and AS exchanging their certificates and admins 
configuring both to require a client certificate authentication ?

and then basically use some simple name/value exchange ? I don't mind 
against having a JWT profile supported at the AS-to-RS path

What I find a bit unusual is the fact that this AS to RS path is even 
covered - this is probably the first attempt AFAIK :-), though I guess 
it must be important to do it

>> Instead this uber-complex (in the context of this spec, IMHO) JWT thing is there once again. I appreciate why it may be the case, primarily to do with reusing the work done around JWT and having some common/recommended access token representation, but disallowing a basic bearer token be 'enhanced' with MAC over two-way TLS seems like not ideal at all IMHO.
>
> Note that JWT is used only for the access token encoding.
>
>> To be honest, I'm not sure why would anyone use JWT+MAC instead of just JWE,
>
> Actually, the authorization server encrypts the access token using JWE and the client uses MAC.
> So, using JWT + MAC is actually not possible since the security mechanisms are used by different entities: the MAC is used by the client and the access token protection is accomplished by the authorization server.
>
Sorry, I got confused earlier :-)
thanks, Sergey

>> in cases when people are really comfortable with doing JWT. I guess we may be talking now about better security characteristics, but this will help a very limited audience as compared to a wider one which can use Bearer+MAC over 2-way TLS, straightforward, very cheap effort to get started.
>>
>
> Ciao
> Hannes
>
>> just my 2c
>> Thanks, Sergey
>>
>>> I would like to point out that this is **discussion input** -- not agreed content. Anything in the document is subject to change!
>>> You also may notice that there are a few questions in the writeup.
>>>
>>> I was trying to more specific about some of the design aspects that folks had proposed during the last few months.
>>> I have also re-submitted the draft-tschofenig-oauth-hotk, which includes a TLS and a JSON-based solution approach.
>>>
>>> In general, the open questions still seem to be related to
>>> * Key distribution: What should be described in a document? What is mandatory to implement?
>>> * Selective header field protection: This is something that was brought forward in discussions and I have included a proposal of how this could look like.
>>> * Channel Binding: Functionality is also included to deal with man-in-the-middle attacks against TLS. There are, however, two types of channel bindings defined in RFC 5929. Are both needed? If not, which one should be selected?
>>> * Integrity protection and data origin authentication in both directions: The current writeup allows the protection to be extended to messages beyond the initial request. This also offers key confirmation by the server and protection of any responses.
>>>
>>> Writing the text I also noticed that I do not quite understand how nested JWT documents are supposed to look like. For example, how do I encrypt the mac_key carried inside the JWT plus add a signature of all other fields? Currently, I have just encrypted the entire payload.
>>>
>>> I hope to have some discussions prior to the IETF meeting so that we have a more fruitful discussion at the face-to-face meeting.
>>>
>>> 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
>

From sberyozkin@gmail.com  Thu Feb 28 09:04:35 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 456F521F8835 for ; Thu, 28 Feb 2013 09:04:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.549
X-Spam-Level: 
X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5Aay08QQHuR for ; Thu, 28 Feb 2013 09:04:34 -0800 (PST)
Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF4921F8860 for ; Thu, 28 Feb 2013 09:04:33 -0800 (PST)
Received: by mail-ee0-f52.google.com with SMTP id b15so1651865eek.39 for ; Thu, 28 Feb 2013 09:04:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=rF+Y62vNF+e9NT29OoWBC+OB35Dp3T3/SbbOuVqHlUQ=; b=RSvaHYGsfTeYmBSXcGwmj6APu7U81HdPqIXWkNOLQ6+JW5liBLlG00WeeRTnTrSkzq xoZ/XCgBwaaZEtfROlhbZWDMSjXuz0tB1QgOVCFE4K4vCatttdgK1hmvTS+WNUH4+vAN Ehc9Kmz1lZQSd44tunax0sYpEruQlC15ZG7OpgxOjW214oF0K24qANJHVqErbM/eMVRb +3sPzBYX3mmNWNO3wUcMUhuYN3EiPQWDCd/8qsjAvuTAjP5sBmFNlr5TKbNfCBnMNdOl PFZPvZ6gDN1wOyVs+UrXMJertDnVFGUOyK3p+7LjWr7tFI6P4SC6fCkO39G18K2cF8vH pmyg==
X-Received: by 10.14.0.73 with SMTP id 49mr18713173eea.21.1362071071874; Thu, 28 Feb 2013 09:04:31 -0800 (PST)
Received: from [192.168.2.5] ([79.97.76.201]) by mx.google.com with ESMTPS id t4sm12828045eel.0.2013.02.28.09.04.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Feb 2013 09:04:31 -0800 (PST)
Message-ID: <512F8E1D.2060408@gmail.com>
Date: Thu, 28 Feb 2013 17:04:29 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: oauth@ietf.org
References: <20130225124642.7425.65145.idtracker@ietfa.amsl.com> <1361956373.9883.YahooMailNeo@web31807.mail.mud.yahoo.com> <21030204-8EA7-4FB0-9DD3-2B6C8CA57E02@gmx.net> <1362057295.36069.YahooMailNeo@web31809.mail.mud.yahoo.com>
In-Reply-To: <1362057295.36069.YahooMailNeo@web31809.mail.mud.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 17:04:35 -0000

Hi
On 28/02/13 13:14, William Mills wrote:
> I'm actually advocating that we change MAC to be a JWT extension.
IMHO, having a simpler option, plus, going forward, a possible JWT 
profile (client to RS path) would work better -

Why would JWT completely take over ? May be it should be possible indeed 
to have it as a JWT extension - should it be part of the relevant JWT 
assertion spec, where JWT is used as a possible grant ?

Thanks, Sergey
>
> ------------------------------------------------------------------------
> *From:* Hannes Tschofenig 
> *To:* William Mills 
> *Cc:* Hannes Tschofenig ; "oauth@ietf.org"
> 
> *Sent:* Thursday, February 28, 2013 2:28 AM
> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
>
> Hi Bill,
>
> I believe you are misreading the document. In
> draft-ietf-oauth-v2-http-mac the client still uses the MAC when it
> accesses a protected resource.
> The only place where the JWT comes into the picture is with the
> description of the access token. This matters from a key distribution
> point of view. The session key for the MAC is included in the encrypted
> JWT. The JWT is encrypted by the authorization server and decrypted by
> the resource server.
>
> Information about how header fields get included in the MAC is described
> in Section 5.
>
> The nonce isn't killed it is just called differently: seq-nr. The stuff
> in the original MAC specification actually wasn't a nonce (from the
> semantic point of view).
> The extension parameter is there implicitly by allowing additional
> header fields to be included in the MAC computation.
>
> I need to look at the port number field again.
>
> Ciao
> Hannes
>
> On Feb 27, 2013, at 11:12 AM, William Mills wrote:
>
>  > Just read the draft quickly.
>  >
>  > Since we're now leaning on JWT do we need to include the token in
> this? Why not just make an additional "Envelope MAC" thing and have the
> signature include the 3 JWT parts in the signature base string? That
> object then just becomes a JSON container for the kid, timestamp,
> signature method, signature etc. That thing then is a 4th base64 encoded
> JSON thing in the auth header.
>  >
>  > How header fields get included in the signature needs definition.
>  >
>  > Why did you kill the port number, nonce, and extension parameter out
> of the signature base string?
>  >
>  > The BNF appears to have no separators between values.
>  >
>  > -bill
>  >
>  >
>  > From: "internet-drafts@ietf.org "
> >
>  > To: i-d-announce@ietf.org 
>  > Cc: oauth@ietf.org 
>  > Sent: Monday, February 25, 2013 4:46 AM
>  > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
>  >
>  >
>  > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>  > This draft is a work item of the Web Authorization Protocol Working
> Group of the IETF.
>  >
>  > Title : OAuth 2.0 Message Authentication Code (MAC) Tokens
>  > Author(s) : Justin Richer
>  > William Mills
>  > Hannes Tschofenig
>  > Filename : draft-ietf-oauth-v2-http-mac-03.txt
>  > Pages : 26
>  > Date : 2013-02-25
>  >
>  > Abstract:
>  > This specification describes how to use MAC Tokens in HTTP requests
>  > to access OAuth 2.0 protected resources. An OAuth client willing to
>  > access a protected resource needs to demonstrate possession of a
>  > crytographic key by using it with a keyed message digest function to
>  > the request.
>  >
>  > The document also defines a key distribution protocol for obtaining a
>  > fresh session key.
>  >
>  >
>  > The IETF datatracker status page for this draft is:
>  > https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac
>  >
>  > There's also a htmlized version available at:
>  > http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03
>  >
>  > A diff from the previous version is available at:
>  > http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-http-mac-03
>  >
>  >
>  > Internet-Drafts are also available by anonymous FTP at:
>  > ftp://ftp.ietf.org/internet-drafts/
>  >
>  > _______________________________________________
>  > 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

From ve7jtb@ve7jtb.com  Thu Feb 28 09:07:56 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB5E721F8C48 for ; Thu, 28 Feb 2013 09:07:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NSkeetHxg2J for ; Thu, 28 Feb 2013 09:07:56 -0800 (PST)
Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by ietfa.amsl.com (Postfix) with ESMTP id 062D521F8C5B for ; Thu, 28 Feb 2013 09:07:54 -0800 (PST)
Received: by mail-pa0-f42.google.com with SMTP id kq12so1251704pab.29 for ; Thu, 28 Feb 2013 09:07:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=NYx77//WswqgXiyuOR/RgrZr1Kw83Fg+utw/ltLBswA=; b=d2131yvzjb6AqYSExo31NcJCbXB6c2tmIlIzJhGMnlCR4P1Gy2MJwhsM/ct5XSERye sWLqiGHD93WEt+hdDhMH1n9tTRjt2mDmzcA8WAunZU4KRPUMdqKXp5JAEXPPwvkrxaWj bVw/mXJ81ebr/2gTeozXSZA39MSWif4/MTidC1d99UnqrEgOZzxXr7A0ZJKRuwu1TXXK 0yRF/gZ9Aq1GcVkneu/u01cvJ5P3t4e5qtNfKkYc7HW8+9KWNU6BBQyWyHmESE7f6AUh wrY2nFo23psS0Zo8mRAiDbXxpBFsiQybgMlvLuX7IveD7+DBH4yNdxN8UOz39oOSVPer lrAQ==
X-Received: by 10.68.224.225 with SMTP id rf1mr10286789pbc.9.1362071274761; Thu, 28 Feb 2013 09:07:54 -0800 (PST)
Received: from [192.168.41.99] (ip-64-134-220-138.public.wayport.net. [64.134.220.138]) by mx.google.com with ESMTPS id z6sm9858434pav.3.2013.02.28.09.07.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Feb 2013 09:07:51 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_01BF8427-BDE4-40FE-A5E2-3162C25A4184"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: 
Date: Thu, 28 Feb 2013 09:07:48 -0800
Message-Id: 
References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net>  
To: Phil Hunt 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQkLIzKlLVnNb9rAvzIM7+GsfI1TJRXV7Sws9m+8vHPLLKrIK+jTWEqhY0KVBA8B6kA70d3O
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] JWT - scope claim missing
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 17:07:56 -0000

--Apple-Mail=_01BF8427-BDE4-40FE-A5E2-3162C25A4184
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I am not advocating anything, only sting what people are doing now.

How authorization is communicated between the AS and RS via a token that =
is opaque to the client is out of scope fro OAuth core, it might be =
magic pixy dust.

This has lead to a number of ways people are doing it.

JWT along with  JOSE provide a container to get some claims from the AS =
to the RS though the JWT is not specific to this and is used in the =
assertions profile and other specs for many things other than access =
tokens.

Yes a profile of JWT for an access token as an access token is needed, =
Yes further profiling is required for a JWT access token using MAC.

The format of the authorization claims is not tightly bound to MAC and =
might be used with other bearer JWT tokens.

I don't know that there will be only one way to communicate those claims =
because different sorts of implementations need different information =
for the RS to act on.
Recommendations are fine but defining a field called scope and passing =
on exactly the scopes the client was granted is not going to work for =
everyone for lots of good reasons.

John B.
On 2013-02-28, at 8:24 AM, Phil Hunt  wrote:

> Are you advocating TWO systems? That seems like a bad choice.=20
>=20
> I would rather fix scope than go to a two system approach.
>=20
> Phil
>=20
> Sent from my phone.
>=20
> On 2013-02-28, at 8:17, John Bradley  wrote:
>=20
>> While scope is one method that a AS could communicate authorization =
to a RS, it is not the only or perhaps even the most likely one.
>> Using scope requires a relatively tight binding between the RS and =
AS,  UMA uses a different mechanism that describes finer grained =
operations. =20
>> The AS may include roles, user, or other more abstract claims that =
the the client may (god help them) pass on to EXCML for processing.
>>=20
>> While having a scopes claim is possible, like any other claim it is =
not part of the JWT core security processing claims, and needs to be =
defined by extension.
>>=20
>> John B.
>> On 2013-02-28, at 2:29 AM, Hannes Tschofenig =
 wrote:
>>=20
>>> Hi Mike,=20
>>>=20
>>> when I worked on the MAC specification I noticed that the JWT does =
not have a claim for the scope. I believe that this would be needed to =
allow the resource server to verify whether the scope the authorization =
server authorized is indeed what the client is asking for.=20
>>>=20
>>> Ciao
>>> Hannes
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail=_01BF8427-BDE4-40FE-A5E2-3162C25A4184
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMjI4MTcwNzQ5WjAjBgkqhkiG9w0BCQQxFgQU0nfiQ3YA
tlJqT/9OUh16ZarQyr8wgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEADpo9/zchEm0ba7SYJp6XXwd1BseSaeuBIAxoLRRQ
DO68q0sl0oeinP0lFxlVhVsPUtzbJ0OcPmSER5QU9fNZiLrh/BlSAKi5VPvx/FzjTyp6FI2EfZ/O
vqwc4pMccevYVAKzeFunxDvbVADZf1XsN/P2C2QLVZSMFBMbLaYq1hV2YAec4ZAxPXeVGlxmKg9L
mXpTmOQW2X4faTJwqRxBxJw2UfxqGlpXKBFmGHLizA/rNm7Mnu0oEAhfS8sZVZ0GREta3L9ZZVW6
S9B9TSljYbrid1lrHqoVUcXcFukLH9kE8ro+zyiXgZIpr7ox90gOG5HXRtiC1F8iBoqrNWv9lQAA
AAAAAA==

--Apple-Mail=_01BF8427-BDE4-40FE-A5E2-3162C25A4184--

From jricher@mitre.org  Thu Feb 28 09:09:49 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E849C21F85D8 for ; Thu, 28 Feb 2013 09:09:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.577
X-Spam-Level: 
X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.021,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTvYP4nH1p5Z for ; Thu, 28 Feb 2013 09:09:49 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id B3ECA21F856F for ; Thu, 28 Feb 2013 09:09:48 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 582675311DBF; Thu, 28 Feb 2013 12:09:48 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 3C4F95311DBC; Thu, 28 Feb 2013 12:09:48 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 28 Feb 2013 12:09:47 -0500
Message-ID: <512F8F1E.3020400@mitre.org>
Date: Thu, 28 Feb 2013 12:08:46 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: William Mills 
References: <20130225124642.7425.65145.idtracker@ietfa.amsl.com> <1361956373.9883.YahooMailNeo@web31807.mail.mud.yahoo.com> <21030204-8EA7-4FB0-9DD3-2B6C8CA57E02@gmx.net> <1362057295.36069.YahooMailNeo@web31809.mail.mud.yahoo.com>
In-Reply-To: <1362057295.36069.YahooMailNeo@web31809.mail.mud.yahoo.com>
Content-Type: multipart/alternative; boundary="------------050206090801030609090305"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 17:09:50 -0000

--------------050206090801030609090305
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

What I don't quite get is what exactly would be presented and processed 
at each step. Who needs to know what piece? We don't want to have to 
push everything into JSON for the signing to take place (that much is 
clear), and we don't want the client to be pushing the MAC secret to the 
RS every time (that would make it a lot less secret, after all). But if 
we can reuse JWT, JWS, and other JOSE mechanisms to make some parts of 
the MAC pattern easier for programmers, I'm for it.

  -- Justin

On 02/28/2013 08:14 AM, William Mills wrote:
> I'm actually advocating that we change MAC to be a JWT extension.
>
> ------------------------------------------------------------------------
> *From:* Hannes Tschofenig 
> *To:* William Mills 
> *Cc:* Hannes Tschofenig ; "oauth@ietf.org" 
> 
> *Sent:* Thursday, February 28, 2013 2:28 AM
> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
>
> Hi Bill,
>
> I believe you are misreading the document. In 
> draft-ietf-oauth-v2-http-mac the client still uses the MAC when it 
> accesses a protected resource.
> The only place where the JWT comes into the picture is with the 
> description of the access token. This matters from a key distribution 
> point of view. The session key for the MAC is included in the 
> encrypted JWT. The JWT is encrypted by the authorization server and 
> decrypted by the resource server.
>
> Information about how header fields get included in the MAC is 
> described in Section 5.
>
> The nonce isn't killed it is just called differently: seq-nr. The 
> stuff in the original MAC specification actually wasn't a nonce (from 
> the semantic point of view).
> The extension parameter is there implicitly by allowing additional 
> header fields to be included in the MAC computation.
>
> I need to look at the port number field again.
>
> Ciao
> Hannes
>
> On Feb 27, 2013, at 11:12 AM, William Mills wrote:
>
> > Just read the draft quickly.
> >
> > Since we're now leaning on JWT do we need to include the token in 
> this?  Why not just make an additional "Envelope MAC" thing and have 
> the signature include the 3 JWT parts in the signature base string?  
> That object then just becomes a JSON container for the kid, timestamp, 
> signature method, signature etc. That thing then is a 4th base64 
> encoded JSON thing in the auth header.
> >
> > How header fields get included in the signature needs definition.
> >
> > Why did you kill the port number, nonce, and extension parameter out 
> of the signature base string?
> >
> > The BNF appears to have no separators between values.
> >
> > -bill
> >
> >
> > From: "internet-drafts@ietf.org " 
> >
> > To: i-d-announce@ietf.org 
> > Cc: oauth@ietf.org 
> > Sent: Monday, February 25, 2013 4:46 AM
> > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> > This draft is a work item of the Web Authorization Protocol Working 
> Group of the IETF.
> >
> >    Title          : OAuth 2.0 Message Authentication Code (MAC) Tokens
> >    Author(s)      : Justin Richer
> >                          William Mills
> >                          Hannes Tschofenig
> >    Filename        : draft-ietf-oauth-v2-http-mac-03.txt
> >    Pages          : 26
> >    Date            : 2013-02-25
> >
> > Abstract:
> >  This specification describes how to use MAC Tokens in HTTP requests
> >  to access OAuth 2.0 protected resources.  An OAuth client willing to
> >  access a protected resource needs to demonstrate possession of a
> >  crytographic key by using it with a keyed message digest function to
> >  the request.
> >
> >  The document also defines a key distribution protocol for obtaining a
> >  fresh session key.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-http-mac-03
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > 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

--------------050206090801030609090305
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

    What I don't quite get is what exactly would be presented and
    processed at each step. Who needs to know what piece? We don't want
    to have to push everything into JSON for the signing to take place
    (that much is clear), and we don't want the client to be pushing the
    MAC secret to the RS every time (that would make it a lot less
    secret, after all). But if we can reuse JWT, JWS, and other JOSE
    mechanisms to make some parts of the MAC pattern easier for
    programmers, I'm for it.

     -- Justin

    On 02/28/2013 08:14 AM, William Mills
      wrote:

        I'm actually advocating that we change MAC to be a
            JWT extension.

 From:
                Hannes Tschofenig <hannes.tschofenig@gmx.net>

                To:
                William Mills <wmills_92105@yahoo.com> 

                Cc:
                Hannes Tschofenig <hannes.tschofenig@gmx.net>;
                "oauth@ietf.org" <oauth@ietf.org> 

                Sent:
                Thursday, February 28, 2013 2:28 AM

                Subject:
                Re: [OAUTH-WG] I-D Action:
                draft-ietf-oauth-v2-http-mac-03.txt

            Hi Bill, 

            I believe you are misreading the document. In
            draft-ietf-oauth-v2-http-mac the client still uses the MAC
            when it accesses a protected resource. 

            The only place where the JWT comes into the picture is with
            the description of the access token. This matters from a key
            distribution point of view. The session key for the MAC is
            included in the encrypted JWT. The JWT is encrypted by the
            authorization server and decrypted by the resource server. 

            Information about how header fields get included in the MAC
            is described in Section 5.

            The nonce isn't killed it is just called differently:
            seq-nr. The stuff in the original MAC specification actually
            wasn't a nonce (from the semantic point of view). 

            The extension parameter is there implicitly by allowing
            additional header fields to be included in the MAC
            computation.

            I need to look at the port number field again. 

            Ciao

            Hannes

            On Feb 27, 2013, at 11:12 AM, William Mills wrote:

            > Just read the draft quickly.  

            > 

            > Since we're now leaning on JWT do we need to include
            the token in this?  Why not just make an additional
            "Envelope MAC" thing and have the signature include the 3
            JWT parts in the signature base string?  That object then
            just becomes a JSON container for the kid, timestamp,
            signature method, signature etc. That thing then is a 4th
            base64 encoded JSON thing in the auth header.

            > 

            > How header fields get included in the signature needs
            definition.

            > 

            > Why did you kill the port number, nonce, and extension
            parameter out of the signature base string?

            > 

            > The BNF appears to have no separators between values.

            > 

            > -bill

            > 

            > 

            > From: "internet-drafts@ietf.org"
            <internet-drafts@ietf.org>

            > To: i-d-announce@ietf.org

            > Cc: oauth@ietf.org 

            > Sent: Monday, February 25, 2013 4:46 AM

            > Subject: [OAUTH-WG] I-D Action:
            draft-ietf-oauth-v2-http-mac-03.txt

            > 

            > 

            > A New Internet-Draft is available from the on-line
            Internet-Drafts directories.

            > This draft is a work item of the Web Authorization
            Protocol Working Group of the IETF.

            > 

            >    Title          : OAuth 2.0 Message Authentication
            Code (MAC) Tokens

            >    Author(s)      : Justin Richer

            >                          William Mills

            >                          Hannes Tschofenig

            >    Filename        :
            draft-ietf-oauth-v2-http-mac-03.txt

            >    Pages          : 26

            >    Date            : 2013-02-25

            > 

            > Abstract:

            >  This specification describes how to use MAC Tokens in
            HTTP requests

            >  to access OAuth 2.0 protected resources.  An OAuth
            client willing to

            >  access a protected resource needs to demonstrate
            possession of a

            >  crytographic key by using it with a keyed message
            digest function to

            >  the request.

            > 

            >  The document also defines a key distribution protocol
            for obtaining a

            >  fresh session key.

            > 

            > 

            > The IETF datatracker status page for this draft is:

            > https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac

            > 

            > There's also a htmlized version available at:

            >
            http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03

            > 

            > A diff from the previous version is available at:

            >
            http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-http-mac-03

            > 

            > 

            > Internet-Drafts are also available by anonymous FTP at:

            > ftp://ftp.ietf.org/internet-drafts/

            > 

            > _______________________________________________

            > 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

--------------050206090801030609090305--

From ve7jtb@ve7jtb.com  Thu Feb 28 09:23:27 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE8821F8B04 for ; Thu, 28 Feb 2013 09:23:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.371
X-Spam-Level: 
X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=-1.227, BAYES_00=-2.599, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyKrIXeBeRVy for ; Thu, 28 Feb 2013 09:23:25 -0800 (PST)
Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by ietfa.amsl.com (Postfix) with ESMTP id 88B4A21F8AC3 for ; Thu, 28 Feb 2013 09:23:25 -0800 (PST)
Received: by mail-pb0-f53.google.com with SMTP id un1so1193756pbc.12 for ; Thu, 28 Feb 2013 09:23:25 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=Ao98uxVG8wm/54d16hqL4gwqsND8SRze0C0ReJ9B/6k=; b=V5mefsLY6mScswsBN6gVNaYvYBnIpM8HWi6ovhFNIo60vGOzjQyzDSawG1eVhY8fpG SHgO7KoiYikxhwR2TYIQ6QBO22Y6L94oMSs1LAg8yO2+HNGjvWig2lBgkjLy/5vtHzR2 R6/+he8jdFhPwkxBCWnQPkuoZQHin7aFdAoBeC77Zsz4DR2v9ehyvRtrEsr1x+pIoA2M WaOTma/hqpHN0F9jzMv+24ns7U7vROmyrBt0nzXS430YEpc+ZVrCrMppwwCxKdZbfomu cczq08c4TzM4ysP76XaI7rAgzqrjY5M6viBlhllopSU7mVzed3WwNoG9XXlOHY+OXMg9 Qhag==
X-Received: by 10.66.158.230 with SMTP id wx6mr14166997pab.147.1362072205243;  Thu, 28 Feb 2013 09:23:25 -0800 (PST)
Received: from [192.168.41.99] (ip-64-134-220-138.public.wayport.net. [64.134.220.138]) by mx.google.com with ESMTPS id pn9sm8976855pbb.22.2013.02.28.09.23.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Feb 2013 09:23:23 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_DB38E877-9011-49F7-A88E-0C87BCC6708B"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <98272BAD-131B-4151-BBB8-0937E8D6781A@adobe.com>
Date: Thu, 28 Feb 2013 09:23:20 -0800
Message-Id: <0F47E4EE-7482-45C9-B0C4-D8B0A21E63AF@ve7jtb.com>
References: <20130225124642.7425.65145.idtracker@ietfa.amsl.com> <1361956373.9883.YahooMailNeo@web31807.mail.mud.yahoo.com> <21030204-8EA7-4FB0-9DD3-2B6C8CA57E02@gmx.net> <98272BAD-131B-4151-BBB8-0937E8D6781A@adobe.com>
To: Antonio Sanso 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQltgOXCsg+pNUnwZhcWxUFyxV5IDwWxnXxK/XtehWH4aj4RLsaLMjv2SfDIOaTzdheIUdRh
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 17:23:27 -0000

--Apple-Mail=_DB38E877-9011-49F7-A88E-0C87BCC6708B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

The communication between AS and RS is not direct it is through the =
client in this case.   If TLS covers all the connections and is =
sufficient you probably don't need MAC:)

If you were to send the symmetric key in the JWT unencrypted than there =
is no real point in signing anything as any one intercepting the request =
can just sign a new one.

For symmetric keys being distributed through the access token the key =
needs to be encrypted to the intended RS to provide value.

John B.

On 2013-02-28, at 2:37 AM, Antonio Sanso  wrote:

> Hi Hannes,
>=20
> apologies if I do the same question again but there is still one point =
that is a little obscure to me.
>=20
> As long I did understand the situation for MAC is the following one.
>=20
> The communication between the client and the authentication server =
must be https but this is not true for the communication between =
authentication server and resource server.
> Hence the need of this key exchange.
>=20
> Is it correct? Should be the case why we do not have the same problem =
in the JWT Bearer case? Is because in that case https is as well =
mandatory between authentication server and resource server?
>=20
> Thanks a lot and regards
>=20
> Antonio
>=20
>=20
> On Feb 28, 2013, at 11:28 AM, Hannes Tschofenig wrote:
>=20
>> Hi Bill,=20
>>=20
>> I believe you are misreading the document. In =
draft-ietf-oauth-v2-http-mac the client still uses the MAC when it =
accesses a protected resource.=20
>> The only place where the JWT comes into the picture is with the =
description of the access token. This matters from a key distribution =
point of view. The session key for the MAC is included in the encrypted =
JWT. The JWT is encrypted by the authorization server and decrypted by =
the resource server.=20
>>=20
>> Information about how header fields get included in the MAC is =
described in Section 5.
>>=20
>> The nonce isn't killed it is just called differently: seq-nr. The =
stuff in the original MAC specification actually wasn't a nonce (from =
the semantic point of view).=20
>> The extension parameter is there implicitly by allowing additional =
header fields to be included in the MAC computation.
>>=20
>> I need to look at the port number field again.=20
>>=20
>> Ciao
>> Hannes
>>=20
>> On Feb 27, 2013, at 11:12 AM, William Mills wrote:
>>=20
>>> Just read the draft quickly. =20
>>>=20
>>> Since we're now leaning on JWT do we need to include the token in =
this?  Why not just make an additional "Envelope MAC" thing and have the =
signature include the 3 JWT parts in the signature base string?  That =
object then just becomes a JSON container for the kid, timestamp, =
signature method, signature etc. That thing then is a 4th base64 encoded =
JSON thing in the auth header.
>>>=20
>>> How header fields get included in the signature needs definition.
>>>=20
>>> Why did you kill the port number, nonce, and extension parameter out =
of the signature base string?
>>>=20
>>> The BNF appears to have no separators between values.
>>>=20
>>> -bill
>>>=20
>>>=20
>>> From: "internet-drafts@ietf.org" 
>>> To: i-d-announce@ietf.org=20
>>> Cc: oauth@ietf.org=20
>>> Sent: Monday, February 25, 2013 4:46 AM
>>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
>>>=20
>>>=20
>>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>>> This draft is a work item of the Web Authorization Protocol Working =
Group of the IETF.
>>>=20
>>>   Title          : OAuth 2.0 Message Authentication Code (MAC) =
Tokens
>>>   Author(s)      : Justin Richer
>>>                         William Mills
>>>                         Hannes Tschofenig
>>>   Filename        : draft-ietf-oauth-v2-http-mac-03.txt
>>>   Pages          : 26
>>>   Date            : 2013-02-25
>>>=20
>>> Abstract:
>>> This specification describes how to use MAC Tokens in HTTP requests
>>> to access OAuth 2.0 protected resources.  An OAuth client willing to
>>> access a protected resource needs to demonstrate possession of a
>>> crytographic key by using it with a keyed message digest function to
>>> the request.
>>>=20
>>> The document also defines a key distribution protocol for obtaining =
a
>>> fresh session key.
>>>=20
>>>=20
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac
>>>=20
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03
>>>=20
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-v2-http-mac-03
>>>=20
>>>=20
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail=_DB38E877-9011-49F7-A88E-0C87BCC6708B
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMjI4MTcyMzIxWjAjBgkqhkiG9w0BCQQxFgQUk331baHg
bDV9Kba8K03WL/f6o9MwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAfKJFcfjqCQUO1sWbjQZocKZxojYXJaG4lJKcBsd3
QOM37BN2ycIYiJNYTQ0/ZMYhVatFQYFilbHXlmcg5dihd2TM+HUti5z4gu6XG5S4X+4dN0oLOqqw
MqP5wUYZioqy1nsOOORYtUzXdbbK1BYTCpaHkcI04mK3ggzWYoShFo7JA2CvM1zSQNv8vef9kVV2
TIr5Ta3zHSegYT/vnJTawa1nZPb87G19l99zejCyR0mjaPb7iNJjhe3yAF1MvKj5G2/Yl7UvwBiB
edyHo06jguwNJ6zuLgcdEHhVSaCMbL28XisSserhmB+KAWOHR2G8q8/2ocVT1uZKw5P52WM53QAA
AAAAAA==

--Apple-Mail=_DB38E877-9011-49F7-A88E-0C87BCC6708B--

From phil.hunt@oracle.com  Thu Feb 28 09:27:32 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9526921F89C0 for ; Thu, 28 Feb 2013 09:27:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.202
X-Spam-Level: 
X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5S7iV+UWhKt for ; Thu, 28 Feb 2013 09:27:31 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9513721F88CF for ; Thu, 28 Feb 2013 09:27:31 -0800 (PST)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1SHRUhN015008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Feb 2013 17:27:30 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1SHRT4N024940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2013 17:27:29 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1SHRT4W020042; Thu, 28 Feb 2013 11:27:29 -0600
Received: from [25.73.5.188] (/74.198.150.188) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 28 Feb 2013 09:27:29 -0800
References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net>   
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: multipart/alternative; boundary=Apple-Mail-691D97B1-1920-4E15-898E-694D86016413
Content-Transfer-Encoding: 7bit
Message-Id: <39016EC6-D3E3-4812-9825-B1C95A5D9AED@oracle.com>
X-Mailer: iPhone Mail (10B146)
From: Phil Hunt 
Date: Thu, 28 Feb 2013 09:27:22 -0800
To: Brian Campbell 
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] JWT - scope claim missing
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 17:27:32 -0000

--Apple-Mail-691D97B1-1920-4E15-898E-694D86016413
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Am I missing something. JWT is firstly an oauth spec. Otherwise why isnt it i=
n jose wg?

Phil

Sent from my phone.

On 2013-02-28, at 8:44, Brian Campbell  wrote:

> I think John's point was more that scope is something rather specific to a=
n OAuth access token and, while JWT is can be used to represent an access to=
ken, it's not the only application of JWT. The 'standard' claims in JWT are t=
hose that are believed (right or wrong) to be widely applicable across diffe=
rent applications of JWT. One could argue about it but scope is probably not=
 one of those.
>=20
> It would probably make sense to try and build a profile of JWT specificall=
y for OAuth access tokens (though I suspect there are some turtles and drago=
ns in there), which might be the appropriate place to define/register a scop=
e claim.
>=20
>=20
> On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt  wrote:
>> Are you advocating TWO systems? That seems like a bad choice.
>>=20
>> I would rather fix scope than go to a two system approach.
>>=20
>> Phil
>>=20
>> Sent from my phone.
>>=20
>> On 2013-02-28, at 8:17, John Bradley  wrote:
>>=20
>> > While scope is one method that a AS could communicate authorization to a=
 RS, it is not the only or perhaps even the most likely one.
>> > Using scope requires a relatively tight binding between the RS and AS, =
 UMA uses a different mechanism that describes finer grained operations.
>> > The AS may include roles, user, or other more abstract claims that the t=
he client may (god help them) pass on to EXCML for processing.
>> >
>> > While having a scopes claim is possible, like any other claim it is not=
 part of the JWT core security processing claims, and needs to be defined by=
 extension.
>> >
>> > John B.
>> > On 2013-02-28, at 2:29 AM, Hannes Tschofenig  wrote:
>> >
>> >> Hi Mike,
>> >>
>> >> when I worked on the MAC specification I noticed that the JWT does not=
 have a claim for the scope. I believe that this would be needed to allow th=
e resource server to verify whether the scope the authorization server autho=
rized is indeed what the client is asking for.
>> >>
>> >> 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
>=20

--Apple-Mail-691D97B1-1920-4E15-898E-694D86016413
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit

Am I missing something. JWT is firstly an oauth spec. Otherwise why isnt it in jose wg?

Phil
Sent from my phone.

On 2013-02-28, at 8:44, Brian Campbell <bcampbell@pingidentity.com> wrote:

I think John's point was more that scope is something rather specific to an OAuth access token and, while JWT is can be used to represent an access token, it's not the only application of JWT. The 'standard' claims in JWT are those that are believed (right or wrong) to be widely applicable across different applications of JWT. One could argue about it but scope is probably not one of those.

It would probably make sense to try and build a profile of JWT specifically for OAuth access tokens (though I suspect there are some turtles and dragons in there), which might be the appropriate place to define/register a scope claim.

On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

Are you advocating TWO systems? That seems like a bad choice.

I would rather fix scope than go to a two system approach.

Phil

Sent from my phone.

On 2013-02-28, at 8:17, John Bradley <ve7jtb@ve7jtb.com> wrote:

> While scope is one method that a AS could communicate authorization to a RS, it is not the only or perhaps even the most likely one.

> Using scope requires a relatively tight binding between the RS and AS,  UMA uses a different mechanism that describes finer grained operations.

> The AS may include roles, user, or other more abstract claims that the the client may (god help them) pass on to EXCML for processing.

>

> While having a scopes claim is possible, like any other claim it is not part of the JWT core security processing claims, and needs to be defined by extension.

>

> John B.

> On 2013-02-28, at 2:29 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

>

>> Hi Mike,

>>

>> when I worked on the MAC specification I noticed that the JWT does not have a claim for the scope. I believe that this would be needed to allow the resource server to verify whether the scope the authorization server authorized is indeed what the client is asking for.

>>

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

--Apple-Mail-691D97B1-1920-4E15-898E-694D86016413--

From phil.hunt@oracle.com  Thu Feb 28 09:28:14 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4086721F8BA1 for ; Thu, 28 Feb 2013 09:28:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.202
X-Spam-Level: 
X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdoQvowscl1N for ; Thu, 28 Feb 2013 09:28:13 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1472721F8B8F for ; Thu, 28 Feb 2013 09:28:09 -0800 (PST)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1SHS8JV015825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Feb 2013 17:28:08 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1SHS7Rt026160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2013 17:28:07 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1SHS7Rl006303; Thu, 28 Feb 2013 11:28:07 -0600
Received: from [25.73.5.188] (/74.198.150.188) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 28 Feb 2013 09:28:07 -0800
References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net>    
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: multipart/alternative; boundary=Apple-Mail-E01B3F4E-4353-4E42-8BE5-FEAB776E1BA2
Content-Transfer-Encoding: 7bit
Message-Id: <48FD87D1-4DF4-4289-99B7-40A515F31890@oracle.com>
X-Mailer: iPhone Mail (10B146)
From: Phil Hunt 
Date: Thu, 28 Feb 2013 09:28:03 -0800
To: John Bradley 
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] JWT - scope claim missing
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 17:28:14 -0000

--Apple-Mail-E01B3F4E-4353-4E42-8BE5-FEAB776E1BA2
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Are you saying jwt is not an access token type?

Phil

Sent from my phone.

On 2013-02-28, at 8:58, John Bradley  wrote:

> Yes, defining scope in JWT is the wrong place.   JWT needs to stick to the=
 security claims needed to process JWT.
>=20
> I also don't know how far you get requiring a specific authorization forma=
t for JWT, some AS will wan to use a opaque reference, some might want to us=
e a user claim or role claim, others may use scopes,  combining scopes and c=
laims is also possible.
>=20
> Right now it is up to a AS RS pair to agree on how to communicate authoriz=
ation.   I don't want MAC to be more restrictive than bearer when it comes t=
o authorization between AS and RS.
>=20
> Hannes wanted to know why JWT didn't define scope.  The simple answer is t=
hat it is out of scope for JWT itself.   It might be defined in a OAuth acce=
ss token profile for JWT but it should not be specific to MAC.
>=20
> John B.
> On 2013-02-28, at 8:44 AM, Brian Campbell  wro=
te:
>=20
>> I think John's point was more that scope is something rather specific to a=
n OAuth access token and, while JWT is can be used to represent an access to=
ken, it's not the only application of JWT. The 'standard' claims in JWT are t=
hose that are believed (right or wrong) to be widely applicable across diffe=
rent applications of JWT. One could argue about it but scope is probably not=
 one of those.
>>=20
>> It would probably make sense to try and build a profile of JWT specifical=
ly for OAuth access tokens (though I suspect there are some turtles and drag=
ons in there), which might be the appropriate place to define/register a sco=
pe claim.
>>=20
>>=20
>> On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt  wrote:
>>> Are you advocating TWO systems? That seems like a bad choice.
>>>=20
>>> I would rather fix scope than go to a two system approach.
>>>=20
>>> Phil
>>>=20
>>> Sent from my phone.
>>>=20
>>> On 2013-02-28, at 8:17, John Bradley  wrote:
>>>=20
>>> > While scope is one method that a AS could communicate authorization to=
 a RS, it is not the only or perhaps even the most likely one.
>>> > Using scope requires a relatively tight binding between the RS and AS,=
  UMA uses a different mechanism that describes finer grained operations.
>>> > The AS may include roles, user, or other more abstract claims that the=
 the client may (god help them) pass on to EXCML for processing.
>>> >
>>> > While having a scopes claim is possible, like any other claim it is no=
t part of the JWT core security processing claims, and needs to be defined b=
y extension.
>>> >
>>> > John B.
>>> > On 2013-02-28, at 2:29 AM, Hannes Tschofenig  wrote:
>>> >
>>> >> Hi Mike,
>>> >>
>>> >> when I worked on the MAC specification I noticed that the JWT does no=
t have a claim for the scope. I believe that this would be needed to allow t=
he resource server to verify whether the scope the authorization server auth=
orized is indeed what the client is asking for.
>>> >>
>>> >> 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
>=20

--Apple-Mail-E01B3F4E-4353-4E42-8BE5-FEAB776E1BA2
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Are you saying jwt is not an access to=
ken type?

Phil
Sent from my phone.

On 2013-02-28, at 8:58, John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes, defining scope in JWT is the wrong place.   JWT needs to s=
tick to the security claims needed to process JWT.
I also=
 don't know how far you get requiring a specific authorization format for JW=
T, some AS will wan to use a opaque reference, some might want to use a user=
 claim or role claim, others may use scopes,  combining scopes and clai=
ms is also possible.

Right now it is up to a AS RS p=
air to agree on how to communicate authorization.   I don't want MAC to=
 be more restrictive than bearer when it comes to authorization between AS a=
nd RS.

Hannes wanted to know why JWT didn't define sc=
ope.  The simple answer is that it is out of scope for JWT itself. &nbs=
p; It might be defined in a OAuth access token profile for JWT but it should=
 not be specific to MAC.

John B.
On 2013-02-28, at 8:44 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

=
I think John's point was more that scope is something rather specific to an O=
Auth access token and, while JWT is can be used to represent an access token=
, it's not the only application of JWT. The 'standard' claims in JWT are tho=
se that are believed (right or wrong) to be widely applicable across differe=
nt applications of JWT. One could argue about it but scope is probably not o=
ne of those.

It would probably make sense to try and build a profile of JWT spe=
cifically for OAuth access tokens (though I suspect there are some turtles a=
nd dragons in there), which might be the appropriate place to define/registe=
r a scope claim.

On Thu, =
Feb 28, 2013 at 9:24 AM, Phil Hunt <phil.hunt@oracle.com> w=
rote:

Are you advocating TWO systems? That seems lik=
e a bad choice.

I would rather fix scope than go to a two system approach.

Phil

Sent from my phone.

On 2013-02-28, at 8:17, John Bradley <ve7jtb@ve7jtb.com> wrote:

> While scope is one method that a AS could communicate authorization to a=
 RS, it is not the only or perhaps even the most likely one.

> Using scope requires a relatively tight binding between the RS and AS, &=
nbsp;UMA uses a different mechanism that describes finer grained operations.=

> The AS may include roles, user, or other more abstract claims that the t=
he client may (god help them) pass on to EXCML for processing.

>

> While having a scopes claim is possible, like any other claim it is not=
 part of the JWT core security processing claims, and needs to be defined by=
 extension.

>

> John B.

> On 2013-02-28, at 2:29 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

>

>> Hi Mike,

>>

>> when I worked on the MAC specification I noticed that the JWT does n=
ot have a claim for the scope. I believe that this would be needed to allow t=
he resource server to verify whether the scope the authorization server auth=
orized is indeed what the client is asking for.

>>

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

ht=
tps://www.ietf.org/mailman/listinfo/oauth

=

--Apple-Mail-E01B3F4E-4353-4E42-8BE5-FEAB776E1BA2--

From phil.hunt@oracle.com  Thu Feb 28 09:29:57 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3DC21F868B for ; Thu, 28 Feb 2013 09:29:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.203
X-Spam-Level: 
X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSRQrxOjGAoa for ; Thu, 28 Feb 2013 09:29:57 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 42F4721F867A for ; Thu, 28 Feb 2013 09:29:57 -0800 (PST)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1SHTrfq007994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Feb 2013 17:29:54 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1SHTq4W029649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2013 17:29:53 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1SHTqAS004746; Thu, 28 Feb 2013 11:29:52 -0600
Received: from [25.73.5.188] (/74.198.150.188) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 28 Feb 2013 09:29:52 -0800
References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net>   
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <1BDBAFF3-6B2D-45EE-8A7E-B0B2572C8A01@oracle.com>
X-Mailer: iPhone Mail (10B146)
From: Phil Hunt 
Date: Thu, 28 Feb 2013 09:29:47 -0800
To: John Bradley 
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] JWT - scope claim missing
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 17:29:58 -0000

What people are doing now is often issuing saml like assertions. Thats not n=
ecessarily indicating intent. It just indicates transition.=20

Phil

Sent from my phone.

On 2013-02-28, at 9:07, John Bradley  wrote:

> I am not advocating anything, only sting what people are doing now.
>=20
> How authorization is communicated between the AS and RS via a token that i=
s opaque to the client is out of scope fro OAuth core, it might be magic pix=
y dust.
>=20
> This has lead to a number of ways people are doing it.
>=20
> JWT along with  JOSE provide a container to get some claims from the AS to=
 the RS though the JWT is not specific to this and is used in the assertions=
 profile and other specs for many things other than access tokens.
>=20
> Yes a profile of JWT for an access token as an access token is needed, Yes=
 further profiling is required for a JWT access token using MAC.
>=20
> The format of the authorization claims is not tightly bound to MAC and mig=
ht be used with other bearer JWT tokens.
>=20
> I don't know that there will be only one way to communicate those claims b=
ecause different sorts of implementations need different information for the=
 RS to act on.
> Recommendations are fine but defining a field called scope and passing on e=
xactly the scopes the client was granted is not going to work for everyone f=
or lots of good reasons.
>=20
> John B.
> On 2013-02-28, at 8:24 AM, Phil Hunt  wrote:
>=20
>> Are you advocating TWO systems? That seems like a bad choice.=20
>>=20
>> I would rather fix scope than go to a two system approach.
>>=20
>> Phil
>>=20
>> Sent from my phone.
>>=20
>> On 2013-02-28, at 8:17, John Bradley  wrote:
>>=20
>>> While scope is one method that a AS could communicate authorization to a=
 RS, it is not the only or perhaps even the most likely one.
>>> Using scope requires a relatively tight binding between the RS and AS,  U=
MA uses a different mechanism that describes finer grained operations. =20
>>> The AS may include roles, user, or other more abstract claims that the t=
he client may (god help them) pass on to EXCML for processing.
>>>=20
>>> While having a scopes claim is possible, like any other claim it is not p=
art of the JWT core security processing claims, and needs to be defined by e=
xtension.
>>>=20
>>> John B.
>>> On 2013-02-28, at 2:29 AM, Hannes Tschofenig =
 wrote:
>>>=20
>>>> Hi Mike,=20
>>>>=20
>>>> when I worked on the MAC specification I noticed that the JWT does not h=
ave a claim for the scope. I believe that this would be needed to allow the r=
esource server to verify whether the scope the authorization server authoriz=
ed is indeed what the client is asking for.=20
>>>>=20
>>>> Ciao
>>>> Hannes
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>=20

From sberyozkin@gmail.com  Thu Feb 28 09:30:33 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5644721F8B33 for ; Thu, 28 Feb 2013 09:30:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.559
X-Spam-Level: 
X-Spam-Status: No, score=-3.559 tagged_above=-999 required=5 tests=[AWL=0.040,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dM0vRFSavZ7l for ; Thu, 28 Feb 2013 09:30:32 -0800 (PST)
Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 997B321F88C1 for ; Thu, 28 Feb 2013 09:30:31 -0800 (PST)
Received: by mail-ee0-f42.google.com with SMTP id b47so1676281eek.15 for ; Thu, 28 Feb 2013 09:30:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=RuWuUqmiRyaWx6xbe9X3J3C+De4NKiPbnTQNEorWsIg=; b=rCnm38eG6R+QBQEHbpAO4nrpezm8pGsRAEVMBE37xLQUNcrY+I44s3IKKXUygmQVwl pJbffzpgQr8/hfdmbnwDwXQOuIbVc4guoy/K+kOQ9ml+8tu/ZtnX+8nZLqZhfe0tnGq2 T2vcqO6GhWyhWojfl1Yt5vz2TTGodQvh/TdSDqf+UZmwir/4Yuk/+M+m0GUT8EI3qNO3 9Efco8a9jZDhg2jmz7iPX0ZMUSjhgkFQibk5cktPR2DoAVoEpmwwnByt5XqSUmI3dym9 HMoM/zpJFL1hrwIAdU00RoW1T6Z0t908JrPNPg2AQvDtfqr1eBcW5TyzI9wQUTloKA+g c46Q==
X-Received: by 10.14.182.137 with SMTP id o9mr18793162eem.13.1362072629286; Thu, 28 Feb 2013 09:30:29 -0800 (PST)
Received: from [192.168.2.5] ([79.97.76.201]) by mx.google.com with ESMTPS id u44sm12918262eel.7.2013.02.28.09.30.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Feb 2013 09:30:28 -0800 (PST)
Message-ID: <512F9432.3000701@gmail.com>
Date: Thu, 28 Feb 2013 17:30:26 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: oauth@ietf.org
References: <20130225124642.7425.65145.idtracker@ietfa.amsl.com> <1361956373.9883.YahooMailNeo@web31807.mail.mud.yahoo.com> <21030204-8EA7-4FB0-9DD3-2B6C8CA57E02@gmx.net> <1362057295.36069.YahooMailNeo@web31809.mail.mud.yahoo.com> <512F8E1D.2060408@gmail.com>
In-Reply-To: <512F8E1D.2060408@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 17:30:33 -0000

On 28/02/13 17:04, Sergey Beryozkin wrote:
> Hi
> On 28/02/13 13:14, William Mills wrote:
>> I'm actually advocating that we change MAC to be a JWT extension.
> IMHO, having a simpler option, plus, going forward, a possible JWT
> profile (client to RS path) would work better -
>
> Why would JWT completely take over ? May be it should be possible indeed
> to have it as a JWT extension - should it be part of the relevant JWT
> assertion spec, where JWT is used as a possible grant ?
We are talking about access tokens here I've just realized, looking at 
other emails...still may be JWT assertion spec may be expanded in 
principle...

Sergey

>
> Thanks, Sergey
>>
>> ------------------------------------------------------------------------
>> *From:* Hannes Tschofenig 
>> *To:* William Mills 
>> *Cc:* Hannes Tschofenig ; "oauth@ietf.org"
>> 
>> *Sent:* Thursday, February 28, 2013 2:28 AM
>> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
>>
>> Hi Bill,
>>
>> I believe you are misreading the document. In
>> draft-ietf-oauth-v2-http-mac the client still uses the MAC when it
>> accesses a protected resource.
>> The only place where the JWT comes into the picture is with the
>> description of the access token. This matters from a key distribution
>> point of view. The session key for the MAC is included in the encrypted
>> JWT. The JWT is encrypted by the authorization server and decrypted by
>> the resource server.
>>
>> Information about how header fields get included in the MAC is described
>> in Section 5.
>>
>> The nonce isn't killed it is just called differently: seq-nr. The stuff
>> in the original MAC specification actually wasn't a nonce (from the
>> semantic point of view).
>> The extension parameter is there implicitly by allowing additional
>> header fields to be included in the MAC computation.
>>
>> I need to look at the port number field again.
>>
>> Ciao
>> Hannes
>>
>> On Feb 27, 2013, at 11:12 AM, William Mills wrote:
>>
>> > Just read the draft quickly.
>> >
>> > Since we're now leaning on JWT do we need to include the token in
>> this? Why not just make an additional "Envelope MAC" thing and have the
>> signature include the 3 JWT parts in the signature base string? That
>> object then just becomes a JSON container for the kid, timestamp,
>> signature method, signature etc. That thing then is a 4th base64 encoded
>> JSON thing in the auth header.
>> >
>> > How header fields get included in the signature needs definition.
>> >
>> > Why did you kill the port number, nonce, and extension parameter out
>> of the signature base string?
>> >
>> > The BNF appears to have no separators between values.
>> >
>> > -bill
>> >
>> >
>> > From: "internet-drafts@ietf.org "
>> >
>> > To: i-d-announce@ietf.org 
>> > Cc: oauth@ietf.org 
>> > Sent: Monday, February 25, 2013 4:46 AM
>> > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
>> >
>> >
>> > A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> > This draft is a work item of the Web Authorization Protocol Working
>> Group of the IETF.
>> >
>> > Title : OAuth 2.0 Message Authentication Code (MAC) Tokens
>> > Author(s) : Justin Richer
>> > William Mills
>> > Hannes Tschofenig
>> > Filename : draft-ietf-oauth-v2-http-mac-03.txt
>> > Pages : 26
>> > Date : 2013-02-25
>> >
>> > Abstract:
>> > This specification describes how to use MAC Tokens in HTTP requests
>> > to access OAuth 2.0 protected resources. An OAuth client willing to
>> > access a protected resource needs to demonstrate possession of a
>> > crytographic key by using it with a keyed message digest function to
>> > the request.
>> >
>> > The document also defines a key distribution protocol for obtaining a
>> > fresh session key.
>> >
>> >
>> > The IETF datatracker status page for this draft is:
>> > https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac
>> >
>> > There's also a htmlized version available at:
>> > http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03
>> >
>> > A diff from the previous version is available at:
>> > http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-http-mac-03
>> >
>> >
>> > Internet-Drafts are also available by anonymous FTP at:
>> > ftp://ftp.ietf.org/internet-drafts/
>> >
>> > _______________________________________________
>> > 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
>
>

From ve7jtb@ve7jtb.com  Thu Feb 28 09:34:33 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B3721F8BF0 for ; Thu, 28 Feb 2013 09:34:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.394
X-Spam-Level: 
X-Spam-Status: No, score=-3.394 tagged_above=-999 required=5 tests=[AWL=0.204,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrcFXkdwq6S5 for ; Thu, 28 Feb 2013 09:34:32 -0800 (PST)
Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by ietfa.amsl.com (Postfix) with ESMTP id 54C4621F8BEC for ; Thu, 28 Feb 2013 09:34:32 -0800 (PST)
Received: by mail-pa0-f41.google.com with SMTP id fb11so1274248pad.0 for ; Thu, 28 Feb 2013 09:34:32 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=e/JIuWzNuR+u0P/MObBiv0/L+VPZIPdQaQa4u5dm/Ko=; b=BKknCj9TBOOP1ctTJ7lZoNayHqRXB41Qi7QSjTMGJbGtz+BBMIdnUmGYknhckL86Az RQlW1id22T2dWDFeCKHzAuZXnVX8eHcLxLnWUVfcUsXYyqOxf5evVsGsZfRtCWwybayI Ht6j7w/5Q1HnVzR5MYGEvo9fXZgDDHxGKAKtvHLOXAcjzb+Z5hsoz7lTXKSLoAoT+cmY 3+evet+6v9z3yG7XoP+63G8aMsg6rZuP1ntHlUqrIob++kQrTj44gJ2DoBgKnh3E5crF ovpzPTTrdDUP30l+mPJS3mVZUIK/1d1zGbXs0JpxWq147nmn2Ix5vCcGtokj2gM+ve0H 86VQ==
X-Received: by 10.68.143.167 with SMTP id sf7mr10304089pbb.21.1362072872112; Thu, 28 Feb 2013 09:34:32 -0800 (PST)
Received: from [192.168.41.99] (ip-64-134-220-138.public.wayport.net. [64.134.220.138]) by mx.google.com with ESMTPS id zm1sm8999512pbc.26.2013.02.28.09.34.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Feb 2013 09:34:30 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_1F5C6D51-B15F-4EC9-BECD-C8B29BCC9943"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <39016EC6-D3E3-4812-9825-B1C95A5D9AED@oracle.com>
Date: Thu, 28 Feb 2013 09:34:27 -0800
Message-Id: <637841B2-C50C-444D-960F-CABB0CEC889D@ve7jtb.com>
References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net>    <39016EC6-D3E3-4812-9825-B1C95A5D9AED@oracle.com>
To: Phil Hunt 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQmJ2stAk9wid4P15cShs99eUFz87L57MMKCJNtN1oB1ze5MKRAHF6YyUMFczFleGgKq2R7P
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] JWT - scope claim missing
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 17:34:33 -0000

--Apple-Mail=_1F5C6D51-B15F-4EC9-BECD-C8B29BCC9943
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_92D6E276-4B99-4D8F-A2E9-055D9D2479E7"

--Apple-Mail=_92D6E276-4B99-4D8F-A2E9-055D9D2479E7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Yes IETF WG politics:)

Should JWT and JOSE  be together ?  Through a number of twists and turns =
they are not, lets not go there.

But to the point a number of us have made JWT is used in OAuth for more =
than access tokens. =20
Currently it's only use in OAuth is in the JWT assertions profile that =
has nothing to do with access tokens.

John B.

On 2013-02-28, at 9:27 AM, Phil Hunt  wrote:

> Am I missing something. JWT is firstly an oauth spec. Otherwise why =
isnt it in jose wg?
>=20
> Phil
>=20
> Sent from my phone.
>=20
> On 2013-02-28, at 8:44, Brian Campbell  =
wrote:
>=20
>> I think John's point was more that scope is something rather specific =
to an OAuth access token and, while JWT is can be used to represent an =
access token, it's not the only application of JWT. The 'standard' =
claims in JWT are those that are believed (right or wrong) to be widely =
applicable across different applications of JWT. One could argue about =
it but scope is probably not one of those.
>>=20
>> It would probably make sense to try and build a profile of JWT =
specifically for OAuth access tokens (though I suspect there are some =
turtles and dragons in there), which might be the appropriate place to =
define/register a scope claim.
>>=20
>>=20
>> On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt  =
wrote:
>> Are you advocating TWO systems? That seems like a bad choice.
>>=20
>> I would rather fix scope than go to a two system approach.
>>=20
>> Phil
>>=20
>> Sent from my phone.
>>=20
>> On 2013-02-28, at 8:17, John Bradley  wrote:
>>=20
>> > While scope is one method that a AS could communicate authorization =
to a RS, it is not the only or perhaps even the most likely one.
>> > Using scope requires a relatively tight binding between the RS and =
AS,  UMA uses a different mechanism that describes finer grained =
operations.
>> > The AS may include roles, user, or other more abstract claims that =
the the client may (god help them) pass on to EXCML for processing.
>> >
>> > While having a scopes claim is possible, like any other claim it is =
not part of the JWT core security processing claims, and needs to be =
defined by extension.
>> >
>> > John B.
>> > On 2013-02-28, at 2:29 AM, Hannes Tschofenig =
 wrote:
>> >
>> >> Hi Mike,
>> >>
>> >> when I worked on the MAC specification I noticed that the JWT does =
not have a claim for the scope. I believe that this would be needed to =
allow the resource server to verify whether the scope the authorization =
server authorized is indeed what the client is asking for.
>> >>
>> >> 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
>>=20

--Apple-Mail=_92D6E276-4B99-4D8F-A2E9-055D9D2479E7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Yes =
IETF WG politics:)
Should JWT and JOSE  be =
together ?  Through a number of twists and turns they are not, lets =
not go there.

But to the point a number of us =
have made JWT is used in OAuth for more than access tokens. =

Currently it's only use in OAuth is in the JWT =
assertions profile that has nothing to do with access =
tokens.

John B.

On =
2013-02-28, at 9:27 AM, Phil Hunt <phil.hunt@oracle.com> =
wrote:

Am I missing something. JWT is =
firstly an oauth spec. Otherwise why isnt it in jose =
wg?

Phil
Sent from my =
phone.

On 2013-02-28, at 8:44, Brian Campbell <bcampbell@pingidentity.com&=
gt; wrote:

I =
think John's point was more that scope is something rather specific to =
an OAuth access token and, while JWT is can be used to represent an =
access token, it's not the only application of JWT. The 'standard' =
claims in JWT are those that are believed (right or wrong) to be widely =
applicable across different applications of JWT. One could argue about =
it but scope is probably not one of those.

It would probably make sense to try and build a profile of JWT =
specifically for OAuth access tokens (though I suspect there are some =
turtles and dragons in there), which might be the appropriate place to =
define/register a scope claim.

On =
Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

Are you advocating TWO =
systems? That seems like a bad choice.

I would rather fix scope than go to a two system approach.

Phil

Sent from my phone.

On 2013-02-28, at 8:17, John Bradley <ve7jtb@ve7jtb.com> wrote:

> While scope is one method that a AS could communicate authorization =
to a RS, it is not the only or perhaps even the most likely one.

> Using scope requires a relatively tight binding between the RS and =
AS,  UMA uses a different mechanism that describes finer grained =
operations.

> The AS may include roles, user, or other more abstract claims that =
the the client may (god help them) pass on to EXCML for processing.

>

> While having a scopes claim is possible, like any other claim it is =
not part of the JWT core security processing claims, and needs to be =
defined by extension.

>

> John B.

> On 2013-02-28, at 2:29 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net>=
; wrote:

>

>> Hi Mike,

>>

>> when I worked on the MAC specification I noticed that the JWT =
does not have a claim for the scope. I believe that this would be needed =
to allow the resource server to verify whether the scope the =
authorization server authorized is indeed what the client is asking =
for.

>>

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

=

--Apple-Mail=_92D6E276-4B99-4D8F-A2E9-055D9D2479E7--

--Apple-Mail=_1F5C6D51-B15F-4EC9-BECD-C8B29BCC9943
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMjI4MTczNDI3WjAjBgkqhkiG9w0BCQQxFgQUCudBYqtj
1S2zgZ+xuiKIfE7eSiQwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAWUxUjKp50cPj/UWpLynl8KcMP09xbUhzrAeFClAj
QPoKb6Y2x7/e4eNW2KuQB9LESYq2akt/c2JCmOfKemYrsBtT1BffyEj/Nz9SxUN40Cb22oMFwUEJ
0ByFDCrHa7XTQrHDxKqDRpQ0JNGry0B8RyDE8NomgtSMezZLr8VSVZW9SHLTNmwCxCqL+7Es30Nk
buKJ3++S9IZitdyAm6SOMhpZRJIlD5RB/NHWXRnobt+PDfvWw856GG8Nxrb/FcuGpDpRfrT6KGSd
ikxJ6pufapFs8f3s5GZJK5X/p0R53Bm8sBgrGZmktzRGYMH8a5EAhOO3aA7QXJDvnje+IIOIzQAA
AAAAAA==

--Apple-Mail=_1F5C6D51-B15F-4EC9-BECD-C8B29BCC9943--

From ve7jtb@ve7jtb.com  Thu Feb 28 09:40:33 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353BD21F8A55 for ; Thu, 28 Feb 2013 09:40:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.423
X-Spam-Level: 
X-Spam-Status: No, score=-3.423 tagged_above=-999 required=5 tests=[AWL=0.175,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAEmA9bB2wyB for ; Thu, 28 Feb 2013 09:40:32 -0800 (PST)
Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3CED721F88A9 for ; Thu, 28 Feb 2013 09:40:32 -0800 (PST)
Received: by mail-pb0-f41.google.com with SMTP id um15so1211082pbc.0 for ; Thu, 28 Feb 2013 09:40:32 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=ZAXMql53Ww9syxB6ysT35ZIFGEqNw2PMercy5UXoK5Y=; b=ExRc7KpaCJTlyDwNBvMRA/5xIvbyAfQzGY/+Oevjn1heJPBhXD4TB+I/FJ+tBoIO7B 3wqf5X9dEz56lCdER+XPclTrQrgJ/isFIjpEoHQbBTz3nAZdTG7UYtNWHa5XU6a5n2+R Qh1lqp5MWlq3GjXK82gFC9LaX7SiIEzjP5HzFVWEHn3s6AWYC24EB5by4MlljqgHFhNi TGFkErQRbTW61ezghLSMPWO3FUJrRb9reFiN0weB4FYZ61nkmn8noyReFo9fDZY0PZ1e jXFRtXwEahRSamMuJq8i0PxbMk2NRO4ga3B3KVOknMc1UiITfprmswq9sGRkXh0+QhSI JlpQ==
X-Received: by 10.68.201.227 with SMTP id kd3mr10179371pbc.65.1362073231953; Thu, 28 Feb 2013 09:40:31 -0800 (PST)
Received: from [192.168.41.99] (ip-64-134-220-138.public.wayport.net. [64.134.220.138]) by mx.google.com with ESMTPS id ww9sm9000888pbc.41.2013.02.28.09.40.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Feb 2013 09:40:30 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_4748AC50-AF64-4040-8475-53ACC1A9C937"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <48FD87D1-4DF4-4289-99B7-40A515F31890@oracle.com>
Date: Thu, 28 Feb 2013 09:40:26 -0800
Message-Id: <3E472720-31A4-40A0-AAA4-402CF850831A@ve7jtb.com>
References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net>     <48FD87D1-4DF4-4289-99B7-40A515F31890@oracle.com>
To: Phil Hunt 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQnRSNa4ymFxo5y145zP24ub6O4YYexkVU4zQSGgAqtzvSsFgSxW2I2FBlE+XUrUHkk2U9Dj
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] JWT - scope claim missing
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 17:40:33 -0000

--Apple-Mail=_4748AC50-AF64-4040-8475-53ACC1A9C937
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_25E7786C-AB10-4B66-AE08-E5610AA605F3"

--Apple-Mail=_25E7786C-AB10-4B66-AE08-E5610AA605F3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

JWT is an assertion( I am probably going to regret using that word).

It is used in openID connect for id_tokens, it is used in OAuth for =
Assertion grant types and authentication of the client to the token =
endpoint.
http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

Dosen't define JWT's use for access tokens for the RS.  =20

Bottom line JWT is for more than access tokens.

John B.

On 2013-02-28, at 9:28 AM, Phil Hunt  wrote:

> Are you saying jwt is not an access token type?
>=20
> Phil
>=20
> Sent from my phone.
>=20
> On 2013-02-28, at 8:58, John Bradley  wrote:
>=20
>> Yes, defining scope in JWT is the wrong place.   JWT needs to stick =
to the security claims needed to process JWT.
>>=20
>> I also don't know how far you get requiring a specific authorization =
format for JWT, some AS will wan to use a opaque reference, some might =
want to use a user claim or role claim, others may use scopes,  =
combining scopes and claims is also possible.
>>=20
>> Right now it is up to a AS RS pair to agree on how to communicate =
authorization.   I don't want MAC to be more restrictive than bearer =
when it comes to authorization between AS and RS.
>>=20
>> Hannes wanted to know why JWT didn't define scope.  The simple answer =
is that it is out of scope for JWT itself.   It might be defined in a =
OAuth access token profile for JWT but it should not be specific to MAC.
>>=20
>> John B.
>> On 2013-02-28, at 8:44 AM, Brian Campbell =
 wrote:
>>=20
>>> I think John's point was more that scope is something rather =
specific to an OAuth access token and, while JWT is can be used to =
represent an access token, it's not the only application of JWT. The =
'standard' claims in JWT are those that are believed (right or wrong) to =
be widely applicable across different applications of JWT. One could =
argue about it but scope is probably not one of those.
>>>=20
>>> It would probably make sense to try and build a profile of JWT =
specifically for OAuth access tokens (though I suspect there are some =
turtles and dragons in there), which might be the appropriate place to =
define/register a scope claim.
>>>=20
>>>=20
>>> On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt  =
wrote:
>>> Are you advocating TWO systems? That seems like a bad choice.
>>>=20
>>> I would rather fix scope than go to a two system approach.
>>>=20
>>> Phil
>>>=20
>>> Sent from my phone.
>>>=20
>>> On 2013-02-28, at 8:17, John Bradley  wrote:
>>>=20
>>> > While scope is one method that a AS could communicate =
authorization to a RS, it is not the only or perhaps even the most =
likely one.
>>> > Using scope requires a relatively tight binding between the RS and =
AS,  UMA uses a different mechanism that describes finer grained =
operations.
>>> > The AS may include roles, user, or other more abstract claims that =
the the client may (god help them) pass on to EXCML for processing.
>>> >
>>> > While having a scopes claim is possible, like any other claim it =
is not part of the JWT core security processing claims, and needs to be =
defined by extension.
>>> >
>>> > John B.
>>> > On 2013-02-28, at 2:29 AM, Hannes Tschofenig =
 wrote:
>>> >
>>> >> Hi Mike,
>>> >>
>>> >> when I worked on the MAC specification I noticed that the JWT =
does not have a claim for the scope. I believe that this would be needed =
to allow the resource server to verify whether the scope the =
authorization server authorized is indeed what the client is asking for.
>>> >>
>>> >> 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
>>>=20
>>=20

--Apple-Mail=_25E7786C-AB10-4B66-AE08-E5610AA605F3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

JWT =
is an assertion( I am probably going to regret using that =
word).
It is used in openID connect for id_tokens, it =
is used in OAuth for Assertion grant types and authentication of the =
client to the token endpoint.
http://=
tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04
JSON Web Token (JWT) Bearer Token =
Profiles for OAuth 2.0

Dosen't =
define JWT's use for access tokens for the RS. =

Bottom line JWT is for more than =
access tokens.

John =
B.

On 2013-02-28, at 9:28 AM, Phil Hunt =
<phil.hunt@oracle.com> =
wrote:

Are you saying jwt is not an =
access token type?

Phil
Sent from my =
phone.

On 2013-02-28, at 8:58, John Bradley <ve7jtb@ve7jtb.com> =
wrote:

Yes, defining scope in JWT is the wrong place. =
  JWT needs to stick to the security claims needed to process =
JWT.
I also don't know how far you get requiring a =
specific authorization format for JWT, some AS will wan to use a opaque =
reference, some might want to use a user claim or role claim, others may =
use scopes,  combining scopes and claims is also =
possible.

Right now it is up to a AS RS pair to =
agree on how to communicate authorization.   I don't want MAC to be =
more restrictive than bearer when it comes to authorization between AS =
and RS.

Hannes wanted to know why JWT didn't =
define scope.  The simple answer is that it is out of scope for JWT =
itself.   It might be defined in a OAuth access token profile for =
JWT but it should not be specific to MAC.

John =
B.
On 2013-02-28, at 8:44 AM, Brian Campbell <bcampbell@pingidentity.com&=
gt; wrote:

I think John's point was more that =
scope is something rather specific to an OAuth access token and, while =
JWT is can be used to represent an access token, it's not the only =
application of JWT. The 'standard' claims in JWT are those that are =
believed (right or wrong) to be widely applicable across different =
applications of JWT. One could argue about it but scope is probably not =
one of those.

It would probably make sense to try and build a profile of JWT =
specifically for OAuth access tokens (though I suspect there are some =
turtles and dragons in there), which might be the appropriate place to =
define/register a scope claim.

On =
Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

Are you advocating TWO =
systems? That seems like a bad choice.

I would rather fix scope than go to a two system approach.

Phil

Sent from my phone.

On 2013-02-28, at 8:17, John Bradley <ve7jtb@ve7jtb.com> wrote:

> While scope is one method that a AS could communicate authorization =
to a RS, it is not the only or perhaps even the most likely one.

> Using scope requires a relatively tight binding between the RS and =
AS,  UMA uses a different mechanism that describes finer grained =
operations.

> The AS may include roles, user, or other more abstract claims that =
the the client may (god help them) pass on to EXCML for processing.

>

> While having a scopes claim is possible, like any other claim it is =
not part of the JWT core security processing claims, and needs to be =
defined by extension.

>

> John B.

> On 2013-02-28, at 2:29 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net>=
; wrote:

>

>> Hi Mike,

>>

>> when I worked on the MAC specification I noticed that the JWT =
does not have a claim for the scope. I believe that this would be needed =
to allow the resource server to verify whether the scope the =
authorization server authorized is indeed what the client is asking =
for.

>>

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

=

<=
br>=

--Apple-Mail=_25E7786C-AB10-4B66-AE08-E5610AA605F3--

--Apple-Mail=_4748AC50-AF64-4040-8475-53ACC1A9C937
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMjI4MTc0MDI3WjAjBgkqhkiG9w0BCQQxFgQU+LQ3wWIF
9mu9hgylvsfKIuSnTokwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAlIRT71JMiTJFCuGvZjzWNvVyBYe4napOLlZUHlU2
BWkjeO5Lml4uVdHITy/4cKFmj07ZYofrfIqN9W0TfXrnV/gJz3cYwIg31vc6uhypQCJjRS4H8t2X
UdTljvbcq6hPDwlvQYjMBxf0LqC1e7lBi38GHI05jq0U2QhDhQj2zzG06bs0/nEoDJH4tA1B1yfH
TesJol/44Gsc0PUaa73DIGKedPS2hg8k54w6Xl1+MtiZ/SRlpxEHL6lBRGZNfS0obpG1dTU7QK7S
x56gUJA7XLLU9gv+zANOYDwph6Fd8Q8g6SJXCmELK/5EtizrxWOIpOnNMfORrCAC7TYYs35qxwAA
AAAAAA==

--Apple-Mail=_4748AC50-AF64-4040-8475-53ACC1A9C937--

From wmills_92105@yahoo.com  Thu Feb 28 09:43:53 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E789321F8C06 for ; Thu, 28 Feb 2013 09:43:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.341
X-Spam-Level: 
X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.257,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5COVv6tRQKH for ; Thu, 28 Feb 2013 09:43:51 -0800 (PST)
Received: from nm37-vm7.bullet.mail.ne1.yahoo.com (nm37-vm7.bullet.mail.ne1.yahoo.com [98.138.229.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7364921F8C08 for ; Thu, 28 Feb 2013 09:43:51 -0800 (PST)
Received: from [98.138.226.177] by nm37.bullet.mail.ne1.yahoo.com with NNFMP; 28 Feb 2013 17:43:43 -0000
Received: from [98.138.89.253] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 28 Feb 2013 17:43:43 -0000
Received: from [127.0.0.1] by omp1045.mail.ne1.yahoo.com with NNFMP; 28 Feb 2013 17:43:43 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 516844.42324.bm@omp1045.mail.ne1.yahoo.com
Received: (qmail 38930 invoked by uid 60001); 28 Feb 2013 17:43:43 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1362073422; bh=n1n/sU7A+rVWbVrMKggsRv8N4CvlmZ0uQ3tt+DDDfOI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=YG1Okq3avJlOkxStGQOoAwViTXOTRtngRszaCKd/YLR8Y9QUIhXRQ3qrMPoInmTWvgQjPeIMlP1ai2OFrj8dSALe2F5Mssny4xvxSR3h0rYYl9ty27dWpNuPRYKPPd36f2HNoQokTtf+ilINc1OwJYwhMXog/TptuG8IzT6Xl6M=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=W/Ksl4fCN9X/ETCYAxVbJbke7u3iTMn0qV404FDq40l7RAWvPUB1s99BAlfs/4mbuM1z5fcy00V+xf/ExlBZaJ1P4qgvs9rfucBRhKVajChaITrylJZ5nNLYubjoI8bN+bD9STvDX+PTW3L3z86mBEyHQwd0yKT81Zd0MY3lRIc=;
X-YMail-OSG: nK8j0zUVM1loAz_tdyB1EW0v.ovh5CfcZZbHCrKQH7jnaAP TYP_hZVCZsiL5WZUqmf10NpngLpAzmuVqqR2uPZW.rOU0EEkvQVuogwf7egx Twe0U4UcaMjtHw7sqOse5iiFLAfHyJhbz9qPtmvQFgJ0Ku8KIycp40camppK gKzPzizOG5PxQ_g7Oz8NjQdNkjcJs3NIm1TQJri4KsiR6zJtGDQMyUBPTjs7 Hi0WVlWnilmDZ.iFVTKceBQx.n8JPzcW_PQzQWySrpEpYweZWoZNY00_B801 mw1osuV.6y0p6Rkmma561DJ.Qnd189ZtuQ6.UpLBIfHysChyIUZ88SMt.b9M Qmf.lzEwkybynVz0utRY__6IC4c0IPQiQQ6H6HZC4zBsWyMkaXUPOcCIHT6i 7Z8wVHbXQ03tLiNFApTBd5g76Ehn8p9p6WsYcy.qGKlgOxpMlGZLlZo3fCIP s5WeEacjymAEzKMPUdV4VRzTbAvB3xRnmlLgbVAjvFY7cD4vSSu6hLh6QTf3 SoiSe6AbTXgh.kYvGHcTuv4nwYVamhJnzMS_9IU652A--
Received: from [209.131.62.115] by web31810.mail.mud.yahoo.com via HTTP; Thu, 28 Feb 2013 09:43:42 PST
X-Rocket-MIMEInfo: 001.001, MSkgQVMgaXNzdWVzIEpXVCArIHNlY3JldCB0byBjbGllbnQuCjIpIENsaWVudCBkZWNpZGVzIHRvIGFjY2VzcyByZXNvdXJjZSwgY3JlYXRlcyB0aGUgSldUIE1BQyBKU09OIG9iamVjdCB3aGljaCBjb250YWlucyBzdHVmZiBhYm91dCB0aGUgc2lnbmF0dXJlIGFuZCB0aGUgc2lnbmF0dXJlIGl0c2VsZi4KMykgY2xpZW50IGFwcGVuZHMgdGhhdCBiYXNlNjQgZW5jb2RlZCB0aGluZyB0byB0aGUgSldUCgoxKSBTZXJ2ZXIgZ2V0cyBhIEpXVE1BQyB0b2tlbiwgdGFrZXMgYXBhcnQgdGhlIEpXVCBwYXJ0IHRvIGcBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.135.514
References: <20130225124642.7425.65145.idtracker@ietfa.amsl.com> <1361956373.9883.YahooMailNeo@web31807.mail.mud.yahoo.com> <21030204-8EA7-4FB0-9DD3-2B6C8CA57E02@gmx.net> <1362057295.36069.YahooMailNeo@web31809.mail.mud.yahoo.com> <512F8F1E.3020400@mitre.org>
Message-ID: <1362073422.89847.YahooMailNeo@web31810.mail.mud.yahoo.com>
Date: Thu, 28 Feb 2013 09:43:42 -0800 (PST)
From: William Mills 
To: Justin Richer 
In-Reply-To: <512F8F1E.3020400@mitre.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="1935884094-986886612-1362073422=:89847"
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 17:43:54 -0000

--1935884094-986886612-1362073422=:89847
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

1) AS issues JWT + secret to client.=0A2) Client decides to access resource=
, creates the JWT MAC JSON object which contains stuff about the signature =
and the signature itself.=0A3) client appends that base64 encoded thing to =
the JWT=0A=0A1) Server gets a JWTMAC token, takes apart the JWT part to get=
 the signing key=0A2) Server looks at the JWTMAC to figure out what all it =
has to do to create the signature base string=A0=0A3) server constructs the=
 SBS computes and checks the sig.=0A=0AThe only hairy bit right now is an a=
rbitrary HTTP header list that may be included in the signature.=0A=0ANo da=
ta in the JWTMAC is duplicated from anywhere else.=0A=0A=0A________________=
________________=0A From: Justin Richer =0ATo: William M=
ills  =0ACc: Hannes Tschofenig ; "oauth@ietf.org"  =0ASent: Thursday, February 28, =
2013 9:08 AM=0ASubject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http=
-mac-03.txt=0A =0A=0AWhat I don't quite get is what exactly would be presen=
ted and processed at each step. Who needs to know what piece? We don't want=
 to have to push everything into JSON for the signing to take place (that m=
uch is clear), and we don't want the client to be pushing the MAC secret to=
 the RS every time (that would make it a lot less secret, after all). But i=
f we can reuse JWT, JWS, and other JOSE mechanisms to make some parts of th=
e MAC pattern easier for programmers, I'm for it.=0A=0A=A0-- Justin=0A=0A=
=0AOn 02/28/2013 08:14 AM, William Mills wrote:=0A=0AI'm actually advocatin=
g that we change MAC to be a JWT extension.=0A>=0A>=0A>=0A>________________=
________________=0A> From: Hannes Tschofenig =0A=
>To: William Mills  =0A>Cc: Hannes Tschofenig ; "oauth@ietf.org"  =0A>Sent: Thursda=
y, February 28, 2013 2:28 AM=0A>Subject: Re: [OAUTH-WG] I-D Action: draft-i=
etf-oauth-v2-http-mac-03.txt=0A> =0A>Hi Bill, =0A>=0A>I believe you are mis=
reading the document. In=0A            draft-ietf-oauth-v2-http-mac the cli=
ent still uses the MAC=0A            when it accesses a protected resource.=
 =0A>The only place where the JWT comes into the picture is with=0A        =
    the description of the access token. This matters from a key=0A        =
    distribution point of view. The session key for the MAC is=0A          =
  included in the encrypted JWT. The JWT is encrypted by the=0A            =
authorization server and decrypted by the resource server. =0A>=0A>Informat=
ion about how header fields get included in the MAC=0A            is descri=
bed in Section 5.=0A>=0A>The nonce isn't killed it is just called different=
ly:=0A            seq-nr. The stuff in the original MAC specification actua=
lly=0A            wasn't a nonce (from the semantic point of view). =0A>The=
 extension parameter is there implicitly by allowing=0A            addition=
al header fields to be included in the MAC=0A            computation.=0A>=
=0A>I need to look at the port number field again. =0A>=0A>Ciao=0A>Hannes=
=0A>=0A>On Feb 27, 2013, at 11:12 AM, William Mills wrote:=0A>=0A>> Just re=
ad the draft quickly.=A0 =0A>> =0A>> Since we're now leaning on JWT do we n=
eed to include=0A            the token in this?=A0 Why not just make an add=
itional=0A            "Envelope MAC" thing and have the signature include t=
he 3=0A            JWT parts in the signature base string?=A0 That object t=
hen=0A            just becomes a JSON container for the kid, timestamp,=0A =
           signature method, signature etc. That thing then is a 4th=0A    =
        base64 encoded JSON thing in the auth header.=0A>> =0A>> How header=
 fields get included in the signature needs=0A            definition.=0A>> =
=0A>> Why did you kill the port number, nonce, and extension=0A            =
parameter out of the signature base string?=0A>> =0A>> The BNF appears to h=
ave no separators between values.=0A>> =0A>> -bill=0A>> =0A>> =0A>> From: "=
internet-drafts@ietf.org" =0A>> To: i-d-announce@=
ietf.org =0A>> Cc: oauth@ietf.org =0A>> Sent: Monday, February 25, 2013 4:4=
6 AM=0A>> Subject: [OAUTH-WG] I-D Action:=0A            draft-ietf-oauth-v2=
-http-mac-03.txt=0A>> =0A>> =0A>> A New Internet-Draft is available from th=
e on-line=0A            Internet-Drafts directories.=0A>> This draft is a w=
ork item of the Web Authorization=0A            Protocol Working Group of t=
he IETF.=0A>> =0A>>=A0 =A0 Title=A0 =A0 =A0 =A0 =A0 : OAuth 2.0 Message Aut=
hentication=0A            Code (MAC) Tokens=0A>>=A0 =A0 Author(s)=A0 =A0 =
=A0 : Justin Richer=0A>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 William Mills=0A>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hann=
es Tschofenig=0A>>=A0 =A0 Filename=A0 =A0 =A0 =A0 :=0A            draft-iet=
f-oauth-v2-http-mac-03.txt=0A>>=A0 =A0 Pages=A0 =A0 =A0 =A0 =A0 : 26=0A>>=
=A0 =A0 Date=A0 =A0 =A0 =A0 =A0 =A0 : 2013-02-25=0A>> =0A>> Abstract:=0A>>=
=A0 This specification describes how to use MAC Tokens in=0A            HTT=
P requests=0A>>=A0 to access OAuth 2.0 protected resources.=A0 An OAuth=0A =
           client willing to=0A>>=A0 access a protected resource needs to d=
emonstrate=0A            possession of a=0A>>=A0 crytographic key by using =
it with a keyed message=0A            digest function to=0A>>=A0 the reques=
t.=0A>> =0A>>=A0 The document also defines a key distribution protocol=0A  =
          for obtaining a=0A>>=A0 fresh session key.=0A>> =0A>> =0A>> The I=
ETF datatracker status page for this draft is:=0A>> https://datatracker.iet=
f.org/doc/draft-ietf-oauth-v2-http-mac=0A>> =0A>> There's also a htmlized v=
ersion available at:=0A>>=0A            http://tools.ietf.org/html/draft-ie=
tf-oauth-v2-http-mac-03=0A>> =0A>> A diff from the previous version is avai=
lable at:=0A>>=0A            http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-=
oauth-v2-http-mac-03=0A>> =0A>> =0A>> Internet-Drafts are also available by=
 anonymous FTP at:=0A>> ftp://ftp.ietf.org/internet-drafts/=0A>> =0A>> ____=
___________________________________________=0A>> OAuth mailing list=0A>> OA=
uth@ietf.org=0A>> https://www.ietf.org/mailman/listinfo/oauth=0A>> =0A>> =
=0A>=0A>=0A>=0A>=0A>=0A>=0A>_______________________________________________=
=0AOAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/=
oauth 
--1935884094-986886612-1362073422=:89847
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

1) AS issues JWT + secret to client.
2) Client decides to access resource, creates the JWT MAC JSON object w=
hich contains stuff about the signature and the signature itself.3) client appends that base64 encoded thing =
to the JWT

1) Server gets a JWTMAC token, takes apart the JWT part t=
o get the signing key
2) Server looks at the JWT=
MAC to figure out what all it has to do to create the signature base string=

3) server constructs the SBS computes and=
 checks the sig.

No data in the JWTMAC is duplicated from anywhere else.

     =

  From: Justin Richer <jricher@mit=
re.org>
 To: William=
 Mills <wmills_92105@yahoo.com> 
Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>; "o=
auth@ietf.org" <oauth@ietf.org> 
 Sent: Thursday, February 28, 2013 9:08 AM
 Subject: Re: [OAUTH-WG] I-D Action: dr=
aft-ietf-oauth-v2-http-mac-03.txt

=0A=0A  =0A=0A    =0A  =0A  =0A    What I don't quite get is wh=
at exactly would be presented and=0A    processed at each step. Who needs t=
o know what piece? We don't want=0A    to have to push everything into JSON=
 for the signing to take place=0A    (that much is clear), and we don't wan=
t the client to be pushing the=0A    MAC secret to the RS every time (that =
would make it a lot less=0A    secret, after all). But if we can reuse JWT,=
 JWS, and other JOSE=0A    mechanisms to make some parts of the MAC pattern=
 easier for=0A    programmers, I'm for it.
=0A    
=0A     -- Ju=
stin
=0A    
=0A    On 02/=
28/2013 08:14 AM, William Mills=0A      wrote:
=0A    
=0A    =0A      =0A      =0A        I'm a=
ctually advocating that we change MAC to be a=0A            JWT extension.<=
/span>
=0A        
=0A        
=0A        =0A          =0A             =0A                
 From:=0A                Hannes Tschofen=
ig <hannes.tschofenig@gmx.net>
=0A        =
        To:=0A             =
   William Mills <wmills_92105@yahoo.com> 
=0A   =
             Cc:=0A        =
        Hannes Tschofenig <hannes.tschofenig@gmx.net&=
gt;;=0A                "oauth@ietf.org" <oauth@ietf.org> 
=
=0A                Sent:=0A=
                Thursday, February 28, 2013 2:28 AM
=0A                <=
b>Subject:=0A                R=
e: [OAUTH-WG] I-D Action:=0A                draft-ietf-oauth-v2-http-mac-03=
.txt
=0A               
=0A            
=0A            Hi=
 Bill, 
=0A            
=0A            I believe you are misreading t=
he document. In=0A            draft-ietf-oauth-v2-http-mac the client still=
 uses the MAC=0A            when it accesses a protected resource. 
=0A =
           The only place where the JWT comes into the picture is with=0A  =
          the description of the access token. This matters from a key=0A  =
          distribution point of view. The session key for the MAC is=0A    =
        included in the encrypted JWT. The JWT is encrypted by the=0A      =
      authorization server and decrypted by the resource server. 
=0A   =

=0A            Information about how header fields get include=
d in the MAC=0A            is described in Section 5.
=0A            =0A            The nonce isn't killed it is just called differently:=0A   =
         seq-nr. The stuff in the original MAC specification actually=0A   =
         wasn't a nonce (from the semantic point of view). 
=0A         =
   The extension parameter is there implicitly by allowing=0A            ad=
ditional header fields to be included in the MAC=0A            computation.=

=0A            
=0A            I need to look at the port number fie=
ld again. 
=0A            
=0A            Ciao
=0A            Hann=
es
=0A            
=0A            On Feb 27, 2013, at 11:12 AM, Willi=
am Mills wrote:
=0A            
=0A            > Just read the dra=
ft quickly.  
=0A            > 
=0A            > Since we'=
re now leaning on JWT do we need to include=0A            the token in this=
?  Why not just make an additional=0A            "Envelope MAC" thing =
and have the signature include the 3=0A            JWT parts in the signatu=
re base string?  That object then=0A            just becomes a JSON co=
ntainer for the kid, timestamp,=0A            signature method, signature e=
tc. That thing then is a 4th=0A            base64 encoded JSON thing in the=
 auth header.
=0A            > 
=0A            > How header fie=
lds get included in the signature needs=0A            definition.
=0A   =
         > 
=0A            > Why did you kill the port number, non=
ce, and extension=0A            parameter out of the signature base string?=

=0A            > 
=0A            > The BNF appears to have no =
separators between values.
=0A            > 
=0A            > -=
bill
=0A            > 
=0A            > 
=0A            >=
 From: "internet-drafts@iet=
f.org"=0A            <internet-drafts@ietf.org>
=0A            > To: i-d-announce@ietf.org=0A            
=
=0A            > Cc: oauth@ietf.org 
=
=0A            > Sent: Monday, February 25, 2013 4:46 AM
=0A         =
   > Subject: [OAUTH-WG] I-D Action:=0A            draft-ietf-oauth-v2-h=
ttp-mac-03.txt
=0A            > 
=0A            > 
=0A      =
      > A New Internet-Draft is available from the on-line=0A           =
 Internet-Drafts directories.
=0A            > This draft is a work i=
tem of the Web Authorization=0A            Protocol Working Group of the IE=
TF.
=0A            > 
=0A            >    Title =
         : OAuth 2.0 Message Authentication=0A         =
   Code (MAC) Tokens
=0A            >    Author(s)  &n=
bsp;   : Justin Richer
=0A            >      &nbs=
p;                   William M=
ills
=0A            >             =
             Hannes Tschofenig
=0A        =
    >    Filename        :=0A            d=
raft-ietf-oauth-v2-http-mac-03.txt
=0A            >    Page=
s          : 26
=0A            >   =
; Date            : 2013-02-25
=0A        =
    > 
=0A            > Abstract:
=0A            >  Thi=
s specification describes how to use MAC Tokens in=0A            HTTP reque=
sts
=0A            >  to access OAuth 2.0 protected resources.&n=
bsp; An OAuth=0A            client willing to
=0A            >  =
access a protected resource needs to demonstrate=0A            possession o=
f a
=0A            >  crytographic key by using it with a keyed =
message=0A            digest function to
=0A            >  the r=
equest.
=0A            > 
=0A            >  The document a=
lso defines a key distribution protocol=0A            for obtaining a
=
=0A            >  fresh session key.
=0A            > 
=0A=
            > 
=0A            > The IETF datatracker status page f=
or this draft is:
=0A            > =
https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac
=0A   =
         > 
=0A            > There's also a htmlized version avail=
able at:
=0A            >=0A            http://tools.ietf.org/html/dr=
aft-ietf-oauth-v2-http-mac-03
=0A            > 
=0A            >=
; A diff from the previous version is available at:
=0A            >=
=0A            http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-v2-http-=
mac-03
=0A            > 
=0A            > 
=0A            &g=
t; Internet-Drafts are also available by anonymous FTP at:
=0A          =
  > ftp://ftp.ietf.org/internet-drafts/
=0A            &g=
t; 
=0A            > _______________________________________________<=
br>=0A            > OAuth mailing list
=0A            > OAuth@ietf.org
=0A            > https://www.ietf.org/mailman/listinfo/oauth
=0A            > =0A            > 
=0A            
=0A            
=0A         =

=0A          
=0A        
=0A      
=0A      
=0A =
     =0A   =

=0A      _______________________________________________=0AOAut=
h mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth=0A=0A    =0A    
=0A  
=0A=0A

 <=
/div>  

--1935884094-986886612-1362073422=:89847--

From wmills_92105@yahoo.com  Thu Feb 28 09:49:06 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995B521F8C3D for ; Thu, 28 Feb 2013 09:49:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.351
X-Spam-Level: 
X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.247,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWCWYfDm8yqb for ; Thu, 28 Feb 2013 09:49:05 -0800 (PST)
Received: from nm23-vm3.bullet.mail.ne1.yahoo.com (nm23-vm3.bullet.mail.ne1.yahoo.com [98.138.91.153]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFF721F8C1E for ; Thu, 28 Feb 2013 09:49:05 -0800 (PST)
Received: from [98.138.226.179] by nm23.bullet.mail.ne1.yahoo.com with NNFMP; 28 Feb 2013 17:49:04 -0000
Received: from [98.138.89.249] by tm14.bullet.mail.ne1.yahoo.com with NNFMP; 28 Feb 2013 17:49:04 -0000
Received: from [127.0.0.1] by omp1041.mail.ne1.yahoo.com with NNFMP; 28 Feb 2013 17:49:04 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 479363.66503.bm@omp1041.mail.ne1.yahoo.com
Received: (qmail 16724 invoked by uid 60001); 28 Feb 2013 17:49:04 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1362073744; bh=mrYomm8vFQW2hD3V7yfztnCCG1bIqPyW9zBJ7g9mptU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=umapFkEeTwJLhQ5lRFWomxGqOhIiMjMPjToIuzQeXl8M1b0Aj5v7eoVuPa/Nls0oqRR/5GgjSHjfUMHLPoPFzXABk9Zqqn7nooAR1nBSBki/PeX+d3/La81TqlAOe1zdRiteiE0NcpQpKOv7PgbPhsI5ifoMhpn/IbSeQs+MnGY=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=jXhvUnMU0cxVRZQJWzPeFfju54ldJuVGJjG3S2rJ2dNDWxIAEzuxXE7v4cVtQIQeh4ybHJRHauo6lAnB9d97RKuqSadfsbX6fk6CN17XL97FZ+FYaNrljJti44+DUoTLUTklGhN2cIHO3HwcEmRKlZHVV1FKvEz/kvpK4WJnCoM=;
X-YMail-OSG: eA1c8oQVM1mwMzlttLvZTR1eTlAVgD1UjikSmyR6fjnyw0B zorWI_FPnbSeMsPfZiWbNA6OdUSoKucxDnwMxB.lWVew9xqqGwPypd7qtWTj 3x1_FMXdZs0jknTv1GMtrYVNUxhycn8fob5.Ne_EpL_IwzmmGvUZAqc4jFFb YmNGdtQp89p8ixyVQzYbrrtPtPAieqXNsFcU41eJmIZPxFr8XVVMwdTa0Prg Qe3IEswwhV1bZfoeO6sv6foceqvSYIjFC30ASDbyGGbT0F91_xXHX3l2LOiR hCmFqb7L4pVuUJv9s02qdkI83HTxvWWlhOdUnnyLu2AtA4rc.16jcu_2ua4O myUmxEpNJ9TF2ereZLC0h66Xf5GCHMNB_yVrGuVgcJHKvrcNLtLvZzJ2DdIE dUBW7Ms1UOAp3k_Ag7xbJboL7bLdJGzDEXTh1wY4sGW6balhqiHHnDVTzkjO ZoadyoMbwVvjIjFJgvdvdMYg_NDQZlyzonyH2HIvJCGWUbEisv9nxIWy9NyZ nIlHHsVzVysWfA2bSqCWjZwEAhUa53kXu8znH8eFEA9iGJHISck9wwhGHRsZ d
Received: from [209.131.62.115] by web31802.mail.mud.yahoo.com via HTTP; Thu, 28 Feb 2013 09:49:03 PST
X-Rocket-MIMEInfo: 001.001, VGhlIEpXVCByZXBsYWNlcyB0aGUgb2F1dGhfdG9rZW4gZGF0YSBlbGVtZW50IGluIHRoZSBvbGQgTUFDIHN0dWZmLiDCoEkganVzdCB3YW50IHRvIHRha2UgYWxsIHRoZSBvdGhlciBvYXV0aF8qIHZhcmlhYmxlcyBhbmQgc3R1ZmYgdGhlbSBpbiBhIHNlcGFyYXRlIEpTT04gb2JqZWN0IGFuZCBjb21wbGV0ZWx5IGtpbGwgdGhlICJmdW4gd2l0aCBzb3J0aW5nIHZhcmlhYmxlcyIgd2hlbiB0aGUgb2F1dGhfKiB0aGluZ3MgY2FuIGJlIGNhcnJpZWQgaW4gdGhlIHF1ZXJ5IHN0cmluZyBvciBoZWFkZXIgb3IgcG8BMAEBAQE-
X-Mailer: YahooMailWebService/0.8.135.514
References: <20130225124642.7425.65145.idtracker@ietfa.amsl.com> <1361956373.9883.YahooMailNeo@web31807.mail.mud.yahoo.com> <21030204-8EA7-4FB0-9DD3-2B6C8CA57E02@gmx.net> <1362057295.36069.YahooMailNeo@web31809.mail.mud.yahoo.com> <512F8E1D.2060408@gmail.com>
Message-ID: <1362073743.15800.YahooMailNeo@web31802.mail.mud.yahoo.com>
Date: Thu, 28 Feb 2013 09:49:03 -0800 (PST)
From: William Mills 
To: Sergey Beryozkin , "oauth@ietf.org" 
In-Reply-To: <512F8E1D.2060408@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-1036955950-98993306-1362073743=:15800"
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 17:49:06 -0000

---1036955950-98993306-1362073743=:15800
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

The JWT replaces the oauth_token data element in the old MAC stuff. =A0I ju=
st want to take all the other oauth_* variables and stuff them in a separat=
e JSON object and completely kill the "fun with sorting variables" when the=
 oauth_* things can be carried in the query string or header or post body.=
=0A=0A=0A________________________________=0A From: Sergey Beryozkin =0ATo: oauth@ietf.org =0ASent: Thursday, February 28, 2013 9=
:04 AM=0ASubject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-0=
3.txt=0A =0AHi=0AOn 28/02/13 13:14, William Mills wrote:=0A> I'm actually a=
dvocating that we change MAC to be a JWT extension.=0AIMHO, having a simple=
r option, plus, going forward, a possible JWT =0Aprofile (client to RS path=
) would work better -=0A=0AWhy would JWT completely take over ? May be it s=
hould be possible indeed =0Ato have it as a JWT extension - should it be pa=
rt of the relevant JWT =0Aassertion spec, where JWT is used as a possible g=
rant ?=0A=0AThanks, Sergey=0A>=0A> ----------------------------------------=
--------------------------------=0A> *From:* Hannes Tschofenig =0A> *To:* William Mills =0A> *Cc:* =
Hannes Tschofenig ; "oauth@ietf.org"=0A> =0A> *Sent:* Thursday, February 28, 2013 2:28 AM=0A> *Subject:* Re=
: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt=0A>=0A> Hi Bil=
l,=0A>=0A> I believe you are misreading the document. In=0A> draft-ietf-oau=
th-v2-http-mac the client still uses the MAC when it=0A> accesses a protect=
ed resource.=0A> The only place where the JWT comes into the picture is wit=
h the=0A> description of the access token. This matters from a key distribu=
tion=0A> point of view. The session key for the MAC is included in the encr=
ypted=0A> JWT. The JWT is encrypted by the authorization server and decrypt=
ed by=0A> the resource server.=0A>=0A> Information about how header fields =
get included in the MAC is described=0A> in Section 5.=0A>=0A> The nonce is=
n't killed it is just called differently: seq-nr. The stuff=0A> in the orig=
inal MAC specification actually wasn't a nonce (from the=0A> semantic point=
 of view).=0A> The extension parameter is there implicitly by allowing addi=
tional=0A> header fields to be included in the MAC computation.=0A>=0A> I n=
eed to look at the port number field again.=0A>=0A> Ciao=0A> Hannes=0A>=0A>=
 On Feb 27, 2013, at 11:12 AM, William Mills wrote:=0A>=0A>=A0 > Just read =
the draft quickly.=0A>=A0 >=0A>=A0 > Since we're now leaning on JWT do we n=
eed to include the token in=0A> this? Why not just make an additional "Enve=
lope MAC" thing and have the=0A> signature include the 3 JWT parts in the s=
ignature base string? That=0A> object then just becomes a JSON container fo=
r the kid, timestamp,=0A> signature method, signature etc. That thing then =
is a 4th base64 encoded=0A> JSON thing in the auth header.=0A>=A0 >=0A>=A0 =
> How header fields get included in the signature needs definition.=0A>=A0 =
>=0A>=A0 > Why did you kill the port number, nonce, and extension parameter=
 out=0A> of the signature base string?=0A>=A0 >=0A>=A0 > The BNF appears to=
 have no separators between values.=0A>=A0 >=0A>=A0 > -bill=0A>=A0 >=0A>=A0=
 >=0A>=A0 > From: "internet-drafts@ietf.org "=0A> >=0A>=A0=
 > To: i-d-announce@ietf.org =0A>=A0 > Cc: oa=
uth@ietf.org =0A>=A0 > Sent: Monday, February 25, 20=
13 4:46 AM=0A>=A0 > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-htt=
p-mac-03.txt=0A>=A0 >=0A>=A0 >=0A>=A0 > A New Internet-Draft is available f=
rom the on-line Internet-Drafts=0A> directories.=0A>=A0 > This draft is a w=
ork item of the Web Authorization Protocol Working=0A> Group of the IETF.=
=0A>=A0 >=0A>=A0 > Title : OAuth 2.0 Message Authentication Code (MAC) Toke=
ns=0A>=A0 > Author(s) : Justin Richer=0A>=A0 > William Mills=0A>=A0 > Hanne=
s Tschofenig=0A>=A0 > Filename : draft-ietf-oauth-v2-http-mac-03.txt=0A>=A0=
 > Pages : 26=0A>=A0 > Date : 2013-02-25=0A>=A0 >=0A>=A0 > Abstract:=0A>=A0=
 > This specification describes how to use MAC Tokens in HTTP requests=0A>=
=A0 > to access OAuth 2.0 protected resources. An OAuth client willing to=
=0A>=A0 > access a protected resource needs to demonstrate possession of a=
=0A>=A0 > crytographic key by using it with a keyed message digest function=
 to=0A>=A0 > the request.=0A>=A0 >=0A>=A0 > The document also defines a key=
 distribution protocol for obtaining a=0A>=A0 > fresh session key.=0A>=A0 >=
=0A>=A0 >=0A>=A0 > The IETF datatracker status page for this draft is:=0A>=
=A0 > https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac=0A>=A0 =
>=0A>=A0 > There's also a htmlized version available at:=0A>=A0 > http://to=
ols.ietf.org/html/draft-ietf-oauth-v2-http-mac-03=0A>=A0 >=0A>=A0 > A diff =
from the previous version is available at:=0A>=A0 > http://www.ietf.org/rfc=
diff?url2=3Ddraft-ietf-oauth-v2-http-mac-03=0A>=A0 >=0A>=A0 >=0A>=A0 > Inte=
rnet-Drafts are also available by anonymous FTP at:=0A>=A0 > ftp://ftp.ietf=
.org/internet-drafts/=0A>=A0 >=0A>=A0 > ___________________________________=
____________=0A>=A0 > OAuth mailing list=0A>=A0 > OAuth@ietf.org =0A>=A0 > https://www.ietf.org/mailman/listinfo/oauth=0A>=A0 >=
=0A>=A0 >=0A>=0A>=0A>=0A>=0A>=0A> _________________________________________=
______=0A> OAuth mailing list=0A> OAuth@ietf.org=0A> https://www.ietf.org/m=
ailman/listinfo/oauth=0A=0A=0A_____________________________________________=
__=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/lis=
tinfo/oauth
---1036955950-98993306-1362073743=:15800
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

The JWT replaces the oauth_token data element in the old MAC stuff.  =
;I just want to take all the other oauth_* variables and stuff them in a se=
parate JSON object and completely kill the "fun with sorting variables" whe=
n the oauth_* things can be carried in the query string or header or post b=
ody.

   =

  From: Sergey Beryozkin <sberyo=
zkin@gmail.com>
 To:=
 oauth@ietf.org 
 Sent:=
 Thursday,
 February 28, 2013 9:04 AM
 Subjec=
t: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.tx=
t

=0AHi
On 28/02/13 13:14, William Mills wrote:> I'm actually advocating that we change MAC to be a JWT extension.IMHO, having a simpler option, plus, going forward, a possible JWT 
pro=
file (client to RS path) would work better -

Why would JWT completel=
y take over ? May be it should be possible indeed 
to have it as a JWT e=
xtension - should it be part of the relevant JWT 
assertion spec, where =
JWT is used as a possible grant ?

Thanks, Sergey
>
> ---=
---------------------------------------------------------------------
&g=
t; *From:* Hannes Tschofenig <hannes.tschofenig@gmx.net>
> *To:* William Mills <wmills_92105@yahoo.com&=
gt;
> *Cc:* Hannes Tschofenig <hannes.tschofenig@gmx.net>=
;; "oau=
th@ietf.org"
> <oauth@ietf.org>
> *Sent:* Thursday, Febr=
uary 28, 2013 2:28 AM
> *Subject:* Re: [OAUTH-WG] I-D Action: draft-i=
etf-oauth-v2-http-mac-03.txt
>
> Hi Bill,
>
> I bel=
ieve you are misreading the document. In
> draft-ietf-oauth-v2-http-m=
ac the client still uses the MAC when it
> accesses a protected resou=
rce.
> The only place where the JWT comes into the picture is with th=
e
> description of the access token. This matters from a key distribu=
tion
> point of view. The session key for the MAC is included in the =
encrypted
> JWT. The JWT is encrypted by the authorization server and=
 decrypted by
> the resource server.
>
> Information abou=
t
 how header fields get included in the MAC is described
> in Section =
5.
>
> The nonce isn't killed it is just called differently: se=
q-nr. The stuff
> in the original MAC specification actually wasn't a=
 nonce (from the
> semantic point of view).
> The extension par=
ameter is there implicitly by allowing additional
> header fields to =
be included in the MAC computation.
>
> I need to look at the p=
ort number field again.
>
> Ciao
> Hannes
>
>=
 On Feb 27, 2013, at 11:12 AM, William Mills wrote:
>
>  &=
gt; Just read the draft quickly.
>  >
>  > Sinc=
e we're now leaning on JWT do we need to include the token in
> this?=
 Why not just make an additional "Envelope MAC" thing and have the
> =
signature include the 3 JWT parts in the signature base string? That
>=
; object then just becomes a JSON container for the kid,
 timestamp,
> signature method, signature etc. That thing then is a 4=
th base64 encoded
> JSON thing in the auth header.
>  >=

>  > How header fields get included in the signature needs d=
efinition.
>  >
>  > Why did you kill the port =
number, nonce, and extension parameter out
> of the signature base st=
ring?
>  >
>  > The BNF appears to have no sepa=
rators between values.
>  >
>  > -bill
>&=
nbsp; >
>  >
>  > From: "intern=
et-drafts@ietf.org <mailto:internet-drafts@ietf.org=
>"
> <internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>
>  > To: i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>=
;
>  > Cc: oauth@ietf.org <mailto:oauth@ietf.org>
>&nbs=
p; > Sent: Monday, February 25, 2013 4:46 AM
>  > Subject:=
 [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
>  &=
gt;
>  >
>  > A New Internet-Draft is available=
 from the on-line Internet-Drafts
> directories.
>  > T=
his draft is a work item of the Web Authorization Protocol Working
> =
Group of the
 IETF.
>  >
>  > Title : OAuth 2.0 Message Auth=
entication Code (MAC) Tokens
>  > Author(s) : Justin Richer>  > William Mills
>  > Hannes Tschofenig
>=
;  > Filename : draft-ietf-oauth-v2-http-mac-03.txt
>  &=
gt; Pages : 26
>  > Date : 2013-02-25
>  >
&=
gt;  > Abstract:
>  > This specification describes ho=
w to use MAC Tokens in HTTP requests
>  > to access OAuth 2.0=
 protected resources. An OAuth client willing to
>  > access =
a protected resource needs to demonstrate possession of a
>  >=
; crytographic key by using it with a keyed message digest function to
&=
gt;  > the request.
>  >
>  > The docum=
ent also defines a key distribution protocol for obtaining a
>  =
> fresh session key.
>  >
> 
 >
>  > The IETF datatracker status page for this draft is=
:
>  > https://datatracker.ietf.org/doc/draf=
t-ietf-oauth-v2-http-mac
>  >
>  > There's =
also a htmlized version available at:
>  > http://tools.ietf.=
org/html/draft-ietf-oauth-v2-http-mac-03
>  >
>  &=
gt; A diff from the previous version is available at:
>  > ht=
tp://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-v2-http-mac-03
>&nb=
sp; >
>  >
>  > Internet-Drafts are also ava=
ilable by anonymous FTP at:
>  > ftp://ftp.ietf.org/internet-drafts/
>  >
>  > __________________________________=
_____________
>  > OAuth mailing list
>  > OAuth@iet=
f.org <mailto: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

<=
br> 

---1036955950-98993306-1362073743=:15800--

From jricher@mitre.org  Thu Feb 28 09:51:02 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E7221F87AA for ; Thu, 28 Feb 2013 09:51:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.578
X-Spam-Level: 
X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.020,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwA9xJogVF9J for ; Thu, 28 Feb 2013 09:51:00 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id BEC6E21F87A3 for ; Thu, 28 Feb 2013 09:50:43 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2E8E45311B94; Thu, 28 Feb 2013 12:50:43 -0500 (EST)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 0BD2D5311B8F; Thu, 28 Feb 2013 12:50:43 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 28 Feb 2013 12:50:42 -0500
Message-ID: <512F98B4.3070303@mitre.org>
Date: Thu, 28 Feb 2013 12:49:40 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: William Mills 
References: <20130225124642.7425.65145.idtracker@ietfa.amsl.com> <1361956373.9883.YahooMailNeo@web31807.mail.mud.yahoo.com> <21030204-8EA7-4FB0-9DD3-2B6C8CA57E02@gmx.net> <1362057295.36069.YahooMailNeo@web31809.mail.mud.yahoo.com> <512F8F1E.3020400@mitre.org> <1362073422.89847.YahooMailNeo@web31810.mail.mud.yahoo.com>
In-Reply-To: <1362073422.89847.YahooMailNeo@web31810.mail.mud.yahoo.com>
Content-Type: multipart/alternative; boundary="------------070904010300040105030308"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 17:51:02 -0000

--------------070904010300040105030308
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

OK, so it still runs the signature over HTTP elements (query, url, 
headers, etc) but all of the structured components are *communicated* 
via a JWT/JOSE structure. That makes sense to me, on the surface at least.

  -- Justin

On 02/28/2013 12:43 PM, William Mills wrote:
> 1) AS issues JWT + secret to client.
> 2) Client decides to access resource, creates the JWT MAC JSON object 
> which contains stuff about the signature and the signature itself.
> 3) client appends that base64 encoded thing to the JWT
>
> 1) Server gets a JWTMAC token, takes apart the JWT part to get the 
> signing key
> 2) Server looks at the JWTMAC to figure out what all it has to do to 
> create the signature base string
> 3) server constructs the SBS computes and checks the sig.
>
> The only hairy bit right now is an arbitrary HTTP header list that may 
> be included in the signature.
>
> No data in the JWTMAC is duplicated from anywhere else.
>
> ------------------------------------------------------------------------
> *From:* Justin Richer 
> *To:* William Mills 
> *Cc:* Hannes Tschofenig ; "oauth@ietf.org" 
> 
> *Sent:* Thursday, February 28, 2013 9:08 AM
> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
>
> What I don't quite get is what exactly would be presented and 
> processed at each step. Who needs to know what piece? We don't want to 
> have to push everything into JSON for the signing to take place (that 
> much is clear), and we don't want the client to be pushing the MAC 
> secret to the RS every time (that would make it a lot less secret, 
> after all). But if we can reuse JWT, JWS, and other JOSE mechanisms to 
> make some parts of the MAC pattern easier for programmers, I'm for it.
>
>  -- Justin
>
> On 02/28/2013 08:14 AM, William Mills wrote:
>> I'm actually advocating that we change MAC to be a JWT extension.
>>
>> ------------------------------------------------------------------------
>> *From:* Hannes Tschofenig  
>> 
>> *To:* William Mills  
>> 
>> *Cc:* Hannes Tschofenig  
>> ; "oauth@ietf.org" 
>>   
>> *Sent:* Thursday, February 28, 2013 2:28 AM
>> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
>>
>> Hi Bill,
>>
>> I believe you are misreading the document. In 
>> draft-ietf-oauth-v2-http-mac the client still uses the MAC when it 
>> accesses a protected resource.
>> The only place where the JWT comes into the picture is with the 
>> description of the access token. This matters from a key distribution 
>> point of view. The session key for the MAC is included in the 
>> encrypted JWT. The JWT is encrypted by the authorization server and 
>> decrypted by the resource server.
>>
>> Information about how header fields get included in the MAC is 
>> described in Section 5.
>>
>> The nonce isn't killed it is just called differently: seq-nr. The 
>> stuff in the original MAC specification actually wasn't a nonce (from 
>> the semantic point of view).
>> The extension parameter is there implicitly by allowing additional 
>> header fields to be included in the MAC computation.
>>
>> I need to look at the port number field again.
>>
>> Ciao
>> Hannes
>>
>> On Feb 27, 2013, at 11:12 AM, William Mills wrote:
>>
>> > Just read the draft quickly.
>> >
>> > Since we're now leaning on JWT do we need to include the token in 
>> this?  Why not just make an additional "Envelope MAC" thing and have 
>> the signature include the 3 JWT parts in the signature base string?  
>> That object then just becomes a JSON container for the kid, 
>> timestamp, signature method, signature etc. That thing then is a 4th 
>> base64 encoded JSON thing in the auth header.
>> >
>> > How header fields get included in the signature needs definition.
>> >
>> > Why did you kill the port number, nonce, and extension parameter 
>> out of the signature base string?
>> >
>> > The BNF appears to have no separators between values.
>> >
>> > -bill
>> >
>> >
>> > From: "internet-drafts@ietf.org " 
>> >
>> > To: i-d-announce@ietf.org 
>> > Cc: oauth@ietf.org 
>> > Sent: Monday, February 25, 2013 4:46 AM
>> > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
>> >
>> >
>> > A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> > This draft is a work item of the Web Authorization Protocol Working 
>> Group of the IETF.
>> >
>> >    Title          : OAuth 2.0 Message Authentication Code (MAC) Tokens
>> >    Author(s)      : Justin Richer
>> >                          William Mills
>> >                          Hannes Tschofenig
>> >    Filename        : draft-ietf-oauth-v2-http-mac-03.txt
>> >    Pages          : 26
>> >    Date            : 2013-02-25
>> >
>> > Abstract:
>> >  This specification describes how to use MAC Tokens in HTTP requests
>> >  to access OAuth 2.0 protected resources. An OAuth client willing to
>> >  access a protected resource needs to demonstrate possession of a
>> >  crytographic key by using it with a keyed message digest function to
>> >  the request.
>> >
>> >  The document also defines a key distribution protocol for obtaining a
>> >  fresh session key.
>> >
>> >
>> > The IETF datatracker status page for this draft is:
>> > https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac
>> >
>> > There's also a htmlized version available at:
>> > http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03
>> >
>> > A diff from the previous version is available at:
>> > http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-http-mac-03
>> >
>> >
>> > Internet-Drafts are also available by anonymous FTP at:
>> > ftp://ftp.ietf.org/internet-drafts/
>> >
>> > _______________________________________________
>> > 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
>
>
>

--------------070904010300040105030308
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

    OK, so it still runs the signature over HTTP elements (query, url,
    headers, etc) but all of the structured components are
    *communicated* via a JWT/JOSE structure. That makes sense to me, on
    the surface at least.

     -- Justin

    On 02/28/2013 12:43 PM, William Mills
      wrote:

        1) AS issues JWT + secret to client.
        2)
            Client decides to access resource, creates the JWT MAC JSON
            object which contains stuff about the signature and the
            signature itself.
        3)
            client appends that base64 encoded thing to the JWT

        1) Server
          gets a JWTMAC token, takes apart the JWT part to get the
          signing key
        2) Server
          looks at the JWTMAC to figure out what all it has to do to
          create the signature base string 
        3) server
          constructs the SBS computes and checks the sig.

        The only
          hairy bit right now is an arbitrary HTTP header list that may
          be included in the signature.

        No data in
          the JWTMAC is duplicated from anywhere else.

 From:
                Justin Richer <jricher@mitre.org>

                To:
                William Mills <wmills_92105@yahoo.com> 

                Cc:
                Hannes Tschofenig <hannes.tschofenig@gmx.net>;
                "oauth@ietf.org" <oauth@ietf.org> 

                Sent:
                Thursday, February 28, 2013 9:08 AM

                Subject:
                Re: [OAUTH-WG] I-D Action:
                draft-ietf-oauth-v2-http-mac-03.txt

               What I don't quite get is what exactly would be
                presented and processed at each step. Who needs to know
                what piece? We don't want to have to push everything
                into JSON for the signing to take place (that much is
                clear), and we don't want the client to be pushing the
                MAC secret to the RS every time (that would make it a
                lot less secret, after all). But if we can reuse JWT,
                JWS, and other JOSE mechanisms to make some parts of the
                MAC pattern easier for programmers, I'm for it.

                 -- Justin

                On 02/28/2013
                  08:14 AM, William Mills wrote:

                    I'm actually advocating that we change
                        MAC to be a JWT extension.

 From:
                            Hannes Tschofenig <hannes.tschofenig@gmx.net>

                            To:
                            William Mills <wmills_92105@yahoo.com>

                            Cc:
                            Hannes Tschofenig <hannes.tschofenig@gmx.net>;
                            "oauth@ietf.org"
                            <oauth@ietf.org>

                            Sent:
                            Thursday, February 28, 2013 2:28 AM

                            Subject:
                            Re: [OAUTH-WG] I-D Action:
                            draft-ietf-oauth-v2-http-mac-03.txt

                        Hi Bill, 

                        I believe you are misreading the document. In
                        draft-ietf-oauth-v2-http-mac the client still
                        uses the MAC when it accesses a protected
                        resource. 

                        The only place where the JWT comes into the
                        picture is with the description of the access
                        token. This matters from a key distribution
                        point of view. The session key for the MAC is
                        included in the encrypted JWT. The JWT is
                        encrypted by the authorization server and
                        decrypted by the resource server. 

                        Information about how header fields get included
                        in the MAC is described in Section 5.

                        The nonce isn't killed it is just called
                        differently: seq-nr. The stuff in the original
                        MAC specification actually wasn't a nonce (from
                        the semantic point of view). 

                        The extension parameter is there implicitly by
                        allowing additional header fields to be included
                        in the MAC computation.

                        I need to look at the port number field again. 

                        Ciao

                        Hannes

                        On Feb 27, 2013, at 11:12 AM, William Mills
                        wrote:

                        > Just read the draft quickly.  

                        > 

                        > Since we're now leaning on JWT do we need
                        to include the token in this?  Why not just make
                        an additional "Envelope MAC" thing and have the
                        signature include the 3 JWT parts in the
                        signature base string?  That object then just
                        becomes a JSON container for the kid, timestamp,
                        signature method, signature etc. That thing then
                        is a 4th base64 encoded JSON thing in the auth
                        header.

                        > 

                        > How header fields get included in the
                        signature needs definition.

                        > 

                        > Why did you kill the port number, nonce,
                        and extension parameter out of the signature
                        base string?

                        > 

                        > The BNF appears to have no separators
                        between values.

                        > 

                        > -bill

                        > 

                        > 

                        > From: "internet-drafts@ietf.org"
                        <internet-drafts@ietf.org>

                        > To: i-d-announce@ietf.org

                        > Cc: oauth@ietf.org

                        > Sent: Monday, February 25, 2013 4:46 AM

                        > Subject: [OAUTH-WG] I-D Action:
                        draft-ietf-oauth-v2-http-mac-03.txt

                        > 

                        > 

                        > A New Internet-Draft is available from the
                        on-line Internet-Drafts directories.

                        > This draft is a work item of the Web
                        Authorization Protocol Working Group of the
                        IETF.

                        > 

                        >    Title          : OAuth 2.0 Message
                        Authentication Code (MAC) Tokens

                        >    Author(s)      : Justin Richer

                        >                          William Mills

                        >                          Hannes Tschofenig

                        >    Filename        :
                        draft-ietf-oauth-v2-http-mac-03.txt

                        >    Pages          : 26

                        >    Date            : 2013-02-25

                        > 

                        > Abstract:

                        >  This specification describes how to use
                        MAC Tokens in HTTP requests

                        >  to access OAuth 2.0 protected resources. 
                        An OAuth client willing to

                        >  access a protected resource needs to
                        demonstrate possession of a

                        >  crytographic key by using it with a keyed
                        message digest function to

                        >  the request.

                        > 

                        >  The document also defines a key
                        distribution protocol for obtaining a

                        >  fresh session key.

                        > 

                        > 

                        > The IETF datatracker status page for this
                        draft is:

                        > https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac

                        > 

                        > There's also a htmlized version available
                        at:

                        >
                        http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03

                        > 

                        > A diff from the previous version is
                        available at:

                        >
                        http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-http-mac-03

                        > 

                        > 

                        > Internet-Drafts are also available by
                        anonymous FTP at:

                        > ftp://ftp.ietf.org/internet-drafts/

                        > 

                        >
                        _______________________________________________

                        > 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

--------------070904010300040105030308--

From hannes.tschofenig@gmx.net  Thu Feb 28 09:56:51 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A8C21F8835 for ; Thu, 28 Feb 2013 09:56:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.533
X-Spam-Level: 
X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhVjXKSkEqD2 for ; Thu, 28 Feb 2013 09:56:50 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 06E1221F8801 for ; Thu, 28 Feb 2013 09:56:50 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.19]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MW5VH-1ULvTM06kz-00XLiq for ; Thu, 28 Feb 2013 18:56:49 +0100
Received: (qmail invoked by alias); 28 Feb 2013 17:56:48 -0000
Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.219.140] by mail.gmx.net (mp019) with SMTP; 28 Feb 2013 18:56:48 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/qA+AIv83qY78549ETKXbQ4F8uymmYECbhMvKtk5 L82/hJjvJF9nDv
Message-ID: <512F9A5C.1070900@gmx.net>
Date: Thu, 28 Feb 2013 19:56:44 +0200
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Phil Hunt 
References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net>    <1BDBAFF3-6B2D-45EE-8A7E-B0B2572C8A01@oracle.com>
In-Reply-To: <1BDBAFF3-6B2D-45EE-8A7E-B0B2572C8A01@oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] JWT - scope claim missing
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 17:56:51 -0000

I guess we first have to agree whether there is a security benefit of 
communicating the scope from the AS to the RS (in a way that it cannot 
be modified by the client or any other party).

The scope indicates permissions (for example, whether the resource owner 
allowed read access to a certain resource or write access).

Do you agree that there is a security benefit (or to put it the other 
way around: do you see the security vulnerability if this information is 
not communicated to the RS and checked against what the resource owner 
accepted?

Then, a secondary question is what the right mechanism is.

Ciao
Hannes

On 02/28/2013 07:29 PM, Phil Hunt wrote:
> What people are doing now is often issuing saml like assertions. Thats not necessarily indicating intent. It just indicates transition.
>
> Phil
>
> Sent from my phone.
>
> On 2013-02-28, at 9:07, John Bradley  wrote:
>
>> I am not advocating anything, only sting what people are doing now.
>>
>> How authorization is communicated between the AS and RS via a token that is opaque to the client is out of scope fro OAuth core, it might be magic pixy dust.
>>
>> This has lead to a number of ways people are doing it.
>>
>> JWT along with  JOSE provide a container to get some claims from the AS to the RS though the JWT is not specific to this and is used in the assertions profile and other specs for many things other than access tokens.
>>
>> Yes a profile of JWT for an access token as an access token is needed, Yes further profiling is required for a JWT access token using MAC.
>>
>> The format of the authorization claims is not tightly bound to MAC and might be used with other bearer JWT tokens.
>>
>> I don't know that there will be only one way to communicate those claims because different sorts of implementations need different information for the RS to act on.
>> Recommendations are fine but defining a field called scope and passing on exactly the scopes the client was granted is not going to work for everyone for lots of good reasons.
>>
>> John B.
>> On 2013-02-28, at 8:24 AM, Phil Hunt  wrote:
>>
>>> Are you advocating TWO systems? That seems like a bad choice.
>>>
>>> I would rather fix scope than go to a two system approach.
>>>
>>> Phil
>>>
>>> Sent from my phone.
>>>
>>> On 2013-02-28, at 8:17, John Bradley  wrote:
>>>
>>>> While scope is one method that a AS could communicate authorization to a RS, it is not the only or perhaps even the most likely one.
>>>> Using scope requires a relatively tight binding between the RS and AS,  UMA uses a different mechanism that describes finer grained operations.
>>>> The AS may include roles, user, or other more abstract claims that the the client may (god help them) pass on to EXCML for processing.
>>>>
>>>> While having a scopes claim is possible, like any other claim it is not part of the JWT core security processing claims, and needs to be defined by extension.
>>>>
>>>> John B.
>>>> On 2013-02-28, at 2:29 AM, Hannes Tschofenig  wrote:
>>>>
>>>>> Hi Mike,
>>>>>
>>>>> when I worked on the MAC specification I noticed that the JWT does not have a claim for the scope. I believe that this would be needed to allow the resource server to verify whether the scope the authorization server authorized is indeed what the client is asking for.
>>>>>
>>>>> 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
>>

From Adam.Lewis@motorolasolutions.com  Thu Feb 28 09:57:56 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667D321F8C2A for ; Thu, 28 Feb 2013 09:57:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.466
X-Spam-Level: 
X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnlauyydH5J9 for ; Thu, 28 Feb 2013 09:57:53 -0800 (PST)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 47C7C21F8835 for ; Thu, 28 Feb 2013 09:57:53 -0800 (PST)
Received: from mail100-va3-R.bigfish.com (10.7.14.238) by VA3EHSOBE012.bigfish.com (10.7.40.62) with Microsoft SMTP Server id 14.1.225.23; Thu, 28 Feb 2013 17:57:52 +0000
Received: from mail100-va3 (localhost [127.0.0.1])	by mail100-va3-R.bigfish.com (Postfix) with ESMTP id 7F6631A0281	for ; Thu, 28 Feb 2013 17:57:52 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:192.160.210.20; KIP:(null); UIP:(null); IPV:NLI; H:ct11msg01.am.mot-solutions.com; RD:ct11msg01.mot-solutions.com; EFVD:NLI
X-SpamScore: -25
X-BigFish: VPS-25(zz98dI9371I936eIc85fhc430I1432Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275ch1033IL177df4h17326ah8275dh18c673h8275bhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1155h)
Received-SPF: pass (mail100-va3: domain of motorolasolutions.com designates 192.160.210.20 as permitted sender) client-ip=192.160.210.20; envelope-from=Adam.Lewis@motorolasolutions.com; helo=ct11msg01.am.mot-solutions.com ; olutions.com ; 
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.237.133; KIP:(null); UIP:(null); (null); H:BY2PRD0411HT003.namprd04.prod.outlook.com; R:internal; EFV:INT
Received: from mail100-va3 (localhost.localdomain [127.0.0.1]) by mail100-va3 (MessageSwitch) id 1362074268614835_24100; Thu, 28 Feb 2013 17:57:48 +0000 (UTC)
Received: from VA3EHSMHS017.bigfish.com (unknown [10.7.14.229])	by mail100-va3.bigfish.com (Postfix) with ESMTP id 7729D260066	for ; Thu, 28 Feb 2013 17:57:48 +0000 (UTC)
Received: from ct11msg01.am.mot-solutions.com (192.160.210.20) by VA3EHSMHS017.bigfish.com (10.7.99.27) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 28 Feb 2013 17:57:47 +0000
Received: from ct11msg01.am.mot-solutions.com (ct11vts03.am.mot.com [10.177.16.162])	by ct11msg01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r1SILtmf003500	for ; Thu, 28 Feb 2013 12:21:55 -0600 (CST)
Received: from CO9EHSOBE020.bigfish.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25])	by ct11msg01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r1SILs05003492	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL)	for ; Thu, 28 Feb 2013 12:21:55 -0600 (CST)
Received: from mail143-co9-R.bigfish.com (10.236.132.254) by CO9EHSOBE020.bigfish.com (10.236.130.83) with Microsoft SMTP Server id 14.1.225.23; Thu, 28 Feb 2013 17:57:45 +0000
Received: from mail143-co9 (localhost [127.0.0.1])	by mail143-co9-R.bigfish.com (Postfix) with ESMTP id EC7441E0240	for ; Thu, 28 Feb 2013 17:57:44 +0000 (UTC)
Received: from mail143-co9 (localhost.localdomain [127.0.0.1]) by mail143-co9 (MessageSwitch) id 1362074263216252_3227; Thu, 28 Feb 2013 17:57:43 +0000 (UTC)
Received: from CO9EHSMHS027.bigfish.com (unknown [10.236.132.245])	by mail143-co9.bigfish.com (Postfix) with ESMTP id 311AB400D6; Thu, 28 Feb 2013 17:57:43 +0000 (UTC)
Received: from BY2PRD0411HT003.namprd04.prod.outlook.com (157.56.237.133) by CO9EHSMHS027.bigfish.com (10.236.130.37) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 28 Feb 2013 17:57:40 +0000
Received: from BY2PRD0411MB441.namprd04.prod.outlook.com ([169.254.5.225]) by BY2PRD0411HT003.namprd04.prod.outlook.com ([10.255.128.38]) with mapi id 14.16.0263.000; Thu, 28 Feb 2013 17:57:40 +0000
From: Lewis Adam-CAL022 
To: John Bradley , Phil Hunt 
Thread-Topic: [OAUTH-WG] JWT - scope claim missing
Thread-Index: AQHOFZ6Qe5ExGqoPnkOeJlU0r70rz5iPcwoAgAAB5gCAAAWJgIAADAUAgAAB+4CAAAU18IAAATlA
Date: Thu, 28 Feb 2013 17:57:40 +0000
Message-ID: <59E470B10C4630419ED717AC79FCF9A948D58AFA@BY2PRD0411MB441.namprd04.prod.outlook.com>
References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net>    <39016EC6-D3E3-4812-9825-B1C95A5D9AED@oracle.com> <637841B2-C50C-444D-960F-CABB0CEC889D@ve7jtb.com> 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [184.78.105.93]
Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A948D58AFABY2PRD0411MB441_"
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%1294$Dn%VE7JTB.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn%
X-FOPE-CONNECTOR: Id%1294$Dn%ORACLE.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn%
X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn%
X-CFilter-Loop: Reflected
X-OriginatorOrg: motorolasolutions.com
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] JWT - scope claim missing
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 17:57:56 -0000

--_000_59E470B10C4630419ED717AC79FCF9A948D58AFABY2PRD0411MB441_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Adding my 2 cents ...

I am looking to use JWT as the structure for my access tokens, and will lik=
ely profile it to look just like an id_token, plus the scope claim which tr=
iggered this thread :-)

I am also looking at JWT as a grant type.

I am also looking into federating my access tokens (one of the main reasons=
 I am looking to use JWT as the structure for the AT).

All is subject to change, but that is where my head is today.

adam

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J=
ohn Bradley
Sent: Thursday, February 28, 2013 11:34 AM
To: Phil Hunt
Cc: "WG "@il06exr02.mot.com
Subject: Re: [OAUTH-WG] JWT - scope claim missing

Yes IETF WG politics:)

Should JWT and JOSE  be together ?  Through a number of twists and turns th=
ey are not, lets not go there.

But to the point a number of us have made JWT is used in OAuth for more tha=
n access tokens.
Currently it's only use in OAuth is in the JWT assertions profile that has =
nothing to do with access tokens.

John B.

On 2013-02-28, at 9:27 AM, Phil Hunt > wrote:

Am I missing something. JWT is firstly an oauth spec. Otherwise why isnt it=
 in jose wg?

Phil

Sent from my phone.

On 2013-02-28, at 8:44, Brian Campbell > wrote:
I think John's point was more that scope is something rather specific to an=
 OAuth access token and, while JWT is can be used to represent an access to=
ken, it's not the only application of JWT. The 'standard' claims in JWT are=
 those that are believed (right or wrong) to be widely applicable across di=
fferent applications of JWT. One could argue about it but scope is probably=
 not one of those.
It would probably make sense to try and build a profile of JWT specifically=
 for OAuth access tokens (though I suspect there are some turtles and drago=
ns in there), which might be the appropriate place to define/register a sco=
pe claim.

On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt > wrote:
Are you advocating TWO systems? That seems like a bad choice.

I would rather fix scope than go to a two system approach.

Phil

Sent from my phone.

On 2013-02-28, at 8:17, John Bradley > wrote:

> While scope is one method that a AS could communicate authorization to a =
RS, it is not the only or perhaps even the most likely one.
> Using scope requires a relatively tight binding between the RS and AS,  U=
MA uses a different mechanism that describes finer grained operations.
> The AS may include roles, user, or other more abstract claims that the th=
e client may (god help them) pass on to EXCML for processing.
>
> While having a scopes claim is possible, like any other claim it is not p=
art of the JWT core security processing claims, and needs to be defined by =
extension.
>
> John B.
> On 2013-02-28, at 2:29 AM, Hannes Tschofenig > wrote:
>
>> Hi Mike,
>>
>> when I worked on the MAC specification I noticed that the JWT does not h=
ave a claim for the scope. I believe that this would be needed to allow the=
 resource server to verify whether the scope the authorization server autho=
rized is indeed what the client is asking for.
>>
>> 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

--_000_59E470B10C4630419ED717AC79FCF9A948D58AFABY2PRD0411MB441_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Adding my 2 cents …

I am looking to use JWT as =
the structure for my access tokens, and will likely profile it to look just=
 like an id_token, plus the scope claim which triggered
 this thread :-)

I am also looking at JWT as=
 a grant type.

I am also looking into fede=
rating my access tokens (one of the main reasons I am looking to use JWT as=
 the structure for the AT). 

All is subject to change, b=
ut that is where my head is today. 

adam

From: oauth-bo=
unces@ietf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of John Bradley

Sent: Thursday, February 28, 2013 11:34 AM

To: Phil Hunt

Cc: "WG <oauth@ietf.org>"@il06exr02.mot.com

Subject: Re: [OAUTH-WG] JWT - scope claim missing<=
/p>

Yes IETF WG politics:)

Should JWT and JOSE  be together ?  Throug=
h a number of twists and turns they are not, lets not go there.<=
/p>

But to the point a number of us have made JWT is use=
d in OAuth for more than access tokens.  

Currently it's only use in OAuth is in the JWT asser=
tions profile that has nothing to do with access tokens.

John B.

On 2013-02-28, at 9:27 AM, Phil Hunt <phil.hunt@oracle.com> wrote:=

Am I missing something. JWT is firstly an oauth spec=
. Otherwise why isnt it in jose wg?

Phil

Sent from my phone.

On 2013-02-28, at 8:44, Brian Campbell <bcampbell@pingidentity.com> wrote:

I think John's point =
was more that scope is something rather specific to an OAuth access token a=
nd, while JWT is can be used to represent an access token, it's not the onl=
y application of JWT. The 'standard'
 claims in JWT are those that are believed (right or wrong) to be widely ap=
plicable across different applications of JWT. One could argue about it but=
 scope is probably not one of those.

It would probably make sense to try and build a prof=
ile of JWT specifically for OAuth access tokens (though I suspect there are=
 some turtles and dragons in there), which might be the appropriate place t=
o define/register a scope claim.

On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

Are you advocating TWO systems? That seems like a ba=
d choice.

I would rather fix scope than go to a two system approach.

Phil

Sent from my phone.

On 2013-02-28, at 8:17, John Bradley <ve7jtb@ve7jtb.com> wrote:

> While scope is one method that a AS could communicate authorization to=
 a RS, it is not the only or perhaps even the most likely one.

> Using scope requires a relatively tight binding between the RS and AS,=
  UMA uses a different mechanism that describes finer grained operatio=
ns.

> The AS may include roles, user, or other more abstract claims that the=
 the client may (god help them) pass on to EXCML for processing.

>

> While having a scopes claim is possible, like any other claim it is no=
t part of the JWT core security processing claims, and needs to be defined =
by extension.

>

> John B.

> On 2013-02-28, at 2:29 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

>

>> Hi Mike,

>>

>> when I worked on the MAC specification I noticed that the JWT does=
 not have a claim for the scope. I believe that this would be needed to all=
ow the resource server to verify whether the scope the authorization server=
 authorized is indeed what the client
 is asking for.

>>

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

h=
ttps://www.ietf.org/mailman/listinfo/oauth

--_000_59E470B10C4630419ED717AC79FCF9A948D58AFABY2PRD0411MB441_--

From sberyozkin@gmail.com  Thu Feb 28 10:02:33 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7411821F8B70 for ; Thu, 28 Feb 2013 10:02:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.566
X-Spam-Level: 
X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5VI1ftTQo0f for ; Thu, 28 Feb 2013 10:02:32 -0800 (PST)
Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9FF21F8B4A for ; Thu, 28 Feb 2013 10:02:31 -0800 (PST)
Received: by mail-ee0-f41.google.com with SMTP id c13so1786462eek.0 for ; Thu, 28 Feb 2013 10:02:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Si6VoxlVpVxtN9XT9DI9HhAA5c+aOz8Jf9sALTnyU3U=; b=psuczaLlg/woguY0VUoArA5f2cydRTzaSPIHF811ka+xvTdBaX0oNSp91VMgVyux6b JWYXHS4FWsdRZ7S2oRh+zIZs+n94E7jvhUyYdYrdyAh+cq/AeFpsOHqTJF9Cb/dUIxYN WtlpP1j1nmKuCZlCddzUqSkqy8x5COQ9ZfGLPzwJh7wU2Gv6JiXrBc4DyXwdW+vZdDbC 1QO2L6q6IAlDdMYYZm4HQIuYmB7fpVZxToxz8ZAwsYQLvu1FHLtrBXvKRREiNzSOwGyw v01tgK4uUpEUjjl84oa3f8orrp+ONHQxYW3YLRgShrvhlMO6NIvM9pdVeIZmWpMZC2wT ai7w==
X-Received: by 10.14.207.73 with SMTP id m49mr19169646eeo.24.1362074551011; Thu, 28 Feb 2013 10:02:31 -0800 (PST)
Received: from [192.168.2.5] ([79.97.76.201]) by mx.google.com with ESMTPS id r4sm13047644eeo.12.2013.02.28.10.02.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Feb 2013 10:02:29 -0800 (PST)
Message-ID: <512F9BB3.2010201@gmail.com>
Date: Thu, 28 Feb 2013 18:02:27 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: William Mills 
References: <20130225124642.7425.65145.idtracker@ietfa.amsl.com> <1361956373.9883.YahooMailNeo@web31807.mail.mud.yahoo.com> <21030204-8EA7-4FB0-9DD3-2B6C8CA57E02@gmx.net> <1362057295.36069.YahooMailNeo@web31809.mail.mud.yahoo.com> <512F8E1D.2060408@gmail.com> <1362073743.15800.YahooMailNeo@web31802.mail.mud.yahoo.com>
In-Reply-To: <1362073743.15800.YahooMailNeo@web31802.mail.mud.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 18:02:33 -0000

On 28/02/13 17:49, William Mills wrote:
> The JWT replaces the oauth_token data element in the old MAC stuff. I
> just want to take all the other oauth_* variables and stuff them in a
> separate JSON object and completely kill the "fun with sorting
> variables" when the oauth_* things can be carried in the query string or
> header or post body.
As far as the client accessing RS is concerned, should it be limited to 
using a header, same as for other OAuth2 tokens ?

Cheers, Sergey

>
> ------------------------------------------------------------------------
> *From:* Sergey Beryozkin 
> *To:* oauth@ietf.org
> *Sent:* Thursday, February 28, 2013 9:04 AM
> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
>
> Hi
> On 28/02/13 13:14, William Mills wrote:
>  > I'm actually advocating that we change MAC to be a JWT extension.
> IMHO, having a simpler option, plus, going forward, a possible JWT
> profile (client to RS path) would work better -
>
> Why would JWT completely take over ? May be it should be possible indeed
> to have it as a JWT extension - should it be part of the relevant JWT
> assertion spec, where JWT is used as a possible grant ?
>
> Thanks, Sergey
>  >
>  > ------------------------------------------------------------------------
>  > *From:* Hannes Tschofenig  >
>  > *To:* William Mills  >
>  > *Cc:* Hannes Tschofenig  >; "oauth@ietf.org
> "
>  > >
>  > *Sent:* Thursday, February 28, 2013 2:28 AM
>  > *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
>  >
>  > Hi Bill,
>  >
>  > I believe you are misreading the document. In
>  > draft-ietf-oauth-v2-http-mac the client still uses the MAC when it
>  > accesses a protected resource.
>  > The only place where the JWT comes into the picture is with the
>  > description of the access token. This matters from a key distribution
>  > point of view. The session key for the MAC is included in the encrypted
>  > JWT. The JWT is encrypted by the authorization server and decrypted by
>  > the resource server.
>  >
>  > Information about how header fields get included in the MAC is described
>  > in Section 5.
>  >
>  > The nonce isn't killed it is just called differently: seq-nr. The stuff
>  > in the original MAC specification actually wasn't a nonce (from the
>  > semantic point of view).
>  > The extension parameter is there implicitly by allowing additional
>  > header fields to be included in the MAC computation.
>  >
>  > I need to look at the port number field again.
>  >
>  > Ciao
>  > Hannes
>  >
>  > On Feb 27, 2013, at 11:12 AM, William Mills wrote:
>  >
>  > > Just read the draft quickly.
>  > >
>  > > Since we're now leaning on JWT do we need to include the token in
>  > this? Why not just make an additional "Envelope MAC" thing and have the
>  > signature include the 3 JWT parts in the signature base string? That
>  > object then just becomes a JSON container for the kid, timestamp,
>  > signature method, signature etc. That thing then is a 4th base64 encoded
>  > JSON thing in the auth header.
>  > >
>  > > How header fields get included in the signature needs definition.
>  > >
>  > > Why did you kill the port number, nonce, and extension parameter out
>  > of the signature base string?
>  > >
>  > > The BNF appears to have no separators between values.
>  > >
>  > > -bill
>  > >
>  > >
>  > > From: "internet-drafts@ietf.org 
> >"
>  > 
> >>
>  > > To: i-d-announce@ietf.org 
> >
>  > > Cc: oauth@ietf.org   >
>  > > Sent: Monday, February 25, 2013 4:46 AM
>  > > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
>  > >
>  > >
>  > > A New Internet-Draft is available from the on-line Internet-Drafts
>  > directories.
>  > > This draft is a work item of the Web Authorization Protocol Working
>  > Group of the IETF.
>  > >
>  > > Title : OAuth 2.0 Message Authentication Code (MAC) Tokens
>  > > Author(s) : Justin Richer
>  > > William Mills
>  > > Hannes Tschofenig
>  > > Filename : draft-ietf-oauth-v2-http-mac-03.txt
>  > > Pages : 26
>  > > Date : 2013-02-25
>  > >
>  > > Abstract:
>  > > This specification describes how to use MAC Tokens in HTTP requests
>  > > to access OAuth 2.0 protected resources. An OAuth client willing to
>  > > access a protected resource needs to demonstrate possession of a
>  > > crytographic key by using it with a keyed message digest function to
>  > > the request.
>  > >
>  > > The document also defines a key distribution protocol for obtaining a
>  > > fresh session key.
>  > >
>  > >
>  > > The IETF datatracker status page for this draft is:
>  > > https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac
>  > >
>  > > There's also a htmlized version available at:
>  > > http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03
>  > >
>  > > A diff from the previous version is available at:
>  > > http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-http-mac-03
>  > >
>  > >
>  > > Internet-Drafts are also available by anonymous FTP at:
>  > > ftp://ftp.ietf.org/internet-drafts/
>  > >
>  > > _______________________________________________
>  > > 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
>
>

From wmills_92105@yahoo.com  Thu Feb 28 10:06:07 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB37F21F8B1E for ; Thu, 28 Feb 2013 10:06:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.361
X-Spam-Level: 
X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=0.237,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDvECQZ8wOwk for ; Thu, 28 Feb 2013 10:06:06 -0800 (PST)
Received: from nm32-vm2.bullet.mail.bf1.yahoo.com (nm32-vm2.bullet.mail.bf1.yahoo.com [72.30.239.138]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD5821F8A5F for ; Thu, 28 Feb 2013 10:06:05 -0800 (PST)
Received: from [98.139.212.144] by nm32.bullet.mail.bf1.yahoo.com with NNFMP; 28 Feb 2013 18:06:05 -0000
Received: from [98.139.212.232] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 28 Feb 2013 18:06:05 -0000
Received: from [127.0.0.1] by omp1041.mail.bf1.yahoo.com with NNFMP; 28 Feb 2013 18:06:05 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 487990.29584.bm@omp1041.mail.bf1.yahoo.com
Received: (qmail 43209 invoked by uid 60001); 28 Feb 2013 18:06:04 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1362074764; bh=mCXNd9Vh7jT11daU1+veM5odseX6Jfo4kulsfIRlZTw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=BsPbxej8KsezKpyYEDd9e6GDVeWvLL8MzbgV7+0RfH7y3A6SED6hcQw2DNE9BLFhBEUBx//frY3J/atOBNqbNVaQ7PQ1CEQQZFBEqfn+p3z7JFZvsqK0hn74yB/IOHBmCwXP1umEul/hdXKRJK5R/ypRmHTbDrLWuZyiBkmHDYs=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=PrnTCaTCUGc3PKEtpGBK6lcP8c5sPs0UDb9J+kcvn0fbyuv095xgFbDHV60wFhqUHPtaXLkouh6dBGO7lD+NRP701SNOeaz6T+ZnDWfj6VrqrWe35g0CY4DWuhn+D9gk2xU58rg7oCLFZYQUet+R2Zsj2yA2Lb6mkJTsqKXV64U=;
X-YMail-OSG: zUdjpcMVM1nVVZvq3rx23yZAJw7oLQBsYG9HHtGq73W2i4s 9T_y1QXRgaGNtp1UM3MnYfI9xriNtgZ3GfHRlzevzHiQNLkIhrp4AqC8ZvPj fu5A9YxsC8t0.OO.G5uj1cI9720_3.m6YfDNOxcMup8qmxsygjpvjlK3nYcr 9GwWlPJ1Xh53wnevzv2Xze35TFSbQOlPhNvFoStBL4GF_.iYJOmr9m5hhdq3 Z3zzlQo0OrWTpe61JGWkHCz5L0qBTZn60ojLQ1YDxbFo2uheOPdIhGX7RxBZ HjG_RcVLG9hLudPUVksWLENB2vRSFRXmRZbbwhmt_f3JRXTXMhiYyOmh2FxN lvd_qi8SjBDscx83Sys6BO9n65B5upxFX247PGNqWNi1bQhjSvfBnlRi8KRY Q6qpem_nn0J1mhMcoxs9U1WorSqzi1N_pG24PKc4sSFUHA4k816sxQSRU3vw cimBpEYZ2fg3RcwZzOouK0PxEhIkrpVpKqXTQFchALwV4E8ibAch08s3wOcy Mejyq_oE0dXZcJkEUwYsaP5jqIFhVcgQ4Bo4wNfIRZDk-
Received: from [209.131.62.115] by web31806.mail.mud.yahoo.com via HTTP; Thu, 28 Feb 2013 10:06:04 PST
X-Rocket-MIMEInfo: 001.001, SSBjZXJ0YWlubHkgaG9wZSBzby4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRnJvbTogU2VyZ2V5IEJlcnlvemtpbiA8c2JlcnlvemtpbkBnbWFpbC5jb20.ClRvOiBXaWxsaWFtIE1pbGxzIDx3bWlsbHNfOTIxMDVAeWFob28uY29tPiAKQ2M6ICJvYXV0aEBpZXRmLm9yZyIgPG9hdXRoQGlldGYub3JnPiAKU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDI4LCAyMDEzIDEwOjAyIEFNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtb2F1dGgtdjItaHR0cC0BMAEBAQE-
X-Mailer: YahooMailWebService/0.8.135.514
References: <20130225124642.7425.65145.idtracker@ietfa.amsl.com> <1361956373.9883.YahooMailNeo@web31807.mail.mud.yahoo.com> <21030204-8EA7-4FB0-9DD3-2B6C8CA57E02@gmx.net> <1362057295.36069.YahooMailNeo@web31809.mail.mud.yahoo.com> <512F8E1D.2060408@gmail.com> <1362073743.15800.YahooMailNeo@web31802.mail.mud.yahoo.com> <512F9BB3.2010201@gmail.com>
Message-ID: <1362074764.35520.YahooMailNeo@web31806.mail.mud.yahoo.com>
Date: Thu, 28 Feb 2013 10:06:04 -0800 (PST)
From: William Mills 
To: Sergey Beryozkin 
In-Reply-To: <512F9BB3.2010201@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-1055047407-710131732-1362074764=:35520"
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 18:06:07 -0000

---1055047407-710131732-1362074764=:35520
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I certainly hope so.=0A=0A=0A________________________________=0A From: Serg=
ey Beryozkin =0ATo: William Mills  =0ACc: "oauth@ietf.org"  =0ASent: Thursday, February =
28, 2013 10:02 AM=0ASubject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2=
-http-mac-03.txt=0A =0AOn 28/02/13 17:49, William Mills wrote:=0A> The JWT =
replaces the oauth_token data element in the old MAC stuff. I=0A> just want=
 to take all the other oauth_* variables and stuff them in a=0A> separate J=
SON object and completely kill the "fun with sorting=0A> variables" when th=
e oauth_* things can be carried in the query string or=0A> header or post b=
ody.=0AAs far as the client accessing RS is concerned, should it be limited=
 to =0Ausing a header, same as for other OAuth2 tokens ?=0A=0ACheers, Serge=
y=0A=0A>=0A> --------------------------------------------------------------=
----------=0A> *From:* Sergey Beryozkin =0A> *To:* oa=
uth@ietf.org=0A> *Sent:* Thursday, February 28, 2013 9:04 AM=0A> *Subject:*=
 Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt=0A>=0A> Hi=
=0A> On 28/02/13 13:14, William Mills wrote:=0A>=A0 > I'm actually advocati=
ng that we change MAC to be a JWT extension.=0A> IMHO, having a simpler opt=
ion, plus, going forward, a possible JWT=0A> profile (client to RS path) wo=
uld work better -=0A>=0A> Why would JWT completely take over ? May be it sh=
ould be possible indeed=0A> to have it as a JWT extension - should it be pa=
rt of the relevant JWT=0A> assertion spec, where JWT is used as a possible =
grant ?=0A>=0A> Thanks, Sergey=0A>=A0 >=0A>=A0 > --------------------------=
----------------------------------------------=0A>=A0 > *From:* Hannes Tsch=
ofenig  >=
=0A>=A0 > *To:* William Mills  >=0A>=A0 > *Cc:* Hannes Tschofenig  >; "oauth@ietf.org=0A> "=0A>=A0 > >=0A>=A0 > *Sen=
t:* Thursday, February 28, 2013 2:28 AM=0A>=A0 > *Subject:* Re: [OAUTH-WG] =
I-D Action: draft-ietf-oauth-v2-http-mac-03.txt=0A>=A0 >=0A>=A0 > Hi Bill,=
=0A>=A0 >=0A>=A0 > I believe you are misreading the document. In=0A>=A0 > d=
raft-ietf-oauth-v2-http-mac the client still uses the MAC when it=0A>=A0 > =
accesses a protected resource.=0A>=A0 > The only place where the JWT comes =
into the picture is with the=0A>=A0 > description of the access token. This=
 matters from a key distribution=0A>=A0 > point of view. The session key fo=
r the MAC is included in the encrypted=0A>=A0 > JWT. The JWT is encrypted b=
y the authorization server and decrypted by=0A>=A0 > the resource server.=
=0A>=A0 >=0A>=A0 > Information about how header fields get included in the =
MAC is described=0A>=A0 > in Section 5.=0A>=A0 >=0A>=A0 > The nonce isn't k=
illed it is just called differently: seq-nr. The stuff=0A>=A0 > in the orig=
inal MAC specification actually wasn't a nonce (from the=0A>=A0 > semantic =
point of view).=0A>=A0 > The extension parameter is there implicitly by all=
owing additional=0A>=A0 > header fields to be included in the MAC computati=
on.=0A>=A0 >=0A>=A0 > I need to look at the port number field again.=0A>=A0=
 >=0A>=A0 > Ciao=0A>=A0 > Hannes=0A>=A0 >=0A>=A0 > On Feb 27, 2013, at 11:1=
2 AM, William Mills wrote:=0A>=A0 >=0A>=A0 > > Just read the draft quickly.=
=0A>=A0 > >=0A>=A0 > > Since we're now leaning on JWT do we need to include=
 the token in=0A>=A0 > this? Why not just make an additional "Envelope MAC"=
 thing and have the=0A>=A0 > signature include the 3 JWT parts in the signa=
ture base string? That=0A>=A0 > object then just becomes a JSON container f=
or the kid, timestamp,=0A>=A0 > signature method, signature etc. That thing=
 then is a 4th base64 encoded=0A>=A0 > JSON thing in the auth header.=0A>=
=A0 > >=0A>=A0 > > How header fields get included in the signature needs de=
finition.=0A>=A0 > >=0A>=A0 > > Why did you kill the port number, nonce, an=
d extension parameter out=0A>=A0 > of the signature base string?=0A>=A0 > >=
=0A>=A0 > > The BNF appears to have no separators between values.=0A>=A0 > =
>=0A>=A0 > > -bill=0A>=A0 > >=0A>=A0 > >=0A>=A0 > > From: "internet-drafts@=
ietf.org =0A> >"=0A>=A0 > =0A> >>=0A>=A0 > > To: i-d-announce@ietf.org =0A> >=0A>=A0 > > Cc: oauth@ietf.org   >=0A>=A0 > > Sent: Monday, Fe=
bruary 25, 2013 4:46 AM=0A>=A0 > > Subject: [OAUTH-WG] I-D Action: draft-ie=
tf-oauth-v2-http-mac-03.txt=0A>=A0 > >=0A>=A0 > >=0A>=A0 > > A New Internet=
-Draft is available from the on-line Internet-Drafts=0A>=A0 > directories.=
=0A>=A0 > > This draft is a work item of the Web Authorization Protocol Wor=
king=0A>=A0 > Group of the IETF.=0A>=A0 > >=0A>=A0 > > Title : OAuth 2.0 Me=
ssage Authentication Code (MAC) Tokens=0A>=A0 > > Author(s) : Justin Richer=
=0A>=A0 > > William Mills=0A>=A0 > > Hannes Tschofenig=0A>=A0 > > Filename =
: draft-ietf-oauth-v2-http-mac-03.txt=0A>=A0 > > Pages : 26=0A>=A0 > > Date=
 : 2013-02-25=0A>=A0 > >=0A>=A0 > > Abstract:=0A>=A0 > > This specification=
 describes how to use MAC Tokens in HTTP requests=0A>=A0 > > to access OAut=
h 2.0 protected resources. An OAuth client willing to=0A>=A0 > > access a p=
rotected resource needs to demonstrate possession of a=0A>=A0 > > crytograp=
hic key by using it with a keyed message digest function to=0A>=A0 > > the =
request.=0A>=A0 > >=0A>=A0 > > The document also defines a key distribution=
 protocol for obtaining a=0A>=A0 > > fresh session key.=0A>=A0 > >=0A>=A0 >=
 >=0A>=A0 > > The IETF datatracker status page for this draft is:=0A>=A0 > =
> https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac=0A>=A0 > >=
=0A>=A0 > > There's also a htmlized version available at:=0A>=A0 > > http:/=
/tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03=0A>=A0 > >=0A>=A0 > > =
A diff from the previous version is available at:=0A>=A0 > > http://www.iet=
f.org/rfcdiff?url2=3Ddraft-ietf-oauth-v2-http-mac-03=0A>=A0 > >=0A>=A0 > >=
=0A>=A0 > > Internet-Drafts are also available by anonymous FTP at:=0A>=A0 =
> > ftp://ftp.ietf.org/internet-drafts/=0A>=A0 > >=0A>=A0 > > _____________=
__________________________________=0A>=A0 > > OAuth mailing list=0A>=A0 > >=
 OAuth@ietf.org   >=0A>=A0 > > https://www.ietf.org/mailman/listinfo/oauth=0A>=
=A0 > >=0A>=A0 > >=0A>=A0 >=0A>=A0 >=0A>=A0 >=0A>=A0 >=0A>=A0 >=0A>=A0 > __=
_____________________________________________=0A>=A0 > OAuth mailing list=
=0A>=A0 > OAuth@ietf.org =0A>=A0 > https://www.ietf.=
org/mailman/listinfo/oauth=0A>=0A>=0A> ____________________________________=
___________=0A> OAuth mailing list=0A> OAuth@ietf.org =0A> https://www.ietf.org/mailman/listinfo/oauth=0A>=0A>
---1055047407-710131732-1362074764=:35520
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I certainly hope so.

  From: Sergey Be=
ryozkin <sberyozkin@gmail.com>
 To: William Mills <wmills_92105@yahoo.com> 
Cc: "oauth@ietf.org" <oauth@ie=
tf.org> 
 Sent: Thur=
sday, February 28, 2013 10:02 AM
 =
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac=
-03.txt

=0AOn 28/02/13 17:49, William Mills wrote:
> The =
JWT replaces the oauth_token data element in the old MAC stuff. I
> j=
ust want to take all the other oauth_* variables and stuff them in a
>=
; separate JSON object and completely kill the "fun with sorting
> va=
riables" when the oauth_* things can be carried in the query string or
&=
gt; header or post body.
As far as the client accessing RS is concerned,=
 should it be limited to 
using a header, same as for other OAuth2 token=
s ?

Cheers, Sergey

>
> -----------------------------=
-------------------------------------------
> *From:* Sergey Beryozki=
n <sberyozkin@gmail.com>
> *To:* oauth@ietf.org
> *=
Sent:* Thursday, February 28, 2013 9:04 AM
> *Subject:* Re: [OAUTH-WG=
] I-D Action:
 draft-ietf-oauth-v2-http-mac-03.txt
>
> Hi
> On 28/02/13=
 13:14, William Mills wrote:
>  > I'm actually advocating tha=
t we change MAC to be a JWT extension.
> IMHO, having a simpler optio=
n, plus, going forward, a possible JWT
> profile (client to RS path) =
would work better -
>
> Why would JWT completely take over ? Ma=
y be it should be possible indeed
> to have it as a JWT extension - s=
hould it be part of the relevant JWT
> assertion spec, where JWT is u=
sed as a possible grant ?
>
> Thanks, Sergey
>  >=

>  > -------------------------------------------------------=
-----------------
>  > *From:* Hannes Tschofenig <hannes.tschofenig@gmx.net
> <mailto:hannes.tschofenig@gmx.net>=
;>
>  > *To:* William Mills <wmills_92105@yaho=
o.com
> <mailto:wmills_92105@yahoo.com>>>  > *Cc:* Hannes Tschofenig <hannes.tschofen=
ig@gmx.net
> <mailto:hannes.tschofenig@gmx.net<=
/a>>>; "oauth@ietf.org
> <mailto:oauth@ietf.org>"
> =
 > <oauth@ietf.org
 <mailto:oauth@ietf.org>>
>  > *Sent:* Thursday, Februa=
ry 28, 2013 2:28 AM
>  > *Subject:* Re: [OAUTH-WG] I-D Action=
: draft-ietf-oauth-v2-http-mac-03.txt
>  >
>  >=
 Hi Bill,
>  >
>  > I believe you are misreadin=
g the document. In
>  > draft-ietf-oauth-v2-http-mac the clie=
nt still uses the MAC when it
>  > accesses a protected resou=
rce.
>  > The only place where the JWT comes into the picture=
 is with the
>  > description of the access token. This matte=
rs from a key distribution
>  > point of view. The session ke=
y for the MAC is included in the encrypted
>  > JWT. The JWT =
is encrypted by the authorization server and decrypted by
>  >=
; the resource server.
>  >
>  > Information
 about how header fields get included in the MAC is described
> =
 > in Section 5.
>  >
>  > The nonce isn't k=
illed it is just called differently: seq-nr. The stuff
>  > i=
n the original MAC specification actually wasn't a nonce (from the
>&=
nbsp; > semantic point of view).
>  > The extension parame=
ter is there implicitly by allowing additional
>  > header fi=
elds to be included in the MAC computation.
>  >
> =
; > I need to look at the port number field again.
>  >>  > Ciao
>  > Hannes
>  >
>&=
nbsp; > On Feb 27, 2013, at 11:12 AM, William Mills wrote:
> =
 >
>  > > Just read the draft quickly.
>  &g=
t; >
>  > > Since we're now leaning on JWT do we need t=
o include the token in
>  > this? Why not just make an
 additional "Envelope MAC" thing and have the
>  > signature =
include the 3 JWT parts in the signature base string? That
>  &g=
t; object then just becomes a JSON container for the kid, timestamp,
>=
;  > signature method, signature etc. That thing then is a 4th base=
64 encoded
>  > JSON thing in the auth header.
>  =
> >
>  > > How header fields get included in the sig=
nature needs definition.
>  > >
>  > > Wh=
y did you kill the port number, nonce, and extension parameter out
>&=
nbsp; > of the signature base string?
>  > >
>&nb=
sp; > > The BNF appears to have no separators between values.
>=
  > >
>  > > -bill
>  > >
&=
gt;  > >
>  > > From: "internet-drafts@ietf.org <=
mailto:internet-drafts@ietf.org>
> <mailto:internet-drafts@ietf.org <mailto:internet-dra=
fts@ietf.org>>"
>  > <internet-draf=
ts@ietf.org <mailto:internet-drafts@ietf.org>> <mailto:internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>&=
gt;>
>  > > To: i-d-announce@ietf.org <ma=
ilto:i-d-announce@ietf.org>
> <mailto:i-d-ann=
ounce@ietf.org <mailto:i-d-announce@ietf.org>>
&=
gt;  > > Cc: oauth@ietf.org <mailto:oauth@ietf.org> <mailto:<=
a ymailto=3D"mailto:oauth@ietf.org" href=3D"mailto:oauth@ietf.org">oauth@ie=
tf.org
> <mailto:oauth@ietf.org>>
>  &g=
t; > Sent: Monday, February 25, 2013 4:46 AM
>  > > Sub=
ject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
>&nb=
sp; > >
>  > >
>  > > A New Interne=
t-Draft is available from the on-line Internet-Drafts
>  > di=
rectories.
>  > > This draft is a work item of the Web Aut=
horization Protocol Working
>  > Group of the IETF.
>&n=
bsp; > >
>  > > Title : OAuth 2.0 Message Authentica=
tion Code (MAC) Tokens
>  > > Author(s) : Justin Richer>  > > William Mills
>  > > Hannes Tschofen=
ig
>  > > Filename : draft-ietf-oauth-v2-http-mac-03.txt>  > > Pages : 26
>  > > Date : 2013-02-25=

>  > >
>  > >
 Abstract:
>  > > This specification describes how to use =
MAC Tokens in HTTP requests
>  > > to access OAuth 2.0 pro=
tected resources. An OAuth client willing to
>  > > access=
 a protected resource needs to demonstrate possession of a
>  &g=
t; > crytographic key by using it with a keyed message digest function t=
o
>  > > the request.
>  > >
> =
; > > The document also defines a key distribution protocol for obtai=
ning a
>  > > fresh session key.
>  > >>  > >
>  > > The IETF datatracker status =
page for this draft is:
>  > > https://da=
tatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac
>  > =
>
>  > > There's also a htmlized version available
 at:
>  > > http://tools.ietf.org/html/draft=
-ietf-oauth-v2-http-mac-03
>  > >
>  > &=
gt; A diff from the previous version is available at:
>  > &g=
t; http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oaut=
h-v2-http-mac-03
>  > >
>  > >
>=
;  > > Internet-Drafts are also available by anonymous FTP at:>  > > ftp://ftp.ietf.org/internet-drafts/
>  > &g=
t;
>  > > _______________________________________________<=
br>>  > > OAuth mailing list
>  > > OAuth@ietf.org<=
/a>
 <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org
> <mailto:OAuth@ietf.o=
rg>>
>  > > https://www.ietf.org/mailman/listinfo=
/oauth
>  > >
>  > >
>  &g=
t;
>  >
>  >
>  >
>  &=
gt;
>  > _______________________________________________
&=
gt;  > OAuth mailing list
>  > OAuth@ietf.org <mailto=
:OAuth@=
ietf.org>
>  > https://www.ietf.org/mailman/listinfo/oauth
><=
br>>
> _______________________________________________
> OAu=
th mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https=
://www.ietf.org/mailman/listinfo/oauth
>
>

---1055047407-710131732-1362074764=:35520--

From phil.hunt@oracle.com  Thu Feb 28 10:12:39 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1846C21F8BCC for ; Thu, 28 Feb 2013 10:12:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.498
X-Spam-Level: 
X-Spam-Status: No, score=-5.498 tagged_above=-999 required=5 tests=[AWL=-0.296, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OEE9TaizjjJ for ; Thu, 28 Feb 2013 10:12:37 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id A584A21F8B9C for ; Thu, 28 Feb 2013 10:12:37 -0800 (PST)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1SICava027054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Feb 2013 18:12:37 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1SICZSR025681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2013 18:12:35 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1SICZMP005954; Thu, 28 Feb 2013 12:12:35 -0600
Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 28 Feb 2013 10:12:34 -0800
References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net>     <48FD87D1-4DF4-4289-99B7-40A515F31890@oracle.com> <3E472720-31A4-40A0-AAA4-402CF850831A@ve7jtb.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <3E472720-31A4-40A0-AAA4-402CF850831A@ve7jtb.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-A2BF8484-4D45-4678-87B3-7208DE2BEF12
Content-Transfer-Encoding: 7bit
Message-Id: <7127843B-D7B0-4AB6-87F1-1604D1EFFA79@oracle.com>
X-Mailer: iPhone Mail (10B146)
From: Phil Hunt 
Date: Thu, 28 Feb 2013 10:12:31 -0800
To: John Bradley 
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] JWT - scope claim missing
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 18:12:39 -0000

--Apple-Mail-A2BF8484-4D45-4678-87B3-7208DE2BEF12
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

Note the title says "for OAuth2"

Sorry. Couldn't resist.=20

Phil

Sent from my phone.

On 2013-02-28, at 9:40, John Bradley  wrote:

> JWT is an assertion( I am probably going to regret using that word).
>=20
> It is used in openID connect for id_tokens, it is used in OAuth for Assert=
ion grant types and authentication of the client to the token endpoint.
> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04
>=20
> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
>=20
> Dosen't define JWT's use for access tokens for the RS.  =20
>=20
> Bottom line JWT is for more than access tokens.
>=20
> John B.
>=20
> On 2013-02-28, at 9:28 AM, Phil Hunt  wrote:
>=20
>> Are you saying jwt is not an access token type?
>>=20
>> Phil
>>=20
>> Sent from my phone.
>>=20
>> On 2013-02-28, at 8:58, John Bradley  wrote:
>>=20
>>> Yes, defining scope in JWT is the wrong place.   JWT needs to stick to t=
he security claims needed to process JWT.
>>>=20
>>> I also don't know how far you get requiring a specific authorization for=
mat for JWT, some AS will wan to use a opaque reference, some might want to u=
se a user claim or role claim, others may use scopes,  combining scopes and c=
laims is also possible.
>>>=20
>>> Right now it is up to a AS RS pair to agree on how to communicate author=
ization.   I don't want MAC to be more restrictive than bearer when it comes=
 to authorization between AS and RS.
>>>=20
>>> Hannes wanted to know why JWT didn't define scope.  The simple answer is=
 that it is out of scope for JWT itself.   It might be defined in a OAuth ac=
cess token profile for JWT but it should not be specific to MAC.
>>>=20
>>> John B.
>>> On 2013-02-28, at 8:44 AM, Brian Campbell  w=
rote:
>>>=20
>>>> I think John's point was more that scope is something rather specific t=
o an OAuth access token and, while JWT is can be used to represent an access=
 token, it's not the only application of JWT. The 'standard' claims in JWT a=
re those that are believed (right or wrong) to be widely applicable across d=
ifferent applications of JWT. One could argue about it but scope is probably=
 not one of those.
>>>>=20
>>>> It would probably make sense to try and build a profile of JWT specific=
ally for OAuth access tokens (though I suspect there are some turtles and dr=
agons in there), which might be the appropriate place to define/register a s=
cope claim.
>>>>=20
>>>>=20
>>>> On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt  wrote=
:
>>>>> Are you advocating TWO systems? That seems like a bad choice.
>>>>>=20
>>>>> I would rather fix scope than go to a two system approach.
>>>>>=20
>>>>> Phil
>>>>>=20
>>>>> Sent from my phone.
>>>>>=20
>>>>> On 2013-02-28, at 8:17, John Bradley  wrote:
>>>>>=20
>>>>> > While scope is one method that a AS could communicate authorization t=
o a RS, it is not the only or perhaps even the most likely one.
>>>>> > Using scope requires a relatively tight binding between the RS and A=
S,  UMA uses a different mechanism that describes finer grained operations.
>>>>> > The AS may include roles, user, or other more abstract claims that t=
he the client may (god help them) pass on to EXCML for processing.
>>>>> >
>>>>> > While having a scopes claim is possible, like any other claim it is n=
ot part of the JWT core security processing claims, and needs to be defined b=
y extension.
>>>>> >
>>>>> > John B.
>>>>> > On 2013-02-28, at 2:29 AM, Hannes Tschofenig  wrote:
>>>>> >
>>>>> >> Hi Mike,
>>>>> >>
>>>>> >> when I worked on the MAC specification I noticed that the JWT does n=
ot have a claim for the scope. I believe that this would be needed to allow t=
he resource server to verify whether the scope the authorization server auth=
orized is indeed what the client is asking for.
>>>>> >>
>>>>> >> 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
>=20

--Apple-Mail-A2BF8484-4D45-4678-87B3-7208DE2BEF12
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

  =
      JSON Web Token (JWT) Bearer Token Profiles for OA=
uth 2.0

Note the title says "for OAuth2"

Sorry. Couldn't resist. 

Phil
Sent from my phone.

On 2013-02-28, at 9:40, John Bradley <ve7jtb@ve7jtb.com> wrote:

JWT is an assert=
ion( I am probably going to regret using that word).
It i=
s used in openID connect for id_tokens, it is used in OAuth for Assertion gr=
ant types and authentication of the client to the token endpoint.
=
http:/=
/tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04

=
JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

Dosen't define JWT's use for access tokens for=
 the RS.   

Bottom line JWT is for more t=
han access tokens.

John B.

On 2013-02-28, at 9:28 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

Are you saying j=
wt is not an access token type?

Phil
Sent from my p=
hone.

On 2013-02-28, at 8:58, John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes, defining scope in JWT is the wrong place.  =
; JWT needs to stick to the security claims needed to process JWT.
<=
/div>I also don't know how far you get requiring a specific authorizati=
on format for JWT, some AS will wan to use a opaque reference, some might wa=
nt to use a user claim or role claim, others may use scopes,  combining=
 scopes and claims is also possible.

Right now it i=
s up to a AS RS pair to agree on how to communicate authorization.   I d=
on't want MAC to be more restrictive than bearer when it comes to authorizat=
ion between AS and RS.

Hannes wanted to know why JWT d=
idn't define scope.  The simple answer is that it is out of scope for J=
WT itself.   It might be defined in a OAuth access token profile for JW=
T but it should not be specific to MAC.

John B.On 2013-02-28, at 8:44 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
I think John's point was more that scope is something rather=
 specific to an OAuth access token and, while JWT is can be used to represen=
t an access token, it's not the only application of JWT. The 'standard' clai=
ms in JWT are those that are believed (right or wrong) to be widely applicab=
le across different applications of JWT. One could argue about it but scope i=
s probably not one of those.

It would probably make sense to try and build a profile of JWT spe=
cifically for OAuth access tokens (though I suspect there are some turtles a=
nd dragons in there), which might be the appropriate place to define/registe=
r a scope claim.

On Thu, =
Feb 28, 2013 at 9:24 AM, Phil Hunt <phil.hunt@oracle.com> w=
rote:

Are you advocating TWO systems? That seems lik=
e a bad choice.

I would rather fix scope than go to a two system approach.

Phil

Sent from my phone.

On 2013-02-28, at 8:17, John Bradley <ve7jtb@ve7jtb.com> wrote:

> While scope is one method that a AS could communicate authorization to a=
 RS, it is not the only or perhaps even the most likely one.

> Using scope requires a relatively tight binding between the RS and AS, &=
nbsp;UMA uses a different mechanism that describes finer grained operations.=

> The AS may include roles, user, or other more abstract claims that the t=
he client may (god help them) pass on to EXCML for processing.

>

> While having a scopes claim is possible, like any other claim it is not=
 part of the JWT core security processing claims, and needs to be defined by=
 extension.

>

> John B.

> On 2013-02-28, at 2:29 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

>

>> Hi Mike,

>>

>> when I worked on the MAC specification I noticed that the JWT does n=
ot have a claim for the scope. I believe that this would be needed to allow t=
he resource server to verify whether the scope the authorization server auth=
orized is indeed what the client is asking for.

>>

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

ht=
tps://www.ietf.org/mailman/listinfo/oauth

=

--Apple-Mail-A2BF8484-4D45-4678-87B3-7208DE2BEF12--

From phil.hunt@oracle.com  Thu Feb 28 10:16:06 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FF821F8B7D for ; Thu, 28 Feb 2013 10:16:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.482
X-Spam-Level: 
X-Spam-Status: No, score=-5.482 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kHDRlaT5lRK for ; Thu, 28 Feb 2013 10:16:05 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0251C21F897F for ; Thu, 28 Feb 2013 10:16:04 -0800 (PST)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1SIG3kD008924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Feb 2013 18:16:04 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1SIG3jO028333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2013 18:16:03 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1SIG2At025573; Thu, 28 Feb 2013 12:16:02 -0600
Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 28 Feb 2013 10:16:02 -0800
References: <20130225124642.7425.65145.idtracker@ietfa.amsl.com> <1361956373.9883.YahooMailNeo@web31807.mail.mud.yahoo.com> <21030204-8EA7-4FB0-9DD3-2B6C8CA57E02@gmx.net> <1362057295.36069.YahooMailNeo@web31809.mail.mud.yahoo.com> <512F8F1E.3020400@mitre.org> <1362073422.89847.YahooMailNeo@web31810.mail.mud.yahoo.com> <512F98B4.3070303@mitre.org>
Mime-Version: 1.0 (1.0)
In-Reply-To: <512F98B4.3070303@mitre.org>
Content-Type: multipart/alternative; boundary=Apple-Mail-D62079BB-A0D4-4FFE-BB3A-1DA61342DD52
Content-Transfer-Encoding: 7bit
Message-Id: <455450D5-B54F-4DDE-9DEC-5681715336DB@oracle.com>
X-Mailer: iPhone Mail (10B146)
From: Phil Hunt 
Date: Thu, 28 Feb 2013 10:15:59 -0800
To: Justin Richer 
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 18:16:06 -0000

--Apple-Mail-D62079BB-A0D4-4FFE-BB3A-1DA61342DD52
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Yes. That is my understanding.=20

Phil

Sent from my phone.

On 2013-02-28, at 9:49, Justin Richer  wrote:

> OK, so it still runs the signature over HTTP elements (query, url, headers=
, etc) but all of the structured components are *communicated* via a JWT/JOS=
E structure. That makes sense to me, on the surface at least.
>=20
>  -- Justin
>=20
>=20
> On 02/28/2013 12:43 PM, William Mills wrote:
>> 1) AS issues JWT + secret to client.
>> 2) Client decides to access resource, creates the JWT MAC JSON object whi=
ch contains stuff about the signature and the signature itself.
>> 3) client appends that base64 encoded thing to the JWT
>>=20
>> 1) Server gets a JWTMAC token, takes apart the JWT part to get the signin=
g key
>> 2) Server looks at the JWTMAC to figure out what all it has to do to crea=
te the signature base string=20
>> 3) server constructs the SBS computes and checks the sig.
>>=20
>> The only hairy bit right now is an arbitrary HTTP header list that may be=
 included in the signature.
>>=20
>> No data in the JWTMAC is duplicated from anywhere else.
>>=20
>> From: Justin Richer 
>> To: William Mills =20
>> Cc: Hannes Tschofenig ; "oauth@ietf.org" =20
>> Sent: Thursday, February 28, 2013 9:08 AM
>> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
>>=20
>> What I don't quite get is what exactly would be presented and processed a=
t each step. Who needs to know what piece? We don't want to have to push eve=
rything into JSON for the signing to take place (that much is clear), and we=
 don't want the client to be pushing the MAC secret to the RS every time (th=
at would make it a lot less secret, after all). But if we can reuse JWT, JWS=
, and other JOSE mechanisms to make some parts of the MAC pattern easier for=
 programmers, I'm for it.
>>=20
>>  -- Justin
>>=20
>> On 02/28/2013 08:14 AM, William Mills wrote:
>>> I'm actually advocating that we change MAC to be a JWT extension.
>>>=20
>>> From: Hannes Tschofenig 
>>> To: William Mills =20
>>> Cc: Hannes Tschofenig ; "oauth@ietf.org" =20
>>> Sent: Thursday, February 28, 2013 2:28 AM
>>> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
>>>=20
>>> Hi Bill,=20
>>>=20
>>> I believe you are misreading the document. In draft-ietf-oauth-v2-http-m=
ac the client still uses the MAC when it accesses a protected resource.=20
>>> The only place where the JWT comes into the picture is with the descript=
ion of the access token. This matters from a key distribution point of view.=
 The session key for the MAC is included in the encrypted JWT. The JWT is en=
crypted by the authorization server and decrypted by the resource server.=20=

>>>=20
>>> Information about how header fields get included in the MAC is described=
 in Section 5.
>>>=20
>>> The nonce isn't killed it is just called differently: seq-nr. The stuff i=
n the original MAC specification actually wasn't a nonce (from the semantic p=
oint of view).=20
>>> The extension parameter is there implicitly by allowing additional heade=
r fields to be included in the MAC computation.
>>>=20
>>> I need to look at the port number field again.=20
>>>=20
>>> Ciao
>>> Hannes
>>>=20
>>> On Feb 27, 2013, at 11:12 AM, William Mills wrote:
>>>=20
>>> > Just read the draft quickly. =20
>>> >=20
>>> > Since we're now leaning on JWT do we need to include the token in this=
?  Why not just make an additional "Envelope MAC" thing and have the signatu=
re include the 3 JWT parts in the signature base string?  That object then j=
ust becomes a JSON container for the kid, timestamp, signature method, signa=
ture etc. That thing then is a 4th base64 encoded JSON thing in the auth hea=
der.
>>> >=20
>>> > How header fields get included in the signature needs definition.
>>> >=20
>>> > Why did you kill the port number, nonce, and extension parameter out o=
f the signature base string?
>>> >=20
>>> > The BNF appears to have no separators between values.
>>> >=20
>>> > -bill
>>> >=20
>>> >=20
>>> > From: "internet-drafts@ietf.org" 
>>> > To: i-d-announce@ietf.org                        =20
>>> > Cc: oauth@ietf.org=20
>>> > Sent: Monday, February 25, 2013 4:46 AM
>>> > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
>>> >=20
>>> >=20
>>> > A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.
>>> > This draft is a work item of the Web Authorization Protocol Working Gr=
oup of the IETF.
>>> >=20
>>> >    Title          : OAuth 2.0 Message Authentication Code (MAC) Tokens=

>>> >    Author(s)      : Justin Richer
>>> >                          William Mills
>>> >                          Hannes Tschofenig
>>> >    Filename        : draft-ietf-oauth-v2-http-mac-03.txt
>>> >    Pages          : 26
>>> >    Date            : 2013-02-25
>>> >=20
>>> > Abstract:
>>> >  This specification describes how to use MAC Tokens in HTTP requests
>>> >  to access OAuth 2.0 protected resources.  An OAuth client willing to
>>> >  access a protected resource needs to demonstrate possession of a
>>> >  crytographic key by using it with a keyed message digest function to
>>> >  the request.
>>> >=20
>>> >  The document also defines a key distribution protocol for obtaining a=

>>> >  fresh session key.
>>> >=20
>>> >=20
>>> > The IETF datatracker status page for this draft is:
>>> > https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac
>>> >=20
>>> > There's also a htmlized version available at:
>>> > http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03
>>> >=20
>>> > A diff from the previous version is available at:
>>> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-v2-http-mac-03
>>> >=20
>>> >=20
>>> > Internet-Drafts are also available by anonymous FTP at:
>>> > ftp://ftp.ietf.org/internet-drafts/
>>> >=20
>>> > _______________________________________________
>>> > OAuth mailing list
>>> > OAuth@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/oauth
>>> >=20
>>> >=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-D62079BB-A0D4-4FFE-BB3A-1DA61342DD52
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit

Yes. That is my understanding. 

Phil
Sent from my phone.

On 2013-02-28, at 9:49, Justin Richer <jricher@mitre.org> wrote:

    OK, so it still runs the signature over HTTP elements (query, url,
    headers, etc) but all of the structured components are
    *communicated* via a JWT/JOSE structure. That makes sense to me, on
    the surface at least.

     -- Justin

    On 02/28/2013 12:43 PM, William Mills
      wrote:

        1) AS issues JWT + secret to client.
        2)
            Client decides to access resource, creates the JWT MAC JSON
            object which contains stuff about the signature and the
            signature itself.
        3)
            client appends that base64 encoded thing to the JWT

        1) Server
          gets a JWTMAC token, takes apart the JWT part to get the
          signing key
        2) Server
          looks at the JWTMAC to figure out what all it has to do to
          create the signature base string 
        3) server
          constructs the SBS computes and checks the sig.

        The only
          hairy bit right now is an arbitrary HTTP header list that may
          be included in the signature.

        No data in
          the JWTMAC is duplicated from anywhere else.

 From:
                Justin Richer <jricher@mitre.org>

                To:
                William Mills <wmills_92105@yahoo.com> 

                Cc:
                Hannes Tschofenig <hannes.tschofenig@gmx.net>;
                "oauth@ietf.org" <oauth@ietf.org> 

                Sent:
                Thursday, February 28, 2013 9:08 AM

                Subject:
                Re: [OAUTH-WG] I-D Action:
                draft-ietf-oauth-v2-http-mac-03.txt

               What I don't quite get is what exactly would be
                presented and processed at each step. Who needs to know
                what piece? We don't want to have to push everything
                into JSON for the signing to take place (that much is
                clear), and we don't want the client to be pushing the
                MAC secret to the RS every time (that would make it a
                lot less secret, after all). But if we can reuse JWT,
                JWS, and other JOSE mechanisms to make some parts of the
                MAC pattern easier for programmers, I'm for it.

                 -- Justin

                On 02/28/2013
                  08:14 AM, William Mills wrote:

                    I'm actually advocating that we change
                        MAC to be a JWT extension.

 From:
                            Hannes Tschofenig <hannes.tschofenig@gmx.net>

                            To:
                            William Mills <wmills_92105@yahoo.com>

                            Cc:
                            Hannes Tschofenig <hannes.tschofenig@gmx.net>;
                            "oauth@ietf.org"
                            <oauth@ietf.org>

                            Sent:
                            Thursday, February 28, 2013 2:28 AM

                            Subject:
                            Re: [OAUTH-WG] I-D Action:
                            draft-ietf-oauth-v2-http-mac-03.txt

                        Hi Bill, 

                        I believe you are misreading the document. In
                        draft-ietf-oauth-v2-http-mac the client still
                        uses the MAC when it accesses a protected
                        resource. 

                        The only place where the JWT comes into the
                        picture is with the description of the access
                        token. This matters from a key distribution
                        point of view. The session key for the MAC is
                        included in the encrypted JWT. The JWT is
                        encrypted by the authorization server and
                        decrypted by the resource server. 

                        Information about how header fields get included
                        in the MAC is described in Section 5.

                        The nonce isn't killed it is just called
                        differently: seq-nr. The stuff in the original
                        MAC specification actually wasn't a nonce (from
                        the semantic point of view). 

                        The extension parameter is there implicitly by
                        allowing additional header fields to be included
                        in the MAC computation.

                        I need to look at the port number field again. 

                        Ciao

                        Hannes

                        On Feb 27, 2013, at 11:12 AM, William Mills
                        wrote:

                        > Just read the draft quickly.  

                        > 

                        > Since we're now leaning on JWT do we need
                        to include the token in this?  Why not just make
                        an additional "Envelope MAC" thing and have the
                        signature include the 3 JWT parts in the
                        signature base string?  That object then just
                        becomes a JSON container for the kid, timestamp,
                        signature method, signature etc. That thing then
                        is a 4th base64 encoded JSON thing in the auth
                        header.

                        > 

                        > How header fields get included in the
                        signature needs definition.

                        > 

                        > Why did you kill the port number, nonce,
                        and extension parameter out of the signature
                        base string?

                        > 

                        > The BNF appears to have no separators
                        between values.

                        > 

                        > -bill

                        > 

                        > 

                        > From: "internet-drafts@ietf.org"
                        <internet-drafts@ietf.org>

                        > To: i-d-announce@ietf.org

                        > Cc: oauth@ietf.org

                        > Sent: Monday, February 25, 2013 4:46 AM

                        > Subject: [OAUTH-WG] I-D Action:
                        draft-ietf-oauth-v2-http-mac-03.txt

                        > 

                        > 

                        > A New Internet-Draft is available from the
                        on-line Internet-Drafts directories.

                        > This draft is a work item of the Web
                        Authorization Protocol Working Group of the
                        IETF.

                        > 

                        >    Title          : OAuth 2.0 Message
                        Authentication Code (MAC) Tokens

                        >    Author(s)      : Justin Richer

                        >                          William Mills

                        >                          Hannes Tschofenig

                        >    Filename        :
                        draft-ietf-oauth-v2-http-mac-03.txt

                        >    Pages          : 26

                        >    Date            : 2013-02-25

                        > 

                        > Abstract:

                        >  This specification describes how to use
                        MAC Tokens in HTTP requests

                        >  to access OAuth 2.0 protected resources. 
                        An OAuth client willing to

                        >  access a protected resource needs to
                        demonstrate possession of a

                        >  crytographic key by using it with a keyed
                        message digest function to

                        >  the request.

                        > 

                        >  The document also defines a key
                        distribution protocol for obtaining a

                        >  fresh session key.

                        > 

                        > 

                        > The IETF datatracker status page for this
                        draft is:

                        > https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac

                        > 

                        > There's also a htmlized version available
                        at:

                        >
                        http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03

                        > 

                        > A diff from the previous version is
                        available at:

                        >
                        http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-http-mac-03

                        > 

                        > 

                        > Internet-Drafts are also available by
                        anonymous FTP at:

                        > ftp://ftp.ietf.org/internet-drafts/

                        > 

                        >
                        _______________________________________________

                        > 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

--Apple-Mail-D62079BB-A0D4-4FFE-BB3A-1DA61342DD52--

From ve7jtb@ve7jtb.com  Thu Feb 28 10:36:18 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3AF521F8899 for ; Thu, 28 Feb 2013 10:36:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.445
X-Spam-Level: 
X-Spam-Status: No, score=-3.445 tagged_above=-999 required=5 tests=[AWL=0.153,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kS8UiGjAKl7 for ; Thu, 28 Feb 2013 10:36:17 -0800 (PST)
Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by ietfa.amsl.com (Postfix) with ESMTP id F293F21F86C4 for ; Thu, 28 Feb 2013 10:36:08 -0800 (PST)
Received: by mail-pa0-f54.google.com with SMTP id fa10so1296546pad.27 for ; Thu, 28 Feb 2013 10:36:08 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=AlH6AqDfaC6IFqA4C75IzUJ6T8Wwrot/52jeOBmqNqo=; b=FALMzYEMAv2bWROiWswqlkvzUixuFHHpCL4Aplis1vcO0+z9mBtmFVt97YQEV98PZK U5eFqwcDQO8boiBMFy+vyVxZ0xJyFu+gmjhvyYUcrb24dja0mFqfuxHG7wN+LsKhbVbY zqd3W2G6/TCe588siuBg/3GNnro2FJ1H/3m8DkbRVGc3IrOnmXPJ94zGrLCJCw3cz4Ht 1osATpyee5W4S7uBPvL4w2CgRDiqRRoGV2DZa724vKuXFz2+xB6pMRUjfhvQWrkA/f8a +wJYkm5T6MEPbIpbtjxccsGsVqHal/ogaimFFEEBihgajugAgJpfrTISXC7puVGuryEf yPZw==
X-Received: by 10.66.158.105 with SMTP id wt9mr14523556pab.156.1362076568624;  Thu, 28 Feb 2013 10:36:08 -0800 (PST)
Received: from [192.168.41.99] (ip-64-134-220-138.public.wayport.net. [64.134.220.138]) by mx.google.com with ESMTPS id i6sm10044759paw.19.2013.02.28.10.36.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Feb 2013 10:36:05 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_9B76360D-5ECC-47AC-B18F-5AADB5182FBF"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <7127843B-D7B0-4AB6-87F1-1604D1EFFA79@oracle.com>
Date: Thu, 28 Feb 2013 10:36:01 -0800
Message-Id: <50DA292F-32F0-4266-8401-006AD837B775@ve7jtb.com>
References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net>     <48FD87D1-4DF4-4289-99B7-40A515F31890@oracle.com> <3E472720-31A4-40A0-AAA4-402CF850831A@ve7jtb.com> <7127843B-D7B0-4AB6-87F1-1604D1EFFA79@oracle.com>
To: Phil Hunt 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQmSk3WKm1w7iGEjdMwSC0CkMFoOzizUhWWby5mt3DZJfwpeTaph+vD8mmLNkxmpM4mC8gdj
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] JWT - scope claim missing
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 18:36:18 -0000

--Apple-Mail=_9B76360D-5ECC-47AC-B18F-5AADB5182FBF
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_6B5A46A7-C593-4720-BAA7-FD9BE76EB427"

--Apple-Mail=_6B5A46A7-C593-4720-BAA7-FD9BE76EB427
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Yes the title likely adds to the confusion given that the bearer tokens =
are not access tokens.

Things as separate from OAuth as the Firefox browerID spec use JWS =
signed JWTs. =20

The bearer token profiles for OAuth 2 are for OAuth2.

The JSON Web Token (JWT) spec did not start in OAuth and is not OAuth =
specific.

A JWT is:
JSON Web Token (JWT)  A string representing a set of claims as a JSON
      object that is encoded in a JWS or JWE, enabling the claims to be
      digitally signed or MACed and/or encrypted.

So OAuth or other profiles may define claims to go in a JWT, but the JWT =
needs to itself only define the claims necessary for security =
processing. =20

John B.
PS that was a soft ball If you hadn't responded I would have been =
disappointed.  I din't pick the title for the bearer token profiles.

On 2013-02-28, at 10:12 AM, Phil Hunt  wrote:

> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
>=20
> Note the title says "for OAuth2"
>=20
> Sorry. Couldn't resist.=20
>=20
> Phil
>=20
> Sent from my phone.
>=20
> On 2013-02-28, at 9:40, John Bradley  wrote:
>=20
>> JWT is an assertion( I am probably going to regret using that word).
>>=20
>> It is used in openID connect for id_tokens, it is used in OAuth for =
Assertion grant types and authentication of the client to the token =
endpoint.
>> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04
>>=20
>> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
>>=20
>> Dosen't define JWT's use for access tokens for the RS.  =20
>>=20
>> Bottom line JWT is for more than access tokens.
>>=20
>> John B.
>>=20
>> On 2013-02-28, at 9:28 AM, Phil Hunt  wrote:
>>=20
>>> Are you saying jwt is not an access token type?
>>>=20
>>> Phil
>>>=20
>>> Sent from my phone.
>>>=20
>>> On 2013-02-28, at 8:58, John Bradley  wrote:
>>>=20
>>>> Yes, defining scope in JWT is the wrong place.   JWT needs to stick =
to the security claims needed to process JWT.
>>>>=20
>>>> I also don't know how far you get requiring a specific =
authorization format for JWT, some AS will wan to use a opaque =
reference, some might want to use a user claim or role claim, others may =
use scopes,  combining scopes and claims is also possible.
>>>>=20
>>>> Right now it is up to a AS RS pair to agree on how to communicate =
authorization.   I don't want MAC to be more restrictive than bearer =
when it comes to authorization between AS and RS.
>>>>=20
>>>> Hannes wanted to know why JWT didn't define scope.  The simple =
answer is that it is out of scope for JWT itself.   It might be defined =
in a OAuth access token profile for JWT but it should not be specific to =
MAC.
>>>>=20
>>>> John B.
>>>> On 2013-02-28, at 8:44 AM, Brian Campbell =
 wrote:
>>>>=20
>>>>> I think John's point was more that scope is something rather =
specific to an OAuth access token and, while JWT is can be used to =
represent an access token, it's not the only application of JWT. The =
'standard' claims in JWT are those that are believed (right or wrong) to =
be widely applicable across different applications of JWT. One could =
argue about it but scope is probably not one of those.
>>>>>=20
>>>>> It would probably make sense to try and build a profile of JWT =
specifically for OAuth access tokens (though I suspect there are some =
turtles and dragons in there), which might be the appropriate place to =
define/register a scope claim.
>>>>>=20
>>>>>=20
>>>>> On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt  =
wrote:
>>>>> Are you advocating TWO systems? That seems like a bad choice.
>>>>>=20
>>>>> I would rather fix scope than go to a two system approach.
>>>>>=20
>>>>> Phil
>>>>>=20
>>>>> Sent from my phone.
>>>>>=20
>>>>> On 2013-02-28, at 8:17, John Bradley  wrote:
>>>>>=20
>>>>> > While scope is one method that a AS could communicate =
authorization to a RS, it is not the only or perhaps even the most =
likely one.
>>>>> > Using scope requires a relatively tight binding between the RS =
and AS,  UMA uses a different mechanism that describes finer grained =
operations.
>>>>> > The AS may include roles, user, or other more abstract claims =
that the the client may (god help them) pass on to EXCML for processing.
>>>>> >
>>>>> > While having a scopes claim is possible, like any other claim it =
is not part of the JWT core security processing claims, and needs to be =
defined by extension.
>>>>> >
>>>>> > John B.
>>>>> > On 2013-02-28, at 2:29 AM, Hannes Tschofenig =
 wrote:
>>>>> >
>>>>> >> Hi Mike,
>>>>> >>
>>>>> >> when I worked on the MAC specification I noticed that the JWT =
does not have a claim for the scope. I believe that this would be needed =
to allow the resource server to verify whether the scope the =
authorization server authorized is indeed what the client is asking for.
>>>>> >>
>>>>> >> 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
>>>>>=20
>>>>=20
>>=20

--Apple-Mail=_6B5A46A7-C593-4720-BAA7-FD9BE76EB427
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Yes =
the title likely adds to the confusion given that the bearer tokens are =
not access tokens.
Things as separate from OAuth as =
the Firefox browerID spec use JWS signed JWTs. =

The bearer token profiles for OAuth 2 =
are for OAuth2.

The JSO=
N Web Token (JWT) spec did not start in OAuth and is not OAuth =
specific.

A JWT is:
JSON Web Token (JWT)  A =
string representing a set of claims as a JSON
      object that is encoded in a JWS or JWE, enabling the claims to be
      digitally signed or MACed and/or encrypted.

So OAuth or other profiles may define claims =
to go in a JWT, but the JWT needs to itself only define the claims =
necessary for security processing.  

John =
B.
PS that was a soft ball If you hadn't responded I would =
have been disappointed.  I din't pick the title for the bearer =
token profiles.

On =
2013-02-28, at 10:12 AM, Phil Hunt <phil.hunt@oracle.com> =
wrote:

        JSON Web Token =
(JWT) Bearer Token Profiles for OAuth =
2.0

Note the title says "for =
OAuth2"

Sorry. Couldn't resist. 

Phil
Sent from my =
phone.

On =
2013-02-28, at 9:40, John Bradley <ve7jtb@ve7jtb.com> =
wrote:

JWT =
is an assertion( I am probably going to regret using that =
word).
It is used in openID connect for id_tokens, it =
is used in OAuth for Assertion grant types and authentication of the =
client to the token endpoint.
http://=
tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04

JSON Web Token (JWT) Bearer Token =
Profiles for OAuth 2.0

Dosen't =
define JWT's use for access tokens for the RS. =

Bottom line JWT is for more than =
access tokens.

John =
B.

On 2013-02-28, at 9:28 AM, Phil Hunt =
<phil.hunt@oracle.com> =
wrote:

Are you saying jwt is not an =
access token type?

Phil
Sent from my =
phone.

On 2013-02-28, at 8:58, John Bradley <ve7jtb@ve7jtb.com> =
wrote:

Yes, defining scope in JWT is the wrong place. =
  JWT needs to stick to the security claims needed to process =
JWT.
I also don't know how far you get requiring a =
specific authorization format for JWT, some AS will wan to use a opaque =
reference, some might want to use a user claim or role claim, others may =
use scopes,  combining scopes and claims is also =
possible.

Right now it is up to a AS RS pair to =
agree on how to communicate authorization.   I don't want MAC to be =
more restrictive than bearer when it comes to authorization between AS =
and RS.

Hannes wanted to know why JWT didn't =
define scope.  The simple answer is that it is out of scope for JWT =
itself.   It might be defined in a OAuth access token profile for =
JWT but it should not be specific to MAC.

John =
B.
On 2013-02-28, at 8:44 AM, Brian Campbell <bcampbell@pingidentity.com&=
gt; wrote:

I think John's point was more that =
scope is something rather specific to an OAuth access token and, while =
JWT is can be used to represent an access token, it's not the only =
application of JWT. The 'standard' claims in JWT are those that are =
believed (right or wrong) to be widely applicable across different =
applications of JWT. One could argue about it but scope is probably not =
one of those.

It would probably make sense to try and build a profile of JWT =
specifically for OAuth access tokens (though I suspect there are some =
turtles and dragons in there), which might be the appropriate place to =
define/register a scope claim.

On =
Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

Are you advocating TWO =
systems? That seems like a bad choice.

I would rather fix scope than go to a two system approach.

Phil

Sent from my phone.

On 2013-02-28, at 8:17, John Bradley <ve7jtb@ve7jtb.com> wrote:

> While scope is one method that a AS could communicate authorization =
to a RS, it is not the only or perhaps even the most likely one.

> Using scope requires a relatively tight binding between the RS and =
AS,  UMA uses a different mechanism that describes finer grained =
operations.

> The AS may include roles, user, or other more abstract claims that =
the the client may (god help them) pass on to EXCML for processing.

>

> While having a scopes claim is possible, like any other claim it is =
not part of the JWT core security processing claims, and needs to be =
defined by extension.

>

> John B.

> On 2013-02-28, at 2:29 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net>=
; wrote:

>

>> Hi Mike,

>>

>> when I worked on the MAC specification I noticed that the JWT =
does not have a claim for the scope. I believe that this would be needed =
to allow the resource server to verify whether the scope the =
authorization server authorized is indeed what the client is asking =
for.

>>

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

=

<=
br>

=

--Apple-Mail=_6B5A46A7-C593-4720-BAA7-FD9BE76EB427--

--Apple-Mail=_9B76360D-5ECC-47AC-B18F-5AADB5182FBF
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMjI4MTgzNjAyWjAjBgkqhkiG9w0BCQQxFgQUe+Nak347
yQ3QEJGaZZ/evCJwvgwwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAsKqdYzS8dfKnpZb6YVbWgGKZq6B27qSnxNnfex6+
MFUxfrXedEkpDcr0dp5ETHSqoelIVwpxMu6SPxxbZBRq2wjw/A0aybt7+kqNafMkAFfO1dvOVbIi
6WJRFEHtuFSNq3OJUh3ShzThFPtQBO4u8/XiCvQq2waZBax+8korXZ5xQTtKJhHUrmJVvxSTAxN0
+27tKU5Z7jZiEXJU0K5exeMPOjbaRrvyfkXB5Q1s6X4J7dgfqB7yx2naAXT7OqPKqmoP9taFQuoN
1afuv7r2+WGtj9LNFyi8vklO5qN3ZttEJFu+GCleos/xltcaJaOdkKo2A484wrbcYexVjqV6NAAA
AAAAAA==

--Apple-Mail=_9B76360D-5ECC-47AC-B18F-5AADB5182FBF--

From bcampbell@pingidentity.com  Thu Feb 28 11:03:49 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B248A21F8AB4 for ; Thu, 28 Feb 2013 11:03:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.905
X-Spam-Level: 
X-Spam-Status: No, score=-5.905 tagged_above=-999 required=5 tests=[AWL=0.071,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUXm-eoFfX6o for ; Thu, 28 Feb 2013 11:03:44 -0800 (PST)
Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by ietfa.amsl.com (Postfix) with ESMTP id 2009F21F8A96 for ; Thu, 28 Feb 2013 11:03:44 -0800 (PST)
Received: from mail-oa0-f71.google.com ([209.85.219.71]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKUS+qD5MUUyvnJeIzYl46DvhxwIIG0glF@postini.com; Thu, 28 Feb 2013 11:03:44 PST
Received: by mail-oa0-f71.google.com with SMTP id o6so14043446oag.6 for ; Thu, 28 Feb 2013 11:03:43 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=FNNoDKeEHc/SN0qI+leQi6DuO/CT2o/CCKh0qWnk04E=; b=creNvZOlfBFr9iVZ7uwRQ33F2eDwR0shAyUJHrbfCNMeiyjW3hJX305bixu9KXhEsW 4zinWPzjUvW9eWCgFCADrEc0u4JdxX3eoKghS48a4IGDekKOX7c6IQCDFd1ZMUbTzAgN 0ZewezW6Yar6UKSNs/2Gni8bjGr5bF49Gaa1x30ANHFyit5GRfiQFG/oT8/n2G17ZyVS ht8oFz01WyeHQeomD3qMTQoy6Mouj/ux42KFX8suU44iCOrpcCamck21PZwgeEg+UMO5 ybngmZ/MvYM15n1u5tNOC9FdvTMHOf4Ze1BDzM1cXMhy8DUA80ykIWDQOYZhZ+l/VhwP mZ9w==
X-Received: by 10.50.37.162 with SMTP id z2mr4544261igj.13.1362078222869; Thu, 28 Feb 2013 11:03:42 -0800 (PST)
X-Received: by 10.50.37.162 with SMTP id z2mr4544129igj.13.1362078220186; Thu, 28 Feb 2013 11:03:40 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.32.106 with HTTP; Thu, 28 Feb 2013 11:03:10 -0800 (PST)
In-Reply-To: <50DA292F-32F0-4266-8401-006AD837B775@ve7jtb.com>
References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net>     <48FD87D1-4DF4-4289-99B7-40A515F31890@oracle.com> <3E472720-31A4-40A0-AAA4-402CF850831A@ve7jtb.com> <7127843B-D7B0-4AB6-87F1-1604D1EFFA79@oracle.com> <50DA292F-32F0-4266-8401-006AD837B775@ve7jtb.com>
From: Brian Campbell 
Date: Thu, 28 Feb 2013 12:03:10 -0700
Message-ID: 
To: John Bradley 
Content-Type: multipart/alternative; boundary=f46d04446b297c44bf04d6cd8c9a
X-Gm-Message-State: ALoCoQmSWCw5BSrrkfOGZrTGVmNXCHVR0YrzksLY7TStbLypTxIJPYSh4kaKkh10rGyuUnBwdJYC+ofJw/FO04zTs1CzY9PmKHB8pfKdEm6lIQ/FT9BRieJkxWEZZhGmTXEPzJD/C6ad
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] JWT - scope claim missing
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 19:03:49 -0000

--f46d04446b297c44bf04d6cd8c9a
Content-Type: text/plain; charset=ISO-8859-1

I'm not sure anyone really "picked" the titles for the bearer token
profiles. They just kind of evolved. And evolved in funny ways especially
when client authn to the AS was added.

You won't hear me argue that the titles are "good" and this is not the
first time there's been confusion about what they actually do. They define
new grant types and new client authentication methods. They *do not* define
an access token format or anything else about access tokens. JWT and SAML
could be used for that but that's not what these drafts do.

Suggestions for better title(s) would be more than welcome.

Here's what they are now:

SAML 2.0 Bearer Assertion Profiles for OAuth 2.0
draft-ietf-oauth-saml2-bearer

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
draft-ietf-oauth-jwt-bearer

Assertion Framework for OAuth 2.0
draft-ietf-oauth-assertions

On Thu, Feb 28, 2013 at 11:36 AM, John Bradley  wrote:

> Yes the title likely adds to the confusion given that the bearer tokens
> are not access tokens.
>
> Things as separate from OAuth as the Firefox browerID spec use JWS signed
> JWTs.
>
> The bearer token profiles for OAuth 2 are for OAuth2.
>
> The JSON Web Token (JWT) spec
> did not start in OAuth and is not OAuth specific.
>
> A JWT is:
>
> JSON Web Token (JWT)  A string representing a set of claims as a JSON
>       object that is encoded in a JWS or JWE, enabling the claims to be
>       digitally signed or MACed and/or encrypted.
>
>
> So OAuth or other profiles may define claims to go in a JWT, but the JWT
> needs to itself only define the claims necessary for security processing.
>
> John B.
> PS that was a soft ball If you hadn't responded I would have been
> disappointed.  I din't pick the title for the bearer token profiles.
>
>
> On 2013-02-28, at 10:12 AM, Phil Hunt  wrote:
>
>
>
> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
>
>
> Note the title says "for OAuth2"
>
> Sorry. Couldn't resist.
>
> Phil
>
> Sent from my phone.
>
> On 2013-02-28, at 9:40, John Bradley  wrote:
>
> JWT is an assertion( I am probably going to regret using that word).
>
> It is used in openID connect for id_tokens, it is used in OAuth for
> Assertion grant types and authentication of the client to the token
> endpoint.
> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04
>
> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
>
>
> Dosen't define JWT's use for access tokens for the RS.
>
> Bottom line JWT is for more than access tokens.
>
> John B.
>
> On 2013-02-28, at 9:28 AM, Phil Hunt  wrote:
>
> Are you saying jwt is not an access token type?
>
> Phil
>
> Sent from my phone.
>
> On 2013-02-28, at 8:58, John Bradley  wrote:
>
> Yes, defining scope in JWT is the wrong place.   JWT needs to stick to the
> security claims needed to process JWT.
>
> I also don't know how far you get requiring a specific authorization
> format for JWT, some AS will wan to use a opaque reference, some might want
> to use a user claim or role claim, others may use scopes,  combining scopes
> and claims is also possible.
>
> Right now it is up to a AS RS pair to agree on how to communicate
> authorization.   I don't want MAC to be more restrictive than bearer when
> it comes to authorization between AS and RS.
>
> Hannes wanted to know why JWT didn't define scope.  The simple answer is
> that it is out of scope for JWT itself.   It might be defined in a OAuth
> access token profile for JWT but it should not be specific to MAC.
>
> John B.
> On 2013-02-28, at 8:44 AM, Brian Campbell 
> wrote:
>
> I think John's point was more that scope is something rather specific to
> an OAuth access token and, while JWT is can be used to represent an access
> token, it's not the only application of JWT. The 'standard' claims in JWT
> are those that are believed (right or wrong) to be widely applicable across
> different applications of JWT. One could argue about it but scope is
> probably not one of those.
>
> It would probably make sense to try and build a profile of JWT
> specifically for OAuth access tokens (though I suspect there are some
> turtles and dragons in there), which might be the appropriate place to
> define/register a scope claim.
>
>
> On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt  wrote:
>
>> Are you advocating TWO systems? That seems like a bad choice.
>>
>> I would rather fix scope than go to a two system approach.
>>
>> Phil
>>
>> Sent from my phone.
>>
>> On 2013-02-28, at 8:17, John Bradley  wrote:
>>
>> > While scope is one method that a AS could communicate authorization to
>> a RS, it is not the only or perhaps even the most likely one.
>> > Using scope requires a relatively tight binding between the RS and AS,
>>  UMA uses a different mechanism that describes finer grained operations.
>> > The AS may include roles, user, or other more abstract claims that the
>> the client may (god help them) pass on to EXCML for processing.
>> >
>> > While having a scopes claim is possible, like any other claim it is not
>> part of the JWT core security processing claims, and needs to be defined by
>> extension.
>> >
>> > John B.
>> > On 2013-02-28, at 2:29 AM, Hannes Tschofenig 
>> wrote:
>> >
>> >> Hi Mike,
>> >>
>> >> when I worked on the MAC specification I noticed that the JWT does not
>> have a claim for the scope. I believe that this would be needed to allow
>> the resource server to verify whether the scope the authorization server
>> authorized is indeed what the client is asking for.
>> >>
>> >> 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
>>
>
>
>
>
>

--f46d04446b297c44bf04d6cd8c9a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I'm not sure anyone really "picked" the=
 titles for the bearer token profiles. They just kind of evolved. And evolv=
ed in funny ways especially when client authn to the AS was added. 

You won't hear me argue that the titles are "good"=
 and this is not the first time there's been confusion about what they =
actually do. They define new grant types and new client authentication meth=
ods. They *do not* define an access token format or anything else about acc=
ess tokens. JWT and SAML could be used for that but that's not what the=
se drafts do. 

Suggestions for better title(s) would be more than welcome.<=
br>

Here's what they are now:
=

SAML 2.0 Bearer Assertion Profiles for OAuth 2.0
draft-ietf-oauth-sa=
ml2-bearer

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0<=
br>

draft-ietf-oauth-jwt-bearer

Assertion Framework for OAuth 2.0
dra=
ft-ietf-oauth-assertions

On Thu, Feb 28, 2013 at 11:36 AM, John Bradley <ve7jtb@ve7jtb.c=
om> wrote:

Yes the title likely adds to the confus=
ion given that the bearer tokens are not access tokens.
=
Things as separate from OAuth as the Firefox browerID spec use JWS signed J=
WTs. =A0

The bearer token profiles for OAuth 2 are for OAuth2.
The=A0JSON Web Token (JWT)=A0s=
pec did not start in OAuth and is not OAuth specific.

A JWT is:
JSON Web Token (JWT)  A string representing a se=
t of claims as a JSON
      object that is encoded in a JWS or JWE, enabling the claims to be
      digitally signed or MACed and/or encrypted.

So OAuth or other profiles may define claims to g=
o in a JWT, but the JWT needs to itself only define the claims necessary fo=
r security processing. =A0

John B.
PS th=
at was a soft ball If you hadn't responded I would have been disappoint=
ed. =A0I din't pick the title for the bearer token profiles.

On 2013-02-28, at 10:12 A=
M, Phil Hunt <=
phil.hunt@oracle.com> wrote:

        <=
h1 style=3D"display:inline">

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0=

Note the title says "for OAuth2"
Sorry. Couldn't resist.=A0

Phil
Sent =
from my phone.

On 2013-02-28, at 9:40, John Bradley <=
;ve7jtb@ve7jtb.com> wrote:

JWT is an assertion( I am probably goin=
g to regret using that word).
It is used in openID conne=
ct for id_tokens, it is used in OAuth for Assertion grant types and authent=
ication of the client to the token endpoint.

http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04=

JSON Web Toke=
n (JWT) Bearer Token Profiles for OAuth 2.0

Dosen't define JWT's use for access tokens for the RS. =A0=A0<=
/div>
Bottom line JWT is for more than access tokens.
John B.

On 2013-02-28,=
 at 9:28 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

Are you saying jwt is =
not an access token type?

Phil
Sent from my phone=
.

On 2013-02-28, at 8:58, John Bradley <ve7jtb@ve7jtb.com> wrote:=

Yes, defining scope in JWT is the wrong=
 place. =A0 JWT needs to stick to the security claims needed to process JWT=
.
I also don't know how far you get requiring a spec=
ific authorization format for JWT, some AS will wan to use a opaque referen=
ce, some might want to use a user claim or role claim, others may use scope=
s, =A0combining scopes and claims is also possible.

Right now it is up to a AS RS pair to agree on how to c=
ommunicate authorization. =A0 I don't want MAC to be more restrictive t=
han bearer when it comes to authorization between AS and RS.

Hannes wanted to know why JWT didn't define scope. =A0The si=
mple answer is that it is out of scope for JWT itself. =A0 It might be defi=
ned in a OAuth access token profile for JWT but it should not be specific t=
o MAC.

John B.
On 2013-02-28, at 8:44 AM, =
Brian Campbell <bcampbell@pingidentity.com> wrote:

I think John's point was more that scope is somet=
hing rather specific to an OAuth access token and, while JWT is can be used=
 to represent an access token, it's not the only application of JWT. Th=
e 'standard' claims in JWT are those that are believed (right or wr=
ong) to be widely applicable across different applications of JWT. One coul=
d argue about it but scope is probably not one of those.

It would probably make sense to try and build a profile of JWT sp=
ecifically for OAuth access tokens (though I suspect there are some turtles=
 and dragons in there), which might be the appropriate place to define/regi=
ster a scope claim.

On Thu,=
 Feb 28, 2013 at 9:24 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

Are you advocating TWO sy=
stems? That seems like a bad choice.

I would rather fix scope than go to a two system approach.

Phil

Sent from my phone.

On 2013-02-28, at 8:17, John Bradley <ve7jtb@ve7jtb.com> wrote:

> While scope is one method that a AS could communicate authorization to=
 a RS, it is not the only or perhaps even the most likely one.

> Using scope requires a relatively tight binding between the RS and AS,=
 =A0UMA uses a different mechanism that describes finer grained operations.=

> The AS may include roles, user, or other more abstract claims that the=
 the client may (god help them) pass on to EXCML for processing.

>

> While having a scopes claim is possible, like any other claim it is no=
t part of the JWT core security processing claims, and needs to be defined =
by extension.

>

> John B.

> On 2013-02-28, at 2:29 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net>=
 wrote:

>

>> Hi Mike,

>>

>> when I worked on the MAC specification I noticed that the JWT does=
 not have a claim for the scope. I believe that this would be needed to all=
ow the resource server to verify whether the scope the authorization server=
 authorized is indeed what the client is asking for.

>>

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

h=
ttps://www.ietf.org/mailman/listinfo/oauth

<=
/blockquote>

--f46d04446b297c44bf04d6cd8c9a--

From jricher@mitre.org  Thu Feb 28 11:13:24 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9575E21F89FC for ; Thu, 28 Feb 2013 11:13:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.578
X-Spam-Level: 
X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.020,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZ3XxJogSv7h for ; Thu, 28 Feb 2013 11:13:19 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC7321F88E8 for ; Thu, 28 Feb 2013 11:13:19 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3B0BB435032D; Thu, 28 Feb 2013 14:13:18 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 175A31F0539; Thu, 28 Feb 2013 14:13:18 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 28 Feb 2013 14:13:17 -0500
Message-ID: <512FAC0F.5070409@mitre.org>
Date: Thu, 28 Feb 2013 14:12:15 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Brian Campbell 
References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net>     <48FD87D1-4DF4-4289-99B7-40A515F31890@oracle.com> <3E472720-31A4-40A0-AAA4-402CF850831A@ve7jtb.com> <7127843B-D7B0-4AB6-87F1-1604D1EFFA79@oracle.com> <50DA292F-32F0-4266-8401-006AD837B775@ve7jtb.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000007040907010705090907"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] JWT - scope claim missing
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 19:13:24 -0000

--------------000007040907010705090907
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Brian, I think you're conflating two things (and John might be, too). On 
the one hand, we've got the JWT document, which talks about what goes 
into the token itself. This can be used as an assertion, as an access 
token, as a floor wax / dessert topping. JWT doesn't really care, and 
this is really only in the OAuth WG thanks to IETF politics. Then we 
have the assertion profiles which say how to use things like JWT to do 
specific things in OAuth, and these are what Brian's talking about below.

Ultimately, this conversation is about the former and not the latter. 
That said, since an OAuth access token is a valid (and common) use of 
JWT, I think that having a common way to put things like "scope" and 
"client_id" and other OAuthy things into a JWT makes a whole heck of a 
lot of sense. Whether or not that is inside of the base JWT draft (since 
it's supposed to be for many use cases), I don't particularly care, and 
I can see the arguments from both sides.

  -- Justin

On 02/28/2013 02:03 PM, Brian Campbell wrote:
> I'm not sure anyone really "picked" the titles for the bearer token 
> profiles. They just kind of evolved. And evolved in funny ways 
> especially when client authn to the AS was added.
>
> You won't hear me argue that the titles are "good" and this is not the 
> first time there's been confusion about what they actually do. They 
> define new grant types and new client authentication methods. They *do 
> not* define an access token format or anything else about access 
> tokens. JWT and SAML could be used for that but that's not what these 
> drafts do.
>
> Suggestions for better title(s) would be more than welcome.
>
> Here's what they are now:
>
> SAML 2.0 Bearer Assertion Profiles for OAuth 2.0
> draft-ietf-oauth-saml2-bearer
>
> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
> draft-ietf-oauth-jwt-bearer
>
> Assertion Framework for OAuth 2.0
> draft-ietf-oauth-assertions
>
> On Thu, Feb 28, 2013 at 11:36 AM, John Bradley  > wrote:
>
>     Yes the title likely adds to the confusion given that the bearer
>     tokens are not access tokens.
>
>     Things as separate from OAuth as the Firefox browerID spec use JWS
>     signed JWTs.
>
>     The bearer token profiles for OAuth 2 are for OAuth2.
>
>     The JSON Web Token (JWT)
>      spec
>     did not start in OAuth and is not OAuth specific.
>
>     A JWT is:
>
>     JSON Web Token (JWT)  A string representing a set of claims as a JSON
>            object that is encoded in a JWS or JWE, enabling the claims to be
>            digitally signed or MACed and/or encrypted.
>
>
>     So OAuth or other profiles may define claims to go in a JWT, but
>     the JWT needs to itself only define the claims necessary for
>     security processing.
>
>     John B.
>     PS that was a soft ball If you hadn't responded I would have been
>     disappointed.  I din't pick the title for the bearer token profiles.
>
>
>     On 2013-02-28, at 10:12 AM, Phil Hunt      > wrote:
>
>>              
>>
>>
>>       JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
>>
>>
>>     Note the title says "for OAuth2"
>>
>>     Sorry. Couldn't resist.
>>
>>     Phil
>>
>>     Sent from my phone.
>>
>>     On 2013-02-28, at 9:40, John Bradley >     > wrote:
>>
>>>     JWT is an assertion( I am probably going to regret using that
>>>     word).
>>>
>>>     It is used in openID connect for id_tokens, it is used in OAuth
>>>     for Assertion grant types and authentication of the client to
>>>     the token endpoint.
>>>     http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04
>>>
>>>
>>>       JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
>>>
>>>
>>>     Dosen't define JWT's use for access tokens for the RS.
>>>
>>>     Bottom line JWT is for more than access tokens.
>>>
>>>     John B.
>>>
>>>     On 2013-02-28, at 9:28 AM, Phil Hunt >>     > wrote:
>>>
>>>>     Are you saying jwt is not an access token type?
>>>>
>>>>     Phil
>>>>
>>>>     Sent from my phone.
>>>>
>>>>     On 2013-02-28, at 8:58, John Bradley >>>     > wrote:
>>>>
>>>>>     Yes, defining scope in JWT is the wrong place.   JWT needs to
>>>>>     stick to the security claims needed to process JWT.
>>>>>
>>>>>     I also don't know how far you get requiring a specific
>>>>>     authorization format for JWT, some AS will wan to use a opaque
>>>>>     reference, some might want to use a user claim or role claim,
>>>>>     others may use scopes,  combining scopes and claims is also
>>>>>     possible.
>>>>>
>>>>>     Right now it is up to a AS RS pair to agree on how to
>>>>>     communicate authorization.   I don't want MAC to be more
>>>>>     restrictive than bearer when it comes to authorization between
>>>>>     AS and RS.
>>>>>
>>>>>     Hannes wanted to know why JWT didn't define scope.  The simple
>>>>>     answer is that it is out of scope for JWT itself.   It might
>>>>>     be defined in a OAuth access token profile for JWT but it
>>>>>     should not be specific to MAC.
>>>>>
>>>>>     John B.
>>>>>     On 2013-02-28, at 8:44 AM, Brian Campbell
>>>>>     >>>>     > wrote:
>>>>>
>>>>>>     I think John's point was more that scope is something rather
>>>>>>     specific to an OAuth access token and, while JWT is can be
>>>>>>     used to represent an access token, it's not the only
>>>>>>     application of JWT. The 'standard' claims in JWT are those
>>>>>>     that are believed (right or wrong) to be widely applicable
>>>>>>     across different applications of JWT. One could argue about
>>>>>>     it but scope is probably not one of those.
>>>>>>
>>>>>>     It would probably make sense to try and build a profile of
>>>>>>     JWT specifically for OAuth access tokens (though I suspect
>>>>>>     there are some turtles and dragons in there), which might be
>>>>>>     the appropriate place to define/register a scope claim.
>>>>>>
>>>>>>
>>>>>>     On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt
>>>>>>     > wrote:
>>>>>>
>>>>>>         Are you advocating TWO systems? That seems like a bad choice.
>>>>>>
>>>>>>         I would rather fix scope than go to a two system approach.
>>>>>>
>>>>>>         Phil
>>>>>>
>>>>>>         Sent from my phone.
>>>>>>
>>>>>>         On 2013-02-28, at 8:17, John Bradley >>>>>         > wrote:
>>>>>>
>>>>>>         > While scope is one method that a AS could communicate
>>>>>>         authorization to a RS, it is not the only or perhaps even
>>>>>>         the most likely one.
>>>>>>         > Using scope requires a relatively tight binding between
>>>>>>         the RS and AS,  UMA uses a different mechanism that
>>>>>>         describes finer grained operations.
>>>>>>         > The AS may include roles, user, or other more abstract
>>>>>>         claims that the the client may (god help them) pass on to
>>>>>>         EXCML for processing.
>>>>>>         >
>>>>>>         > While having a scopes claim is possible, like any other
>>>>>>         claim it is not part of the JWT core security processing
>>>>>>         claims, and needs to be defined by extension.
>>>>>>         >
>>>>>>         > John B.
>>>>>>         > On 2013-02-28, at 2:29 AM, Hannes Tschofenig
>>>>>>         >>>>>         > wrote:
>>>>>>         >
>>>>>>         >> Hi Mike,
>>>>>>         >>
>>>>>>         >> when I worked on the MAC specification I noticed that
>>>>>>         the JWT does not have a claim for the scope. I believe
>>>>>>         that this would be needed to allow the resource server to
>>>>>>         verify whether the scope the authorization server
>>>>>>         authorized is indeed what the client is asking for.
>>>>>>         >>
>>>>>>         >> 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

--------------000007040907010705090907
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

    Brian, I think you're conflating two things (and John might be,
    too). On the one hand, we've got the JWT document, which talks about
    what goes into the token itself. This can be used as an assertion,
    as an access token, as a floor wax / dessert topping. JWT doesn't
    really care, and this is really only in the OAuth WG thanks to IETF
    politics. Then we have the assertion profiles which say how to use
    things like JWT to do specific things in OAuth, and these are what
    Brian's talking about below.

    Ultimately, this conversation is about the former and not the
    latter. That said, since an OAuth access token is a valid (and
    common) use of JWT, I think that having a common way to put things
    like "scope" and "client_id" and other OAuthy things into a JWT
    makes a whole heck of a lot of sense. Whether or not that is inside
    of the base JWT draft (since it's supposed to be for many use
    cases), I don't particularly care, and I can see the arguments from
    both sides.

     -- Justin

    On 02/28/2013 02:03 PM, Brian Campbell
      wrote:

        I'm not sure anyone really "picked" the titles for the
          bearer token profiles. They just kind of evolved. And evolved
          in funny ways especially when client authn to the AS was
          added. 

        You won't hear me argue that the titles are "good" and this
          is not the first time there's been confusion about what they
          actually do. They define new grant types and new client
          authentication methods. They *do not* define an access token
          format or anything else about access tokens. JWT and SAML
          could be used for that but that's not what these drafts do. 

        Suggestions for better title(s) would be more than welcome.

          Here's what they are now:

            SAML 2.0 Bearer Assertion Profiles for OAuth 2.0

            draft-ietf-oauth-saml2-bearer

            JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

            draft-ietf-oauth-jwt-bearer

            Assertion Framework for OAuth 2.0

            draft-ietf-oauth-assertions

              On Thu, Feb 28, 2013 at 11:36 AM,
                John Bradley <ve7jtb@ve7jtb.com>
                wrote:

                  Yes the title likely
                    adds to the confusion given that the bearer tokens
                    are not access tokens.

                    Things as separate from OAuth as the Firefox
                      browerID spec use JWS signed JWTs.  

                    The bearer token profiles for OAuth 2 are for
                      OAuth2.

                    The JSON Web Token (JWT) spec
                      did not start in OAuth and is not OAuth specific.

                    A JWT is:

                      JSON Web Token (JWT)  A string representing a set of claims as a JSON
      object that is encoded in a JWS or JWE, enabling the claims to be
      digitally signed or MACed and/or encrypted.

                      So OAuth or other profiles may define claims
                        to go in a JWT, but the JWT needs to itself only
                        define the claims necessary for security
                        processing.  

                      John B.
                      PS that was a soft ball If you hadn't
                        responded I would have been disappointed.  I
                        din't pick the title for the bearer token
                        profiles.

                            On 2013-02-28, at 10:12 AM, Phil Hunt
                              <phil.hunt@oracle.com>
                              wrote:

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

                                  Note the title says "for OAuth2"

                                Sorry. Couldn't resist. 

                                Phil

                                  Sent from my phone.

                                  On 2013-02-28, at 9:40, John Bradley
                                  <ve7jtb@ve7jtb.com>
                                  wrote:

                                JWT is an
                                  assertion( I am probably going to
                                  regret using that word).

                                  It is used in openID connect for
                                    id_tokens, it is used in OAuth for
                                    Assertion grant types and
                                    authentication of the client to the
                                    token endpoint.
                                  http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04

                                    JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

                                    Dosen't define JWT's use for
                                      access tokens for the RS.   

                                    Bottom line JWT is for more
                                      than access tokens.

                                    John B.

                                      On 2013-02-28, at 9:28 AM,
                                        Phil Hunt <phil.hunt@oracle.com>
                                        wrote:

                                          Are you saying jwt is not
                                            an access token type?

                                            Phil

                                            Sent from my phone.

                                            On 2013-02-28, at 8:58, John
                                            Bradley <ve7jtb@ve7jtb.com>
                                            wrote:

                                          Yes,
                                            defining scope in JWT is the
                                            wrong place.   JWT needs to
                                            stick to the security claims
                                            needed to process JWT.

                                            I also don't know how
                                              far you get requiring a
                                              specific authorization
                                              format for JWT, some AS
                                              will wan to use a opaque
                                              reference, some might want
                                              to use a user claim or
                                              role claim, others may use
                                              scopes,  combining scopes
                                              and claims is also
                                              possible.

                                            Right now it is up to a
                                              AS RS pair to agree on how
                                              to communicate
                                              authorization.   I don't
                                              want MAC to be more
                                              restrictive than bearer
                                              when it comes to
                                              authorization between AS
                                              and RS.

                                              Hannes wanted to know
                                                why JWT didn't define
                                                scope.  The simple
                                                answer is that it is out
                                                of scope for JWT itself.
                                                  It might be defined in
                                                a OAuth access token
                                                profile for JWT but it
                                                should not be specific
                                                to MAC.

                                              John B.

                                                  On 2013-02-28, at
                                                    8:44 AM, Brian
                                                    Campbell <bcampbell@pingidentity.com>
                                                    wrote:

                                                      I think
                                                        John's point was
                                                        more that scope
                                                        is something
                                                        rather specific
                                                        to an OAuth
                                                        access token
                                                        and, while JWT
                                                        is can be used
                                                        to represent an
                                                        access token,
                                                        it's not the
                                                        only application
                                                        of JWT. The
                                                        'standard'
                                                        claims in JWT
                                                        are those that
                                                        are believed
                                                        (right or wrong)
                                                        to be widely
                                                        applicable
                                                        across different
                                                        applications of
                                                        JWT. One could
                                                        argue about it
                                                        but scope is
                                                        probably not one
                                                        of those.

                                                      It would probably
                                                      make sense to try
                                                      and build a
                                                      profile of JWT
                                                      specifically for
                                                      OAuth access
                                                      tokens (though I
                                                      suspect there are
                                                      some turtles and
                                                      dragons in there),
                                                      which might be the
                                                      appropriate place
                                                      to define/register
                                                      a scope claim.

                                                      On
                                                        Thu, Feb 28,
                                                        2013 at 9:24 AM,
                                                        Phil Hunt <phil.hunt@oracle.com>
                                                        wrote:

                                                        Are
                                                          you advocating
                                                          TWO systems?
                                                          That seems
                                                          like a bad
                                                          choice.

                                                          I would rather
                                                          fix scope than
                                                          go to a two
                                                          system
                                                          approach.

                                                          Phil

                                                          Sent from my
                                                          phone.

                                                          On 2013-02-28,
                                                          at 8:17, John
                                                          Bradley <ve7jtb@ve7jtb.com>
                                                          wrote:

                                                          > While
                                                          scope is one
                                                          method that a
                                                          AS could
                                                          communicate
                                                          authorization
                                                          to a RS, it is
                                                          not the only
                                                          or perhaps
                                                          even the most
                                                          likely one.

                                                          > Using
                                                          scope requires
                                                          a relatively
                                                          tight binding
                                                          between the RS
                                                          and AS,  UMA
                                                          uses a
                                                          different
                                                          mechanism that
                                                          describes
                                                          finer grained
                                                          operations.

                                                          > The AS
                                                          may include
                                                          roles, user,
                                                          or other more
                                                          abstract
                                                          claims that
                                                          the the client
                                                          may (god help
                                                          them) pass on
                                                          to EXCML for
                                                          processing.

                                                          >

                                                          > While
                                                          having a
                                                          scopes claim
                                                          is possible,
                                                          like any other
                                                          claim it is
                                                          not part of
                                                          the JWT core
                                                          security
                                                          processing
                                                          claims, and
                                                          needs to be
                                                          defined by
                                                          extension.

                                                          >

                                                          > John B.

                                                          > On
                                                          2013-02-28, at
                                                          2:29 AM,
                                                          Hannes
                                                          Tschofenig
                                                          <hannes.tschofenig@gmx.net>
                                                          wrote:

                                                          >

                                                          >> Hi
                                                          Mike,

                                                          >>

                                                          >> when
                                                          I worked on
                                                          the MAC
                                                          specification
                                                          I noticed that
                                                          the JWT does
                                                          not have a
                                                          claim for the
                                                          scope. I
                                                          believe that
                                                          this would be
                                                          needed to
                                                          allow the
                                                          resource
                                                          server to
                                                          verify whether
                                                          the scope the
                                                          authorization
                                                          server
                                                          authorized is
                                                          indeed what
                                                          the client is
                                                          asking for.

                                                          >>

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

--------------000007040907010705090907--

From Adam.Lewis@motorolasolutions.com  Thu Feb 28 11:13:44 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED4F21F8A85 for ; Thu, 28 Feb 2013 11:13:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.466
X-Spam-Level: 
X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAbHOe557DZc for ; Thu, 28 Feb 2013 11:13:38 -0800 (PST)
Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 82F9E21F8A8E for ; Thu, 28 Feb 2013 11:13:38 -0800 (PST)
Received: from mail182-co1-R.bigfish.com (10.243.78.232) by CO1EHSOBE014.bigfish.com (10.243.66.77) with Microsoft SMTP Server id 14.1.225.23; Thu, 28 Feb 2013 19:13:37 +0000
Received: from mail182-co1 (localhost [127.0.0.1])	by mail182-co1-R.bigfish.com (Postfix) with ESMTP id 0D57B880094	for ; Thu, 28 Feb 2013 19:13:37 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:129.188.136.18; KIP:(null); UIP:(null); IPV:NLI; H:il06msg02.am.mot-solutions.com; RD:none; EFVD:NLI
X-SpamScore: -24
X-BigFish: VPS-24(zz98dI9371Ic89bh936eIc85dh1432Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275ch1033IL177df4h17326ah8275dh18c673h8275bhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1155h)
Received-SPF: pass (mail182-co1: domain of motorolasolutions.com designates 129.188.136.18 as permitted sender) client-ip=129.188.136.18; envelope-from=Adam.Lewis@motorolasolutions.com; helo=il06msg02.am.mot-solutions.com ; olutions.com ; 
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.237.133; KIP:(null); UIP:(null); (null); H:BY2PRD0411HT001.namprd04.prod.outlook.com; R:internal; EFV:INT
Received: from mail182-co1 (localhost.localdomain [127.0.0.1]) by mail182-co1 (MessageSwitch) id 1362078814896178_30950; Thu, 28 Feb 2013 19:13:34 +0000 (UTC)
Received: from CO1EHSMHS009.bigfish.com (unknown [10.243.78.230])	by mail182-co1.bigfish.com (Postfix) with ESMTP id D863080057	for ; Thu, 28 Feb 2013 19:13:34 +0000 (UTC)
Received: from il06msg02.am.mot-solutions.com (129.188.136.18) by CO1EHSMHS009.bigfish.com (10.243.66.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 28 Feb 2013 19:13:31 +0000
Received: from il06msg02.am.mot-solutions.com (il06vts03.mot.com [129.188.137.143])	by il06msg02.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r1SJDUQq002243	for ; Thu, 28 Feb 2013 14:13:30 -0500 (EST)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31])	by il06msg02.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r1SJDTD2002237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL)	for ; Thu, 28 Feb 2013 14:13:30 -0500 (EST)
Received: from mail72-va3-R.bigfish.com (10.7.14.233) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.23; Thu, 28 Feb 2013 19:13:29 +0000
Received: from mail72-va3 (localhost [127.0.0.1])	by mail72-va3-R.bigfish.com (Postfix) with ESMTP id A82BDC02AC	for ; Thu, 28 Feb 2013 19:13:29 +0000 (UTC)
Received: from mail72-va3 (localhost.localdomain [127.0.0.1]) by mail72-va3 (MessageSwitch) id 1362078807355111_2387; Thu, 28 Feb 2013 19:13:27 +0000 (UTC)
Received: from VA3EHSMHS002.bigfish.com (unknown [10.7.14.254])	by mail72-va3.bigfish.com (Postfix) with ESMTP id 4D3E6A028D; Thu, 28 Feb 2013 19:13:27 +0000 (UTC)
Received: from BY2PRD0411HT001.namprd04.prod.outlook.com (157.56.237.133) by VA3EHSMHS002.bigfish.com (10.7.99.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 28 Feb 2013 19:13:23 +0000
Received: from BY2PRD0411MB441.namprd04.prod.outlook.com ([169.254.5.225]) by BY2PRD0411HT001.namprd04.prod.outlook.com ([10.255.128.36]) with mapi id 14.16.0275.006; Thu, 28 Feb 2013 19:13:20 +0000
From: Lewis Adam-CAL022 
To: Brian Campbell , John Bradley 
Thread-Topic: [OAUTH-WG] JWT - scope claim missing
Thread-Index: AQHOFZ6Qe5ExGqoPnkOeJlU0r70rz5iPcwoAgAAB5gCAAAWJgIAABAMAgAAIM4CAAAN2AIAACPeAgAAGkICAAAeWAIAAAR2A
Date: Thu, 28 Feb 2013 19:13:20 +0000
Message-ID: <59E470B10C4630419ED717AC79FCF9A948D58BEE@BY2PRD0411MB441.namprd04.prod.outlook.com>
References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net>     <48FD87D1-4DF4-4289-99B7-40A515F31890@oracle.com> <3E472720-31A4-40A0-AAA4-402CF850831A@ve7jtb.com> <7127843B-D7B0-4AB6-87F1-1604D1EFFA79@oracle.com> <50DA292F-32F0-4266-8401-006AD837B775@ve7jtb.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [184.78.105.93]
Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A948D58BEEBY2PRD0411MB441_"
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%1294$Dn%PINGIDENTITY.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn%
X-FOPE-CONNECTOR: Id%1294$Dn%VE7JTB.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn%
X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn%
X-CFilter-Loop: Reflected
X-OriginatorOrg: motorolasolutions.com
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] JWT - scope claim missing
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 19:13:44 -0000

--_000_59E470B10C4630419ED717AC79FCF9A948D58BEEBY2PRD0411MB441_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Brian, a few thoughts from somebody outside of the WG ...

As a newcomer to OAuth last year, I was initially confused by the titles.  =
It was confusing because we have SAML bearer *assertions* and JWT bearer *t=
okens* ... and as John just (begrudgingly) stated in this thread, the JWT i=
s being used as an assertion in this profile (and in OIDC).  I think it wil=
l be difficult to find a good name for these profiles since they do two ent=
irely different things (e.g. define a new grant type and define a new metho=
d of client authentication).  One could argue that as long as the WG is at =
it, then why not add a third section to the JWT profile, which talks about =
usage of JWT-structured bearer access tokens: it would not be any less rela=
ted than the other two focuses of the doc.  Then the document could be call=
ed something simple like "profiles of JWT usage in OAuth" or something like=
 that.

On one hand, it is probably na=EFve to think that an access token can be st=
andardized in a profile given how many have already been released into the =
wild, but on the other hand, a WG profile of a JWT-structured access token =
could lend itself to interoperability, where AS implementations can adverti=
se conformance to the profile and who knows ... maybe the RS's of the futur=
e will be good with this.

adam

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B=
rian Campbell
Sent: Thursday, February 28, 2013 1:03 PM
To: John Bradley
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] JWT - scope claim missing

I'm not sure anyone really "picked" the titles for the bearer token profile=
s. They just kind of evolved. And evolved in funny ways especially when cli=
ent authn to the AS was added.
You won't hear me argue that the titles are "good" and this is not the firs=
t time there's been confusion about what they actually do. They define new =
grant types and new client authentication methods. They *do not* define an =
access token format or anything else about access tokens. JWT and SAML coul=
d be used for that but that's not what these drafts do.
Suggestions for better title(s) would be more than welcome.

Here's what they are now:

SAML 2.0 Bearer Assertion Profiles for OAuth 2.0
draft-ietf-oauth-saml2-bearer

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
draft-ietf-oauth-jwt-bearer

Assertion Framework for OAuth 2.0
draft-ietf-oauth-assertions

On Thu, Feb 28, 2013 at 11:36 AM, John Bradley > wrote:
Yes the title likely adds to the confusion given that the bearer tokens are=
 not access tokens.

Things as separate from OAuth as the Firefox browerID spec use JWS signed J=
WTs.

The bearer token profiles for OAuth 2 are for OAuth2.

The JSON Web Token (JWT) spec did not start in OAuth and is not OAuth specific.

A JWT is:

JSON Web Token (JWT)  A string representing a set of claims as a JSON

      object that is encoded in a JWS or JWE, enabling the claims to be

      digitally signed or MACed and/or encrypted.

So OAuth or other profiles may define claims to go in a JWT, but the JWT ne=
eds to itself only define the claims necessary for security processing.

John B.
PS that was a soft ball If you hadn't responded I would have been disappoin=
ted.  I din't pick the title for the bearer token profiles.

On 2013-02-28, at 10:12 AM, Phil Hunt > wrote:

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

Note the title says "for OAuth2"

Sorry. Couldn't resist.

Phil

Sent from my phone.

On 2013-02-28, at 9:40, John Bradley > wrote:
JWT is an assertion( I am probably going to regret using that word).

It is used in openID connect for id_tokens, it is used in OAuth for Asserti=
on grant types and authentication of the client to the token endpoint.
http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

Dosen't define JWT's use for access tokens for the RS.

Bottom line JWT is for more than access tokens.

John B.

On 2013-02-28, at 9:28 AM, Phil Hunt > wrote:

Are you saying jwt is not an access token type?

Phil

Sent from my phone.

On 2013-02-28, at 8:58, John Bradley > wrote:
Yes, defining scope in JWT is the wrong place.   JWT needs to stick to the =
security claims needed to process JWT.

I also don't know how far you get requiring a specific authorization format=
 for JWT, some AS will wan to use a opaque reference, some might want to us=
e a user claim or role claim, others may use scopes,  combining scopes and =
claims is also possible.

Right now it is up to a AS RS pair to agree on how to communicate authoriza=
tion.   I don't want MAC to be more restrictive than bearer when it comes t=
o authorization between AS and RS.

Hannes wanted to know why JWT didn't define scope.  The simple answer is th=
at it is out of scope for JWT itself.   It might be defined in a OAuth acce=
ss token profile for JWT but it should not be specific to MAC.

John B.
On 2013-02-28, at 8:44 AM, Brian Campbell > wrote:

I think John's point was more that scope is something rather specific to an=
 OAuth access token and, while JWT is can be used to represent an access to=
ken, it's not the only application of JWT. The 'standard' claims in JWT are=
 those that are believed (right or wrong) to be widely applicable across di=
fferent applications of JWT. One could argue about it but scope is probably=
 not one of those.
It would probably make sense to try and build a profile of JWT specifically=
 for OAuth access tokens (though I suspect there are some turtles and drago=
ns in there), which might be the appropriate place to define/register a sco=
pe claim.

On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt > wrote:
Are you advocating TWO systems? That seems like a bad choice.

I would rather fix scope than go to a two system approach.

Phil

Sent from my phone.

On 2013-02-28, at 8:17, John Bradley > wrote:

> While scope is one method that a AS could communicate authorization to a =
RS, it is not the only or perhaps even the most likely one.
> Using scope requires a relatively tight binding between the RS and AS,  U=
MA uses a different mechanism that describes finer grained operations.
> The AS may include roles, user, or other more abstract claims that the th=
e client may (god help them) pass on to EXCML for processing.
>
> While having a scopes claim is possible, like any other claim it is not p=
art of the JWT core security processing claims, and needs to be defined by =
extension.
>
> John B.
> On 2013-02-28, at 2:29 AM, Hannes Tschofenig > wrote:
>
>> Hi Mike,
>>
>> when I worked on the MAC specification I noticed that the JWT does not h=
ave a claim for the scope. I believe that this would be needed to allow the=
 resource server to verify whether the scope the authorization server autho=
rized is indeed what the client is asking for.
>>
>> 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

--_000_59E470B10C4630419ED717AC79FCF9A948D58BEEBY2PRD0411MB441_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Brian, a few thoughts fr=
om somebody outside of the WG …

As a newcomer to OAuth last=
 year, I was initially confused by the titles.  It was confusing becau=
se we have SAML bearer *assertions* and JWT bearer *tokens*
 … and as John just (begrudgingly) stated in this thread, the JWT is =
being used as an assertion in this profile (and in OIDC).  I think it =
will be difficult to find a good name for these profiles since they do two =
entirely different things (e.g. define a new
 grant type and define a new method of client authentication).  One co=
uld argue that as long as the WG is at it, then why not add a third section=
 to the JWT profile, which talks about usage of JWT-structured bearer acces=
s tokens: it would not be any less related
 than the other two focuses of the doc.  Then the document could be ca=
lled something simple like “profiles of JWT usage in OAuth” or =
something like that. 

On one hand, it is probably=
 na=EFve to think that an access token can be standardized in a profile giv=
en how many have already been released into the wild, but
 on the other hand, a WG profile of a JWT-structured access token could len=
d itself to interoperability, where AS implementations can advertise confor=
mance to the profile and who knows … maybe the RS’s of the futu=
re will be good with this. 

adam

From: oauth-bo=
unces@ietf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Brian Campbell

Sent: Thursday, February 28, 2013 1:03 PM

To: John Bradley

Cc: oauth@ietf.org WG

Subject: Re: [OAUTH-WG] JWT - scope claim missing<=
/p>

I'm not sure anyone r=
eally "picked" the titles for the bearer token profiles. They jus=
t kind of evolved. And evolved in funny ways especially when client authn t=
o the AS was added.

You won't hear me arg=
ue that the titles are "good" and this is not the first time ther=
e's been confusion about what they actually do. They define new grant types=
 and new client authentication methods. They *do
 not* define an access token format or anything else about access tokens. J=
WT and SAML could be used for that but that's not what these drafts do.

Suggestions for better title(s) would be more than w=
elcome.

Here's what they are now:

SAML 2.0 Bearer Assertion Profiles for OAuth 2.0

draft-ietf-oauth-saml2-bearer

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

draft-ietf-oauth-jwt-bearer

Assertion Framework for OAuth 2.0

draft-ietf-oauth-assertions

On Thu, Feb 28, 2013 at 11:36 AM, John Bradley <<=
a href=3D"mailto:ve7jtb@ve7jtb.com" target=3D"_blank">ve7jtb@ve7jtb.com=
> wrote:

Yes the title likely adds to the confusion given tha=
t the bearer tokens are not access tokens.

Things as separate from OAuth as the Firefox browerI=
D spec use JWS signed JWTs.  

The bearer token profiles for OAuth 2 are for OAuth2=
.

The JSON Web Token (JWT)&n=
bsp;spec did not start in OAuth and is not OAuth specific.

A JWT is:

JSON Web Token (JWT)  A string r=
epresenting a set of claims as a JSON
      object=
 that is encoded in a JWS or JWE, enabling the claims to be
      digita=
lly signed or MACed and/or encrypted.

So OAuth or other profiles may define claims to go i=
n a JWT, but the JWT needs to itself only define the claims necessary for s=
ecurity processing.  

John B.

PS that was a soft ball If you hadn't responded I wo=
uld have been disappointed.  I din't pick the title for the bearer tok=
en profiles.

On 2013-02-28, at 10:12 AM, Phil Hunt <phil.hunt@oracle.com>=
; wrote:

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

Note the title says "for OAuth2"

Sorry. Couldn't resist. 

Phil

Sent from my phone.

On 2013-02-28, at 9:40, John Bradley <ve7jtb@ve7jtb.com> wrote:

JWT is an assertion( I am probably going to regret u=
sing that word).

It is used in openID connect for id_tokens, it is us=
ed in OAuth for Assertion grant types and authentication of the client to t=
he token endpoint.

http://tools.ietf.org/html/draft-ietf-o=
auth-jwt-bearer-04

JSON Web Token (JWT) Bearer Token Profiles =
for OAuth 2.0

Dosen't define JWT's use for access tokens for the R=
S.   

Bottom line JWT is for more than access tokens.=

John B.

On 2013-02-28, at 9:28 AM, Phil Hunt <phil.hunt@oracle.com>=
 wrote:

Are you saying jwt is not an access token type?

Phil

Sent from my phone.

On 2013-02-28, at 8:58, John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes, defining scope in JWT is the wrong place.  =
; JWT needs to stick to the security claims needed to process JWT.

I also don't know how far you get requiring a specif=
ic authorization format for JWT, some AS will wan to use a opaque reference=
, some might want to use a user claim or role claim, others may use scopes,=
  combining scopes and claims is also
 possible.

Right now it is up to a AS RS pair to agree on how t=
o communicate authorization.   I don't want MAC to be more restrictive=
 than bearer when it comes to authorization between AS and RS.

Hannes wanted to know why JWT didn't define scope. &=
nbsp;The simple answer is that it is out of scope for JWT itself.   It=
 might be defined in a OAuth access token profile for JWT but it should not=
 be specific to MAC.

John B.

On 2013-02-28, at 8:44 AM, Brian Campbell <bcampbell@pingide=
ntity.com> wrote:

I think John's point =
was more that scope is something rather specific to an OAuth access token a=
nd, while JWT is can be used to represent an access token, it's not the onl=
y application of JWT. The 'standard'
 claims in JWT are those that are believed (right or wrong) to be widely ap=
plicable across different applications of JWT. One could argue about it but=
 scope is probably not one of those.

It would probably make sense to try and build a prof=
ile of JWT specifically for OAuth access tokens (though I suspect there are=
 some turtles and dragons in there), which might be the appropriate place t=
o define/register a scope claim.

On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

Are you advocating TWO systems? That seems like a ba=
d choice.

I would rather fix scope than go to a two system approach.

Phil

Sent from my phone.

On 2013-02-28, at 8:17, John Bradley <ve7jtb@ve7jtb.com> wrote:

> While scope is one method that a AS could communicate authorization to=
 a RS, it is not the only or perhaps even the most likely one.

> Using scope requires a relatively tight binding between the RS and AS,=
  UMA uses a different mechanism that describes finer grained operatio=
ns.

> The AS may include roles, user, or other more abstract claims that the=
 the client may (god help them) pass on to EXCML for processing.

>

> While having a scopes claim is possible, like any other claim it is no=
t part of the JWT core security processing claims, and needs to be defined =
by extension.

>

> John B.

> On 2013-02-28, at 2:29 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net>=
 wrote:

>

>> Hi Mike,

>>

>> when I worked on the MAC specification I noticed that the JWT does=
 not have a claim for the scope. I believe that this would be needed to all=
ow the resource server to verify whether the scope the authorization server=
 authorized is indeed what the client
 is asking for.

>>

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

h=
ttps://www.ietf.org/mailman/listinfo/oauth

--_000_59E470B10C4630419ED717AC79FCF9A948D58BEEBY2PRD0411MB441_--

From oleg_gryb@yahoo.com  Thu Feb 28 11:21:08 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC11821F8B0A for ; Thu, 28 Feb 2013 11:21:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFNpVlNp79Hb for ; Thu, 28 Feb 2013 11:21:07 -0800 (PST)
Received: from nm18-vm0.bullet.mail.bf1.yahoo.com (nm18-vm0.bullet.mail.bf1.yahoo.com [98.139.213.138]) by ietfa.amsl.com (Postfix) with SMTP id 7DEFE21F89A4 for ; Thu, 28 Feb 2013 11:21:07 -0800 (PST)
Received: from [98.139.212.147] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 28 Feb 2013 19:21:06 -0000
Received: from [98.139.212.202] by tm4.bullet.mail.bf1.yahoo.com with NNFMP; 28 Feb 2013 19:21:06 -0000
Received: from [127.0.0.1] by omp1011.mail.bf1.yahoo.com with NNFMP; 28 Feb 2013 19:21:06 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 941986.26418.bm@omp1011.mail.bf1.yahoo.com
Received: (qmail 29395 invoked by uid 60001); 28 Feb 2013 19:21:06 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1362079266; bh=Vwgggfgx4DflXHKDIa/xWfku98jB/JxiGYMgUIcsTYk=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=ibtU4j7gsr+axYQsVEIgl+YyxF/ZTfbRpAFUY6JkkLBFLpACzcB0JGkH20vibp9yE62jsi/DudBvJj0iHw4fF808jig0bV/wH3jYBee6pcHgHvAhxVx/x11ZG/4fKolU+Cd0tbKIODkjJH3/Sut9WqgEIngWJ1ujL38GqxJMaMY=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=sYvzLERWXEy1c7ziSyiO2XmkdZ45UWjJv2fZH9RyQTaFSRU5mmPrHbRQSiu9vc/0GPoao/HscuKORtA+Ue1+ngmpNnX6Vt4Khs9tEJtkxh/U0CUSljcHn6a2WtRb6Bj+wIiOVSPytDBjpmfZjPlC/kJBn4gmhF6QhP6uuwFDY7M=;
X-YMail-OSG: kfI_PtYVM1nO3OUP1TbbgaLeC.DTXkd4CrxgzPlsKRf0H66 _mHJwwUffdF8TDxkW9.4MblRdPDW7d6csehlN5WEAfK64IC3i.UJ5PvJs.Tc GHY0BVNZJg4i88SiXxKSeMWFoddYbHIOslhlmU7zuiHXTTfuJMecPha92VoV R6Csxkta_NrLcV2Xlj9aIstU6ejHZx5XXEkLezsXBzH4n.qKa_lnx4yYXK1w L139WT6yn1ROwpbhFuh0Vd3JLlFaxI4qH5LyLUUSjdhIuCjENYFmy69GIZHe M3GDI51UfAvxhKUbnUvDCQ8ThtlshvINOX3xHAXD9E6PF1A9VEYz1ksTgO5r _njSB6nVqF6qXImmI1HHXnrUmgda.CEFn.8UrwObMX0ZEfM0clWrL4X4Gv8_ 9fhCDxvb0W4VO0bkqbfdPGvoyVpWYJ5g.vnPp6SbzA2ayoUwUSC8lR5Pw_8n Oxqo4Q.yTRi08OxiK7ioYVWzHSPYI1wgtDdVBuJLhTTlLrVXeBvMnrVVhdJ9 OYdsuV3QdulN38hI-
Received: from [199.16.140.28] by web141002.mail.bf1.yahoo.com via HTTP; Thu, 28 Feb 2013 11:21:06 PST
X-Rocket-MIMEInfo: 001.001, RGVhciBPQXV0aCBXRyBhbmQgQ2hhaXJzLA0KDQpDYW4gc29tZWJvZHkgcGxlYXNlIGNvbW1lbnQgdGhlIENlcnRpY29tJ3MgZGlzY2xvc3VyZSBiZWxvdz8gSWYgdGhlIHB1cnBvc2Ugb2YgdGhpcyBkaXNjbG9zdXJlIGlzIHRvIGluZm9ybSB1cyB0aGF0IEpXVCBjYW4gYmUgcG90ZW50aWFsbHkgYSBzdWJqZWN0IG9mIHJveWFsdGllcyBhbmQgb3RoZXIgcG9zc2libGUgbGVnYWwgYWN0aW9ucywgdGhlIHZhbHVlIG9mIGFkb3B0aW5nIEpXVCBpbiB0aGUgc2NvcGUgb2YgT0F1dGggMi4wIElFVEYgc3RhbmRhcmQBMAEBAQE-
X-Mailer: YahooMailClassic/15.1.4 YahooMailWebService/0.8.135.514
Message-ID: <1362079266.8952.YahooMailClassic@web141002.mail.bf1.yahoo.com>
Date: Thu, 28 Feb 2013 11:21:06 -0800 (PST)
From: Oleg Gryb 
To: oauth@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="348076277-717348825-1362079266=:8952"
Subject: [OAUTH-WG] Fw:  IPR Disclosure: - What to Do with JWT ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: oleg@gryb.info
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 19:21:09 -0000

--348076277-717348825-1362079266=:8952
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Dear OAuth WG and Chairs,

Can somebody please comment the Certicom's disclosure below? If the purpose=
 of this disclosure is to inform us that JWT can be potentially a subject o=
f royalties and other possible legal actions, the value of adopting JWT in =
the scope of OAuth 2.0 IETF standard would definitely diminish and if this =
is the case shouldn't we consider replacing it with something similar, but =
different, which would not be a subject of the future possible litigation?=
=A0 =A0=20

I'm not a lawyer and might not understand the statement below correctly, so=
 please let me know if/where I'm wrong. Please keep in mind also that the p=
opularity of JWT is growing fast along with the implementations, so we need=
 to do something quickly.

Thanks,
Oleg.

--- On Wed, 2/27/13, IETF Secretariat  wrote:

From: IETF Secretariat 
Subject: [OAUTH-WG] IPR Disclosure: Certicom Corporation's Statement about =
IPR related to draft-ietf-oauth-json-web-token-06 (2)
To: mbj@microsoft.com, ve7jtb@ve7jtb.com, n-sakimura@nri.co.jp
Cc: derek@ihtfp.com, oauth@ietf.org, ipr-announce@ietf.org
Date: Wednesday, February 27, 2013, 4:16 PM

Dear Michael Jones, John Bradley, Nat Sakimura:

 An IPR disclosure that pertains to your Internet-Draft entitled "JSON Web =
Token
(JWT)" (draft-ietf-oauth-json-web-token) was submitted to the IETF Secretar=
iat
on 2013-02-20 and has been posted on the "IETF Page of Intellectual Propert=
y
Rights Disclosures" (https://datatracker.ietf.org/ipr/1968/). The title of =
the
IPR disclosure is "Certicom Corporation's Statement about IPR related to dr=
aft-
ietf-oauth-json-web-token-06 (2)."");

The IETF Secretariat

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--348076277-717348825-1362079266=:8952
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Dear OAuth WG and Chairs,

Can somebody=
 please comment the Certicom's disclosure below? If the purpose of this dis=
closure is to inform us that JWT can be potentially a subject of royalties =
and other possible legal actions, the value of adopting JWT in the scope of=
 OAuth 2.0 IETF standard would definitely diminish and if this is the case =
shouldn't we consider replacing it with something similar, but different, w=
hich would not be a subject of the future possible litigation?   =

I'm not a lawyer and might not understand the statement below corr=
ectly, so please let me know if/where I'm wrong. Please keep in mind also t=
hat the popularity of JWT is growing fast along with the implementations, s=
o we need to do something quickly.

Thanks,
Oleg.

--- O=
n Wed, 2/27/13, IETF Secretariat <ietf-ipr@ietf.org>
 wrote:

From: IETF Secretariat <ietf-ipr=
@ietf.org>
Subject: [OAUTH-WG] IPR Disclosure: Certicom Corporation's=
 Statement about IPR related to draft-ietf-oauth-json-web-token-06 (2)
T=
o: mbj@microsoft.com, ve7jtb@ve7jtb.com, n-sakimura@nri.co.jp
Cc: derek@=
ihtfp.com, oauth@ietf.org, ipr-announce@ietf.org
Date: Wednesday, Februa=
ry 27, 2013, 4:16 PM

Dear Michael Jones=
, John Bradley, Nat Sakimura:

 An IPR disclosure that pertains to yo=
ur Internet-Draft entitled "JSON Web Token
(JWT)" (draft-ietf-oauth-json=
-web-token) was submitted to the IETF Secretariat
on 2013-02-20 and has =
been posted on the "IETF Page of Intellectual Property
Rights Disclosure=
s" (ht=
tps://datatracker.ietf.org/ipr/1968/). The title of the
IPR
 disclosure is "Certicom Corporation's Statement about IPR related to draft=
-
ietf-oauth-json-web-token-06 (2)."");

The IETF Secretariat
<=
br>_______________________________________________
OAuth mailing listOAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--348076277-717348825-1362079266=:8952--

From bcampbell@pingidentity.com  Thu Feb 28 11:25:12 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B704121F8519 for ; Thu, 28 Feb 2013 11:25:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.907
X-Spam-Level: 
X-Spam-Status: No, score=-5.907 tagged_above=-999 required=5 tests=[AWL=0.069,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgyrMoz1dsjq for ; Thu, 28 Feb 2013 11:25:03 -0800 (PST)
Received: from na3sys009aog122.obsmtp.com (na3sys009aog122.obsmtp.com [74.125.149.147]) by ietfa.amsl.com (Postfix) with ESMTP id C39C021F8501 for ; Thu, 28 Feb 2013 11:25:02 -0800 (PST)
Received: from mail-ob0-f199.google.com ([209.85.214.199]) (using TLSv1) by na3sys009aob122.postini.com ([74.125.148.12]) with SMTP ID DSNKUS+vDnZFRZp4PtbmTC2zqlfqdtTA47M1@postini.com; Thu, 28 Feb 2013 11:25:02 PST
Received: by mail-ob0-f199.google.com with SMTP id wd20so2000158obb.6 for ; Thu, 28 Feb 2013 11:25:02 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=BxaUrJmrhPFsm3lcTPKZMV63YyT799hB7vFYsCZ01xQ=; b=CExtaGsM4TV3yF2/wdbycoATD+n6oA5hKckP5TWSw4WBzlPzXSiebV32cbr965RGtx cmUn/6tOy5SmTkQOV+QsxNTkoVM60vueN+yt79FiR7A6xeeW2YR5mFAUP0Fg4virYHm0 r11AujqPL4SS2CGJP6DNbsd6nXOj+VihBg3pvQraO5uVRaHuOJT3q8hdyRF2kWN/FE0M 5r1bj9JB+kSMWxoSPXQ3xAVQhKf4q9jWvvWsKIPyXguNpS9pdJDkzP19L3dc1U9h4huH QNQKY5LwXdAWsz1Jv0xaxdgozqesi26NAaGHffn7FRMIFir7ZapaCl1Pynx5oxtY5KMO xiMA==
X-Received: by 10.50.151.179 with SMTP id ur19mr10855482igb.79.1362079501785;  Thu, 28 Feb 2013 11:25:01 -0800 (PST)
X-Received: by 10.50.151.179 with SMTP id ur19mr10855472igb.79.1362079501644;  Thu, 28 Feb 2013 11:25:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.32.106 with HTTP; Thu, 28 Feb 2013 11:24:31 -0800 (PST)
In-Reply-To: 
References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net>     <48FD87D1-4DF4-4289-99B7-40A515F31890@oracle.com> <3E472720-31A4-40A0-AAA4-402CF850831A@ve7jtb.com> <7127843B-D7B0-4AB6-87F1-1604D1EFFA79@oracle.com> <50DA292F-32F0-4266-8401-006AD837B775@ve7jtb.com> 
From: Brian Campbell 
Date: Thu, 28 Feb 2013 12:24:31 -0700
Message-ID: 
To: John Bradley 
Content-Type: multipart/alternative; boundary=e89a8f3b9ff5da0e5c04d6cdd863
X-Gm-Message-State: ALoCoQl4/y6fUmcNShLYiGtgNqQZMFAF1Bgm8HjqoSLtMjkS0ZYmx2lEjC2h/60mKsO1jZJDNP9vhp+DDeVTwBxC9kJVxOzu/3gsag3qfhD8aR8SrTgWNFwm6lQnDCJttbeXoje1ROIR
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] JWT - scope claim missing
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 19:25:12 -0000

--e89a8f3b9ff5da0e5c04d6cdd863
Content-Type: text/plain; charset=ISO-8859-1

To be fair, I think it was Phil who first conflated the things :) I just
picked up the ball and ran with it. But you are right, I did kind of hijack
the thread which was originally about if a scope claim should be defined in
draft-ietf-oauth-json-web-token. I'd say no but I can see how an argument
could be made the other way.

On Thu, Feb 28, 2013 at 12:03 PM, Brian Campbell  wrote:

> I'm not sure anyone really "picked" the titles for the bearer token
> profiles. They just kind of evolved. And evolved in funny ways especially
> when client authn to the AS was added.
>
> You won't hear me argue that the titles are "good" and this is not the
> first time there's been confusion about what they actually do. They define
> new grant types and new client authentication methods. They *do not* define
> an access token format or anything else about access tokens. JWT and SAML
> could be used for that but that's not what these drafts do.
>
> Suggestions for better title(s) would be more than welcome.
>
> Here's what they are now:
>
> SAML 2.0 Bearer Assertion Profiles for OAuth 2.0
> draft-ietf-oauth-saml2-bearer
>
>
> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
>  draft-ietf-oauth-jwt-bearer
>
> Assertion Framework for OAuth 2.0
> draft-ietf-oauth-assertions
>
>
> On Thu, Feb 28, 2013 at 11:36 AM, John Bradley  wrote:
>
>> Yes the title likely adds to the confusion given that the bearer tokens
>> are not access tokens.
>>
>> Things as separate from OAuth as the Firefox browerID spec use JWS signed
>> JWTs.
>>
>> The bearer token profiles for OAuth 2 are for OAuth2.
>>
>> The JSON Web Token (JWT) spec
>> did not start in OAuth and is not OAuth specific.
>>
>> A JWT is:
>>
>> JSON Web Token (JWT)  A string representing a set of claims as a JSON
>>       object that is encoded in a JWS or JWE, enabling the claims to be
>>       digitally signed or MACed and/or encrypted.
>>
>>
>> So OAuth or other profiles may define claims to go in a JWT, but the JWT
>> needs to itself only define the claims necessary for security processing.
>>
>> John B.
>> PS that was a soft ball If you hadn't responded I would have been
>> disappointed.  I din't pick the title for the bearer token profiles.
>>
>>
>> On 2013-02-28, at 10:12 AM, Phil Hunt  wrote:
>>
>>
>>
>>
>> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
>>
>>
>> Note the title says "for OAuth2"
>>
>> Sorry. Couldn't resist.
>>
>> Phil
>>
>> Sent from my phone.
>>
>> On 2013-02-28, at 9:40, John Bradley  wrote:
>>
>> JWT is an assertion( I am probably going to regret using that word).
>>
>> It is used in openID connect for id_tokens, it is used in OAuth for
>> Assertion grant types and authentication of the client to the token
>> endpoint.
>> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04
>>
>> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
>>
>>
>> Dosen't define JWT's use for access tokens for the RS.
>>
>> Bottom line JWT is for more than access tokens.
>>
>> John B.
>>
>> On 2013-02-28, at 9:28 AM, Phil Hunt  wrote:
>>
>> Are you saying jwt is not an access token type?
>>
>> Phil
>>
>> Sent from my phone.
>>
>> On 2013-02-28, at 8:58, John Bradley  wrote:
>>
>> Yes, defining scope in JWT is the wrong place.   JWT needs to stick to
>> the security claims needed to process JWT.
>>
>> I also don't know how far you get requiring a specific authorization
>> format for JWT, some AS will wan to use a opaque reference, some might want
>> to use a user claim or role claim, others may use scopes,  combining scopes
>> and claims is also possible.
>>
>> Right now it is up to a AS RS pair to agree on how to communicate
>> authorization.   I don't want MAC to be more restrictive than bearer when
>> it comes to authorization between AS and RS.
>>
>> Hannes wanted to know why JWT didn't define scope.  The simple answer is
>> that it is out of scope for JWT itself.   It might be defined in a OAuth
>> access token profile for JWT but it should not be specific to MAC.
>>
>> John B.
>> On 2013-02-28, at 8:44 AM, Brian Campbell 
>> wrote:
>>
>> I think John's point was more that scope is something rather specific to
>> an OAuth access token and, while JWT is can be used to represent an access
>> token, it's not the only application of JWT. The 'standard' claims in JWT
>> are those that are believed (right or wrong) to be widely applicable across
>> different applications of JWT. One could argue about it but scope is
>> probably not one of those.
>>
>> It would probably make sense to try and build a profile of JWT
>> specifically for OAuth access tokens (though I suspect there are some
>> turtles and dragons in there), which might be the appropriate place to
>> define/register a scope claim.
>>
>>
>> On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt  wrote:
>>
>>> Are you advocating TWO systems? That seems like a bad choice.
>>>
>>> I would rather fix scope than go to a two system approach.
>>>
>>> Phil
>>>
>>> Sent from my phone.
>>>
>>> On 2013-02-28, at 8:17, John Bradley  wrote:
>>>
>>> > While scope is one method that a AS could communicate authorization to
>>> a RS, it is not the only or perhaps even the most likely one.
>>> > Using scope requires a relatively tight binding between the RS and AS,
>>>  UMA uses a different mechanism that describes finer grained operations.
>>> > The AS may include roles, user, or other more abstract claims that the
>>> the client may (god help them) pass on to EXCML for processing.
>>> >
>>> > While having a scopes claim is possible, like any other claim it is
>>> not part of the JWT core security processing claims, and needs to be
>>> defined by extension.
>>> >
>>> > John B.
>>> > On 2013-02-28, at 2:29 AM, Hannes Tschofenig <
>>> hannes.tschofenig@gmx.net> wrote:
>>> >
>>> >> Hi Mike,
>>> >>
>>> >> when I worked on the MAC specification I noticed that the JWT does
>>> not have a claim for the scope. I believe that this would be needed to
>>> allow the resource server to verify whether the scope the authorization
>>> server authorized is indeed what the client is asking for.
>>> >>
>>> >> 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
>>>
>>
>>
>>
>>
>>
>

--e89a8f3b9ff5da0e5c04d6cdd863
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

To be fair, I think it was Phil who first conflated the th=
ings :) I just picked up the ball and ran with it. But you are right, I did=
 kind of hijack the thread which was originally about if a scope claim shou=
ld be defined in draft-ietf-oauth-json-web-token. I'd say no but I can =
see how an argument could be made the other way.

On Thu,=
 Feb 28, 2013 at 12:03 PM, Brian Campbell <bcampbell@pingidentity=
.com> wrote:

I'm not sure anyon=
e really "picked" the titles for the bearer token profiles. They =
just kind of evolved. And evolved in funny ways especially when client auth=
n to the AS was added. 

You won't hear me argue that the titles are "good"=
 and this is not the first time there's been confusion about what they =
actually do. They define new grant types and new client authentication meth=
ods. They *do not* define an access token format or anything else about acc=
ess tokens. JWT and SAML could be used for that but that's not what the=
se drafts do. 

Suggestions for better title(s) would be more than welcome.<=
br>

Here's what they are now:
=

SAML 2.0 Bearer Assertion Profiles for OAuth 2.0
draft-ietf-oauth-sa=
ml2-bearer

JSON Web Token (JWT) Bearer Token Profi=
les for OAuth 2.0

draft-ietf-oauth-jwt-bearer

Assertion Framework for OAuth 2.0
dra=
ft-ietf-oauth-assertions

On Thu, Feb 28, 2013 at 11:36 AM, John Br=
adley <ve7jtb@ve7jtb.com> wrote:

Yes the title likely adds to the confus=
ion given that the bearer tokens are not access tokens.
=
Things as separate from OAuth as the Firefox browerID spec use JWS signed J=
WTs. =A0

The bearer token profiles for OAuth 2 are for OAuth2.
The=A0JSON Web Token (JWT)=A0s=
pec did not start in OAuth and is not OAuth specific.

A JWT is:
JSON Web Token (JWT)  A string representing a se=
t of claims as a JSON
      object that is encoded in a JWS or JWE, enabling the claims to be
      digitally signed or MACed and/or encrypted.

So OAuth or other profiles may define claims to g=
o in a JWT, but the JWT needs to itself only define the claims necessary fo=
r security processing. =A0

John B.
PS th=
at was a soft ball If you hadn't responded I would have been disappoint=
ed. =A0I din't pick the title for the bearer token profiles.

On 2013-02-28, at 10:12 A=
M, Phil Hunt <=
phil.hunt@oracle.com> wrote:

        <=
h1 style=3D"display:inline">

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0=

Note the title says "for OAuth2"
Sorry. Couldn't resist.=A0

Phil
Sent =
from my phone.

On 2013-02-28, at 9:40, John Bradley <=
;ve7jtb@ve7jtb.com> wrote:

JWT is an assertion( I am probably goin=
g to regret using that word).
It is used in openID conne=
ct for id_tokens, it is used in OAuth for Assertion grant types and authent=
ication of the client to the token endpoint.

http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04=

JSON Web Toke=
n (JWT) Bearer Token Profiles for OAuth 2.0

Dosen't define JWT's use for access tokens for the RS. =A0=A0<=
/div>
Bottom line JWT is for more than access tokens.
John B.

On 2013-02-28,=
 at 9:28 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

Are you saying jwt is =
not an access token type?

Phil
Sent from my phone=
.

On 2013-02-28, at 8:58, John Bradley <ve7jtb@ve7jtb.com> wrote:=

Yes, defining scope in JWT is the wrong=
 place. =A0 JWT needs to stick to the security claims needed to process JWT=
.
I also don't know how far you get requiring a spec=
ific authorization format for JWT, some AS will wan to use a opaque referen=
ce, some might want to use a user claim or role claim, others may use scope=
s, =A0combining scopes and claims is also possible.

Right now it is up to a AS RS pair to agree on how to c=
ommunicate authorization. =A0 I don't want MAC to be more restrictive t=
han bearer when it comes to authorization between AS and RS.

Hannes wanted to know why JWT didn't define scope. =A0The si=
mple answer is that it is out of scope for JWT itself. =A0 It might be defi=
ned in a OAuth access token profile for JWT but it should not be specific t=
o MAC.

John B.
On 2013-02-28, at 8:44 AM, =
Brian Campbell <bcampbell@pingidentity.com> wrote:

I think John's point was more that scope is somet=
hing rather specific to an OAuth access token and, while JWT is can be used=
 to represent an access token, it's not the only application of JWT. Th=
e 'standard' claims in JWT are those that are believed (right or wr=
ong) to be widely applicable across different applications of JWT. One coul=
d argue about it but scope is probably not one of those.

It would probably make sense to try and build a profile of JWT sp=
ecifically for OAuth access tokens (though I suspect there are some turtles=
 and dragons in there), which might be the appropriate place to define/regi=
ster a scope claim.

On Thu,=
 Feb 28, 2013 at 9:24 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

Are you advocating TWO sy=
stems? That seems like a bad choice.

I would rather fix scope than go to a two system approach.

Phil

Sent from my phone.

On 2013-02-28, at 8:17, John Bradley <ve7jtb@ve7jtb.com> wrote:

> While scope is one method that a AS could communicate authorization to=
 a RS, it is not the only or perhaps even the most likely one.

> Using scope requires a relatively tight binding between the RS and AS,=
 =A0UMA uses a different mechanism that describes finer grained operations.=

> The AS may include roles, user, or other more abstract claims that the=
 the client may (god help them) pass on to EXCML for processing.

>

> While having a scopes claim is possible, like any other claim it is no=
t part of the JWT core security processing claims, and needs to be defined =
by extension.

>

> John B.

> On 2013-02-28, at 2:29 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net>=
 wrote:

>

>> Hi Mike,

>>

>> when I worked on the MAC specification I noticed that the JWT does=
 not have a claim for the scope. I believe that this would be needed to all=
ow the resource server to verify whether the scope the authorization server=
 authorized is indeed what the client is asking for.

>>

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

h=
ttps://www.ietf.org/mailman/listinfo/oauth

<=
/blockquote>

--e89a8f3b9ff5da0e5c04d6cdd863--

From bcampbell@pingidentity.com  Thu Feb 28 11:36:58 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6021621F86F4 for ; Thu, 28 Feb 2013 11:36:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.909
X-Spam-Level: 
X-Spam-Status: No, score=-5.909 tagged_above=-999 required=5 tests=[AWL=0.067,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwry3F1n8Pb8 for ; Thu, 28 Feb 2013 11:36:56 -0800 (PST)
Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE6721F8698 for ; Thu, 28 Feb 2013 11:36:56 -0800 (PST)
Received: from mail-ia0-f199.google.com ([209.85.210.199]) (using TLSv1) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKUS+x2BVj59i5mNh936UERvqkYt5vL6Cj@postini.com; Thu, 28 Feb 2013 11:36:56 PST
Received: by mail-ia0-f199.google.com with SMTP id o25so8656975iad.6 for ; Thu, 28 Feb 2013 11:36:55 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=YHH1w6t4CMa5QM1aRTCrtKbKeaTTA9K6N0NUwut3wLY=; b=RFfiEq/qR5qWeSHdfMlV14fEnPfCsOJigVMgBE218viV5xl3ziK8RUWKVFb0MdDkRw WswabRB6to9pjyGlFdjWUu9ponlDN7lapZk+la15SeMRRig6JEyOv5iV9xyQHxHSSg+x gRtrWkBaxcmx956YtCvfIQh4JrRWB8x6YHgGt57AwOaVv2ov5ErDWY8EETby7yPObAlZ GVOLM+DP7xfY900zhdCwRvzM0GpleumOk2gvjchvEsp8Vj2XMxZkMW5f6Pw8MAULRzNY Im6zs3lrchpOV0kU/22IEEDCjsE70nxExODxNQ/qCHZUKOH3LvPDTcahPeP+vD8qok1K 90Og==
X-Received: by 10.42.122.66 with SMTP id m2mr4101042icr.15.1362080215667; Thu, 28 Feb 2013 11:36:55 -0800 (PST)
X-Received: by 10.42.122.66 with SMTP id m2mr4101036icr.15.1362080215497; Thu, 28 Feb 2013 11:36:55 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.32.106 with HTTP; Thu, 28 Feb 2013 11:36:25 -0800 (PST)
In-Reply-To: <59E470B10C4630419ED717AC79FCF9A948D58BEE@BY2PRD0411MB441.namprd04.prod.outlook.com>
References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net>     <48FD87D1-4DF4-4289-99B7-40A515F31890@oracle.com> <3E472720-31A4-40A0-AAA4-402CF850831A@ve7jtb.com> <7127843B-D7B0-4AB6-87F1-1604D1EFFA79@oracle.com> <50DA292F-32F0-4266-8401-006AD837B775@ve7jtb.com>  <59E470B10C4630419ED717AC79FCF9A948D58BEE@BY2PRD0411MB441.namprd04.prod.outlook.com>
From: Brian Campbell 
Date: Thu, 28 Feb 2013 12:36:25 -0700
Message-ID: 
To: Lewis Adam-CAL022 
Content-Type: multipart/alternative; boundary=20cf3003bbb6669a1204d6ce0317
X-Gm-Message-State: ALoCoQnKSnePp3KCWtzEIaku4VZhLlJRIP5Zm1IqmSsmJ5NwIfxCLRv3JpcTGprvMJDRwueoXEoES6naFb/57W3qoyD6wUZa7FkDuiULp3Ny7yWDsVV7+NKFcZFVDL7jeA5HxqWtR/LY
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] JWT - scope claim missing
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 19:36:58 -0000

--20cf3003bbb6669a1204d6ce0317
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I do agree that a WG profile of a JWT-structured access token could lend
itself to interoperability and ultimately be a useful thing. But you are
right that there already are many implementations out there in the wild
(heck, I've written one myself) and that might make it difficult to
standardize on something.

Because of that, and many other reasons, I don't want to try and add that
to existing assertion drafts.

On Thu, Feb 28, 2013 at 12:13 PM, Lewis Adam-CAL022 <
Adam.Lewis@motorolasolutions.com> wrote:

>  Hi Brian, a few thoughts from somebody outside of the WG =85 ****
>
> ** **
>
> As a newcomer to OAuth last year, I was initially confused by the titles.
> It was confusing because we have SAML bearer **assertions** and JWT
> bearer **tokens** =85 and as John just (begrudgingly) stated in this
> thread, the JWT is being used as an assertion in this profile (and in
> OIDC).  I think it will be difficult to find a good name for these profil=
es
> since they do two entirely different things (e.g. define a new grant type
> and define a new method of client authentication).  One could argue that =
as
> long as the WG is at it, then why not add a third section to the JWT
> profile, which talks about usage of JWT-structured bearer access tokens: =
it
> would not be any less related than the other two focuses of the doc.  The=
n
> the document could be called something simple like =93profiles of JWT usa=
ge
> in OAuth=94 or something like that.  ****
>
> ** **
>
> On one hand, it is probably na=EFve to think that an access token can be
> standardized in a profile given how many have already been released into
> the wild, but on the other hand, a WG profile of a JWT-structured access
> token could lend itself to interoperability, where AS implementations can
> advertise conformance to the profile and who knows =85 maybe the RS=92s o=
f the
> future will be good with this.  ****
>
> ** **
>
> adam****
>
> ** **
>
> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf
> Of *Brian Campbell
> *Sent:* Thursday, February 28, 2013 1:03 PM
> *To:* John Bradley
> *Cc:* oauth@ietf.org WG
>
> *Subject:* Re: [OAUTH-WG] JWT - scope claim missing****
>
>  ** **
>
> I'm not sure anyone really "picked" the titles for the bearer token
> profiles. They just kind of evolved. And evolved in funny ways especially
> when client authn to the AS was added. ****
>
> You won't hear me argue that the titles are "good" and this is not the
> first time there's been confusion about what they actually do. They defin=
e
> new grant types and new client authentication methods. They *do not* defi=
ne
> an access token format or anything else about access tokens. JWT and SAML
> could be used for that but that's not what these drafts do. ****
>
> Suggestions for better title(s) would be more than welcome.****
>
> ** **
>
> Here's what they are now:****
>
>
> SAML 2.0 Bearer Assertion Profiles for OAuth 2.0
> draft-ietf-oauth-saml2-bearer
>
> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
> draft-ietf-oauth-jwt-bearer
>
> Assertion Framework for OAuth 2.0
> draft-ietf-oauth-assertions****
>
> ** **
>
> On Thu, Feb 28, 2013 at 11:36 AM, John Bradley  wrote:=
*
> ***
>
> Yes the title likely adds to the confusion given that the bearer tokens
> are not access tokens.****
>
> ** **
>
> Things as separate from OAuth as the Firefox browerID spec use JWS signed
> JWTs.  ****
>
> ** **
>
> The bearer token profiles for OAuth 2 are for OAuth2.****
>
> ** **
>
> The JSON Web Token (JWT) spec
> did not start in OAuth and is not OAuth specific.****
>
> ** **
>
> A JWT is:****
>
> JSON Web Token (JWT)  A string representing a set of claims as a JSON****
>
>       object that is encoded in a JWS or JWE, enabling the claims to be**=
**
>
>       digitally signed or MACed and/or encrypted.****
>
>  ** **
>
> So OAuth or other profiles may define claims to go in a JWT, but the JWT
> needs to itself only define the claims necessary for security processing.
> ****
>
> ** **
>
> John B.****
>
> PS that was a soft ball If you hadn't responded I would have been
> disappointed.  I din't pick the title for the bearer token profiles.****
>
> ** **
>
> ** **
>
> On 2013-02-28, at 10:12 AM, Phil Hunt  wrote:****
>
>
>
> ****
>  JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0****
>
>
> Note the title says "for OAuth2"****
>
> ** **
>
> Sorry. Couldn't resist. ****
>
> ** **
>
> Phil****
>
> ** **
>
> Sent from my phone.****
>
>
> On 2013-02-28, at 9:40, John Bradley  wrote:****
>
> JWT is an assertion( I am probably going to regret using that word).****
>
> ** **
>
> It is used in openID connect for id_tokens, it is used in OAuth for
> Assertion grant types and authentication of the client to the token
> endpoint.****
>
> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04****
>
> ** **
>
> ** **
>
> ** **
>
> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0****
>
> ** **
>
> Dosen't define JWT's use for access tokens for the RS.   ****
>
> ** **
>
> Bottom line JWT is for more than access tokens.****
>
> ** **
>
> John B.****
>
> ** **
>
> On 2013-02-28, at 9:28 AM, Phil Hunt  wrote:****
>
>
>
> ****
>
> Are you saying jwt is not an access token type?
>
> Phil****
>
> ** **
>
> Sent from my phone.****
>
>
> On 2013-02-28, at 8:58, John Bradley  wrote:****
>
> Yes, defining scope in JWT is the wrong place.   JWT needs to stick to th=
e
> security claims needed to process JWT.****
>
> ** **
>
> I also don't know how far you get requiring a specific authorization
> format for JWT, some AS will wan to use a opaque reference, some might wa=
nt
> to use a user claim or role claim, others may use scopes,  combining scop=
es
> and claims is also possible.****
>
> ** **
>
> Right now it is up to a AS RS pair to agree on how to communicate
> authorization.   I don't want MAC to be more restrictive than bearer when
> it comes to authorization between AS and RS.****
>
> ** **
>
> Hannes wanted to know why JWT didn't define scope.  The simple answer is
> that it is out of scope for JWT itself.   It might be defined in a OAuth
> access token profile for JWT but it should not be specific to MAC.****
>
> ** **
>
> John B.****
>
> On 2013-02-28, at 8:44 AM, Brian Campbell 
> wrote:****
>
>
>
> ****
>
> I think John's point was more that scope is something rather specific to
> an OAuth access token and, while JWT is can be used to represent an acces=
s
> token, it's not the only application of JWT. The 'standard' claims in JWT
> are those that are believed (right or wrong) to be widely applicable acro=
ss
> different applications of JWT. One could argue about it but scope is
> probably not one of those.****
>
> It would probably make sense to try and build a profile of JWT
> specifically for OAuth access tokens (though I suspect there are some
> turtles and dragons in there), which might be the appropriate place to
> define/register a scope claim.****
>
> ** **
>
> On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt  wrote:*=
*
> **
>
> Are you advocating TWO systems? That seems like a bad choice.
>
> I would rather fix scope than go to a two system approach.
>
> Phil
>
> Sent from my phone.
>
> On 2013-02-28, at 8:17, John Bradley  wrote:
>
> > While scope is one method that a AS could communicate authorization to =
a
> RS, it is not the only or perhaps even the most likely one.
> > Using scope requires a relatively tight binding between the RS and AS,
>  UMA uses a different mechanism that describes finer grained operations.
> > The AS may include roles, user, or other more abstract claims that the
> the client may (god help them) pass on to EXCML for processing.
> >
> > While having a scopes claim is possible, like any other claim it is not
> part of the JWT core security processing claims, and needs to be defined =
by
> extension.
> >
> > John B.
> > On 2013-02-28, at 2:29 AM, Hannes Tschofenig 
> wrote:
> >
> >> Hi Mike,
> >>
> >> when I worked on the MAC specification I noticed that the JWT does not
> have a claim for the scope. I believe that this would be needed to allow
> the resource server to verify whether the scope the authorization server
> authorized is indeed what the client is asking for.
> >>
> >> 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****
>
> ** **
>
> ** **
>
>  ** **
>
>  ** **
>
> ** **
>

--20cf3003bbb6669a1204d6ce0317
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I do agree that a WG profile of a JWT-structured acce=
ss token could lend itself to interoperability and ultimately be a useful t=
hing. But you are right that there already are many implementations out the=
re in the wild (heck, I've written one myself) and that might make it d=
ifficult to standardize on something.

Because of that, and many other reasons, I don't want to try =
and add that to existing assertion drafts.

On Thu, Feb 28, 2013 at 12:13 PM, Lewis Ad=
am-CAL022 <Adam.Lewis@motorolasolutions.com> =
wrote:

Hi Brian, a few thoughts fr=
om somebody outside of the WG =85

=A0
As a newcomer to OAuth last=
 year, I was initially confused by the titles.=A0 It was confusing because =
we have SAML bearer *assertions* and JWT bearer *tokens*
 =85 and as John just (begrudgingly) stated in this thread, the JWT is bein=
g used as an assertion in this profile (and in OIDC).=A0 I think it will be=
 difficult to find a good name for these profiles since they do two entirel=
y different things (e.g. define a new
 grant type and define a new method of client authentication).=A0 One could=
 argue that as long as the WG is at it, then why not add a third section to=
 the JWT profile, which talks about usage of JWT-structured bearer access t=
okens: it would not be any less related
 than the other two focuses of the doc.=A0 Then the document could be calle=
d something simple like =93profiles of JWT usage in OAuth=94 or something l=
ike that.=A0

=A0
On one hand, it is probably=
 na=EFve to think that an access token can be standardized in a profile giv=
en how many have already been released into the wild, but
 on the other hand, a WG profile of a JWT-structured access token could len=
d itself to interoperability, where AS implementations can advertise confor=
mance to the profile and who knows =85 maybe the RS=92s of the future will =
be good with this.=A0

=A0
adam
=A0

From: oauth-bounces@ietf.org=
 [mailto:oa=
uth-bounces@ietf.org]
On Behalf Of Brian Campbell

Sent: Thursday, February 28, 2013 1:03 PM

To: John Bradley

Cc: oauth@ietf.o=
rg WG

Subject: Re: [OAUTH-WG] JWT - scope claim missing

=A0

I'm not sure anyo=
ne really "picked" the titles for the bearer token profiles. They=
 just kind of evolved. And evolved in funny ways especially when client aut=
hn to the AS was added.

You won't hear me=
 argue that the titles are "good" and this is not the first time =
there's been confusion about what they actually do. They define new gra=
nt types and new client authentication methods. They *do
 not* define an access token format or anything else about access tokens. J=
WT and SAML could be used for that but that's not what these drafts do.

Suggestions for better title(s) would be more than w=
elcome.

=A0

Here's what they are now:

SAML 2.0 Bearer Assertion Profiles for OAuth 2.0

draft-ietf-oauth-saml2-bearer

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

draft-ietf-oauth-jwt-bearer

Assertion Framework for OAuth 2.0

draft-ietf-oauth-assertions

=A0

On Thu, Feb 28, 2013 at 11:36 AM, John Bradley <<=
a href=3D"mailto:ve7jtb@ve7jtb.com" target=3D"_blank">ve7jtb@ve7jtb.com=
> wrote:

Yes the title likely adds to the confusion given tha=
t the bearer tokens are not access tokens.

=A0

Things as separate from OAuth as the Firefox browerI=
D spec use JWS signed JWTs. =A0

=A0

The bearer token profiles for OAuth 2 are for OAuth2=
.

=A0

The=A0JSON Web Token (JWT)=A0sp=
ec did not start in OAuth and is not OAuth specific.

=A0

A JWT is:

JSON Web Token (JWT)=A0 A string repr=
esenting a set of claims as a JSON
=A0=A0=A0=A0=A0 object that is encode=
d in a JWS or JWE, enabling the claims to be
=A0=A0=A0=A0=A0 digitally signed or M=
ACed and/or encrypted.

=A0

So OAuth or other profiles may define claims to go i=
n a JWT, but the JWT needs to itself only define the claims necessary for s=
ecurity processing. =A0

=A0

John B.

PS that was a soft ball If you hadn't responded =
I would have been disappointed. =A0I din't pick the title for the beare=
r token profiles.

=A0

=A0

On 2013-02-28, at 10:12 AM, Phil Hunt <phil.hunt@oracle.com>=
; wrote:

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

Note the title says "for OAuth2"

=A0

Sorry. Couldn't resist.=A0

=A0

Phil

=A0

Sent from my phone.

On 2013-02-28, at 9:40, John Bradley <ve7jtb@ve7jtb.com> wrote:

JWT is an assertion( I am probably going to regret u=
sing that word).

=A0

It is used in openID connect for id_tokens, it is us=
ed in OAuth for Assertion grant types and authentication of the client to t=
he token endpoint.

http://tools.ietf.org/html/draft-ietf-o=
auth-jwt-bearer-04

=A0

=A0
=A0
JS=
ON Web Token (JWT) Bearer Token Profiles for OAuth 2.0=

=A0

Dosen't define JWT's use for access tokens f=
or the RS. =A0=A0

=A0

Bottom line JWT is for more than access tokens.

=A0

John B.

=A0

On 2013-02-28, at 9:28 AM, Phil Hunt <phil.hunt@oracle.com>=
 wrote:

Are you saying jwt is not an access token type?

Phil

=A0

Sent from my phone.

On 2013-02-28, at 8:58, John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes, defining scope in JWT is the wrong place. =A0 J=
WT needs to stick to the security claims needed to process JWT.

=A0

I also don't know how far you get requiring a sp=
ecific authorization format for JWT, some AS will wan to use a opaque refer=
ence, some might want to use a user claim or role claim, others may use sco=
pes, =A0combining scopes and claims is also
 possible.

=A0

Right now it is up to a AS RS pair to agree on how t=
o communicate authorization. =A0 I don't want MAC to be more restrictiv=
e than bearer when it comes to authorization between AS and RS.

=A0

Hannes wanted to know why JWT didn't define scop=
e. =A0The simple answer is that it is out of scope for JWT itself. =A0 It m=
ight be defined in a OAuth access token profile for JWT but it should not b=
e specific to MAC.

=A0

John B.

On 2013-02-28, at 8:44 AM, Brian Campbell <bcampbell@pingide=
ntity.com> wrote:

I think John's po=
int was more that scope is something rather specific to an OAuth access tok=
en and, while JWT is can be used to represent an access token, it's not=
 the only application of JWT. The 'standard'
 claims in JWT are those that are believed (right or wrong) to be widely ap=
plicable across different applications of JWT. One could argue about it but=
 scope is probably not one of those.

It would probably make sense to try and build a prof=
ile of JWT specifically for OAuth access tokens (though I suspect there are=
 some turtles and dragons in there), which might be the appropriate place t=
o define/register a scope claim.

=A0

On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

Are you advocating TWO systems? That seems like a ba=
d choice.

I would rather fix scope than go to a two system approach.

Phil

Sent from my phone.

On 2013-02-28, at 8:17, John Bradley <ve7jtb@ve7jtb.com> wrote:

> While scope is one method that a AS could communicate authorization to=
 a RS, it is not the only or perhaps even the most likely one.

> Using scope requires a relatively tight binding between the RS and AS,=
 =A0UMA uses a different mechanism that describes finer grained operations.=

> The AS may include roles, user, or other more abstract claims that the=
 the client may (god help them) pass on to EXCML for processing.

>

> While having a scopes claim is possible, like any other claim it is no=
t part of the JWT core security processing claims, and needs to be defined =
by extension.

>

> John B.

> On 2013-02-28, at 2:29 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net>=
 wrote:

>

>> Hi Mike,

>>

>> when I worked on the MAC specification I noticed that the JWT does=
 not have a claim for the scope. I believe that this would be needed to all=
ow the resource server to verify whether the scope the authorization server=
 authorized is indeed what the client
 is asking for.

>>

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

h=
ttps://www.ietf.org/mailman/listinfo/oauth

=A0

=A0

=A0

=A0

=A0

--20cf3003bbb6669a1204d6ce0317--

From jricher@mitre.org  Thu Feb 28 11:40:44 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4481421F86F4 for ; Thu, 28 Feb 2013 11:40:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.578
X-Spam-Level: 
X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.020,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVpsRu43ERor for ; Thu, 28 Feb 2013 11:40:39 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4130B21F8717 for ; Thu, 28 Feb 2013 11:40:29 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 509301F04A7; Thu, 28 Feb 2013 14:40:28 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 2FB4C1F0499; Thu, 28 Feb 2013 14:40:28 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 28 Feb 2013 14:40:27 -0500
Message-ID: <512FB26D.5030401@mitre.org>
Date: Thu, 28 Feb 2013 14:39:25 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Brian Campbell 
References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net>     <48FD87D1-4DF4-4289-99B7-40A515F31890@oracle.com> <3E472720-31A4-40A0-AAA4-402CF850831A@ve7jtb.com> <7127843B-D7B0-4AB6-87F1-1604D1EFFA79@oracle.com> <50DA292F-32F0-4266-8401-006AD837B775@ve7jtb.com>  <59E470B10C4630419ED717AC79FCF9A948D58BEE@BY2PRD0411MB441.namprd04.prod.outlook.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080405010908090104000606"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] JWT - scope claim missing
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 19:40:44 -0000

--------------080405010908090104000606
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit

It doesn't belong in the assertion drafts, but maybe it can be combined 
with the token introspection piece I've started (but isn't an item yet)? 
I think that would address the other thread that Hannes was talking 
about as well. We'd essentially be defining one set of token metadata 
(including scopes, client_id, subject, audience, expiration and a few 
others) and two methods to get at it: either by making an introspection 
call, or by packing it into the token directly. And the two could even 
work together if you wanted to.

  -- Justin

On 02/28/2013 02:36 PM, Brian Campbell wrote:
> I do agree that a WG profile of a JWT-structured access token could 
> lend itself to interoperability and ultimately be a useful thing. But 
> you are right that there already are many implementations out there in 
> the wild (heck, I've written one myself) and that might make it 
> difficult to standardize on something.
>
> Because of that, and many other reasons, I don't want to try and add 
> that to existing assertion drafts.
>
>
> On Thu, Feb 28, 2013 at 12:13 PM, Lewis Adam-CAL022 
>  > wrote:
>
>     Hi Brian, a few thoughts from somebody outside of the WG ...
>
>     As a newcomer to OAuth last year, I was initially confused by the
>     titles.  It was confusing because we have SAML bearer
>     **assertions** and JWT bearer **tokens** ... and as John just
>     (begrudgingly) stated in this thread, the JWT is being used as an
>     assertion in this profile (and in OIDC).  I think it will be
>     difficult to find a good name for these profiles since they do two
>     entirely different things (e.g. define a new grant type and define
>     a new method of client authentication).  One could argue that as
>     long as the WG is at it, then why not add a third section to the
>     JWT profile, which talks about usage of JWT-structured bearer
>     access tokens: it would not be any less related than the other two
>     focuses of the doc.  Then the document could be called something
>     simple like "profiles of JWT usage in OAuth" or something like that.
>
>     On one hand, it is probably na�ve to think that an access token
>     can be standardized in a profile given how many have already been
>     released into the wild, but on the other hand, a WG profile of a
>     JWT-structured access token could lend itself to interoperability,
>     where AS implementations can advertise conformance to the profile
>     and who knows ... maybe the RS's of the future will be good with
>     this.
>
>     adam
>
>     *From:*oauth-bounces@ietf.org 
>     [mailto:oauth-bounces@ietf.org ]
>     *On Behalf Of *Brian Campbell
>     *Sent:* Thursday, February 28, 2013 1:03 PM
>     *To:* John Bradley
>     *Cc:* oauth@ietf.org  WG
>
>
>     *Subject:* Re: [OAUTH-WG] JWT - scope claim missing
>
>     I'm not sure anyone really "picked" the titles for the bearer
>     token profiles. They just kind of evolved. And evolved in funny
>     ways especially when client authn to the AS was added.
>
>     You won't hear me argue that the titles are "good" and this is not
>     the first time there's been confusion about what they actually do.
>     They define new grant types and new client authentication methods.
>     They *do not* define an access token format or anything else about
>     access tokens. JWT and SAML could be used for that but that's not
>     what these drafts do.
>
>     Suggestions for better title(s) would be more than welcome.
>
>     Here's what they are now:
>
>
>     SAML 2.0 Bearer Assertion Profiles for OAuth 2.0
>     draft-ietf-oauth-saml2-bearer
>
>     JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
>     draft-ietf-oauth-jwt-bearer
>
>     Assertion Framework for OAuth 2.0
>     draft-ietf-oauth-assertions
>
>     On Thu, Feb 28, 2013 at 11:36 AM, John Bradley      > wrote:
>
>     Yes the title likely adds to the confusion given that the bearer
>     tokens are not access tokens.
>
>     Things as separate from OAuth as the Firefox browerID spec use JWS
>     signed JWTs.
>
>     The bearer token profiles for OAuth 2 are for OAuth2.
>
>     The JSON Web Token (JWT)
>      spec
>     did not start in OAuth and is not OAuth specific.
>
>     A JWT is:
>
>     JSON Web Token (JWT)  A string representing a set of claims as a JSON
>
>            object that is encoded in a JWS or JWE, enabling the claims to be
>
>            digitally signed or MACed and/or encrypted.
>
>     So OAuth or other profiles may define claims to go in a JWT, but
>     the JWT needs to itself only define the claims necessary for
>     security processing.
>
>     John B.
>
>     PS that was a soft ball If you hadn't responded I would have been
>     disappointed.  I din't pick the title for the bearer token profiles.
>
>     On 2013-02-28, at 10:12 AM, Phil Hunt      > wrote:
>
>
>
>       JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
>
>
>     Note the title says "for OAuth2"
>
>     Sorry. Couldn't resist.
>
>     Phil
>
>     Sent from my phone.
>
>
>     On 2013-02-28, at 9:40, John Bradley      > wrote:
>
>         JWT is an assertion( I am probably going to regret using that
>         word).
>
>         It is used in openID connect for id_tokens, it is used in
>         OAuth for Assertion grant types and authentication of the
>         client to the token endpoint.
>
>         http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04
>
>           
>
>           
>
>
>           JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
>
>         Dosen't define JWT's use for access tokens for the RS.
>
>         Bottom line JWT is for more than access tokens.
>
>         John B.
>
>         On 2013-02-28, at 9:28 AM, Phil Hunt          > wrote:
>
>
>
>         Are you saying jwt is not an access token type?
>
>         Phil
>
>         Sent from my phone.
>
>
>         On 2013-02-28, at 8:58, John Bradley          > wrote:
>
>             Yes, defining scope in JWT is the wrong place. JWT needs
>             to stick to the security claims needed to process JWT.
>
>             I also don't know how far you get requiring a specific
>             authorization format for JWT, some AS will wan to use a
>             opaque reference, some might want to use a user claim or
>             role claim, others may use scopes,  combining scopes and
>             claims is also possible.
>
>             Right now it is up to a AS RS pair to agree on how to
>             communicate authorization.   I don't want MAC to be more
>             restrictive than bearer when it comes to authorization
>             between AS and RS.
>
>             Hannes wanted to know why JWT didn't define scope.  The
>             simple answer is that it is out of scope for JWT itself.  
>             It might be defined in a OAuth access token profile for
>             JWT but it should not be specific to MAC.
>
>             John B.
>
>             On 2013-02-28, at 8:44 AM, Brian Campbell
>                          > wrote:
>
>
>
>             I think John's point was more that scope is something
>             rather specific to an OAuth access token and, while JWT is
>             can be used to represent an access token, it's not the
>             only application of JWT. The 'standard' claims in JWT are
>             those that are believed (right or wrong) to be widely
>             applicable across different applications of JWT. One could
>             argue about it but scope is probably not one of those.
>
>             It would probably make sense to try and build a profile of
>             JWT specifically for OAuth access tokens (though I suspect
>             there are some turtles and dragons in there), which might
>             be the appropriate place to define/register a scope claim.
>
>             On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt
>             > wrote:
>
>             Are you advocating TWO systems? That seems like a bad choice.
>
>             I would rather fix scope than go to a two system approach.
>
>             Phil
>
>             Sent from my phone.
>
>             On 2013-02-28, at 8:17, John Bradley              > wrote:
>
>             > While scope is one method that a AS could communicate
>             authorization to a RS, it is not the only or perhaps even
>             the most likely one.
>             > Using scope requires a relatively tight binding between
>             the RS and AS,  UMA uses a different mechanism that
>             describes finer grained operations.
>             > The AS may include roles, user, or other more abstract
>             claims that the the client may (god help them) pass on to
>             EXCML for processing.
>             >
>             > While having a scopes claim is possible, like any other
>             claim it is not part of the JWT core security processing
>             claims, and needs to be defined by extension.
>             >
>             > John B.
>             > On 2013-02-28, at 2:29 AM, Hannes Tschofenig
>                          > wrote:
>             >
>             >> Hi Mike,
>             >>
>             >> when I worked on the MAC specification I noticed that
>             the JWT does not have a claim for the scope. I believe
>             that this would be needed to allow the resource server to
>             verify whether the scope the authorization server
>             authorized is indeed what the client is asking for.
>             >>
>             >> 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

--------------080405010908090104000606
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

    It doesn't belong in the assertion drafts, but maybe it can be
    combined with the token introspection piece I've started (but isn't
    an item yet)? I think that would address the other thread that
    Hannes was talking about as well. We'd essentially be defining one
    set of token metadata (including scopes, client_id, subject,
    audience, expiration and a few others) and two methods to get at it:
    either by making an introspection call, or by packing it into the
    token directly. And the two could even work together if you wanted
    to.

     -- Justin

    On 02/28/2013 02:36 PM, Brian Campbell
      wrote:

        I do agree that a WG profile of a JWT-structured access
          token could lend itself to interoperability and ultimately be
          a useful thing. But you are right that there already are many
          implementations out there in the wild (heck, I've written one
          myself) and that might make it difficult to standardize on
          something.

        Because of that, and many other reasons, I don't want to try and
        add that to existing assertion drafts.

          On Thu, Feb 28, 2013 at 12:13 PM,
            Lewis Adam-CAL022 <Adam.Lewis@motorolasolutions.com>
            wrote:

                  Hi
                      Brian, a few thoughts from somebody outside of the
                      WG …

                  As a
                      newcomer to OAuth last year, I was initially
                      confused by the titles.  It was confusing because
                      we have SAML bearer *assertions* and JWT
                      bearer *tokens* … and as John just
                      (begrudgingly) stated in this thread, the JWT is
                      being used as an assertion in this profile (and in
                      OIDC).  I think it will be difficult to find a
                      good name for these profiles since they do two
                      entirely different things (e.g. define a new grant
                      type and define a new method of client
                      authentication).  One could argue that as long as
                      the WG is at it, then why not add a third section
                      to the JWT profile, which talks about usage of
                      JWT-structured bearer access tokens: it would not
                      be any less related than the other two focuses of
                      the doc.  Then the document could be called
                      something simple like “profiles of JWT usage in
                      OAuth” or something like that. 

                  On
                      one hand, it is probably naïve to think that an
                      access token can be standardized in a profile
                      given how many have already been released into the
                      wild, but on the other hand, a WG profile of a
                      JWT-structured access token could lend itself to
                      interoperability, where AS implementations can
                      advertise conformance to the profile and who knows
                      … maybe the RS’s of the future will be good with
                      this. 

                  adam

                    From:
                        oauth-bounces@ietf.org
                        [mailto:oauth-bounces@ietf.org]
                        On Behalf Of Brian Campbell

                        Sent: Thursday, February 28, 2013 1:03 PM

                        To: John Bradley

                        Cc: oauth@ietf.org
                        WG

                      Subject: Re: [OAUTH-WG] JWT - scope claim
                      missing

                      I'm
                        not sure anyone really "picked" the titles for
                        the bearer token profiles. They just kind of
                        evolved. And evolved in funny ways especially
                        when client authn to the AS was added.

                          You won't hear
                            me argue that the titles are "good" and this
                            is not the first time there's been confusion
                            about what they actually do. They define new
                            grant types and new client authentication
                            methods. They *do not* define an access
                            token format or anything else about access
                            tokens. JWT and SAML could be used for that
                            but that's not what these drafts do.

                          Suggestions for better
                            title(s) would be more than welcome.

                            Here's what they are
                              now:

                              SAML 2.0 Bearer Assertion Profiles for
                              OAuth 2.0

                              draft-ietf-oauth-saml2-bearer

                              JSON Web Token (JWT) Bearer Token Profiles
                              for OAuth 2.0

                              draft-ietf-oauth-jwt-bearer

                              Assertion Framework for OAuth 2.0

                              draft-ietf-oauth-assertions

                                On Thu, Feb 28,
                                  2013 at 11:36 AM, John Bradley <ve7jtb@ve7jtb.com>
                                  wrote:

                                  Yes the title
                                    likely adds to the confusion given
                                    that the bearer tokens are not
                                    access tokens.

                                    Things as
                                      separate from OAuth as the Firefox
                                      browerID spec use JWS signed JWTs.

                                    The bearer
                                      token profiles for OAuth 2 are for
                                      OAuth2.

                                    The JSON Web Token
                                        (JWT) spec did not start in
                                      OAuth and is not OAuth specific.

                                    A JWT is:

                                    JSON Web Token (JWT)  A string representing a set of claims as a JSON
                                          object that is encoded in a JWS or JWE, enabling the claims to be
                                          digitally signed or MACed and/or encrypted.

                                      So OAuth or
                                        other profiles may define claims
                                        to go in a JWT, but the JWT
                                        needs to itself only define the
                                        claims necessary for security
                                        processing.  

                                      John B.

                                      PS that was a
                                        soft ball If you hadn't
                                        responded I would have been
                                        disappointed.  I din't pick the
                                        title for the bearer token
                                        profiles.

                                            On
                                              2013-02-28, at 10:12 AM,
                                              Phil Hunt <phil.hunt@oracle.com>
                                              wrote:

                                              JSON
                                                  Web Token (JWT) Bearer
                                                  Token Profiles for
                                                  OAuth 2.0

                                                Note the title says "for
                                                OAuth2"

                                              Sorry.
                                                Couldn't resist. 

                                              Phil

                                                Sent
                                                  from my phone.

                                                On 2013-02-28, at 9:40,
                                                John Bradley <ve7jtb@ve7jtb.com>
                                                wrote:

                                              JWT
                                                is an assertion( I am
                                                probably going to regret
                                                using that word).

                                                It
                                                  is used in openID
                                                  connect for id_tokens,
                                                  it is used in OAuth
                                                  for Assertion grant
                                                  types and
                                                  authentication of the
                                                  client to the token
                                                  endpoint.

                                                http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04

                                                JSON Web
                                                    Token (JWT) Bearer
                                                    Token Profiles for
                                                    OAuth 2.0

                                                  Dosen't
                                                    define JWT's use for
                                                    access tokens for
                                                    the RS.   

                                                  Bottom
                                                    line JWT is for more
                                                    than access tokens.

                                                  John
                                                    B.

                                                    On
                                                      2013-02-28, at
                                                      9:28 AM, Phil Hunt
                                                      <phil.hunt@oracle.com>
                                                      wrote:

                                                      Are
                                                        you saying jwt
                                                        is not an access
                                                        token type?

                                                        Phil

                                                        Sent
                                                          from my phone.

                                                        On 2013-02-28,
                                                        at 8:58, John
                                                        Bradley <ve7jtb@ve7jtb.com>
                                                        wrote:

                                                      Yes,
                                                        defining scope
                                                        in JWT is the
                                                        wrong place.  
                                                        JWT needs to
                                                        stick to the
                                                        security claims
                                                        needed to
                                                        process JWT.

                                                        I
                                                          also don't
                                                          know how far
                                                          you get
                                                          requiring a
                                                          specific
                                                          authorization
                                                          format for
                                                          JWT, some AS
                                                          will wan to
                                                          use a opaque
                                                          reference,
                                                          some might
                                                          want to use a
                                                          user claim or
                                                          role claim,
                                                          others may use
                                                          scopes,
                                                           combining
                                                          scopes and
                                                          claims is also
                                                          possible.

                                                        Right
                                                          now it is up
                                                          to a AS RS
                                                          pair to agree
                                                          on how to
                                                          communicate
                                                          authorization.
                                                            I don't want
                                                          MAC to be more
                                                          restrictive
                                                          than bearer
                                                          when it comes
                                                          to
                                                          authorization
                                                          between AS and
                                                          RS.

                                                          Hannes
                                                          wanted to know
                                                          why JWT didn't
                                                          define scope.
                                                           The simple
                                                          answer is that
                                                          it is out of
                                                          scope for JWT
                                                          itself.   It
                                                          might be
                                                          defined in a
                                                          OAuth access
                                                          token profile
                                                          for JWT but it
                                                          should not be
                                                          specific to
                                                          MAC.

                                                          John
                                                          B.

                                                          On
                                                          2013-02-28, at
                                                          8:44 AM, Brian
                                                          Campbell <bcampbell@pingidentity.com>
                                                          wrote:

                                                          I think John's point was more that scope is
                                                          something
                                                          rather
                                                          specific to an
                                                          OAuth access
                                                          token and,
                                                          while JWT is
                                                          can be used to
                                                          represent an
                                                          access token,
                                                          it's not the
                                                          only
                                                          application of
                                                          JWT. The
                                                          'standard'
                                                          claims in JWT
                                                          are those that
                                                          are believed
                                                          (right or
                                                          wrong) to be
                                                          widely
                                                          applicable
                                                          across
                                                          different
                                                          applications
                                                          of JWT. One
                                                          could argue
                                                          about it but
                                                          scope is
                                                          probably not
                                                          one of those.

                                                          It
                                                          would probably
                                                          make sense to
                                                          try and build
                                                          a profile of
                                                          JWT
                                                          specifically
                                                          for OAuth
                                                          access tokens
                                                          (though I
                                                          suspect there
                                                          are some
                                                          turtles and
                                                          dragons in
                                                          there), which
                                                          might be the
                                                          appropriate
                                                          place to
                                                          define/register
                                                          a scope claim.

                                                          On
                                                          Thu, Feb 28,
                                                          2013 at 9:24
                                                          AM, Phil Hunt
                                                          <phil.hunt@oracle.com>
                                                          wrote:
                                                          Are
                                                          you advocating
                                                          TWO systems?
                                                          That seems
                                                          like a bad
                                                          choice.

                                                          I would rather
                                                          fix scope than
                                                          go to a two
                                                          system
                                                          approach.

                                                          Phil

                                                          Sent from my
                                                          phone.

                                                          On 2013-02-28,
                                                          at 8:17, John
                                                          Bradley <ve7jtb@ve7jtb.com>
                                                          wrote:

                                                          > While
                                                          scope is one
                                                          method that a
                                                          AS could
                                                          communicate
                                                          authorization
                                                          to a RS, it is
                                                          not the only
                                                          or perhaps
                                                          even the most
                                                          likely one.

                                                          > Using
                                                          scope requires
                                                          a relatively
                                                          tight binding
                                                          between the RS
                                                          and AS,  UMA
                                                          uses a
                                                          different
                                                          mechanism that
                                                          describes
                                                          finer grained
                                                          operations.

                                                          > The AS
                                                          may include
                                                          roles, user,
                                                          or other more
                                                          abstract
                                                          claims that
                                                          the the client
                                                          may (god help
                                                          them) pass on
                                                          to EXCML for
                                                          processing.

                                                          >

                                                          > While
                                                          having a
                                                          scopes claim
                                                          is possible,
                                                          like any other
                                                          claim it is
                                                          not part of
                                                          the JWT core
                                                          security
                                                          processing
                                                          claims, and
                                                          needs to be
                                                          defined by
                                                          extension.

                                                          >

                                                          > John B.

                                                          > On
                                                          2013-02-28, at
                                                          2:29 AM,
                                                          Hannes
                                                          Tschofenig
                                                          <hannes.tschofenig@gmx.net>
                                                          wrote:

                                                          >

                                                          >> Hi
                                                          Mike,

                                                          >>

                                                          >> when
                                                          I worked on
                                                          the MAC
                                                          specification
                                                          I noticed that
                                                          the JWT does
                                                          not have a
                                                          claim for the
                                                          scope. I
                                                          believe that
                                                          this would be
                                                          needed to
                                                          allow the
                                                          resource
                                                          server to
                                                          verify whether
                                                          the scope the
                                                          authorization
                                                          server
                                                          authorized is
                                                          indeed what
                                                          the client is
                                                          asking for.

                                                          >>

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

--------------080405010908090104000606--

From Michael.Jones@microsoft.com  Thu Feb 28 11:46:07 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC4421F8756 for ; Thu, 28 Feb 2013 11:46:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.587
X-Spam-Level: 
X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.011,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bd7stYJJ+g2W for ; Thu, 28 Feb 2013 11:46:02 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.24]) by ietfa.amsl.com (Postfix) with ESMTP id 674E621F8749 for ; Thu, 28 Feb 2013 11:46:02 -0800 (PST)
Received: from BY2FFO11FD022.protection.gbl (10.1.15.200) by BY2FFO11HUB026.protection.gbl (10.1.14.112) with Microsoft SMTP Server (TLS) id 15.0.620.12; Thu, 28 Feb 2013 19:45:59 +0000
Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD022.mail.protection.outlook.com (10.1.15.211) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Thu, 28 Feb 2013 19:45:59 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Thu, 28 Feb 2013 19:45:38 +0000
From: Mike Jones 
To: Brian Campbell , John Bradley 
Thread-Topic: [OAUTH-WG] JWT - scope claim missing
Thread-Index: AQHOFZ6hIxtkb1+gY0y+b2wB9BjwWJiPcwkAgAAB5wCAAAWJgIAABAMAgAAIM4CAAAN2AIAACPaAgAAGkYCAAAeWAIAABfeAgAAA29A=
Date: Thu, 28 Feb 2013 19:45:37 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943674C40B7@TK5EX14MBXC283.redmond.corp.microsoft.com>
References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net>     <48FD87D1-4DF4-4289-99B7-40A515F31890@oracle.com> <3E472720-31A4-40A0-AAA4-402CF850831A@ve7jtb.com> <7127843B-D7B0-4AB6-87F1-1604D1EFFA79@oracle.com> <50DA292F-32F0-4266-8401-006AD837B775@ve7jtb.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.36]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943674C40B7TK5EX14MBXC283r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377424002)(51704002)(199002)(189002)(377454001)(24454001)(56776001)(4396001)(33656001)(16236675001)(512954001)(50986001)(31966008)(63696002)(74502001)(20776003)(77982001)(66066001)(76482001)(74662001)(49866001)(56816002)(79102001)(5343635001)(5343655001)(65816001)(59766001)(44976002)(54356001)(53806001)(47446002)(15202345001)(16406001)(54316002)(80022001)(47736001)(47976001)(46102001)(5343645001)(51856001)(55846006)(550254004); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB026; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0771670921
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] JWT - scope claim missing
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 19:46:07 -0000

--_000_4E1F6AAD24975D4BA5B1680429673943674C40B7TK5EX14MBXC283r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I believe that a "scope" claim should be defined by a particular profile or=
 profiles that use JWT in a way that needs it, since it's not of general ap=
plicability.  The JSON Web Token Claims Registry (http://tools.ietf.org/htm=
l/draft-ietf-oauth-json-web-token-06#section-9.1) is defined exactly for th=
e purpose of registering claims that aren't in the base JWT spec.  Let's us=
e that, once there's a profile written that needs a "scope" claim.

                                                            Cheers,
                                                            -- Mike

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B=
rian Campbell
Sent: Thursday, February 28, 2013 11:25 AM
To: John Bradley
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] JWT - scope claim missing

To be fair, I think it was Phil who first conflated the things :) I just pi=
cked up the ball and ran with it. But you are right, I did kind of hijack t=
he thread which was originally about if a scope claim should be defined in =
draft-ietf-oauth-json-web-token. I'd say no but I can see how an argument c=
ould be made the other way.

On Thu, Feb 28, 2013 at 12:03 PM, Brian Campbell > wrote:
I'm not sure anyone really "picked" the titles for the bearer token profile=
s. They just kind of evolved. And evolved in funny ways especially when cli=
ent authn to the AS was added.
You won't hear me argue that the titles are "good" and this is not the firs=
t time there's been confusion about what they actually do. They define new =
grant types and new client authentication methods. They *do not* define an =
access token format or anything else about access tokens. JWT and SAML coul=
d be used for that but that's not what these drafts do.
Suggestions for better title(s) would be more than welcome.

Here's what they are now:

SAML 2.0 Bearer Assertion Profiles for OAuth 2.0
draft-ietf-oauth-saml2-bearer

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
draft-ietf-oauth-jwt-bearer

Assertion Framework for OAuth 2.0
draft-ietf-oauth-assertions

On Thu, Feb 28, 2013 at 11:36 AM, John Bradley > wrote:
Yes the title likely adds to the confusion given that the bearer tokens are=
 not access tokens.

Things as separate from OAuth as the Firefox browerID spec use JWS signed J=
WTs.

The bearer token profiles for OAuth 2 are for OAuth2.

The JSON Web Token (JWT) spec did not start in OAuth and is not OAuth specific.

A JWT is:

JSON Web Token (JWT)  A string representing a set of claims as a JSON

      object that is encoded in a JWS or JWE, enabling the claims to be

      digitally signed or MACed and/or encrypted.

So OAuth or other profiles may define claims to go in a JWT, but the JWT ne=
eds to itself only define the claims necessary for security processing.

John B.
PS that was a soft ball If you hadn't responded I would have been disappoin=
ted.  I din't pick the title for the bearer token profiles.

On 2013-02-28, at 10:12 AM, Phil Hunt > wrote:

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

Note the title says "for OAuth2"

Sorry. Couldn't resist.

Phil

Sent from my phone.

On 2013-02-28, at 9:40, John Bradley > wrote:
JWT is an assertion( I am probably going to regret using that word).

It is used in openID connect for id_tokens, it is used in OAuth for Asserti=
on grant types and authentication of the client to the token endpoint.
http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

Dosen't define JWT's use for access tokens for the RS.

Bottom line JWT is for more than access tokens.

John B.

On 2013-02-28, at 9:28 AM, Phil Hunt > wrote:

Are you saying jwt is not an access token type?

Phil

Sent from my phone.

On 2013-02-28, at 8:58, John Bradley > wrote:
Yes, defining scope in JWT is the wrong place.   JWT needs to stick to the =
security claims needed to process JWT.

I also don't know how far you get requiring a specific authorization format=
 for JWT, some AS will wan to use a opaque reference, some might want to us=
e a user claim or role claim, others may use scopes,  combining scopes and =
claims is also possible.

Right now it is up to a AS RS pair to agree on how to communicate authoriza=
tion.   I don't want MAC to be more restrictive than bearer when it comes t=
o authorization between AS and RS.

Hannes wanted to know why JWT didn't define scope.  The simple answer is th=
at it is out of scope for JWT itself.   It might be defined in a OAuth acce=
ss token profile for JWT but it should not be specific to MAC.

John B.
On 2013-02-28, at 8:44 AM, Brian Campbell > wrote:

I think John's point was more that scope is something rather specific to an=
 OAuth access token and, while JWT is can be used to represent an access to=
ken, it's not the only application of JWT. The 'standard' claims in JWT are=
 those that are believed (right or wrong) to be widely applicable across di=
fferent applications of JWT. One could argue about it but scope is probably=
 not one of those.
It would probably make sense to try and build a profile of JWT specifically=
 for OAuth access tokens (though I suspect there are some turtles and drago=
ns in there), which might be the appropriate place to define/register a sco=
pe claim.

On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt > wrote:
Are you advocating TWO systems? That seems like a bad choice.

I would rather fix scope than go to a two system approach.

Phil

Sent from my phone.

On 2013-02-28, at 8:17, John Bradley > wrote:

> While scope is one method that a AS could communicate authorization to a =
RS, it is not the only or perhaps even the most likely one.
> Using scope requires a relatively tight binding between the RS and AS,  U=
MA uses a different mechanism that describes finer grained operations.
> The AS may include roles, user, or other more abstract claims that the th=
e client may (god help them) pass on to EXCML for processing.
>
> While having a scopes claim is possible, like any other claim it is not p=
art of the JWT core security processing claims, and needs to be defined by =
extension.
>
> John B.
> On 2013-02-28, at 2:29 AM, Hannes Tschofenig > wrote:
>
>> Hi Mike,
>>
>> when I worked on the MAC specification I noticed that the JWT does not h=
ave a claim for the scope. I believe that this would be needed to allow the=
 resource server to verify whether the scope the authorization server autho=
rized is indeed what the client is asking for.
>>
>> 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

--_000_4E1F6AAD24975D4BA5B1680429673943674C40B7TK5EX14MBXC283r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I believe that a “s=
cope” claim should be defined by a particular profile or profiles tha=
t use JWT in a way that needs it, since it’s not of general applicabi=
lity. 
 The JSON Web Token Claims Registry (http://tools.ietf.org/html/=
draft-ietf-oauth-json-web-token-06#section-9.1) is defined exactly for =
the purpose of registering claims
 that aren’t in the base JWT spec.  Let’s use that, once t=
here’s a profile written that needs a “scope” claim.=

 <=
/p>
    &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;     Cheers,
    &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;     -- Mike
 <=
/p>
From: oauth-bo=
unces@ietf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Brian Campbell

Sent: Thursday, February 28, 2013 11:25 AM

To: John Bradley

Cc: oauth@ietf.org WG

Subject: Re: [OAUTH-WG] JWT - scope claim missing<=
/p>

To be fair, I think it was Phil who first conflated =
the things :) I just picked up the ball and ran with it. But you are right,=
 I did kind of hijack the thread which was originally about if a scope clai=
m should be defined in draft-ietf-oauth-json-web-token.
 I'd say no but I can see how an argument could be made the other way.=

On Thu, Feb 28, 2013 at 12:03 PM, Brian Campbell <=
;bcampbell@=
pingidentity.com> wrote:

I'm not sure anyone r=
eally "picked" the titles for the bearer token profiles. They jus=
t kind of evolved. And evolved in funny ways especially when client authn t=
o the AS was added.

You won't hear me arg=
ue that the titles are "good" and this is not the first time ther=
e's been confusion about what they actually do. They define new grant types=
 and new client authentication methods. They *do
 not* define an access token format or anything else about access tokens. J=
WT and SAML could be used for that but that's not what these drafts do.

Suggestions for better title(s) would be more than w=
elcome.

Here's what they are now:

SAML 2.0 Bearer Assertion Profiles for OAuth 2.0

draft-ietf-oauth-saml2-bearer

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

draft-ietf-oauth-jwt-bearer

Assertion Framework for OAuth 2.0

draft-ietf-oauth-assertions

On Thu, Feb 28, 2013 at 11:36 AM, John Bradley <<=
a href=3D"mailto:ve7jtb@ve7jtb.com" target=3D"_blank">ve7jtb@ve7jtb.com=
> wrote:

Yes the title likely adds to the confusion given tha=
t the bearer tokens are not access tokens.

Things as separate from OAuth as the Firefox browerI=
D spec use JWS signed JWTs.  

The bearer token profiles for OAuth 2 are for OAuth2=
.

The JSON Web Token (JWT)&n=
bsp;spec did not start in OAuth and is not OAuth specific.

A JWT is:

JSON Web Token (JWT)  A string r=
epresenting a set of claims as a JSON
      object=
 that is encoded in a JWS or JWE, enabling the claims to be
      digita=
lly signed or MACed and/or encrypted.

So OAuth or other profiles may define claims to go i=
n a JWT, but the JWT needs to itself only define the claims necessary for s=
ecurity processing.  

John B.

PS that was a soft ball If you hadn't responded I wo=
uld have been disappointed.  I din't pick the title for the bearer tok=
en profiles.

On 2013-02-28, at 10:12 AM, Phil Hunt <phil.hunt@oracle.com>=
; wrote:

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

Note the title says "for OAuth2"

Sorry. Couldn't resist. 

Phil

Sent from my phone.

On 2013-02-28, at 9:40, John Bradley <ve7jtb@ve7jtb.com> wrote:

JWT is an assertion( I am probably going to regret u=
sing that word).

It is used in openID connect for id_tokens, it is us=
ed in OAuth for Assertion grant types and authentication of the client to t=
he token endpoint.

http://tools.ietf.org/html/draft-ietf-o=
auth-jwt-bearer-04

JSON Web Token (JWT) Bear=
er Token Profiles for OAuth 2.0

Dosen't define JWT's use for access tokens for the R=
S.   

Bottom line JWT is for more than access tokens.=

John B.

On 2013-02-28, at 9:28 AM, Phil Hunt <phil.hunt@oracle.com>=
 wrote:

Are you saying jwt is not an access token type?

Phil

Sent from my phone.

On 2013-02-28, at 8:58, John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes, defining scope in JWT is the wrong place.  =
; JWT needs to stick to the security claims needed to process JWT.

I also don't know how far you get requiring a specif=
ic authorization format for JWT, some AS will wan to use a opaque reference=
, some might want to use a user claim or role claim, others may use scopes,=
  combining scopes and claims is also
 possible.

Right now it is up to a AS RS pair to agree on how t=
o communicate authorization.   I don't want MAC to be more restrictive=
 than bearer when it comes to authorization between AS and RS.

Hannes wanted to know why JWT didn't define scope. &=
nbsp;The simple answer is that it is out of scope for JWT itself.   It=
 might be defined in a OAuth access token profile for JWT but it should not=
 be specific to MAC.

John B.

On 2013-02-28, at 8:44 AM, Brian Campbell <bcampbell@pingide=
ntity.com> wrote:

I think John's point =
was more that scope is something rather specific to an OAuth access token a=
nd, while JWT is can be used to represent an access token, it's not the onl=
y application of JWT. The 'standard'
 claims in JWT are those that are believed (right or wrong) to be widely ap=
plicable across different applications of JWT. One could argue about it but=
 scope is probably not one of those.

It would probably make sense to try and build a prof=
ile of JWT specifically for OAuth access tokens (though I suspect there are=
 some turtles and dragons in there), which might be the appropriate place t=
o define/register a scope claim.

On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

Are you advocating TWO systems? That seems like a ba=
d choice.

I would rather fix scope than go to a two system approach.

Phil

Sent from my phone.

On 2013-02-28, at 8:17, John Bradley <ve7jtb@ve7jtb.com> wrote:

> While scope is one method that a AS could communicate authorization to=
 a RS, it is not the only or perhaps even the most likely one.

> Using scope requires a relatively tight binding between the RS and AS,=
  UMA uses a different mechanism that describes finer grained operatio=
ns.

> The AS may include roles, user, or other more abstract claims that the=
 the client may (god help them) pass on to EXCML for processing.

>

> While having a scopes claim is possible, like any other claim it is no=
t part of the JWT core security processing claims, and needs to be defined =
by extension.

>

> John B.

> On 2013-02-28, at 2:29 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net>=
 wrote:

>

>> Hi Mike,

>>

>> when I worked on the MAC specification I noticed that the JWT does=
 not have a claim for the scope. I believe that this would be needed to all=
ow the resource server to verify whether the scope the authorization server=
 authorized is indeed what the client
 is asking for.

>>

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

h=
ttps://www.ietf.org/mailman/listinfo/oauth

--_000_4E1F6AAD24975D4BA5B1680429673943674C40B7TK5EX14MBXC283r_--

From ve7jtb@ve7jtb.com  Thu Feb 28 11:57:15 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDBD421F88E1 for ; Thu, 28 Feb 2013 11:57:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.365
X-Spam-Level: 
X-Spam-Status: No, score=-3.365 tagged_above=-999 required=5 tests=[AWL=0.233,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cmlOhnXJfC1 for ; Thu, 28 Feb 2013 11:57:14 -0800 (PST)
Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 38C6721F88DD for ; Thu, 28 Feb 2013 11:57:14 -0800 (PST)
Received: by mail-pa0-f44.google.com with SMTP id kp1so1332576pab.31 for ; Thu, 28 Feb 2013 11:57:13 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=dj2nr+7RHeK8+E6BCXxTTQciUeD7CRqN7NL0Fo3lcYc=; b=cEKDktBIfNKS27/KurdZGYFDQ3snJCRd3wz0Wm/gbVCm/17A7G3Jv5W7ug101dna6v J644HN0u6eIPFQ7t4zBY1t2yEvqWLCwqcwIDJ/fbUuV3/aoKkMWR/FjeanEHqUd5FuKI +PQjHVcOGD1VLED3L6nKqaZypvz1EdvB+RTJiH0vuvRUCiXxuY8dL4yVDfq7Oexdxsil 5xKuRe82oH7fTcT9qlGbMtZKjDsq0/q+VhBhrQlVx6q//BugW9Q+1xk9fmmh5b09NXIN gvA1jORnpkEUKDWfBzY5uc7wqmH/JHfYGIymk3JV3V3C+5OwKzkyYhAHZP/XSjNhgd1n mngA==
X-Received: by 10.66.145.130 with SMTP id su2mr14904682pab.74.1362081433734; Thu, 28 Feb 2013 11:57:13 -0800 (PST)
Received: from [192.168.43.179] (mobile-166-137-184-056.mycingular.net. [166.137.184.56]) by mx.google.com with ESMTPS id a4sm10226976paw.21.2013.02.28.11.57.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Feb 2013 11:57:12 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_B7B7849C-52AA-447C-84F4-2002C676ECE2"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <512FAC0F.5070409@mitre.org>
Date: Thu, 28 Feb 2013 11:57:08 -0800
Message-Id: <3D9DC9D6-35E4-4C86-8891-ED5420D2602E@ve7jtb.com>
References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net>     <48FD87D1-4DF4-4289-99B7-40A515F31890@oracle.com> <3E472720-31A4-40A0-AAA4-402CF850831A@ve7jtb.com> <7127843B-D7B0-4AB6-87F1-1604D1EFFA79@oracle.com> <50DA292F-32F0-4266-8401-006AD837B775@ve7jtb.com>  <512FAC0F.5070409@mitre.org>
To: Justin Richer 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQn9+ivznjaPOspwKlGfECdGpsHKbQObr7jZHY91WiVIKsJWkLFSlEeNQkhequGIftcwwB0/
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] JWT - scope claim missing
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 19:57:16 -0000

--Apple-Mail=_B7B7849C-52AA-447C-84F4-2002C676ECE2
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_04C55B8F-B6D1-4038-94E4-6132B5266687"

--Apple-Mail=_04C55B8F-B6D1-4038-94E4-6132B5266687
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Agreed profiling needs to happen for access tokens someplace.   In the =
MAC spec is probably not the best place if the claims are used outside =
of MAC as well.

There is a separate issue once we get to that profile about scope.   I =
don't know many RS that do a 1 to 1 mapping of scope at the AS.  Not =
that they couldn't.
I just don't want to start the access token profiling assuming a one to =
one mapping of scopes is the only way to do it.

John B.
On 2013-02-28, at 11:12 AM, Justin Richer  wrote:

> Brian, I think you're conflating two things (and John might be, too). =
On the one hand, we've got the JWT document, which talks about what goes =
into the token itself. This can be used as an assertion, as an access =
token, as a floor wax / dessert topping. JWT doesn't really care, and =
this is really only in the OAuth WG thanks to IETF politics. Then we =
have the assertion profiles which say how to use things like JWT to do =
specific things in OAuth, and these are what Brian's talking about =
below.
>=20
> Ultimately, this conversation is about the former and not the latter. =
That said, since an OAuth access token is a valid (and common) use of =
JWT, I think that having a common way to put things like "scope" and =
"client_id" and other OAuthy things into a JWT makes a whole heck of a =
lot of sense. Whether or not that is inside of the base JWT draft (since =
it's supposed to be for many use cases), I don't particularly care, and =
I can see the arguments from both sides.
>=20
>  -- Justin
>=20
> On 02/28/2013 02:03 PM, Brian Campbell wrote:
>> I'm not sure anyone really "picked" the titles for the bearer token =
profiles. They just kind of evolved. And evolved in funny ways =
especially when client authn to the AS was added.=20
>>=20
>> You won't hear me argue that the titles are "good" and this is not =
the first time there's been confusion about what they actually do. They =
define new grant types and new client authentication methods. They *do =
not* define an access token format or anything else about access tokens. =
JWT and SAML could be used for that but that's not what these drafts do.=20=

>>=20
>> Suggestions for better title(s) would be more than welcome.
>>=20
>> Here's what they are now:
>>=20
>> SAML 2.0 Bearer Assertion Profiles for OAuth 2.0
>> draft-ietf-oauth-saml2-bearer
>>=20
>> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
>> draft-ietf-oauth-jwt-bearer
>>=20
>> Assertion Framework for OAuth 2.0
>> draft-ietf-oauth-assertions
>>=20
>> On Thu, Feb 28, 2013 at 11:36 AM, John Bradley  =
wrote:
>> Yes the title likely adds to the confusion given that the bearer =
tokens are not access tokens.
>>=20
>> Things as separate from OAuth as the Firefox browerID spec use JWS =
signed JWTs. =20
>>=20
>> The bearer token profiles for OAuth 2 are for OAuth2.
>>=20
>> The JSON Web Token (JWT) spec did not start in OAuth and is not OAuth =
specific.
>>=20
>> A JWT is:
>> JSON Web Token (JWT)  A string representing a set of claims as a JSON
>>       object that is encoded in a JWS or JWE, enabling the claims to =
be
>>       digitally signed or MACed and/or encrypted.
>>=20
>> So OAuth or other profiles may define claims to go in a JWT, but the =
JWT needs to itself only define the claims necessary for security =
processing. =20
>>=20
>> John B.
>> PS that was a soft ball If you hadn't responded I would have been =
disappointed.  I din't pick the title for the bearer token profiles.
>>=20
>>=20
>> On 2013-02-28, at 10:12 AM, Phil Hunt  wrote:
>>=20
>>> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
>>>=20
>>> Note the title says "for OAuth2"
>>>=20
>>> Sorry. Couldn't resist.=20
>>>=20
>>> Phil
>>>=20
>>> Sent from my phone.
>>>=20
>>> On 2013-02-28, at 9:40, John Bradley  wrote:
>>>=20
>>>> JWT is an assertion( I am probably going to regret using that =
word).
>>>>=20
>>>> It is used in openID connect for id_tokens, it is used in OAuth for =
Assertion grant types and authentication of the client to the token =
endpoint.
>>>> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04
>>>>=20
>>>> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
>>>>=20
>>>> Dosen't define JWT's use for access tokens for the RS.  =20
>>>>=20
>>>> Bottom line JWT is for more than access tokens.
>>>>=20
>>>> John B.
>>>>=20
>>>> On 2013-02-28, at 9:28 AM, Phil Hunt  wrote:
>>>>=20
>>>>> Are you saying jwt is not an access token type?
>>>>>=20
>>>>> Phil
>>>>>=20
>>>>> Sent from my phone.
>>>>>=20
>>>>> On 2013-02-28, at 8:58, John Bradley  wrote:
>>>>>=20
>>>>>> Yes, defining scope in JWT is the wrong place.   JWT needs to =
stick to the security claims needed to process JWT.
>>>>>>=20
>>>>>> I also don't know how far you get requiring a specific =
authorization format for JWT, some AS will wan to use a opaque =
reference, some might want to use a user claim or role claim, others may =
use scopes,  combining scopes and claims is also possible.
>>>>>>=20
>>>>>> Right now it is up to a AS RS pair to agree on how to communicate =
authorization.   I don't want MAC to be more restrictive than bearer =
when it comes to authorization between AS and RS.
>>>>>>=20
>>>>>> Hannes wanted to know why JWT didn't define scope.  The simple =
answer is that it is out of scope for JWT itself.   It might be defined =
in a OAuth access token profile for JWT but it should not be specific to =
MAC.
>>>>>>=20
>>>>>> John B.
>>>>>> On 2013-02-28, at 8:44 AM, Brian Campbell =
 wrote:
>>>>>>=20
>>>>>>> I think John's point was more that scope is something rather =
specific to an OAuth access token and, while JWT is can be used to =
represent an access token, it's not the only application of JWT. The =
'standard' claims in JWT are those that are believed (right or wrong) to =
be widely applicable across different applications of JWT. One could =
argue about it but scope is probably not one of those.
>>>>>>>=20
>>>>>>> It would probably make sense to try and build a profile of JWT =
specifically for OAuth access tokens (though I suspect there are some =
turtles and dragons in there), which might be the appropriate place to =
define/register a scope claim.
>>>>>>>=20
>>>>>>>=20
>>>>>>> On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt =
 wrote:
>>>>>>> Are you advocating TWO systems? That seems like a bad choice.
>>>>>>>=20
>>>>>>> I would rather fix scope than go to a two system approach.
>>>>>>>=20
>>>>>>> Phil
>>>>>>>=20
>>>>>>> Sent from my phone.
>>>>>>>=20
>>>>>>> On 2013-02-28, at 8:17, John Bradley  wrote:
>>>>>>>=20
>>>>>>> > While scope is one method that a AS could communicate =
authorization to a RS, it is not the only or perhaps even the most =
likely one.
>>>>>>> > Using scope requires a relatively tight binding between the RS =
and AS,  UMA uses a different mechanism that describes finer grained =
operations.
>>>>>>> > The AS may include roles, user, or other more abstract claims =
that the the client may (god help them) pass on to EXCML for processing.
>>>>>>> >
>>>>>>> > While having a scopes claim is possible, like any other claim =
it is not part of the JWT core security processing claims, and needs to =
be defined by extension.
>>>>>>> >
>>>>>>> > John B.
>>>>>>> > On 2013-02-28, at 2:29 AM, Hannes Tschofenig =
 wrote:
>>>>>>> >
>>>>>>> >> Hi Mike,
>>>>>>> >>
>>>>>>> >> when I worked on the MAC specification I noticed that the JWT =
does not have a claim for the scope. I believe that this would be needed =
to allow the resource server to verify whether the scope the =
authorization server authorized is indeed what the client is asking for.
>>>>>>> >>
>>>>>>> >> 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
>>>>>>>=20
>>>>>>=20
>>>>=20
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20

--Apple-Mail=_04C55B8F-B6D1-4038-94E4-6132B5266687
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=iso-8859-1

Agreed profiling needs to happen for access tokens someplace.   In the MAC spec is probably not the best place if the claims are used outside of MAC as well.
There is a separate issue once we get to that profile about scope.   I don't know many RS that do a 1 to 1 mapping of scope at the AS.  Not that they couldn't.
I just don't want to start the access token profiling assuming a one to one mapping of scopes is the only way to do it.

John B.
On 2013-02-28, at 11:12 AM, Justin Richer <jricher@mitre.org> wrote:

    Brian, I think you're conflating two things (and John might be,
    too). On the one hand, we've got the JWT document, which talks about
    what goes into the token itself. This can be used as an assertion,
    as an access token, as a floor wax / dessert topping. JWT doesn't
    really care, and this is really only in the OAuth WG thanks to IETF
    politics. Then we have the assertion profiles which say how to use
    things like JWT to do specific things in OAuth, and these are what
    Brian's talking about below.

    Ultimately, this conversation is about the former and not the
    latter. That said, since an OAuth access token is a valid (and
    common) use of JWT, I think that having a common way to put things
    like "scope" and "client_id" and other OAuthy things into a JWT
    makes a whole heck of a lot of sense. Whether or not that is inside
    of the base JWT draft (since it's supposed to be for many use
    cases), I don't particularly care, and I can see the arguments from
    both sides.

     -- Justin

    On 02/28/2013 02:03 PM, Brian Campbell
      wrote:

        I'm not sure anyone really "picked" the titles for the
          bearer token profiles. They just kind of evolved. And evolved
          in funny ways especially when client authn to the AS was
          added. 

        You won't hear me argue that the titles are "good" and this
          is not the first time there's been confusion about what they
          actually do. They define new grant types and new client
          authentication methods. They *do not* define an access token
          format or anything else about access tokens. JWT and SAML
          could be used for that but that's not what these drafts do. 

        Suggestions for better title(s) would be more than welcome.

          Here's what they are now:

            SAML 2.0 Bearer Assertion Profiles for OAuth 2.0

            draft-ietf-oauth-saml2-bearer

            JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

            draft-ietf-oauth-jwt-bearer

            Assertion Framework for OAuth 2.0

            draft-ietf-oauth-assertions

              On Thu, Feb 28, 2013 at 11:36 AM,
                John Bradley <ve7jtb@ve7jtb.com>
                wrote:

                  Yes the title likely
                    adds to the confusion given that the bearer tokens
                    are not access tokens.

                    Things as separate from OAuth as the Firefox
                      browerID spec use JWS signed JWTs.  

                    The bearer token profiles for OAuth 2 are for
                      OAuth2.

                    The JSON Web Token (JWT) spec
                      did not start in OAuth and is not OAuth specific.

                    A JWT is:

                      JSON Web Token (JWT)  A string representing a set of claims as a JSON
      object that is encoded in a JWS or JWE, enabling the claims to be
      digitally signed or MACed and/or encrypted.

                      So OAuth or other profiles may define claims
                        to go in a JWT, but the JWT needs to itself only
                        define the claims necessary for security
                        processing.  

                      John B.
                      PS that was a soft ball If you hadn't
                        responded I would have been disappointed.  I
                        din't pick the title for the bearer token
                        profiles.

                            On 2013-02-28, at 10:12 AM, Phil Hunt
                              <phil.hunt@oracle.com>
                              wrote:

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

                                  Note the title says "for OAuth2"

                                Sorry. Couldn't resist. 

                                Phil

                                  Sent from my phone.

                                  On 2013-02-28, at 9:40, John Bradley
                                  <ve7jtb@ve7jtb.com>
                                  wrote:

                                JWT is an
                                  assertion( I am probably going to
                                  regret using that word).

                                  It is used in openID connect for
                                    id_tokens, it is used in OAuth for
                                    Assertion grant types and
                                    authentication of the client to the
                                    token endpoint.
                                  http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04

                                    JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

                                    Dosen't define JWT's use for
                                      access tokens for the RS.   

                                    Bottom line JWT is for more
                                      than access tokens.

                                    John B.

                                      On 2013-02-28, at 9:28 AM,
                                        Phil Hunt <phil.hunt@oracle.com>
                                        wrote:

                                          Are you saying jwt is not
                                            an access token type?

                                            Phil

                                            Sent from my phone.

                                            On 2013-02-28, at 8:58, John
                                            Bradley <ve7jtb@ve7jtb.com>
                                            wrote:

                                          Yes,
                                            defining scope in JWT is the
                                            wrong place.   JWT needs to
                                            stick to the security claims
                                            needed to process JWT.

                                            I also don't know how
                                              far you get requiring a
                                              specific authorization
                                              format for JWT, some AS
                                              will wan to use a opaque
                                              reference, some might want
                                              to use a user claim or
                                              role claim, others may use
                                              scopes,  combining scopes
                                              and claims is also
                                              possible.

                                            Right now it is up to a
                                              AS RS pair to agree on how
                                              to communicate
                                              authorization.   I don't
                                              want MAC to be more
                                              restrictive than bearer
                                              when it comes to
                                              authorization between AS
                                              and RS.

                                              Hannes wanted to know
                                                why JWT didn't define
                                                scope.  The simple
                                                answer is that it is out
                                                of scope for JWT itself.
                                                  It might be defined in
                                                a OAuth access token
                                                profile for JWT but it
                                                should not be specific
                                                to MAC.

                                              John B.

                                                  On 2013-02-28, at
                                                    8:44 AM, Brian
                                                    Campbell <bcampbell@pingidentity.com>
                                                    wrote:

                                                      I think
                                                        John's point was
                                                        more that scope
                                                        is something
                                                        rather specific
                                                        to an OAuth
                                                        access token
                                                        and, while JWT
                                                        is can be used
                                                        to represent an
                                                        access token,
                                                        it's not the
                                                        only application
                                                        of JWT. The
                                                        'standard'
                                                        claims in JWT
                                                        are those that
                                                        are believed
                                                        (right or wrong)
                                                        to be widely
                                                        applicable
                                                        across different
                                                        applications of
                                                        JWT. One could
                                                        argue about it
                                                        but scope is
                                                        probably not one
                                                        of those.

                                                      It would probably
                                                      make sense to try
                                                      and build a
                                                      profile of JWT
                                                      specifically for
                                                      OAuth access
                                                      tokens (though I
                                                      suspect there are
                                                      some turtles and
                                                      dragons in there),
                                                      which might be the
                                                      appropriate place
                                                      to define/register
                                                      a scope claim.

                                                      On
                                                        Thu, Feb 28,
                                                        2013 at 9:24 AM,
                                                        Phil Hunt <phil.hunt@oracle.com>
                                                        wrote:

                                                        Are
                                                          you advocating
                                                          TWO systems?
                                                          That seems
                                                          like a bad
                                                          choice.

                                                          I would rather
                                                          fix scope than
                                                          go to a two
                                                          system
                                                          approach.

                                                          Phil

                                                          Sent from my
                                                          phone.

                                                          On 2013-02-28,
                                                          at 8:17, John
                                                          Bradley <ve7jtb@ve7jtb.com>
                                                          wrote:

                                                          > While
                                                          scope is one
                                                          method that a
                                                          AS could
                                                          communicate
                                                          authorization
                                                          to a RS, it is
                                                          not the only
                                                          or perhaps
                                                          even the most
                                                          likely one.

                                                          > Using
                                                          scope requires
                                                          a relatively
                                                          tight binding
                                                          between the RS
                                                          and AS,  UMA
                                                          uses a
                                                          different
                                                          mechanism that
                                                          describes
                                                          finer grained
                                                          operations.

                                                          > The AS
                                                          may include
                                                          roles, user,
                                                          or other more
                                                          abstract
                                                          claims that
                                                          the the client
                                                          may (god help
                                                          them) pass on
                                                          to EXCML for
                                                          processing.

                                                          >

                                                          > While
                                                          having a
                                                          scopes claim
                                                          is possible,
                                                          like any other
                                                          claim it is
                                                          not part of
                                                          the JWT core
                                                          security
                                                          processing
                                                          claims, and
                                                          needs to be
                                                          defined by
                                                          extension.

                                                          >

                                                          > John B.

                                                          > On
                                                          2013-02-28, at
                                                          2:29 AM,
                                                          Hannes
                                                          Tschofenig
                                                          <hannes.tschofenig@gmx.net>
                                                          wrote:

                                                          >

                                                          >> Hi
                                                          Mike,

                                                          >>

                                                          >> when
                                                          I worked on
                                                          the MAC
                                                          specification
                                                          I noticed that
                                                          the JWT does
                                                          not have a
                                                          claim for the
                                                          scope. I
                                                          believe that
                                                          this would be
                                                          needed to
                                                          allow the
                                                          resource
                                                          server to
                                                          verify whether
                                                          the scope the
                                                          authorization
                                                          server
                                                          authorized is
                                                          indeed what
                                                          the client is
                                                          asking for.

                                                          >>

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

--Apple-Mail=_04C55B8F-B6D1-4038-94E4-6132B5266687--

--Apple-Mail=_B7B7849C-52AA-447C-84F4-2002C676ECE2
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMjI4MTk1NzA5WjAjBgkqhkiG9w0BCQQxFgQUhSBMr3fO
TEEzrrYaB9SmxNrxPI0wgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAJBCFe1bjqVmjoZDoustrOb+l6QV+AnbeIaEMhu6K
m5USmiWu+azmqITuklxlTtIzCT3APyhjUkFZosSZIP9ittdmfAIzXn1LbQgiHG94Y8OLXynbhGKk
ks1an/2NBN+2LRIOR6Q65LQZLYxZVyaUsVCfQJmNWcBjbwyqdHCu1gvWQqsg+07/A8ZJMvjn8Drk
Ls6cbWJpIZkDDHQGSWXX1Q2J+CDwgkZF5nKFvCzf6lAk+B8Sqf9V2iGqBMJ0sWbwjID6ySXkoSc3
6do9pT+r2j8/1l4mT42HeWhjpIK5VVGG6ubXy3RzEkLDeIHlEIW0Yp5s/XbatAz5uv5sKFhOhgAA
AAAAAA==

--Apple-Mail=_B7B7849C-52AA-447C-84F4-2002C676ECE2--

From ve7jtb@ve7jtb.com  Thu Feb 28 11:59:18 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C864921F891C for ; Thu, 28 Feb 2013 11:59:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.424
X-Spam-Level: 
X-Spam-Status: No, score=-3.424 tagged_above=-999 required=5 tests=[AWL=0.174,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7AlUcfJPGRV for ; Thu, 28 Feb 2013 11:59:17 -0800 (PST)
Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by ietfa.amsl.com (Postfix) with ESMTP id DFE7921F88E1 for ; Thu, 28 Feb 2013 11:59:16 -0800 (PST)
Received: by mail-pa0-f52.google.com with SMTP id fb1so1334003pad.25 for ; Thu, 28 Feb 2013 11:59:16 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=0tF5I2blCMhnWU3h+Tszbc0btrTc9rDVA9E9NupSRWM=; b=fJjEGWNfpAddMh7i2pi0reo3uO+n06Mu6CedkHCZOZJRgpXLtiLFnb7BfHIfeX4BhF TCanReF/Ya+id3+owvbY9wdzCP/DV1y7kQTxevcPINydP5z2dP9gt0zEcYxl01bQsEd2 Kvu2Z7bigKos5dvBZQg8OyAoMvPgyI+TOfWoKd7XTBiCSi3yrbBUaSqPMSL+wMIaUEV2 yMwZEXnZ7yERV+JA63YQgpPlAUuDch2318YS2uIwf2pyHNx8nEmn5NEAT1EMWUsL3o6/ 3SWSmgohRrLW2/AHKktIlHp5nZGF7agJehLVLnCQYiaNe5yBUoVirLjyExuTqp+nvBbb N1FA==
X-Received: by 10.66.4.193 with SMTP id m1mr14748433pam.214.1362081556266; Thu, 28 Feb 2013 11:59:16 -0800 (PST)
Received: from [192.168.43.179] (mobile-166-137-184-056.mycingular.net. [166.137.184.56]) by mx.google.com with ESMTPS id i6sm10234900paw.19.2013.02.28.11.59.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Feb 2013 11:59:14 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_C1163A94-0DDC-4C53-8B2D-1FF0203C2F90"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <512FB26D.5030401@mitre.org>
Date: Thu, 28 Feb 2013 11:59:08 -0800
Message-Id: <3E71DC94-44AF-40BC-B9B9-3D09606BA2B0@ve7jtb.com>
References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net>     <48FD87D1-4DF4-4289-99B7-40A515F31890@oracle.com> <3E472720-31A4-40A0-AAA4-402CF850831A@ve7jtb.com> <7127843B-D7B0-4AB6-87F1-1604D1EFFA79@oracle.com> <50DA292F-32F0-4266-8401-006AD837B775@ve7jtb.com>  <59E470B10C4630419ED717AC79FCF9A948D58BEE@BY2PRD0411MB441.namprd04.prod.outlook.com>  <512FB26D.5030401@mitre.org>
To: Justin Richer 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQltimbE70yIbk+PEl99N1V7hAk7q1SNe9zqevHU1STgzFrKXLGXm8OxKdNQXNFT+W/HHo/4
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] JWT - scope claim missing
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 19:59:18 -0000

--Apple-Mail=_C1163A94-0DDC-4C53-8B2D-1FF0203C2F90
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_D5978521-803D-4BAE-A5F6-3EB39A01B565"

--Apple-Mail=_D5978521-803D-4BAE-A5F6-3EB39A01B565
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Yes that may be the best place for it.

John B.
On 2013-02-28, at 11:39 AM, Justin Richer  wrote:

> It doesn't belong in the assertion drafts, but maybe it can be =
combined with the token introspection piece I've started (but isn't an =
item yet)? I think that would address the other thread that Hannes was =
talking about as well. We'd essentially be defining one set of token =
metadata (including scopes, client_id, subject, audience, expiration and =
a few others) and two methods to get at it: either by making an =
introspection call, or by packing it into the token directly. And the =
two could even work together if you wanted to.
>=20
>  -- Justin
>=20
> On 02/28/2013 02:36 PM, Brian Campbell wrote:
>> I do agree that a WG profile of a JWT-structured access token could =
lend itself to interoperability and ultimately be a useful thing. But =
you are right that there already are many implementations out there in =
the wild (heck, I've written one myself) and that might make it =
difficult to standardize on something.
>>=20
>> Because of that, and many other reasons, I don't want to try and add =
that to existing assertion drafts.
>>=20
>>=20
>> On Thu, Feb 28, 2013 at 12:13 PM, Lewis Adam-CAL022 =
 wrote:
>> Hi Brian, a few thoughts from somebody outside of the WG =85
>>=20
>> =20
>> As a newcomer to OAuth last year, I was initially confused by the =
titles.  It was confusing because we have SAML bearer *assertions* and =
JWT bearer *tokens* =85 and as John just (begrudgingly) stated in this =
thread, the JWT is being used as an assertion in this profile (and in =
OIDC).  I think it will be difficult to find a good name for these =
profiles since they do two entirely different things (e.g. define a new =
grant type and define a new method of client authentication).  One could =
argue that as long as                       the WG is at it, then why =
not add a third section to the JWT profile, which talks about usage of =
JWT-structured bearer access tokens: it would not be any less related =
than the other two focuses of the doc.  Then the document could be =
called something simple like =93profiles of JWT usage in OAuth=94 or =
something like that.=20
>>=20
>> =20
>> On one hand, it is probably na=EFve to think that an access token can =
be standardized in a profile given how many have already been released =
into the wild, but on the other hand, a WG profile of a JWT-structured =
access token could lend itself to interoperability, where AS =
implementations can advertise conformance to the profile and who knows =85=
 maybe the RS=92s of the future will be good with this.=20
>>=20
>> =20
>> adam
>>=20
>> =20
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf Of Brian Campbell
>> Sent: Thursday, February 28, 2013 1:03 PM
>> To: John Bradley
>> Cc: oauth@ietf.org WG
>>=20
>>=20
>> Subject: Re: [OAUTH-WG] JWT - scope claim missing
>> =20
>> I'm not sure anyone really "picked" the titles for the bearer token =
profiles. They just kind of evolved. And evolved in funny ways =
especially when client authn to the AS was added.
>>=20
>> You won't hear me argue that the titles are "good" and this is not =
the first time there's been confusion about what they actually do. They =
define new grant types and new client authentication methods. They *do =
not* define an access token format or anything else about access tokens. =
JWT and SAML could be used for that but that's not what these drafts do.
>>=20
>> Suggestions for better title(s) would be more than welcome.
>>=20
>> =20
>> Here's what they are now:
>>=20
>>=20
>> SAML 2.0 Bearer Assertion Profiles for OAuth 2.0
>> draft-ietf-oauth-saml2-bearer
>>=20
>> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
>> draft-ietf-oauth-jwt-bearer
>>=20
>> Assertion Framework for OAuth 2.0
>> draft-ietf-oauth-assertions
>>=20
>> =20
>> On Thu, Feb 28, 2013 at 11:36 AM, John Bradley  =
wrote:
>>=20
>> Yes the title likely adds to the confusion given that the bearer =
tokens are not access tokens.
>>=20
>> =20
>> Things as separate from OAuth as the Firefox browerID spec use JWS =
signed JWTs. =20
>>=20
>> =20
>> The bearer token profiles for OAuth 2 are for OAuth2.
>>=20
>> =20
>> The JSON Web Token (JWT) spec did not start in OAuth and is not OAuth =
specific.
>>=20
>> =20
>> A JWT is:
>>=20
>> JSON Web Token (JWT)  A string representing a set of claims as a JSON
>>       object that is encoded in a JWS or JWE, enabling the claims to =
be
>>       digitally signed or MACed and/or encrypted.
>> =20
>> So OAuth or other profiles may define claims to go in a JWT, but the =
JWT needs to itself only define the claims necessary for security =
processing. =20
>>=20
>> =20
>> John B.
>>=20
>> PS that was a soft ball If you hadn't responded I would have been =
disappointed.  I din't pick the title for the bearer token profiles.
>>=20
>> =20
>> =20
>> On 2013-02-28, at 10:12 AM, Phil Hunt  wrote:
>>=20
>>=20
>>=20
>> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
>>=20
>>=20
>> Note the title says "for OAuth2"
>>=20
>> =20
>> Sorry. Couldn't resist.=20
>>=20
>> =20
>> Phil
>>=20
>> =20
>> Sent from my phone.
>>=20
>>=20
>> On 2013-02-28, at 9:40, John Bradley  wrote:
>>=20
>> JWT is an assertion( I am probably going to regret using that word).
>>=20
>> =20
>> It is used in openID connect for id_tokens, it is used in OAuth for =
Assertion grant types and authentication of the client to the token =
endpoint.
>>=20
>> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04
>>=20
>> =20
>> =20
>> =20
>> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
>>=20
>> =20
>> Dosen't define JWT's use for access tokens for the RS.  =20
>>=20
>> =20
>> Bottom line JWT is for more than access tokens.
>>=20
>> =20
>> John B.
>>=20
>> =20
>> On 2013-02-28, at 9:28 AM, Phil Hunt  wrote:
>>=20
>>=20
>>=20
>> Are you saying jwt is not an access token type?
>>=20
>> Phil
>>=20
>> =20
>> Sent from my phone.
>>=20
>>=20
>> On 2013-02-28, at 8:58, John Bradley  wrote:
>>=20
>> Yes, defining scope in JWT is the wrong place.   JWT needs to stick =
to the security claims needed to process JWT.
>>=20
>> =20
>> I also don't know how far you get requiring a specific authorization =
format for JWT, some AS will wan to use a opaque reference, some might =
want to use a user claim or                                              =
             role claim, others may use scopes,  combining scopes and =
claims is also possible.
>>=20
>> =20
>> Right now it is up to a AS RS pair to agree on how to communicate =
authorization.   I don't want MAC to be more restrictive than bearer =
when it comes to authorization between AS and RS.
>>=20
>> =20
>> Hannes wanted to know why JWT didn't define scope.  The simple answer =
is that it is out of scope for JWT itself.   It might be defined in a =
OAuth access token profile for JWT but it should not be specific to MAC.
>>=20
>> =20
>> John B.
>>=20
>> On 2013-02-28, at 8:44 AM, Brian Campbell =
 wrote:
>>=20
>>=20
>>=20
>> I think John's point was more that scope is something rather specific =
to an OAuth access token and, while JWT is can be used to represent an =
access token, it's not the only application of JWT. The 'standard' =
claims in JWT are those that are believed (right or wrong) to be widely =
applicable across different applications of JWT. One could argue about =
it but scope is probably not one of those.
>>=20
>> It would probably make sense to try and build a profile of JWT =
specifically for OAuth access tokens (though I suspect there are some =
turtles and dragons in there), which                                     =
                      might be the appropriate place to define/register =
a scope claim.
>>=20
>> =20
>> On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt  =
wrote:
>>=20
>> Are you advocating TWO systems? That seems like a bad choice.
>>=20
>> I would rather fix scope than go to a two system approach.
>>=20
>> Phil
>>=20
>> Sent from my phone.
>>=20
>> On 2013-02-28, at 8:17, John Bradley  wrote:
>>=20
>> > While scope is one method that a AS could communicate authorization =
to a RS, it is not the only or perhaps even the most likely one.
>> > Using scope requires a relatively tight binding between the RS and =
AS,  UMA uses a different mechanism that describes finer grained =
operations.
>> > The AS may include roles, user, or other more abstract claims that =
the the client may (god help them) pass on to EXCML for processing.
>> >
>> > While having a scopes claim is possible, like any other claim it is =
not part of the JWT core security processing claims, and needs to be =
defined by extension.
>> >
>> > John B.
>> > On 2013-02-28, at 2:29 AM, Hannes Tschofenig =
 wrote:
>> >
>> >> Hi Mike,
>> >>
>> >> when I worked on the MAC specification I noticed that the JWT does =
not have a claim for the scope. I believe that this would be needed to =
allow the resource server to verify whether the scope the authorization =
server authorized is indeed what the client is asking for.
>> >>
>> >> 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
>>=20
>> =20
>> =20
>> =20
>> =20
>> =20
>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail=_D5978521-803D-4BAE-A5F6-3EB39A01B565
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Yes =
that may be the best place for it.
John =
B.
On 2013-02-28, at 11:39 AM, Justin Richer <jricher@mitre.org> =
wrote:

 =20

 =20

    It doesn't belong in the assertion drafts, but maybe it can be
    combined with the token introspection piece I've started (but isn't
    an item yet)? I think that would address the other thread that
    Hannes was talking about as well. We'd essentially be defining one
    set of token metadata (including scopes, client_id, subject,
    audience, expiration and a few others) and two methods to get at it:
    either by making an introspection call, or by packing it into the
    token directly. And the two could even work together if you wanted
    to.

     -- Justin

    On 02/28/2013 02:36 PM, Brian =
Campbell
      wrote:

        I do agree that a WG profile of a JWT-structured access
          token could lend itself to interoperability and ultimately be
          a useful thing. But you are right that there already are many
          implementations out there in the wild (heck, I've written one
          myself) and that might make it difficult to standardize on
          something.

        Because of that, and many other reasons, I don't want to try and
        add that to existing assertion drafts.

          On Thu, Feb 28, 2013 at 12:13 PM,
            Lewis Adam-CAL022 <Adam.Lewis@motorolasolutions.com>
            wrote:

                Hi
                      Brian, a few thoughts from somebody outside of the
                      WG =85

As a
                      newcomer to OAuth last year, I was initially
                      confused by the titles.  It was confusing =
because
                      we have SAML bearer *assertions* and JWT
                      bearer *tokens* =85 and as John just
                      (begrudgingly) stated in this thread, the JWT is
                      being used as an assertion in this profile (and in
                      OIDC).  I think it will be difficult to find =
a
                      good name for these profiles since they do two
                      entirely different things (e.g. define a new grant
                      type and define a new method of client
                      authentication).  One could argue that as =
long as
                      the WG is at it, then why not add a third section
                      to the JWT profile, which talks about usage of
                      JWT-structured bearer access tokens: it would not
                      be any less related than the other two focuses of
                      the doc.  Then the document could be called
                      something simple like =93profiles of JWT usage in
                      OAuth=94 or something like that. 

On
                      one hand, it is probably na=EFve to think that an
                      access token can be standardized in a profile
                      given how many have already been released into the
                      wild, but on the other hand, a WG profile of a
                      JWT-structured access token could lend itself to
                      interoperability, where AS implementations can
                      advertise conformance to the profile and who knows
                      =85 maybe the RS=92s of the future will be good =
with
                      this. 

adam

                  From:
                        oauth-bounces@ietf.org
                        [mailto:oauth-bounces@ietf.org]
                        On Behalf Of Brian Campbell

                        Sent: Thursday, February 28, 2013 1:03 =
PM

                        To: John Bradley

                        Cc: oauth@ietf.org
                        WG

                      Subject: Re: [OAUTH-WG] JWT - scope claim
                      missing

                    I'm
                        not sure anyone really "picked" the titles for
                        the bearer token profiles. They just kind of
                        evolved. And evolved in funny ways especially
                        when client authn to the AS was added.

                        You won't hear
                            me argue that the titles are "good" and this
                            is not the first time there's been confusion
                            about what they actually do. They define new
                            grant types and new client authentication
                            methods. They *do not* define an access
                            token format or anything else about access
                            tokens. JWT and SAML could be used for that
                            but that's not what these drafts do.

                        Suggestions for =
better
                            title(s) would be more than welcome.

                          Here's what they =
are
                              now:

                              SAML 2.0 Bearer Assertion Profiles for
                              OAuth 2.0

                              draft-ietf-oauth-saml2-bearer

                              JSON Web Token (JWT) Bearer Token Profiles
                              for OAuth 2.0

                              draft-ietf-oauth-jwt-bearer

                              Assertion Framework for OAuth 2.0

                              draft-ietf-oauth-assertions

                              On Thu, Feb =
28,
                                  2013 at 11:36 AM, John Bradley <ve7jtb@ve7jtb.com>
                                  wrote:
                                Yes the =
title
                                    likely adds to the confusion given
                                    that the bearer tokens are not
                                    access tokens.

                                  Things as
                                      separate from OAuth as the Firefox
                                      browerID spec use JWS signed JWTs.

                                  The bearer
                                      token profiles for OAuth 2 are for
                                      OAuth2.

                                  The JSON Web Token
                                        (JWT) spec did not =
start in
                                      OAuth and is not OAuth =
specific.

                                  A JWT =
is:

                                    JSON Web Token (JWT)  A string =
representing a set of claims as a JSON
                                          object that is =
encoded in a JWS or JWE, enabling the claims to be
                                          digitally =
signed or MACed and/or encrypted.

                                    So OAuth =
or
                                        other profiles may define claims
                                        to go in a JWT, but the JWT
                                        needs to itself only define the
                                        claims necessary for security
                                        processing.  

                                    John =
B.

                                    PS that =
was a
                                        soft ball If you hadn't
                                        responded I would have been
                                        disappointed.  I din't pick =
the
                                        title for the bearer token
                                        profiles.

                                          On
                                              2013-02-28, at 10:12 AM,
                                              Phil Hunt <phil.hunt@oracle.com>
                                              wrote:

                                              JSON
                                                  Web Token (JWT) Bearer
                                                  Token Profiles for
                                                  OAuth =
2.0

                                                Note the title says "for
                                                OAuth2"

                                            Sorry.
                                                Couldn't =
resist. 

                                            Phil

                                              Sent
                                                  from my phone.

                                                On 2013-02-28, at 9:40,
                                                John Bradley <ve7jtb@ve7jtb.com>
                                                wrote:

                                            JWT
                                                is an assertion( I am
                                                probably going to regret
                                                using that word).

                                              It
                                                  is used in openID
                                                  connect for id_tokens,
                                                  it is used in OAuth
                                                  for Assertion grant
                                                  types and
                                                  authentication of the
                                                  client to the token
                                                  endpoint.

                                              http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-0=
4

                                                JSON Web
                                                    Token (JWT) Bearer
                                                    Token Profiles for
                                                    OAuth =
2.0

                                                Dosen't
                                                    define JWT's use for
                                                    access tokens for
                                                    the RS. =

                                                Bottom
                                                    line JWT is for more
                                                    than access =
tokens.

                                                John
                                                    B.

                                                  On
                                                      2013-02-28, at
                                                      9:28 AM, Phil Hunt
                                                      <phil.hunt@oracle.com>
                                                      wrote:

                                                    Are
                                                        you saying jwt
                                                        is not an access
                                                        token type?

                                                        Phil
                                                      =

                                                      Sent
                                                          from my =
phone.

                                                        On 2013-02-28,
                                                        at 8:58, John
                                                        Bradley <ve7jtb@ve7jtb.com>
                                                        wrote:

                                                    Yes,=

                                                        defining scope
                                                        in JWT is the
                                                        wrong place. =

                                                        JWT needs to
                                                        stick to the
                                                        security claims
                                                        needed to
                                                        process JWT.
                                                      =

                                                      I
                                                          also don't
                                                          know how far
                                                          you get
                                                          requiring a
                                                          specific
                                                          authorization
                                                          format for
                                                          JWT, some AS
                                                          will wan to
                                                          use a opaque
                                                          reference,
                                                          some might
                                                          want to use a
                                                          user claim or
                                                          role claim,
                                                          others may use
                                                          scopes,
                                                          =
 combining
                                                          scopes and
                                                          claims is also
                                                          possible.

                                                      =

                                                      Right
                                                          now it is up
                                                          to a AS RS
                                                          pair to agree
                                                          on how to
                                                          communicate
                                                          authorization.
                                                            I don't =
want
                                                          MAC to be more
                                                          restrictive
                                                          than bearer
                                                          when it comes
                                                          to
                                                          authorization
                                                          between AS and
                                                          RS.
                                                        =

                                                        Hannes
                                                          wanted to know
                                                          why JWT didn't
                                                          define scope.
                                                           The =
simple
                                                          answer is that
                                                          it is out of
                                                          scope for JWT
                                                          itself.   =
It
                                                          might be
                                                          defined in a
                                                          OAuth access
                                                          token profile
                                                          for JWT but it
                                                          should not be
                                                          specific to
                                                          MAC.

                                                        =

                                                        John
                                                          B.

                                                          On
                                                          2013-02-28, at
                                                          8:44 AM, Brian
                                                          Campbell =
<bcampbell@pingidentity.com>
                                                          wrote:

                                                          I think John's point =
was more that scope is
                                                          something
                                                          rather
                                                          specific to an
                                                          OAuth access
                                                          token and,
                                                          while JWT is
                                                          can be used to
                                                          represent an
                                                          access token,
                                                          it's not the
                                                          only
                                                          application of
                                                          JWT. The
                                                          'standard'
                                                          claims in JWT
                                                          are those that
                                                          are believed
                                                          (right or
                                                          wrong) to be
                                                          widely
                                                          applicable
                                                          across
                                                          different
                                                          applications
                                                          of JWT. One
                                                          could argue
                                                          about it but
                                                          scope is
                                                          probably not
                                                          one of =
those.

It
                                                          would probably
                                                          make sense to
                                                          try and build
                                                          a profile of
                                                          JWT
                                                          specifically
                                                          for OAuth
                                                          access tokens
                                                          (though I
                                                          suspect there
                                                          are some
                                                          turtles and
                                                          dragons in
                                                          there), which
                                                          might be the
                                                          appropriate
                                                          place to
                                                          =
define/register
                                                          a scope =
claim.

                                                          On
                                                          Thu, Feb 28,
                                                          2013 at 9:24
                                                          AM, Phil Hunt
                                                          <phil.hunt@oracle.com>
                                                          wrote:
Are
                                                          you advocating
                                                          TWO systems?
                                                          That seems
                                                          like a bad
                                                          choice.

                                                          I would rather
                                                          fix scope than
                                                          go to a two
                                                          system
                                                          approach.

                                                          Phil

                                                          Sent from my
                                                          phone.

                                                          On 2013-02-28,
                                                          at 8:17, John
                                                          Bradley <ve7jtb@ve7jtb.com>
                                                          wrote:

                                                          > While
                                                          scope is one
                                                          method that a
                                                          AS could
                                                          communicate
                                                          authorization
                                                          to a RS, it is
                                                          not the only
                                                          or perhaps
                                                          even the most
                                                          likely =
one.

                                                          > Using
                                                          scope requires
                                                          a relatively
                                                          tight binding
                                                          between the RS
                                                          and AS, =
 UMA
                                                          uses a
                                                          different
                                                          mechanism that
                                                          describes
                                                          finer grained
                                                          =
operations.

                                                          > The AS
                                                          may include
                                                          roles, user,
                                                          or other more
                                                          abstract
                                                          claims that
                                                          the the client
                                                          may (god help
                                                          them) pass on
                                                          to EXCML for
                                                          =
processing.

                                                          >

                                                          > While
                                                          having a
                                                          scopes claim
                                                          is possible,
                                                          like any other
                                                          claim it is
                                                          not part of
                                                          the JWT core
                                                          security
                                                          processing
                                                          claims, and
                                                          needs to be
                                                          defined by
                                                          extension.

                                                          >

                                                          > John =
B.

                                                          > On
                                                          2013-02-28, at
                                                          2:29 AM,
                                                          Hannes
                                                          Tschofenig
                                                          <hannes.tschofenig@gmx.net>
                                                          wrote:

                                                          >

                                                          >> Hi
                                                          Mike,

                                                          >>

                                                          >> when
                                                          I worked on
                                                          the MAC
                                                          specification
                                                          I noticed that
                                                          the JWT does
                                                          not have a
                                                          claim for the
                                                          scope. I
                                                          believe that
                                                          this would be
                                                          needed to
                                                          allow the
                                                          resource
                                                          server to
                                                          verify whether
                                                          the scope the
                                                          authorization
                                                          server
                                                          authorized is
                                                          indeed what
                                                          the client is
                                                          asking =
for.

                                                          >>

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

_______________________________________________
OAuth mailing =
list
OAuth@ietf.org
https://www.ietf.org/=
mailman/listinfo/oauth

=

--Apple-Mail=_D5978521-803D-4BAE-A5F6-3EB39A01B565--

--Apple-Mail=_C1163A94-0DDC-4C53-8B2D-1FF0203C2F90
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMjI4MTk1OTA5WjAjBgkqhkiG9w0BCQQxFgQUoMdfd+z+
QZjJ+XHpZC4ejmdBHuIwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAOpkbMuOo3B0Smht30iSVkJE+DbloFZfTNdNRUkmS
PE5UPPJs0N+GXlYlN1uCJO2p03DwFnp/CSVrIblH8xgN1KBdew+GRgOkD/GnaoE3lT33zyeTu2HV
QSDzNx6fTg7pXyq1WwvMNTnUh9cz27O4ctt5JESNokl15JegsYMdHaF5er1mm4Qb8KPGIEHu/L1j
V8Kn2ojdr4Oq+/ftAOvA3gyg5gOpolF1oaLN+Ey3mEwT1uZdH6l9tH545GaYgwdsnWRimfbrbbzq
lHSSMV+C5EyT7OINKf2eI33jSbFtVVtdDFR9e+0oCYe6SDK8ePdt7h1s0XghJs3jBE6+Yfq89AAA
AAAAAA==

--Apple-Mail=_C1163A94-0DDC-4C53-8B2D-1FF0203C2F90--

From leifj@mnt.se  Thu Feb 28 12:13:28 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB5621F89FC for ; Thu, 28 Feb 2013 12:13:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.733
X-Spam-Level: 
X-Spam-Status: No, score=-1.733 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ff3KuYyaXxFv for ; Thu, 28 Feb 2013 12:13:28 -0800 (PST)
Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id D3F4521F8845 for ; Thu, 28 Feb 2013 12:13:27 -0800 (PST)
Received: by mail-la0-f42.google.com with SMTP id fe20so2228916lab.15 for ; Thu, 28 Feb 2013 12:13:26 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:x-gm-message-state; bh=8KXu85yGHq/pbzFW2Zwkyk6+Z8jq6DgJwmcri7YeUfQ=; b=opFBzfXxLtlZAo/aC1d5hjN2EExfQnqMbAWVxsDfcjdFRBAXCYMBzDQrS4jFLr9yKX XfrG6p/AKwAvy1hN/4m9KiebV/7wMMvEQDR9KHx2YM9blo1Ncktk1tHjhc3/YAlrVhT/ xsLjtYgaq4/LTXetbs0QYdNi2BdmSGtND3xUBSFc9DJoY7+wGrmAh6xX0+Jsm/cxEsDP ada4EELt8RovMSn/VHnaC6iF+fUGuFlrpuQXazDRMQBXDPK9yW8QXkZk/ezXlOsIiY/9 2eJCyeDh8p1KOa9QCh+L5sDOiKtrtM/yMnnCVlXM3tJT0wIOWF2YlQSamnBu7WZRAlDT DGew==
X-Received: by 10.112.28.41 with SMTP id y9mr4083620lbg.133.1362082406698; Thu, 28 Feb 2013 12:13:26 -0800 (PST)
Received: from [10.0.0.244] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPS id gm20sm5325292lab.7.2013.02.28.12.13.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Feb 2013 12:13:25 -0800 (PST)
Message-ID: <512FBA63.4060108@mnt.se>
Date: Thu, 28 Feb 2013 21:13:23 +0100
From: Leif Johansson 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: oauth@ietf.org
References: <1362079266.8952.YahooMailClassic@web141002.mail.bf1.yahoo.com>
In-Reply-To: <1362079266.8952.YahooMailClassic@web141002.mail.bf1.yahoo.com>
Content-Type: multipart/alternative; boundary="------------040905060306030803090703"
X-Gm-Message-State: ALoCoQnwCCcGd+J6B2ibT1k+C40kwYaAurtDTUA2VEgxNizWnhGuszEZIoKYYkLo2Rd0rQNKzkW8
Subject: Re: [OAUTH-WG] Fw:  IPR Disclosure: - What to Do with JWT ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 20:13:29 -0000

This is a multi-part message in MIME format.
--------------040905060306030803090703
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 02/28/2013 08:21 PM, Oleg Gryb wrote:
> Dear OAuth WG and Chairs,
>
> Can somebody please comment the Certicom's disclosure below? If the
> purpose of this disclosure is to inform us that JWT can be potentially
> a subject of royalties and other possible legal actions, the value of
> adopting JWT in the scope of OAuth 2.0 IETF standard would definitely
> diminish and if this is the case shouldn't we consider replacing it
> with something similar, but different, which would not be a subject of
> the future possible litigation?   
>
> I'm not a lawyer and might not understand the statement below
> correctly, so please let me know if/where I'm wrong. Please keep in
> mind also that the popularity of JWT is growing fast along with the
> implementations, so we need to do something quickly.
>
I'm curious too.

Skimming through the summaries on google patents of the cited patents I
couldn't immediately see
the relationship with JWTs but then again I'm not a patent lawyer (nor
do I play one on the net).

        Cheers Leif

--------------040905060306030803090703
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

    On 02/28/2013 08:21 PM, Oleg Gryb
      wrote:

            Dear OAuth WG and
              Chairs,

              Can somebody please comment the Certicom's disclosure
              below? If the purpose of this disclosure is to inform us
              that JWT can be potentially a subject of royalties and
              other possible legal actions, the value of adopting JWT in
              the scope of OAuth 2.0 IETF standard would definitely
              diminish and if this is the case shouldn't we consider
              replacing it with something similar, but different, which
              would not be a subject of the future possible litigation? 

              I'm not a lawyer and might not understand the statement
              below correctly, so please let me know if/where I'm wrong.
              Please keep in mind also that the popularity of JWT is
              growing fast along with the implementations, so we need to
              do something quickly.

    I'm curious too. 

    Skimming through the summaries on google patents of the cited
    patents I couldn't immediately see 

    the relationship with JWTs but then again I'm not a patent lawyer
    (nor do I play one on the net).

            Cheers Leif

--------------040905060306030803090703--

From prateek.mishra@oracle.com  Thu Feb 28 12:44:06 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909A121F89B2 for ; Thu, 28 Feb 2013 12:44:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.565
X-Spam-Level: 
X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.033,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMHFl3lMnFdW for ; Thu, 28 Feb 2013 12:44:05 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id B9CCF21F89CC for ; Thu, 28 Feb 2013 12:44:03 -0800 (PST)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1SKi2V6016227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Feb 2013 20:44:03 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1SKi1ha015048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2013 20:44:02 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1SKi1Ad023595; Thu, 28 Feb 2013 14:44:01 -0600
Received: from [10.152.55.88] (/10.152.55.88) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 28 Feb 2013 12:44:00 -0800
Message-ID: <512FC18D.1020803@oracle.com>
Date: Thu, 28 Feb 2013 15:43:57 -0500
From: prateek mishra 
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: oauth@ietf.org, Brian Campbell 
References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net>     <48FD87D1-4DF4-4289-99B7-40A515F31890@oracle.com> <3E472720-31A4-40A0-AAA4-402CF850831A@ve7jtb.com> <7127843B-D7B0-4AB6-87F1-1604D1EFFA79@oracle.com> <50DA292F-32F0-4266-8401-006AD837B775@ve7jtb.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------010101070200010105050902"
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: Re: [OAUTH-WG] JWT - scope claim missing
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 20:44:06 -0000

This is a multi-part message in MIME format.
--------------010101070200010105050902
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization 
Grants
JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants
Assertion Framework for OAuth 2.0 

a bit wordy, but does get the point across IMO

- prateek
> I'm not sure anyone really "picked" the titles for the bearer token 
> profiles. They just kind of evolved. And evolved in funny ways 
> especially when client authn to the AS was added.
>
> You won't hear me argue that the titles are "good" and this is not the 
> first time there's been confusion about what they actually do. They 
> define new grant types and new client authentication methods. They *do 
> not* define an access token format or anything else about access 
> tokens. JWT and SAML could be used for that but that's not what these 
> drafts do.
>
> Suggestions for better title(s) would be more than welcome.
>
> Here's what they are now:
>
> SAML 2.0 Bearer Assertion Profiles for OAuth 2.0
> draft-ietf-oauth-saml2-bearer
>
> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
> draft-ietf-oauth-jwt-bearer
>
> Assertion Framework for OAuth 2.0
> draft-ietf-oauth-assertions
>
> On Thu, Feb 28, 2013 at 11:36 AM, John Bradley  > wrote:
>
>     Yes the title likely adds to the confusion given that the bearer
>     tokens are not access tokens.
>
>     Things as separate from OAuth as the Firefox browerID spec use JWS
>     signed JWTs.
>
>     The bearer token profiles for OAuth 2 are for OAuth2.
>
>     The JSON Web Token (JWT)
>      spec
>     did not start in OAuth and is not OAuth specific.
>
>     A JWT is:
>
>     JSON Web Token (JWT)  A string representing a set of claims as a JSON
>            object that is encoded in a JWS or JWE, enabling the claims to be
>            digitally signed or MACed and/or encrypted.
>
>
>     So OAuth or other profiles may define claims to go in a JWT, but
>     the JWT needs to itself only define the claims necessary for
>     security processing.
>
>     John B.
>     PS that was a soft ball If you hadn't responded I would have been
>     disappointed.  I din't pick the title for the bearer token profiles.
>
>
>     On 2013-02-28, at 10:12 AM, Phil Hunt      > wrote:
>
>>              
>>
>>
>>       JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
>>
>>
>>     Note the title says "for OAuth2"
>>
>>     Sorry. Couldn't resist.
>>
>>     Phil
>>
>>     Sent from my phone.
>>
>>     On 2013-02-28, at 9:40, John Bradley >     > wrote:
>>
>>>     JWT is an assertion( I am probably going to regret using that
>>>     word).
>>>
>>>     It is used in openID connect for id_tokens, it is used in OAuth
>>>     for Assertion grant types and authentication of the client to
>>>     the token endpoint.
>>>     http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04
>>>
>>>
>>>       JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
>>>
>>>
>>>     Dosen't define JWT's use for access tokens for the RS.
>>>
>>>     Bottom line JWT is for more than access tokens.
>>>
>>>     John B.
>>>
>>>     On 2013-02-28, at 9:28 AM, Phil Hunt >>     > wrote:
>>>
>>>>     Are you saying jwt is not an access token type?
>>>>
>>>>     Phil
>>>>
>>>>     Sent from my phone.
>>>>
>>>>     On 2013-02-28, at 8:58, John Bradley >>>     > wrote:
>>>>
>>>>>     Yes, defining scope in JWT is the wrong place.   JWT needs to
>>>>>     stick to the security claims needed to process JWT.
>>>>>
>>>>>     I also don't know how far you get requiring a specific
>>>>>     authorization format for JWT, some AS will wan to use a opaque
>>>>>     reference, some might want to use a user claim or role claim,
>>>>>     others may use scopes,  combining scopes and claims is also
>>>>>     possible.
>>>>>
>>>>>     Right now it is up to a AS RS pair to agree on how to
>>>>>     communicate authorization.   I don't want MAC to be more
>>>>>     restrictive than bearer when it comes to authorization between
>>>>>     AS and RS.
>>>>>
>>>>>     Hannes wanted to know why JWT didn't define scope.  The simple
>>>>>     answer is that it is out of scope for JWT itself.   It might
>>>>>     be defined in a OAuth access token profile for JWT but it
>>>>>     should not be specific to MAC.
>>>>>
>>>>>     John B.
>>>>>     On 2013-02-28, at 8:44 AM, Brian Campbell
>>>>>     >>>>     > wrote:
>>>>>
>>>>>>     I think John's point was more that scope is something rather
>>>>>>     specific to an OAuth access token and, while JWT is can be
>>>>>>     used to represent an access token, it's not the only
>>>>>>     application of JWT. The 'standard' claims in JWT are those
>>>>>>     that are believed (right or wrong) to be widely applicable
>>>>>>     across different applications of JWT. One could argue about
>>>>>>     it but scope is probably not one of those.
>>>>>>
>>>>>>     It would probably make sense to try and build a profile of
>>>>>>     JWT specifically for OAuth access tokens (though I suspect
>>>>>>     there are some turtles and dragons in there), which might be
>>>>>>     the appropriate place to define/register a scope claim.
>>>>>>
>>>>>>
>>>>>>     On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt
>>>>>>     > wrote:
>>>>>>
>>>>>>         Are you advocating TWO systems? That seems like a bad choice.
>>>>>>
>>>>>>         I would rather fix scope than go to a two system approach.
>>>>>>
>>>>>>         Phil
>>>>>>
>>>>>>         Sent from my phone.
>>>>>>
>>>>>>         On 2013-02-28, at 8:17, John Bradley >>>>>         > wrote:
>>>>>>
>>>>>>         > While scope is one method that a AS could communicate
>>>>>>         authorization to a RS, it is not the only or perhaps even
>>>>>>         the most likely one.
>>>>>>         > Using scope requires a relatively tight binding between
>>>>>>         the RS and AS,  UMA uses a different mechanism that
>>>>>>         describes finer grained operations.
>>>>>>         > The AS may include roles, user, or other more abstract
>>>>>>         claims that the the client may (god help them) pass on to
>>>>>>         EXCML for processing.
>>>>>>         >
>>>>>>         > While having a scopes claim is possible, like any other
>>>>>>         claim it is not part of the JWT core security processing
>>>>>>         claims, and needs to be defined by extension.
>>>>>>         >
>>>>>>         > John B.
>>>>>>         > On 2013-02-28, at 2:29 AM, Hannes Tschofenig
>>>>>>         >>>>>         > wrote:
>>>>>>         >
>>>>>>         >> Hi Mike,
>>>>>>         >>
>>>>>>         >> when I worked on the MAC specification I noticed that
>>>>>>         the JWT does not have a claim for the scope. I believe
>>>>>>         that this would be needed to allow the resource server to
>>>>>>         verify whether the scope the authorization server
>>>>>>         authorized is indeed what the client is asking for.
>>>>>>         >>
>>>>>>         >> 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

--------------010101070200010105050902
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

    SAML 2.0 Profile for OAuth 2.0 Client Authentication and
    Authorization Grants 

    JWT Profile for OAuth 2.0 Client Authentication and Authorization
    Grants 

    Assertion Framework for OAuth 2.0 <as above> 

    a bit wordy, but does get the point across IMO

    - prateek

        I'm not sure anyone really "picked" the titles for the
          bearer token profiles. They just kind of evolved. And evolved
          in funny ways especially when client authn to the AS was
          added. 

        You won't hear me argue that the titles are "good" and this
          is not the first time there's been confusion about what they
          actually do. They define new grant types and new client
          authentication methods. They *do not* define an access token
          format or anything else about access tokens. JWT and SAML
          could be used for that but that's not what these drafts do. 

        Suggestions for better title(s) would be more than welcome.

          Here's what they are now:

            SAML 2.0 Bearer Assertion Profiles for OAuth 2.0

            draft-ietf-oauth-saml2-bearer

            JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

            draft-ietf-oauth-jwt-bearer

            Assertion Framework for OAuth 2.0

            draft-ietf-oauth-assertions

              On Thu, Feb 28, 2013 at 11:36 AM,
                John Bradley <ve7jtb@ve7jtb.com>
                wrote:

                  Yes the title likely
                    adds to the confusion given that the bearer tokens
                    are not access tokens.

                    Things as separate from OAuth as the Firefox
                      browerID spec use JWS signed JWTs.  

                    The bearer token profiles for OAuth 2 are for
                      OAuth2.

                    The JSON Web Token (JWT) spec
                      did not start in OAuth and is not OAuth specific.

                    A JWT is:

                      JSON Web Token (JWT)  A string representing a set of claims as a JSON
      object that is encoded in a JWS or JWE, enabling the claims to be
      digitally signed or MACed and/or encrypted.

                      So OAuth or other profiles may define claims
                        to go in a JWT, but the JWT needs to itself only
                        define the claims necessary for security
                        processing.  

                      John B.
                      PS that was a soft ball If you hadn't
                        responded I would have been disappointed.  I
                        din't pick the title for the bearer token
                        profiles.

                            On 2013-02-28, at 10:12 AM, Phil Hunt
                              <phil.hunt@oracle.com>
                              wrote:

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

                                  Note the title says "for OAuth2"

                                Sorry. Couldn't resist. 

                                Phil

                                  Sent from my phone.

                                  On 2013-02-28, at 9:40, John Bradley
                                  <ve7jtb@ve7jtb.com>
                                  wrote:

                                JWT is an
                                  assertion( I am probably going to
                                  regret using that word).

                                  It is used in openID connect for
                                    id_tokens, it is used in OAuth for
                                    Assertion grant types and
                                    authentication of the client to the
                                    token endpoint.
                                  http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04

                                    JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

                                    Dosen't define JWT's use for
                                      access tokens for the RS.   

                                    Bottom line JWT is for more
                                      than access tokens.

                                    John B.

                                      On 2013-02-28, at 9:28 AM,
                                        Phil Hunt <phil.hunt@oracle.com>
                                        wrote:

                                          Are you saying jwt is not
                                            an access token type?

                                            Phil

                                            Sent from my phone.

                                            On 2013-02-28, at 8:58, John
                                            Bradley <ve7jtb@ve7jtb.com>
                                            wrote:

                                          Yes,
                                            defining scope in JWT is the
                                            wrong place.   JWT needs to
                                            stick to the security claims
                                            needed to process JWT.

                                            I also don't know how
                                              far you get requiring a
                                              specific authorization
                                              format for JWT, some AS
                                              will wan to use a opaque
                                              reference, some might want
                                              to use a user claim or
                                              role claim, others may use
                                              scopes,  combining scopes
                                              and claims is also
                                              possible.

                                            Right now it is up to a
                                              AS RS pair to agree on how
                                              to communicate
                                              authorization.   I don't
                                              want MAC to be more
                                              restrictive than bearer
                                              when it comes to
                                              authorization between AS
                                              and RS.

                                              Hannes wanted to know
                                                why JWT didn't define
                                                scope.  The simple
                                                answer is that it is out
                                                of scope for JWT itself.
                                                  It might be defined in
                                                a OAuth access token
                                                profile for JWT but it
                                                should not be specific
                                                to MAC.

                                              John B.

                                                  On 2013-02-28, at
                                                    8:44 AM, Brian
                                                    Campbell <bcampbell@pingidentity.com>
                                                    wrote:

                                                      I think
                                                        John's point was
                                                        more that scope
                                                        is something
                                                        rather specific
                                                        to an OAuth
                                                        access token
                                                        and, while JWT
                                                        is can be used
                                                        to represent an
                                                        access token,
                                                        it's not the
                                                        only application
                                                        of JWT. The
                                                        'standard'
                                                        claims in JWT
                                                        are those that
                                                        are believed
                                                        (right or wrong)
                                                        to be widely
                                                        applicable
                                                        across different
                                                        applications of
                                                        JWT. One could
                                                        argue about it
                                                        but scope is
                                                        probably not one
                                                        of those.

                                                      It would probably
                                                      make sense to try
                                                      and build a
                                                      profile of JWT
                                                      specifically for
                                                      OAuth access
                                                      tokens (though I
                                                      suspect there are
                                                      some turtles and
                                                      dragons in there),
                                                      which might be the
                                                      appropriate place
                                                      to define/register
                                                      a scope claim.

                                                      On
                                                        Thu, Feb 28,
                                                        2013 at 9:24 AM,
                                                        Phil Hunt <phil.hunt@oracle.com>
                                                        wrote:

                                                        Are
                                                          you advocating
                                                          TWO systems?
                                                          That seems
                                                          like a bad
                                                          choice.

                                                          I would rather
                                                          fix scope than
                                                          go to a two
                                                          system
                                                          approach.

                                                          Phil

                                                          Sent from my
                                                          phone.

                                                          On 2013-02-28,
                                                          at 8:17, John
                                                          Bradley <ve7jtb@ve7jtb.com>
                                                          wrote:

                                                          > While
                                                          scope is one
                                                          method that a
                                                          AS could
                                                          communicate
                                                          authorization
                                                          to a RS, it is
                                                          not the only
                                                          or perhaps
                                                          even the most
                                                          likely one.

                                                          > Using
                                                          scope requires
                                                          a relatively
                                                          tight binding
                                                          between the RS
                                                          and AS,  UMA
                                                          uses a
                                                          different
                                                          mechanism that
                                                          describes
                                                          finer grained
                                                          operations.

                                                          > The AS
                                                          may include
                                                          roles, user,
                                                          or other more
                                                          abstract
                                                          claims that
                                                          the the client
                                                          may (god help
                                                          them) pass on
                                                          to EXCML for
                                                          processing.

                                                          >

                                                          > While
                                                          having a
                                                          scopes claim
                                                          is possible,
                                                          like any other
                                                          claim it is
                                                          not part of
                                                          the JWT core
                                                          security
                                                          processing
                                                          claims, and
                                                          needs to be
                                                          defined by
                                                          extension.

                                                          >

                                                          > John B.

                                                          > On
                                                          2013-02-28, at
                                                          2:29 AM,
                                                          Hannes
                                                          Tschofenig
                                                          <hannes.tschofenig@gmx.net>
                                                          wrote:

                                                          >

                                                          >> Hi
                                                          Mike,

                                                          >>

                                                          >> when
                                                          I worked on
                                                          the MAC
                                                          specification
                                                          I noticed that
                                                          the JWT does
                                                          not have a
                                                          claim for the
                                                          scope. I
                                                          believe that
                                                          this would be
                                                          needed to
                                                          allow the
                                                          resource
                                                          server to
                                                          verify whether
                                                          the scope the
                                                          authorization
                                                          server
                                                          authorized is
                                                          indeed what
                                                          the client is
                                                          asking for.

                                                          >>

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

--------------010101070200010105050902--

From phil.hunt@oracle.com  Thu Feb 28 12:51:50 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644E821F8967 for ; Thu, 28 Feb 2013 12:51:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.165
X-Spam-Level: 
X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=0.434,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTO49aT5JawS for ; Thu, 28 Feb 2013 12:51:49 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 63DA821F87D2 for ; Thu, 28 Feb 2013 12:51:49 -0800 (PST)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1SKpjYa018171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Feb 2013 20:51:46 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1SKpjLV004085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2013 20:51:45 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1SKpi96013981; Thu, 28 Feb 2013 14:51:44 -0600
Received: from [192.168.1.14] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 28 Feb 2013 12:51:44 -0800
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=iso-8859-1
From: Phil Hunt 
In-Reply-To: <512F9A5C.1070900@gmx.net>
Date: Thu, 28 Feb 2013 12:51:42 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <65953ADA-B947-4C16-A746-F184C0DAC3C2@oracle.com>
References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net>    <1BDBAFF3-6B2D-45EE-8A7E-B0B2572C8A01@oracle.com> <512F9A5C.1070900@gmx.net>
To: Hannes Tschofenig 
X-Mailer: Apple Mail (2.1283)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] JWT - scope claim missing
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 20:51:50 -0000

I believe that depending on the resource server that scope is important =
for both the security layers and application function layers.  For =
example, an application may wish to use scope as a set of entitlements.  =
Does client have entitlement "readProfile".

It makes no sense to me to have a scope in the authorization request and =
then not make it available to the resource endpoint except via back =
channels.  If that was the case why would I use anything other than an =
artifact?

That said, I think scope is way underdefined. But that's another issue.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On 2013-02-28, at 9:56 AM, Hannes Tschofenig wrote:

> I guess we first have to agree whether there is a security benefit of =
communicating the scope from the AS to the RS (in a way that it cannot =
be modified by the client or any other party).
>=20
> The scope indicates permissions (for example, whether the resource =
owner allowed read access to a certain resource or write access).
>=20
> Do you agree that there is a security benefit (or to put it the other =
way around: do you see the security vulnerability if this information is =
not communicated to the RS and checked against what the resource owner =
accepted?
>=20
> Then, a secondary question is what the right mechanism is.
>=20
> Ciao
> Hannes
>=20
>=20
> On 02/28/2013 07:29 PM, Phil Hunt wrote:
>> What people are doing now is often issuing saml like assertions. =
Thats not necessarily indicating intent. It just indicates transition.
>>=20
>> Phil
>>=20
>> Sent from my phone.
>>=20
>> On 2013-02-28, at 9:07, John Bradley  wrote:
>>=20
>>> I am not advocating anything, only sting what people are doing now.
>>>=20
>>> How authorization is communicated between the AS and RS via a token =
that is opaque to the client is out of scope fro OAuth core, it might be =
magic pixy dust.
>>>=20
>>> This has lead to a number of ways people are doing it.
>>>=20
>>> JWT along with  JOSE provide a container to get some claims from the =
AS to the RS though the JWT is not specific to this and is used in the =
assertions profile and other specs for many things other than access =
tokens.
>>>=20
>>> Yes a profile of JWT for an access token as an access token is =
needed, Yes further profiling is required for a JWT access token using =
MAC.
>>>=20
>>> The format of the authorization claims is not tightly bound to MAC =
and might be used with other bearer JWT tokens.
>>>=20
>>> I don't know that there will be only one way to communicate those =
claims because different sorts of implementations need different =
information for the RS to act on.
>>> Recommendations are fine but defining a field called scope and =
passing on exactly the scopes the client was granted is not going to =
work for everyone for lots of good reasons.
>>>=20
>>> John B.
>>> On 2013-02-28, at 8:24 AM, Phil Hunt  wrote:
>>>=20
>>>> Are you advocating TWO systems? That seems like a bad choice.
>>>>=20
>>>> I would rather fix scope than go to a two system approach.
>>>>=20
>>>> Phil
>>>>=20
>>>> Sent from my phone.
>>>>=20
>>>> On 2013-02-28, at 8:17, John Bradley  wrote:
>>>>=20
>>>>> While scope is one method that a AS could communicate =
authorization to a RS, it is not the only or perhaps even the most =
likely one.
>>>>> Using scope requires a relatively tight binding between the RS and =
AS,  UMA uses a different mechanism that describes finer grained =
operations.
>>>>> The AS may include roles, user, or other more abstract claims that =
the the client may (god help them) pass on to EXCML for processing.
>>>>>=20
>>>>> While having a scopes claim is possible, like any other claim it =
is not part of the JWT core security processing claims, and needs to be =
defined by extension.
>>>>>=20
>>>>> John B.
>>>>> On 2013-02-28, at 2:29 AM, Hannes Tschofenig =
 wrote:
>>>>>=20
>>>>>> Hi Mike,
>>>>>>=20
>>>>>> when I worked on the MAC specification I noticed that the JWT =
does not have a claim for the scope. I believe that this would be needed =
to allow the resource server to verify whether the scope the =
authorization server authorized is indeed what the client is asking for.
>>>>>>=20
>>>>>> Ciao
>>>>>> Hannes
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>=20

From bcampbell@pingidentity.com  Thu Feb 28 13:00:22 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E183A21F863C for ; Thu, 28 Feb 2013 13:00:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.911
X-Spam-Level: 
X-Spam-Status: No, score=-5.911 tagged_above=-999 required=5 tests=[AWL=0.065,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnpgoHQr3UdA for ; Thu, 28 Feb 2013 13:00:21 -0800 (PST)
Received: from na3sys009aog129.obsmtp.com (na3sys009aog129.obsmtp.com [74.125.149.142]) by ietfa.amsl.com (Postfix) with ESMTP id 14F5B21F8540 for ; Thu, 28 Feb 2013 13:00:21 -0800 (PST)
Received: from mail-oa0-f70.google.com ([209.85.219.70]) (using TLSv1) by na3sys009aob129.postini.com ([74.125.148.12]) with SMTP ID DSNKUS/FYwZJU1lsFLL31p5eZECH88XClNVz@postini.com; Thu, 28 Feb 2013 13:00:21 PST
Received: by mail-oa0-f70.google.com with SMTP id h2so14849232oag.5 for ; Thu, 28 Feb 2013 13:00:19 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=x5t95WElj43QHzDGkdt3hXJEiz3S0LqnKnOjp2AgMwY=; b=A7ULgv4X5WiiETAmsXzAZXhfHWMmYVi3ABZbMTSUHPINJ5UETp6NAk5CQ46FElW5p/ RkAg9gZH9BpYmEkOBCKLEiD+mlzLQIM2rMQodf6IGA4FfSlrLnraT2cNu72nVtET7vX2 lnB5D1T5H7Y4AZqSPSTYGAxvKlpjeMA9twu1H42OxgedFaieU6HnZdCdzu8zCxg0igx0 KJ3y/ZedVfU7PY1wpq0YC5GKbKzJvz3mZKoSG38Z8zAorgweg+Mj7a9IUZnFEUlnJHAb SjNuok9sNaWIGDb6/HkaiGfimTSfmHNHRi5WrhWxL+6GBtkyKG6vkv0XfMfHEWnOd43U TG8g==
X-Received: by 10.42.30.132 with SMTP id v4mr4256360icc.34.1362085218944; Thu, 28 Feb 2013 13:00:18 -0800 (PST)
X-Received: by 10.42.30.132 with SMTP id v4mr4256357icc.34.1362085218816; Thu, 28 Feb 2013 13:00:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.32.106 with HTTP; Thu, 28 Feb 2013 12:59:48 -0800 (PST)
In-Reply-To: <512FC18D.1020803@oracle.com>
References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net>     <48FD87D1-4DF4-4289-99B7-40A515F31890@oracle.com> <3E472720-31A4-40A0-AAA4-402CF850831A@ve7jtb.com> <7127843B-D7B0-4AB6-87F1-1604D1EFFA79@oracle.com> <50DA292F-32F0-4266-8401-006AD837B775@ve7jtb.com>  <512FC18D.1020803@oracle.com>
From: Brian Campbell 
Date: Thu, 28 Feb 2013 13:59:48 -0700
Message-ID: 
To: prateek mishra 
Content-Type: multipart/alternative; boundary=20cf301d420e9f2fa804d6cf2d44
X-Gm-Message-State: ALoCoQmfS1M7gan+gAl+nXDwf7jzPOvyise6eSXBc3nZGLNCNHMLh7FgfIDPTGHSbwWBXoO3s7d63GYooUCFQMrqqiHLW6R4HteiXJnmUxFy1NJmL8qgo7lue/93uQa9KXvx7ANLxz4y
Cc: oauth 
Subject: Re: [OAUTH-WG] JWT - scope claim missing
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 21:00:23 -0000

--20cf301d420e9f2fa804d6cf2d44
Content-Type: text/plain; charset=ISO-8859-1

Thanks Prateek. I like it and I think wordy might be the way to go here.

On Thu, Feb 28, 2013 at 1:43 PM, prateek mishra
wrote:

>  SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization
> Grants
> JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants
> Assertion Framework for OAuth 2.0 
>
> a bit wordy, but does get the point across IMO
>
> - prateek
>
>  I'm not sure anyone really "picked" the titles for the bearer token
> profiles. They just kind of evolved. And evolved in funny ways especially
> when client authn to the AS was added.
>
>  You won't hear me argue that the titles are "good" and this is not the
> first time there's been confusion about what they actually do. They define
> new grant types and new client authentication methods. They *do not* define
> an access token format or anything else about access tokens. JWT and SAML
> could be used for that but that's not what these drafts do.
>
>  Suggestions for better title(s) would be more than welcome.
>
>  Here's what they are now:
>
> SAML 2.0 Bearer Assertion Profiles for OAuth 2.0
> draft-ietf-oauth-saml2-bearer
>
> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
> draft-ietf-oauth-jwt-bearer
>
> Assertion Framework for OAuth 2.0
> draft-ietf-oauth-assertions
>
> On Thu, Feb 28, 2013 at 11:36 AM, John Bradley  wrote:
>
>> Yes the title likely adds to the confusion given that the bearer tokens
>> are not access tokens.
>>
>>  Things as separate from OAuth as the Firefox browerID spec use JWS
>> signed JWTs.
>>
>>  The bearer token profiles for OAuth 2 are for OAuth2.
>>
>>  The JSON Web Token (JWT) spec
>> did not start in OAuth and is not OAuth specific.
>>
>>  A JWT is:
>>
>> JSON Web Token (JWT)  A string representing a set of claims as a JSON
>>       object that is encoded in a JWS or JWE, enabling the claims to be
>>       digitally signed or MACed and/or encrypted.
>>
>>
>>  So OAuth or other profiles may define claims to go in a JWT, but the
>> JWT needs to itself only define the claims necessary for security
>> processing.
>>
>>  John B.
>> PS that was a soft ball If you hadn't responded I would have been
>> disappointed.  I din't pick the title for the bearer token profiles.
>>
>>
>>  On 2013-02-28, at 10:12 AM, Phil Hunt  wrote:
>>
>>
>>
>>
>>
>> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
>>
>>
>> Note the title says "for OAuth2"
>>
>>  Sorry. Couldn't resist.
>>
>>  Phil
>>
>>  Sent from my phone.
>>
>> On 2013-02-28, at 9:40, John Bradley  wrote:
>>
>>  JWT is an assertion( I am probably going to regret using that word).
>>
>>  It is used in openID connect for id_tokens, it is used in OAuth for
>> Assertion grant types and authentication of the client to the token
>> endpoint.
>> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04
>>
>>
>> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
>>
>>
>>  Dosen't define JWT's use for access tokens for the RS.
>>
>>  Bottom line JWT is for more than access tokens.
>>
>>  John B.
>>
>>  On 2013-02-28, at 9:28 AM, Phil Hunt  wrote:
>>
>>  Are you saying jwt is not an access token type?
>>
>> Phil
>>
>>  Sent from my phone.
>>
>> On 2013-02-28, at 8:58, John Bradley  wrote:
>>
>>  Yes, defining scope in JWT is the wrong place.   JWT needs to stick to
>> the security claims needed to process JWT.
>>
>>  I also don't know how far you get requiring a specific authorization
>> format for JWT, some AS will wan to use a opaque reference, some might want
>> to use a user claim or role claim, others may use scopes,  combining scopes
>> and claims is also possible.
>>
>>  Right now it is up to a AS RS pair to agree on how to communicate
>> authorization.   I don't want MAC to be more restrictive than bearer when
>> it comes to authorization between AS and RS.
>>
>>  Hannes wanted to know why JWT didn't define scope.  The simple answer
>> is that it is out of scope for JWT itself.   It might be defined in a OAuth
>> access token profile for JWT but it should not be specific to MAC.
>>
>>  John B.
>>  On 2013-02-28, at 8:44 AM, Brian Campbell 
>> wrote:
>>
>>  I think John's point was more that scope is something rather specific
>> to an OAuth access token and, while JWT is can be used to represent an
>> access token, it's not the only application of JWT. The 'standard' claims
>> in JWT are those that are believed (right or wrong) to be widely applicable
>> across different applications of JWT. One could argue about it but scope is
>> probably not one of those.
>>
>>  It would probably make sense to try and build a profile of JWT
>> specifically for OAuth access tokens (though I suspect there are some
>> turtles and dragons in there), which might be the appropriate place to
>> define/register a scope claim.
>>
>>
>> On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt  wrote:
>>
>>> Are you advocating TWO systems? That seems like a bad choice.
>>>
>>> I would rather fix scope than go to a two system approach.
>>>
>>> Phil
>>>
>>> Sent from my phone.
>>>
>>> On 2013-02-28, at 8:17, John Bradley  wrote:
>>>
>>> > While scope is one method that a AS could communicate authorization to
>>> a RS, it is not the only or perhaps even the most likely one.
>>> > Using scope requires a relatively tight binding between the RS and AS,
>>>  UMA uses a different mechanism that describes finer grained operations.
>>> > The AS may include roles, user, or other more abstract claims that the
>>> the client may (god help them) pass on to EXCML for processing.
>>> >
>>> > While having a scopes claim is possible, like any other claim it is
>>> not part of the JWT core security processing claims, and needs to be
>>> defined by extension.
>>> >
>>> > John B.
>>> > On 2013-02-28, at 2:29 AM, Hannes Tschofenig <
>>> hannes.tschofenig@gmx.net> wrote:
>>> >
>>> >> Hi Mike,
>>> >>
>>> >> when I worked on the MAC specification I noticed that the JWT does
>>> not have a claim for the scope. I believe that this would be needed to
>>> allow the resource server to verify whether the scope the authorization
>>> server authorized is indeed what the client is asking for.
>>> >>
>>> >> 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
>

--20cf301d420e9f2fa804d6cf2d44
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thanks Prateek. I like it and I think wordy might be the w=
ay to go here. 

On Thu, Feb 28, 2013 at 1:43 PM, prateek mishra <prate=
ek.mishra@oracle.com> wrote:

 =20
   =20
 =20

    SAML 2.0 Profile for OAuth 2.0 Client Authentication and
    Authorization Grants 

    JWT Profile for OAuth 2.0 Client Authentication and Authorization
    Grants 

    Assertion Framework for OAuth 2.0 <as above> 

    a bit wordy, but does get the point across IMO

    - prateek

        I'm not sure anyone really "picked" the titles f=
or the
          bearer token profiles. They just kind of evolved. And evolved
          in funny ways especially when client authn to the AS was
          added. 

        You won't hear me argue that the titles are "good&quo=
t; and this
          is not the first time there's been confusion about what they
          actually do. They define new grant types and new client
          authentication methods. They *do not* define an access token
          format or anything else about access tokens. JWT and SAML
          could be used for that but that's not what these drafts do. <=
br>

        Suggestions for better title(s) would be more than welcome.

          Here's what they are now:

            SAML 2.0 Bearer Assertion Profiles for OAuth 2.0

            draft-ietf-oauth-saml2-bearer

            JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

            draft-ietf-oauth-jwt-bearer

            Assertion Framework for OAuth 2.0

            draft-ietf-oauth-assertions

              On Thu, Feb 28, 2013 at 11:36 AM,
                John Bradley <ve7jtb@ve7jtb.com>
                wrote:

                  Yes the title likely
                    adds to the confusion given that the bearer tokens
                    are not access tokens.

                    Things as separate from OAuth as the Firefox
                      browerID spec use JWS signed JWTs. =A0

                    The bearer token profiles for OAuth 2 are for
                      OAuth2.

                    The=A0JSON Web Token (JWT)=A0=
spec
                      did not start in OAuth and is not OAuth specific.

                    A JWT is:

                      JSON Web Token (JWT)  A string representing a set of claims as a J=
SON
      object that is encoded in a JWS or JWE, enabling the claims to be
      digitally signed or MACed and/or encrypted.

                      So OAuth or other profiles may define claims
                        to go in a JWT, but the JWT needs to itself only
                        define the claims necessary for security
                        processing. =A0

                      John B.
                      PS that was a soft ball If you hadn't
                        responded I would have been disappointed. =A0I
                        din't pick the title for the bearer token
                        profiles.

                            On 2013-02-28, at 10:12 AM, Phil Hunt
                              <phil.hunt@oracle.com>
                              wrote:

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0=

                                  Note the title says "for OAuth=
2"

                                Sorry. Couldn't resist.=A0

                                Phil

                                  Sent from my phone.

                                  On 2013-02-28, at 9:40, John Bradley
                                  <ve7jtb@ve7jtb.com>
                                  wrote:

                                JWT is an
                                  assertion( I am probably going to
                                  regret using that word).

                                  It is used in openID connect for
                                    id_tokens, it is used in OAuth for
                                    Assertion grant types and
                                    authentication of the client to the
                                    token endpoint.
                                  http://tools.ietf.org/h=
tml/draft-ietf-oauth-jwt-bearer-04

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

                                    Dosen't define JWT's use f=
or
                                      access tokens for the RS. =A0=A0

                                    Bottom line JWT is for more
                                      than access tokens.

                                    John B.

                                      On 2013-02-28, at 9:28 AM,
                                        Phil Hunt <phil.hunt@oracle.com>
                                        wrote:

                                          Are you saying jwt is not
                                            an access token type?

                                            Phil

                                            Sent from my phone.

                                            On 2013-02-28, at 8:58, John
                                            Bradley <ve7jtb@ve7jtb.com>
                                            wrote:

                                          Yes,
                                            defining scope in JWT is the
                                            wrong place. =A0 JWT needs to
                                            stick to the security claims
                                            needed to process JWT.

                                            I also don't know how
                                              far you get requiring a
                                              specific authorization
                                              format for JWT, some AS
                                              will wan to use a opaque
                                              reference, some might want
                                              to use a user claim or
                                              role claim, others may use
                                              scopes, =A0combining scopes
                                              and claims is also
                                              possible.

                                            Right now it is up to a
                                              AS RS pair to agree on how
                                              to communicate
                                              authorization. =A0 I don'=
t
                                              want MAC to be more
                                              restrictive than bearer
                                              when it comes to
                                              authorization between AS
                                              and RS.

                                              Hannes wanted to know
                                                why JWT didn't define
                                                scope. =A0The simple
                                                answer is that it is out
                                                of scope for JWT itself.
                                                =A0 It might be defined in
                                                a OAuth access token
                                                profile for JWT but it
                                                should not be specific
                                                to MAC.

                                              John B.

                                                  On 2013-02-28, at
                                                    8:44 AM, Brian
                                                    Campbell <bcampbell@pingidentit=
y.com>
                                                    wrote:

                                                      I think
                                                        John's point wa=
s
                                                        more that scope
                                                        is something
                                                        rather specific
                                                        to an OAuth
                                                        access token
                                                        and, while JWT
                                                        is can be used
                                                        to represent an
                                                        access token,
                                                        it's not the
                                                        only application
                                                        of JWT. The
                                                        'standard'
                                                        claims in JWT
                                                        are those that
                                                        are believed
                                                        (right or wrong)
                                                        to be widely
                                                        applicable
                                                        across different
                                                        applications of
                                                        JWT. One could
                                                        argue about it
                                                        but scope is
                                                        probably not one
                                                        of those.

                                                      It would probably
                                                      make sense to try
                                                      and build a
                                                      profile of JWT
                                                      specifically for
                                                      OAuth access
                                                      tokens (though I
                                                      suspect there are
                                                      some turtles and
                                                      dragons in there),
                                                      which might be the
                                                      appropriate place
                                                      to define/register
                                                      a scope claim.

                                                      On
                                                        Thu, Feb 28,
                                                        2013 at 9:24 AM,
                                                        Phil Hunt <phil=
.hunt@oracle.com>
                                                        wrote:

                                                        Are
                                                          you advocating
                                                          TWO systems?
                                                          That seems
                                                          like a bad
                                                          choice.

                                                          I would rather
                                                          fix scope than
                                                          go to a two
                                                          system
                                                          approach.

                                                          Phil

                                                          Sent from my
                                                          phone.

                                                          On 2013-02-28,
                                                          at 8:17, John
                                                          Bradley <ve7jtb@ve7jtb.com>
                                                          wrote:

                                                          > While
                                                          scope is one
                                                          method that a
                                                          AS could
                                                          communicate
                                                          authorization
                                                          to a RS, it is
                                                          not the only
                                                          or perhaps
                                                          even the most
                                                          likely one.

                                                          > Using
                                                          scope requires
                                                          a relatively
                                                          tight binding
                                                          between the RS
                                                          and AS, =A0UMA
                                                          uses a
                                                          different
                                                          mechanism that
                                                          describes
                                                          finer grained
                                                          operations.

                                                          > The AS
                                                          may include
                                                          roles, user,
                                                          or other more
                                                          abstract
                                                          claims that
                                                          the the client
                                                          may (god help
                                                          them) pass on
                                                          to EXCML for
                                                          processing.

                                                          >

                                                          > While
                                                          having a
                                                          scopes claim
                                                          is possible,
                                                          like any other
                                                          claim it is
                                                          not part of
                                                          the JWT core
                                                          security
                                                          processing
                                                          claims, and
                                                          needs to be
                                                          defined by
                                                          extension.

                                                          >

                                                          > John B.

                                                          > On
                                                          2013-02-28, at
                                                          2:29 AM,
                                                          Hannes
                                                          Tschofenig
                                                          <hannes.tschofenig@gmx.net=
>
                                                          wrote:

                                                          >

                                                          >> Hi
                                                          Mike,

                                                          >>

                                                          >> when
                                                          I worked on
                                                          the MAC
                                                          specification
                                                          I noticed that
                                                          the JWT does
                                                          not have a
                                                          claim for the
                                                          scope. I
                                                          believe that
                                                          this would be
                                                          needed to
                                                          allow the
                                                          resource
                                                          server to
                                                          verify whether
                                                          the scope the
                                                          authorization
                                                          server
                                                          authorized is
                                                          indeed what
                                                          the client is
                                                          asking for.

                                                          >>

                                                          >> Ciao

                                                          >>
                                                          Hannes

                                                          >>

                                                          >>
                                                          _________________=
______________________________

                                                          >> OAuth
                                                          mailing list

                                                          >> OAuth@ietf.org

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

                                                          >

                                                          >
                                                          _________________=
______________________________

                                                          > OAuth
                                                          mailing list

                                                          > OAuth@ietf.org

                                                          > https://www.i=
etf.org/mailman/listinfo/oauth

_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

                                                          https://www.ietf.o=
rg/mailman/listinfo/oauth

      _______________________________________________
OAuth mailing list
OAuth@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/oauth

--20cf301d420e9f2fa804d6cf2d44--

From hannes.tschofenig@gmx.net  Thu Feb 28 13:36:52 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD5F21F863C for ; Thu, 28 Feb 2013 13:36:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.534
X-Spam-Level: 
X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZWoJM-gwJJo for ; Thu, 28 Feb 2013 13:36:52 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id AE8FA21F859A for ; Thu, 28 Feb 2013 13:36:51 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.28]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MFOSw-1U5j663Bfo-00ELmr for ; Thu, 28 Feb 2013 22:36:50 +0100
Received: (qmail invoked by alias); 28 Feb 2013 21:36:50 -0000
Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.115]) [88.115.219.140] by mail.gmx.net (mp028) with SMTP; 28 Feb 2013 22:36:50 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX184/GVU+Xs4uPURILEdZpTYqvAuSqbjgrqh/pzPQx iBCPMHl4HyKhk4
Message-ID: <512FCDF0.6010807@gmx.net>
Date: Thu, 28 Feb 2013 23:36:48 +0200
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: oleg@gryb.info
References: <1362079266.8952.YahooMailClassic@web141002.mail.bf1.yahoo.com>
In-Reply-To: <1362079266.8952.YahooMailClassic@web141002.mail.bf1.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Fw:  IPR Disclosure: - What to Do with JWT ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 21:36:52 -0000

Hi Oleg,

my personal experience with Certicom's IPR disclosures is that they 
focus on Elliptic Curve Cryptography. There were several IPR disclosures 
on documents in the JOSE WG and some of them contain ECC algorithms.

The JWT does not list an ECC algorithm but the referenced documents do.

Having said that the two cited IPRs seem to be:
http://www.google.com/patents/US6704870
http://www.google.com/patents/US7215773

Take a look at it and make your assessment whether there is anything we 
can change.

Ciao
Hannes

On 02/28/2013 09:21 PM, Oleg Gryb wrote:
> Dear OAuth WG and Chairs,
>
> Can somebody please comment the Certicom's disclosure below? If the
> purpose of this disclosure is to inform us that JWT can be potentially a
> subject of royalties and other possible legal actions, the value of
> adopting JWT in the scope of OAuth 2.0 IETF standard would definitely
> diminish and if this is the case shouldn't we consider replacing it with
> something similar, but different, which would not be a subject of the
> future possible litigation?
>
> I'm not a lawyer and might not understand the statement below correctly,
> so please let me know if/where I'm wrong. Please keep in mind also that
> the popularity of JWT is growing fast along with the implementations, so
> we need to do something quickly.
>
> Thanks,
> Oleg.
>
>
> --- On *Wed, 2/27/13, IETF Secretariat //* wrote:
>
>
>     From: IETF Secretariat 
>     Subject: [OAUTH-WG] IPR Disclosure: Certicom Corporation's Statement
>     about IPR related to draft-ietf-oauth-json-web-token-06 (2)
>     To: mbj@microsoft.com, ve7jtb@ve7jtb.com, n-sakimura@nri.co.jp
>     Cc: derek@ihtfp.com, oauth@ietf.org, ipr-announce@ietf.org
>     Date: Wednesday, February 27, 2013, 4:16 PM
>
>
>     Dear Michael Jones, John Bradley, Nat Sakimura:
>
>     An IPR disclosure that pertains to your Internet-Draft entitled
>     "JSON Web Token
>     (JWT)" (draft-ietf-oauth-json-web-token) was submitted to the IETF
>     Secretariat
>     on 2013-02-20 and has been posted on the "IETF Page of Intellectual
>     Property
>     Rights Disclosures" (https://datatracker.ietf.org/ipr/1968/). The
>     title of the
>     IPR disclosure is "Certicom Corporation's Statement about IPR
>     related to draft-
>     ietf-oauth-json-web-token-06 (2)."");
>
>     The IETF Secretariat
>
>     _______________________________________________
>     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
>

From prateek.mishra@oracle.com  Thu Feb 28 13:54:15 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F76821F8B83 for ; Thu, 28 Feb 2013 13:54:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.569
X-Spam-Level: 
X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeundtApvkpU for ; Thu, 28 Feb 2013 13:54:14 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED2D21F8B2F for ; Thu, 28 Feb 2013 13:54:14 -0800 (PST)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1SLrEJD019070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Feb 2013 21:53:15 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1SLrDWm019599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2013 21:53:14 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1SLrDLm009394; Thu, 28 Feb 2013 15:53:13 -0600
Received: from [10.152.55.88] (/10.152.55.88) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 28 Feb 2013 13:53:13 -0800
Message-ID: <512FD1C5.2070100@oracle.com>
Date: Thu, 28 Feb 2013 16:53:09 -0500
From: prateek mishra 
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Hannes Tschofenig 
References: <1362079266.8952.YahooMailClassic@web141002.mail.bf1.yahoo.com> <512FCDF0.6010807@gmx.net>
In-Reply-To: <512FCDF0.6010807@gmx.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: oleg@gryb.info, oauth@ietf.org
Subject: Re: [OAUTH-WG] Fw:  IPR Disclosure: - What to Do with JWT ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 21:54:15 -0000

Two points  -

1) I request that this mailing list NOT be used for any substantive 
discussion of patent claims and so on. This will create difficulties for 
many participants and
I dont believe is within the charter of this effort.

2) I would encourage interested parties to review the following 
document, which may be relevant to this discussion

http://www.w3.org/2011/xmlsec-pag/

- prateek

> Hi Oleg,
>
> my personal experience with Certicom's IPR disclosures is that they 
> focus on Elliptic Curve Cryptography. There were several IPR 
> disclosures on documents in the JOSE WG and some of them contain ECC 
> algorithms.
>
> The JWT does not list an ECC algorithm but the referenced documents do.
>
> Having said that the two cited IPRs seem to be:
> http://www.google.com/patents/US6704870
> http://www.google.com/patents/US7215773
>
> Take a look at it and make your assessment whether there is anything 
> we can change.
>
> Ciao
> Hannes
>
>
> On 02/28/2013 09:21 PM, Oleg Gryb wrote:
>> Dear OAuth WG and Chairs,
>>
>> Can somebody please comment the Certicom's disclosure below? If the
>> purpose of this disclosure is to inform us that JWT can be potentially a
>> subject of royalties and other possible legal actions, the value of
>> adopting JWT in the scope of OAuth 2.0 IETF standard would definitely
>> diminish and if this is the case shouldn't we consider replacing it with
>> something similar, but different, which would not be a subject of the
>> future possible litigation?
>>
>> I'm not a lawyer and might not understand the statement below correctly,
>> so please let me know if/where I'm wrong. Please keep in mind also that
>> the popularity of JWT is growing fast along with the implementations, so
>> we need to do something quickly.
>>
>> Thanks,
>> Oleg.
>>
>>
>> --- On *Wed, 2/27/13, IETF Secretariat //* wrote:
>>
>>
>>     From: IETF Secretariat 
>>     Subject: [OAUTH-WG] IPR Disclosure: Certicom Corporation's Statement
>>     about IPR related to draft-ietf-oauth-json-web-token-06 (2)
>>     To: mbj@microsoft.com, ve7jtb@ve7jtb.com, n-sakimura@nri.co.jp
>>     Cc: derek@ihtfp.com, oauth@ietf.org, ipr-announce@ietf.org
>>     Date: Wednesday, February 27, 2013, 4:16 PM
>>
>>
>>     Dear Michael Jones, John Bradley, Nat Sakimura:
>>
>>     An IPR disclosure that pertains to your Internet-Draft entitled
>>     "JSON Web Token
>>     (JWT)" (draft-ietf-oauth-json-web-token) was submitted to the IETF
>>     Secretariat
>>     on 2013-02-20 and has been posted on the "IETF Page of Intellectual
>>     Property
>>     Rights Disclosures" (https://datatracker.ietf.org/ipr/1968/). The
>>     title of the
>>     IPR disclosure is "Certicom Corporation's Statement about IPR
>>     related to draft-
>>     ietf-oauth-json-web-token-06 (2)."");
>>
>>     The IETF Secretariat
>>
>>     _______________________________________________
>>     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

From hannes.tschofenig@gmx.net  Thu Feb 28 13:57:04 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17CBB21F89B2 for ; Thu, 28 Feb 2013 13:57:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.535
X-Spam-Level: 
X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APmx3mmzuSLb for ; Thu, 28 Feb 2013 13:57:03 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 28EE121F89CC for ; Thu, 28 Feb 2013 13:57:03 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.24]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MB0kk-1U1K6E1SBI-009wGG for ; Thu, 28 Feb 2013 22:57:02 +0100
Received: (qmail invoked by alias); 28 Feb 2013 21:57:02 -0000
Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.115]) [88.115.219.140] by mail.gmx.net (mp024) with SMTP; 28 Feb 2013 22:57:02 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+BSx1C5eSBC1YtDvtwGyQ4H9n0lCRKQWOcdfGnKz OqBjZ5iI3gDxLK
Message-ID: <512FD2AC.2000607@gmx.net>
Date: Thu, 28 Feb 2013 23:57:00 +0200
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: prateek mishra 
References: <1362079266.8952.YahooMailClassic@web141002.mail.bf1.yahoo.com> <512FCDF0.6010807@gmx.net> <512FD1C5.2070100@oracle.com>
In-Reply-To: <512FD1C5.2070100@oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: oleg@gryb.info, oauth@ietf.org
Subject: Re: [OAUTH-WG] Fw:  IPR Disclosure: - What to Do with JWT ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 21:57:04 -0000

This is certainly a good point. Stating whether certain claims are valid 
or not valid is not a good use of our time and may lead to legal 
problems later on.

So, read through the patents and make your own assessment whether this 
IPRs are a concern for you and whether you want anything in the drafts 
to be changed.

On 02/28/2013 11:53 PM, prateek mishra wrote:
> Two points  -
>
> 1) I request that this mailing list NOT be used for any substantive
> discussion of patent claims and so on. This will create difficulties for
> many participants and
> I dont believe is within the charter of this effort.
>
> 2) I would encourage interested parties to review the following
> document, which may be relevant to this discussion
>
> http://www.w3.org/2011/xmlsec-pag/
>
> - prateek
>
>> Hi Oleg,
>>
>> my personal experience with Certicom's IPR disclosures is that they
>> focus on Elliptic Curve Cryptography. There were several IPR
>> disclosures on documents in the JOSE WG and some of them contain ECC
>> algorithms.
>>
>> The JWT does not list an ECC algorithm but the referenced documents do.
>>
>> Having said that the two cited IPRs seem to be:
>> http://www.google.com/patents/US6704870
>> http://www.google.com/patents/US7215773
>>
>> Take a look at it and make your assessment whether there is anything
>> we can change.
>>
>> Ciao
>> Hannes
>>
>>
>> On 02/28/2013 09:21 PM, Oleg Gryb wrote:
>>> Dear OAuth WG and Chairs,
>>>
>>> Can somebody please comment the Certicom's disclosure below? If the
>>> purpose of this disclosure is to inform us that JWT can be potentially a
>>> subject of royalties and other possible legal actions, the value of
>>> adopting JWT in the scope of OAuth 2.0 IETF standard would definitely
>>> diminish and if this is the case shouldn't we consider replacing it with
>>> something similar, but different, which would not be a subject of the
>>> future possible litigation?
>>>
>>> I'm not a lawyer and might not understand the statement below correctly,
>>> so please let me know if/where I'm wrong. Please keep in mind also that
>>> the popularity of JWT is growing fast along with the implementations, so
>>> we need to do something quickly.
>>>
>>> Thanks,
>>> Oleg.
>>>
>>>
>>> --- On *Wed, 2/27/13, IETF Secretariat //* wrote:
>>>
>>>
>>>     From: IETF Secretariat 
>>>     Subject: [OAUTH-WG] IPR Disclosure: Certicom Corporation's Statement
>>>     about IPR related to draft-ietf-oauth-json-web-token-06 (2)
>>>     To: mbj@microsoft.com, ve7jtb@ve7jtb.com, n-sakimura@nri.co.jp
>>>     Cc: derek@ihtfp.com, oauth@ietf.org, ipr-announce@ietf.org
>>>     Date: Wednesday, February 27, 2013, 4:16 PM
>>>
>>>
>>>     Dear Michael Jones, John Bradley, Nat Sakimura:
>>>
>>>     An IPR disclosure that pertains to your Internet-Draft entitled
>>>     "JSON Web Token
>>>     (JWT)" (draft-ietf-oauth-json-web-token) was submitted to the IETF
>>>     Secretariat
>>>     on 2013-02-20 and has been posted on the "IETF Page of Intellectual
>>>     Property
>>>     Rights Disclosures" (https://datatracker.ietf.org/ipr/1968/). The
>>>     title of the
>>>     IPR disclosure is "Certicom Corporation's Statement about IPR
>>>     related to draft-
>>>     ietf-oauth-json-web-token-06 (2)."");
>>>
>>>     The IETF Secretariat
>>>
>>>     _______________________________________________
>>>     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
>

From Adam.Lewis@motorolasolutions.com  Thu Feb 28 14:13:59 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F19F21F8B06 for ; Thu, 28 Feb 2013 14:13:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.466
X-Spam-Level: 
X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xy5cbUgMqzjZ for ; Thu, 28 Feb 2013 14:13:53 -0800 (PST)
Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id 78E8F21F85B4 for ; Thu, 28 Feb 2013 14:13:53 -0800 (PST)
Received: from mail14-co1-R.bigfish.com (10.243.78.237) by CO1EHSOBE003.bigfish.com (10.243.66.66) with Microsoft SMTP Server id 14.1.225.23; Thu, 28 Feb 2013 22:13:52 +0000
Received: from mail14-co1 (localhost [127.0.0.1])	by mail14-co1-R.bigfish.com (Postfix) with ESMTP id A60829C0218	for ; Thu, 28 Feb 2013 22:13:52 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:129.188.136.18; KIP:(null); UIP:(null); IPV:NLI; H:il06msg02.am.mot-solutions.com; RD:none; EFVD:NLI
X-SpamScore: -30
X-BigFish: VPS-30(zz98dI9371Ic89bh936eIc85dh1432I179dNzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275ch1033IL177df4h17326ah8275dh18c673h8275bhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1155h)
Received-SPF: pass (mail14-co1: domain of motorolasolutions.com designates 129.188.136.18 as permitted sender) client-ip=129.188.136.18; envelope-from=Adam.Lewis@motorolasolutions.com; helo=il06msg02.am.mot-solutions.com ; olutions.com ; 
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.237.133; KIP:(null); UIP:(null); (null); H:BY2PRD0411HT002.namprd04.prod.outlook.com; R:internal; EFV:INT
Received: from mail14-co1 (localhost.localdomain [127.0.0.1]) by mail14-co1 (MessageSwitch) id 1362089630126889_2552; Thu, 28 Feb 2013 22:13:50 +0000 (UTC)
Received: from CO1EHSMHS028.bigfish.com (unknown [10.243.78.242])	by mail14-co1.bigfish.com (Postfix) with ESMTP id 11F644600A2	for ; Thu, 28 Feb 2013 22:13:50 +0000 (UTC)
Received: from il06msg02.am.mot-solutions.com (129.188.136.18) by CO1EHSMHS028.bigfish.com (10.243.66.38) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 28 Feb 2013 22:13:49 +0000
Received: from il06msg02.am.mot-solutions.com (il06vts01.mot.com [129.188.137.141])	by il06msg02.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r1SMDmWM000294	for ; Thu, 28 Feb 2013 17:13:48 -0500 (EST)
Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14])	by il06msg02.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id r1SMDlxN000287 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL)	for ; Thu, 28 Feb 2013 17:13:47 -0500 (EST)
Received: from mail47-tx2-R.bigfish.com (10.9.14.240) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.23; Thu, 28 Feb 2013 22:13:47 +0000
Received: from mail47-tx2 (localhost [127.0.0.1])	by mail47-tx2-R.bigfish.com (Postfix) with ESMTP id F1775420179	for ; Thu, 28 Feb 2013 22:13:46 +0000 (UTC)
Received: from mail47-tx2 (localhost.localdomain [127.0.0.1]) by mail47-tx2 (MessageSwitch) id 1362089616175957_2521; Thu, 28 Feb 2013 22:13:36 +0000 (UTC)
Received: from TX2EHSMHS044.bigfish.com (unknown [10.9.14.254])	by mail47-tx2.bigfish.com (Postfix) with ESMTP id 253094C0095; Thu, 28 Feb 2013 22:13:36 +0000 (UTC)
Received: from BY2PRD0411HT002.namprd04.prod.outlook.com (157.56.237.133) by TX2EHSMHS044.bigfish.com (10.9.99.144) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 28 Feb 2013 22:13:36 +0000
Received: from BY2PRD0411MB441.namprd04.prod.outlook.com ([169.254.5.225]) by BY2PRD0411HT002.namprd04.prod.outlook.com ([10.255.128.37]) with mapi id 14.16.0275.006; Thu, 28 Feb 2013 22:13:32 +0000
From: Lewis Adam-CAL022 
To: Brian Campbell 
Thread-Topic: [OAUTH-WG] JWT - scope claim missing
Thread-Index: AQHOFZ6Qe5ExGqoPnkOeJlU0r70rz5iPcwoAgAAB5gCAAAWJgIAABAMAgAAIM4CAAAN2AIAACPeAgAAGkICAAAeWAIAAAR2AgAAILoCAACqKMA==
Date: Thu, 28 Feb 2013 22:13:31 +0000
Message-ID: <59E470B10C4630419ED717AC79FCF9A948D58DC0@BY2PRD0411MB441.namprd04.prod.outlook.com>
References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net>     <48FD87D1-4DF4-4289-99B7-40A515F31890@oracle.com> <3E472720-31A4-40A0-AAA4-402CF850831A@ve7jtb.com> <7127843B-D7B0-4AB6-87F1-1604D1EFFA79@oracle.com> <50DA292F-32F0-4266-8401-006AD837B775@ve7jtb.com>  <59E470B10C4630419ED717AC79FCF9A948D58BEE@BY2PRD0411MB441.namprd04.prod.outlook.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [184.78.105.93]
Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A948D58DC0BY2PRD0411MB441_"
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%1294$Dn%PINGIDENTITY.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn%
X-FOPE-CONNECTOR: Id%1294$Dn%VE7JTB.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn%
X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn%
X-CFilter-Loop: Reflected
X-OriginatorOrg: motorolasolutions.com
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] JWT - scope claim missing
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 22:13:59 -0000

--_000_59E470B10C4630419ED717AC79FCF9A948D58DC0BY2PRD0411MB441_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hmmm, I'm not so sure.  It depends where we all think OAuth is on its traje=
ctory.  On one hand, OAuth has already seen an insanely massive amount of d=
eployment.  On the other hand, RESTful APIs see no sign of slowing down.   =
Now I'm not going to go so far as Craig B. and say that everything and ever=
yone will be API enabled in the future, but it sure is going to be a lot.  =
That being said, one could argue that even with all the OAuth implementatio=
n we've seen, that this is just the infancy of it.  Obviously a WG profile =
of a JWT-structured AT could not deprecate other forms (unstructured, SAML,=
 etc.) but going forward new developers may choose to embrace this, and in =
fact this could even be the guidance.   I agree with previous comments that=
 Justin's introspection draft might be a good place to explore this.

adam

From: Brian Campbell [mailto:bcampbell@pingidentity.com]
Sent: Thursday, February 28, 2013 1:36 PM
To: Lewis Adam-CAL022
Cc: John Bradley; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] JWT - scope claim missing

I do agree that a WG profile of a JWT-structured access token could lend it=
self to interoperability and ultimately be a useful thing. But you are righ=
t that there already are many implementations out there in the wild (heck, =
I've written one myself) and that might make it difficult to standardize on=
 something.
Because of that, and many other reasons, I don't want to try and add that t=
o existing assertion drafts.

On Thu, Feb 28, 2013 at 12:13 PM, Lewis Adam-CAL022 > wrote:
Hi Brian, a few thoughts from somebody outside of the WG ...

As a newcomer to OAuth last year, I was initially confused by the titles.  =
It was confusing because we have SAML bearer *assertions* and JWT bearer *t=
okens* ... and as John just (begrudgingly) stated in this thread, the JWT i=
s being used as an assertion in this profile (and in OIDC).  I think it wil=
l be difficult to find a good name for these profiles since they do two ent=
irely different things (e.g. define a new grant type and define a new metho=
d of client authentication).  One could argue that as long as the WG is at =
it, then why not add a third section to the JWT profile, which talks about =
usage of JWT-structured bearer access tokens: it would not be any less rela=
ted than the other two focuses of the doc.  Then the document could be call=
ed something simple like "profiles of JWT usage in OAuth" or something like=
 that.

On one hand, it is probably na=EFve to think that an access token can be st=
andardized in a profile given how many have already been released into the =
wild, but on the other hand, a WG profile of a JWT-structured access token =
could lend itself to interoperability, where AS implementations can adverti=
se conformance to the profile and who knows ... maybe the RS's of the futur=
e will be good with this.

adam

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, February 28, 2013 1:03 PM
To: John Bradley
Cc: oauth@ietf.org WG

Subject: Re: [OAUTH-WG] JWT - scope claim missing

I'm not sure anyone really "picked" the titles for the bearer token profile=
s. They just kind of evolved. And evolved in funny ways especially when cli=
ent authn to the AS was added.
You won't hear me argue that the titles are "good" and this is not the firs=
t time there's been confusion about what they actually do. They define new =
grant types and new client authentication methods. They *do not* define an =
access token format or anything else about access tokens. JWT and SAML coul=
d be used for that but that's not what these drafts do.
Suggestions for better title(s) would be more than welcome.

Here's what they are now:

SAML 2.0 Bearer Assertion Profiles for OAuth 2.0
draft-ietf-oauth-saml2-bearer

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
draft-ietf-oauth-jwt-bearer

Assertion Framework for OAuth 2.0
draft-ietf-oauth-assertions

On Thu, Feb 28, 2013 at 11:36 AM, John Bradley > wrote:
Yes the title likely adds to the confusion given that the bearer tokens are=
 not access tokens.

Things as separate from OAuth as the Firefox browerID spec use JWS signed J=
WTs.

The bearer token profiles for OAuth 2 are for OAuth2.

The JSON Web Token (JWT) spec did not start in OAuth and is not OAuth specific.

A JWT is:

JSON Web Token (JWT)  A string representing a set of claims as a JSON

      object that is encoded in a JWS or JWE, enabling the claims to be

      digitally signed or MACed and/or encrypted.

So OAuth or other profiles may define claims to go in a JWT, but the JWT ne=
eds to itself only define the claims necessary for security processing.

John B.
PS that was a soft ball If you hadn't responded I would have been disappoin=
ted.  I din't pick the title for the bearer token profiles.

On 2013-02-28, at 10:12 AM, Phil Hunt > wrote:

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

Note the title says "for OAuth2"

Sorry. Couldn't resist.

Phil

Sent from my phone.

On 2013-02-28, at 9:40, John Bradley > wrote:
JWT is an assertion( I am probably going to regret using that word).

It is used in openID connect for id_tokens, it is used in OAuth for Asserti=
on grant types and authentication of the client to the token endpoint.
http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

Dosen't define JWT's use for access tokens for the RS.

Bottom line JWT is for more than access tokens.

John B.

On 2013-02-28, at 9:28 AM, Phil Hunt > wrote:

Are you saying jwt is not an access token type?

Phil

Sent from my phone.

On 2013-02-28, at 8:58, John Bradley > wrote:
Yes, defining scope in JWT is the wrong place.   JWT needs to stick to the =
security claims needed to process JWT.

I also don't know how far you get requiring a specific authorization format=
 for JWT, some AS will wan to use a opaque reference, some might want to us=
e a user claim or role claim, others may use scopes,  combining scopes and =
claims is also possible.

Right now it is up to a AS RS pair to agree on how to communicate authoriza=
tion.   I don't want MAC to be more restrictive than bearer when it comes t=
o authorization between AS and RS.

Hannes wanted to know why JWT didn't define scope.  The simple answer is th=
at it is out of scope for JWT itself.   It might be defined in a OAuth acce=
ss token profile for JWT but it should not be specific to MAC.

John B.
On 2013-02-28, at 8:44 AM, Brian Campbell > wrote:

I think John's point was more that scope is something rather specific to an=
 OAuth access token and, while JWT is can be used to represent an access to=
ken, it's not the only application of JWT. The 'standard' claims in JWT are=
 those that are believed (right or wrong) to be widely applicable across di=
fferent applications of JWT. One could argue about it but scope is probably=
 not one of those.
It would probably make sense to try and build a profile of JWT specifically=
 for OAuth access tokens (though I suspect there are some turtles and drago=
ns in there), which might be the appropriate place to define/register a sco=
pe claim.

On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt > wrote:
Are you advocating TWO systems? That seems like a bad choice.

I would rather fix scope than go to a two system approach.

Phil

Sent from my phone.

On 2013-02-28, at 8:17, John Bradley > wrote:

> While scope is one method that a AS could communicate authorization to a =
RS, it is not the only or perhaps even the most likely one.
> Using scope requires a relatively tight binding between the RS and AS,  U=
MA uses a different mechanism that describes finer grained operations.
> The AS may include roles, user, or other more abstract claims that the th=
e client may (god help them) pass on to EXCML for processing.
>
> While having a scopes claim is possible, like any other claim it is not p=
art of the JWT core security processing claims, and needs to be defined by =
extension.
>
> John B.
> On 2013-02-28, at 2:29 AM, Hannes Tschofenig > wrote:
>
>> Hi Mike,
>>
>> when I worked on the MAC specification I noticed that the JWT does not h=
ave a claim for the scope. I believe that this would be needed to allow the=
 resource server to verify whether the scope the authorization server autho=
rized is indeed what the client is asking for.
>>
>> 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

--_000_59E470B10C4630419ED717AC79FCF9A948D58DC0BY2PRD0411MB441_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hmmm, I’m not so sure=
.  It depends where we all think OAuth is on its trajectory.  On =
one hand, OAuth has already seen an insanely massive amount of deployment.&=
nbsp;
 On the other hand, RESTful APIs see no sign of slowing down.   N=
ow I’m not going to go so far as Craig B. and say that everything and=
 everyone will be API enabled in the future, but it sure is going to be a l=
ot.  That being said, one could argue that even
 with all the OAuth implementation we’ve seen, that this is just the =
infancy of it.  Obviously a WG profile of a JWT-structured AT could no=
t deprecate other forms (unstructured, SAML, etc.) but going forward new de=
velopers may choose to embrace this, and in
 fact this could even be the guidance.   I agree with previous co=
mments that Justin’s introspection draft might be a good place to exp=
lore this.

adam

From: Brian Ca=
mpbell [mailto:bcampbell@pingidentity.com]

Sent: Thursday, February 28, 2013 1:36 PM

To: Lewis Adam-CAL022

Cc: John Bradley; oauth@ietf.org WG

Subject: Re: [OAUTH-WG] JWT - scope claim missing<=
/p>

I do agree that a WG =
profile of a JWT-structured access token could lend itself to interoperabil=
ity and ultimately be a useful thing. But you are right that there already =
are many implementations out there in
 the wild (heck, I've written one myself) and that might make it difficult =
to standardize on something.

Because of that, and many other reasons, I don't wan=
t to try and add that to existing assertion drafts.

On Thu, Feb 28, 2013 at 12:13 PM, Lewis Adam-CAL022 =
<A=
dam.Lewis@motorolasolutions.com> wrote:

Hi Brian, a few thoughts from somebody ou=
tside of the WG …

As a newcomer to OAuth last year, I was i=
nitially confused by the titles.  It was confusing because
 we have SAML bearer *assertions* and JWT bearer *tokens* =
230; and as John just (begrudgingly) stated in this thread, the JWT is bein=
g used as an assertion in this profile (and in OIDC).  I think it will=
 be difficult to find a good name for these
 profiles since they do two entirely different things (e.g. define a new gr=
ant type and define a new method of client authentication).  One could=
 argue that as long as the WG is at it, then why not add a third section to=
 the JWT profile, which talks about usage
 of JWT-structured bearer access tokens: it would not be any less related t=
han the other two focuses of the doc.  Then the document could be call=
ed something simple like “profiles of JWT usage in OAuth” or so=
mething like that. 

On one hand, it is probably na=EFve to th=
ink that an access token can be standardized in a profile given
 how many have already been released into the wild, but on the other hand, =
a WG profile of a JWT-structured access token could lend itself to interope=
rability, where AS implementations can advertise conformance to the profile=
 and who knows … maybe the RS’s
 of the future will be good with this.  

adam

From:
oauth-bounces@i=
etf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Brian Campbell

Sent: Thursday, February 28, 2013 1:03 PM

To: John Bradley

Cc: oauth@ietf.o=
rg WG

Subject: Re: [OAUTH-WG] JWT - scope claim missing

I'm not sure anyone really "picked" the titles for the bearer =
token profiles. They just kind of evolved. And evolved in funny ways especi=
ally when client authn to the AS was added.

You won't hear me argue that the titles are "good" and this is=
 not the first time there's been confusion about what they actually do. The=
y define new grant types and new client authentication
 methods. They *do not* define an access token format or anything else abou=
t access tokens. JWT and SAML could be used for that but that's not what th=
ese drafts do.

Suggestions for better title(s) would be more than welcome.

Here's what they are now:

SAML 2.0 Bearer Assertion Profiles for OAuth 2.0

draft-ietf-oauth-saml2-bearer

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

draft-ietf-oauth-jwt-bearer

Assertion Framework for OAuth 2.0

draft-ietf-oauth-assertions

On Thu, Feb 28, 2013 at 11:36 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes the title likely adds to the confusion given that the bearer t=
okens are not access tokens.

Things as separate from OAuth as the Firefox browerID spec use JWS=
 signed JWTs.  

The bearer token profiles for OAuth 2 are for OAuth2.

The JSON Web Token (JWT) spec did n=
ot start in OAuth and is not OAuth specific.

A JWT is:

JSON Web Token (JWT)  A string r=
epresenting a set of claims as a JSON
      object=
 that is encoded in a JWS or JWE, enabling the claims to be
      digita=
lly signed or MACed and/or encrypted.

So OAuth or other profiles may define claims to go in a JWT, but t=
he JWT needs to itself only define the claims necessary for security proces=
sing.  

John B.

PS that was a soft ball If you hadn't responded I would have been =
disappointed.  I din't pick the title for the bearer token profiles.

On 2013-02-28, at 10:12 AM, Phil Hunt <phil.hunt@oracle.com> wrote:<=
/o:p>

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

Note the title says "for OAuth2"

Sorry. Couldn't resist. 

Phil

Sent from my phone.

On 2013-02-28, at 9:40, John Bradley <ve7jtb@ve7jtb.com> wrote:

JWT is an assertion( I am probably going to regret using that word=
).

It is used in openID connect for id_tokens, it is used in OAuth fo=
r Assertion grant types and authentication of the client to the token endpo=
int.

http://tools.ietf.org/html/draft-ietf-oauth-jwt-beare=
r-04

JS=
ON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

Dosen't define JWT's use for access tokens for the RS.   =
;

Bottom line JWT is for more than access tokens.

John B.

On 2013-02-28, at 9:28 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

Are you saying jwt is not an access token type?

Phil

Sent from my phone.

On 2013-02-28, at 8:58, John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes, defining scope in JWT is the wrong place.   JWT needs to=
 stick to the security claims needed to process JWT.

I also don't know how far you get requiring a specific authorizati=
on format for JWT, some AS will wan to use a opaque reference, some might w=
ant to use a user claim or role claim,
 others may use scopes,  combining scopes and claims is also possible.=

Right now it is up to a AS RS pair to agree on how to communicate =
authorization.   I don't want MAC to be more restrictive than bearer w=
hen it comes to authorization between AS
 and RS.

Hannes wanted to know why JWT didn't define scope.  The simpl=
e answer is that it is out of scope for JWT itself.   It might be defi=
ned in a OAuth access token profile for JWT but
 it should not be specific to MAC.

John B.

On 2013-02-28, at 8:44 AM, Brian Campbell <bcampbell@pingidentity.com&=
gt; wrote:

I think John's point was more that scope is something rather specific to=
 an OAuth access token and, while JWT is can be used to represent an access=
 token, it's not the only application
 of JWT. The 'standard' claims in JWT are those that are believed (right or=
 wrong) to be widely applicable across different applications of JWT. One c=
ould argue about it but scope is probably not one of those.

It would probably make sense to try and build a profile of JWT spe=
cifically for OAuth access tokens (though I suspect there are some turtles =
and dragons in there), which might be
 the appropriate place to define/register a scope claim.

On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt <phil.hunt@oracle.com> wrote:<=
o:p>
Are you advocating TWO systems? That seems like a bad choice.

I would rather fix scope than go to a two system approach.

Phil

Sent from my phone.

On 2013-02-28, at 8:17, John Bradley <ve7jtb@ve7jtb.com> wrote:

> While scope is one method that a AS could communicate authorization to=
 a RS, it is not the only or perhaps even the most likely one.

> Using scope requires a relatively tight binding between the RS and AS,=
  UMA uses a different mechanism that describes finer grained operatio=
ns.

> The AS may include roles, user, or other more abstract claims that the=
 the client may (god help them) pass on to EXCML for processing.

>

> While having a scopes claim is possible, like any other claim it is no=
t part of the JWT core security processing claims, and needs to be defined =
by extension.

>

> John B.

> On 2013-02-28, at 2:29 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net>=
 wrote:

>

>> Hi Mike,

>>

>> when I worked on the MAC specification I noticed that the JWT does=
 not have a claim for the scope. I believe that this would be needed to all=
ow the resource server to verify whether the scope the authorization server=
 authorized is indeed what the client
 is asking for.

>>

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

h=
ttps://www.ietf.org/mailman/listinfo/oauth

--_000_59E470B10C4630419ED717AC79FCF9A948D58DC0BY2PRD0411MB441_--

From leifj@mnt.se  Thu Feb 28 14:23:52 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830D321F8BCE for ; Thu, 28 Feb 2013 14:23:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.734
X-Spam-Level: 
X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0d914dos+od for ; Thu, 28 Feb 2013 14:23:52 -0800 (PST)
Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B952421F8BCD for ; Thu, 28 Feb 2013 14:23:51 -0800 (PST)
Received: by mail-la0-f46.google.com with SMTP id fq12so2330111lab.33 for ; Thu, 28 Feb 2013 14:23:48 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=0vr4A+BNHFrWCYxH3RLly/DH5TvBag+8zGARx1vrXbE=; b=LmDYmBJe+5QVoAzf1X5rVhgUWtliGc7PowlzrPYXKqwDQclWtqvxz0ZECwKq+3Nki4 XEkbRwelMYjMEcgRuztY9wdoRLIKHUNAsQO94pxGFpzuasH9dae4NJibFciWk0aKo9qf OA9rsfLrzwa4dXsBs1ziu04716clCNBFzmWUpfYPepnAll3AtcU2aPr8AvulkEBHuAt7 GOmePZWrQBbd676nW+UH27xrC2XWZdHO0w4ZIT6oSw13f/hf1QM3AhiOybt0Xu8Cms/3 3bCoFL7Iwhkh082y65Wn9RB70MndIW4BIx63LlGaTYN0uCfYHP8e42PnnUgLl7BYkVQy w6SQ==
X-Received: by 10.152.133.130 with SMTP id pc2mr6937819lab.51.1362090228645; Thu, 28 Feb 2013 14:23:48 -0800 (PST)
Received: from [10.0.0.244] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPS id gm20sm5477641lab.7.2013.02.28.14.23.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Feb 2013 14:23:47 -0800 (PST)
Message-ID: <512FD8F0.6080109@mnt.se>
Date: Thu, 28 Feb 2013 23:23:44 +0100
From: Leif Johansson 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: oauth@ietf.org
References: <1362079266.8952.YahooMailClassic@web141002.mail.bf1.yahoo.com> <512FCDF0.6010807@gmx.net> <512FD1C5.2070100@oracle.com> <512FD2AC.2000607@gmx.net>
In-Reply-To: <512FD2AC.2000607@gmx.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQlrdvjzMjIHligOL/kSIXBYvuDDqEex+tQtuyoE4B2frWEgAwWbxYH7S1R0IQBWhgAOt7v8
Subject: Re: [OAUTH-WG] Fw:  IPR Disclosure: - What to Do with JWT ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 22:23:52 -0000

On 02/28/2013 10:57 PM, Hannes Tschofenig wrote:
> This is certainly a good point. Stating whether certain claims are
> valid or not valid is not a good use of our time and may lead to legal
> problems later on.
>
> So, read through the patents and make your own assessment whether this
> IPRs are a concern for you and whether you want anything in the drafts
> to be changed.
>
good point. thx

From Michael.Jones@microsoft.com  Thu Feb 28 14:54:33 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC0E21F8922 for ; Thu, 28 Feb 2013 14:54:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.51
X-Spam-Level: 
X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.088,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+V4abcdjk86 for ; Thu, 28 Feb 2013 14:54:27 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAE221F886B for ; Thu, 28 Feb 2013 14:54:26 -0800 (PST)
Received: from BL2FFO11FD005.protection.gbl (10.173.161.201) by BL2FFO11HUB008.protection.gbl (10.173.160.228) with Microsoft SMTP Server (TLS) id 15.0.620.12; Thu, 28 Feb 2013 22:54:23 +0000
Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD005.mail.protection.outlook.com (10.173.161.1) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Thu, 28 Feb 2013 22:54:23 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Thu, 28 Feb 2013 22:53:54 +0000
From: Mike Jones 
To: Brian Campbell , prateek mishra 
Thread-Topic: [OAUTH-WG] JWT - scope claim missing
Thread-Index: AQHOFZ6hIxtkb1+gY0y+b2wB9BjwWJiPcwkAgAAB5wCAAAWJgIAABAMAgAAIM4CAAAN2AIAACPaAgAAGkYCAAAeWAIAAHCmAgAAEbQCAAB/izw==
Date: Thu, 28 Feb 2013 22:53:53 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943674C4DB1@TK5EX14MBXC283.redmond.corp.microsoft.com>
References: <0EC2404F-E3C5-4AD1-88B4-E74AA0394DD9@gmx.net>     <48FD87D1-4DF4-4289-99B7-40A515F31890@oracle.com> <3E472720-31A4-40A0-AAA4-402CF850831A@ve7jtb.com> <7127843B-D7B0-4AB6-87F1-1604D1EFFA79@oracle.com> <50DA292F-32F0-4266-8401-006AD837B775@ve7jtb.com>  <512FC18D.1020803@oracle.com>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943674C4DB1TK5EX14MBXC283r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(24454001)(479174001)(189002)(199002)(51704002)(377424002)(377454001)(56776001)(5343645001)(56816002)(512934001)(33656001)(5343635001)(79102001)(5343655001)(63696002)(50986001)(47976001)(54316002)(51856001)(46102001)(54356001)(4396001)(49866001)(47736001)(53806001)(55846006)(74662001)(65816001)(80022001)(44976002)(16236675001)(16406001)(76482001)(20776003)(47446002)(59766001)(77982001)(74502001)(15202345001)(31966008)(550254004); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB008; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0771670921
Cc: oauth 
Subject: Re: [OAUTH-WG] JWT - scope claim missing
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 22:54:33 -0000

--_000_4E1F6AAD24975D4BA5B1680429673943674C4DB1TK5EX14MBXC283r_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

+1

________________________________
From: Brian Campbell
Sent: 2/28/2013 1:00 PM
To: prateek mishra
Cc: oauth
Subject: Re: [OAUTH-WG] JWT - scope claim missing

Thanks Prateek. I like it and I think wordy might be the way to go here.

On Thu, Feb 28, 2013 at 1:43 PM, prateek mishra > wrote:
SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Gran=
ts
JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants
Assertion Framework for OAuth 2.0 

a bit wordy, but does get the point across IMO

- prateek

I'm not sure anyone really "picked" the titles for the bearer token profile=
s. They just kind of evolved. And evolved in funny ways especially when cli=
ent authn to the AS was added.

You won't hear me argue that the titles are "good" and this is not the firs=
t time there's been confusion about what they actually do. They define new =
grant types and new client authentication methods. They *do not* define an =
access token format or anything else about access tokens. JWT and SAML coul=
d be used for that but that's not what these drafts do.

Suggestions for better title(s) would be more than welcome.

Here's what they are now:

SAML 2.0 Bearer Assertion Profiles for OAuth 2.0
draft-ietf-oauth-saml2-bearer

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
draft-ietf-oauth-jwt-bearer

Assertion Framework for OAuth 2.0
draft-ietf-oauth-assertions

On Thu, Feb 28, 2013 at 11:36 AM, John Bradley > wrote:
Yes the title likely adds to the confusion given that the bearer tokens are=
 not access tokens.

Things as separate from OAuth as the Firefox browerID spec use JWS signed J=
WTs.

The bearer token profiles for OAuth 2 are for OAuth2.

The JSON Web Token (JWT) spec did not start in OAuth and is not OAuth specific.

A JWT is:

JSON Web Token (JWT)  A string representing a set of claims as a JSON
      object that is encoded in a JWS or JWE, enabling the claims to be
      digitally signed or MACed and/or encrypted.

So OAuth or other profiles may define claims to go in a JWT, but the JWT ne=
eds to itself only define the claims necessary for security processing.

John B.
PS that was a soft ball If you hadn't responded I would have been disappoin=
ted.  I din't pick the title for the bearer token profiles.

On 2013-02-28, at 10:12 AM, Phil Hunt > wrote:

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

Note the title says "for OAuth2"

Sorry. Couldn't resist.

Phil

Sent from my phone.

On 2013-02-28, at 9:40, John Bradley > wrote:

JWT is an assertion( I am probably going to regret using that word).

It is used in openID connect for id_tokens, it is used in OAuth for Asserti=
on grant types and authentication of the client to the token endpoint.
http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

Dosen't define JWT's use for access tokens for the RS.

Bottom line JWT is for more than access tokens.

John B.

On 2013-02-28, at 9:28 AM, Phil Hunt > wrote:

Are you saying jwt is not an access token type?

Phil

Sent from my phone.

On 2013-02-28, at 8:58, John Bradley > wrote:

Yes, defining scope in JWT is the wrong place.   JWT needs to stick to the =
security claims needed to process JWT.

I also don't know how far you get requiring a specific authorization format=
 for JWT, some AS will wan to use a opaque reference, some might want to us=
e a user claim or role claim, others may use scopes,  combining scopes and =
claims is also possible.

Right now it is up to a AS RS pair to agree on how to communicate authoriza=
tion.   I don't want MAC to be more restrictive than bearer when it comes t=
o authorization between AS and RS.

Hannes wanted to know why JWT didn't define scope.  The simple answer is th=
at it is out of scope for JWT itself.   It might be defined in a OAuth acce=
ss token profile for JWT but it should not be specific to MAC.

John B.
On 2013-02-28, at 8:44 AM, Brian Campbell > wrote:

I think John's point was more that scope is something rather specific to an=
 OAuth access token and, while JWT is can be used to represent an access to=
ken, it's not the only application of JWT. The 'standard' claims in JWT are=
 those that are believed (right or wrong) to be widely applicable across di=
fferent applications of JWT. One could argue about it but scope is probably=
 not one of those.

It would probably make sense to try and build a profile of JWT specifically=
 for OAuth access tokens (though I suspect there are some turtles and drago=
ns in there), which might be the appropriate place to define/register a sco=
pe claim.

On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt > wrote:
Are you advocating TWO systems? That seems like a bad choice.

I would rather fix scope than go to a two system approach.

Phil

Sent from my phone.

On 2013-02-28, at 8:17, John Bradley > wrote:

> While scope is one method that a AS could communicate authorization to a =
RS, it is not the only or perhaps even the most likely one.
> Using scope requires a relatively tight binding between the RS and AS,  U=
MA uses a different mechanism that describes finer grained operations.
> The AS may include roles, user, or other more abstract claims that the th=
e client may (god help them) pass on to EXCML for processing.
>
> While having a scopes claim is possible, like any other claim it is not p=
art of the JWT core security processing claims, and needs to be defined by =
extension.
>
> John B.
> On 2013-02-28, at 2:29 AM, Hannes Tschofenig > wrote:
>
>> Hi Mike,
>>
>> when I worked on the MAC specification I noticed that the JWT does not h=
ave a claim for the scope. I believe that this would be needed to allow the=
 resource server to verify whether the scope the authorization server autho=
rized is indeed what the client is asking for.
>>
>> 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

--_000_4E1F6AAD24975D4BA5B1680429673943674C4DB1TK5EX14MBXC283r_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

+1

From:
Brian =
Campbell

Sent:
2/28/2=
013 1:00 PM

To:
pratee=
k mishra

Cc:
oauth<=
/span>

Subject:
Re: [O=
AUTH-WG] JWT - scope claim missing

Thanks Prateek. I like it and I think wordy might be the w=
ay to go here.

On Thu, Feb 28, 2013 at 1:43 PM, prateek mishra =

<prateek.=
mishra@oracle.com> wrote:

SAML 2.0 Profile for OAuth 2.0 Client Authenticati=
on and Authorization Grants

JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants 
Assertion Framework for OAuth 2.0 <as above> 

a bit wordy, but does get the point across IMO

- prateek

I'm not sure anyone really "picked" the titles for the beare=
r token profiles. They just kind of evolved. And evolved in funny ways espe=
cially when client authn to the AS was added.

You won't hear me argue that the titles are "good" and this =
is not the first time there's been confusion about what they actually do. T=
hey define new grant types and new client authentication methods. They *do =
not* define an access token format or anything
 else about access tokens. JWT and SAML could be used for that but that's n=
ot what these drafts do.

Suggestions for better title(s) would be more than welcome.

Here's what they are now:

SAML 2.0 Bearer Assertion Profiles for OAuth 2.0

draft-ietf-oauth-saml2-bearer

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

draft-ietf-oauth-jwt-bearer

Assertion Framework for OAuth 2.0

draft-ietf-oauth-assertions

On Thu, Feb 28, 2013 at 11:36 AM, John Bradley <=
span dir=3D"ltr">
<ve7jtb@ve7jtb.co=
m> wrote:

Yes the title likely adds to the confus=
ion given that the bearer tokens are not access tokens.

Things as separate from OAuth as the Firefox browerID spec use JWS sig=
ned JWTs.  

The bearer token profiles for OAuth 2 are for OAuth2.

The JSON Web Token (JWT) spec did not s=
tart in OAuth and is not OAuth specific.

A JWT is:

JSON Web To=
ken (JWT)  A string representing a set of claims as a JSON
      object that is encoded in a JWS or JWE, enabling the claims to be
      digitally signed or MACed and/or encrypted.

So OAuth or other profiles may define claims to go in a JWT, but the J=
WT needs to itself only define the claims necessary for security processing=
.  

John B.
PS that was a soft ball If you hadn't responded I would have been disa=
ppointed.  I din't pick the title for the bearer token profiles.

On 2013-02-28, at 10:12 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

<=
span style=3D"white-space:normal">        

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0=

Note the title says "for OAuth2"

Sorry. Couldn't resist. 

Phil

Sent from my phone.

On 2013-02-28, at 9:40, John Bradley <ve7jtb@ve7jtb.com> wrote:

JWT is an assertion( I am probably going to regre=
t using that word).

It is used in openID connect for id_tokens, it is used in OAuth for As=
sertion grant types and authentication of the client to the token endpoint.=

http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04=

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

Dosen't define JWT's use for access tokens for the RS.   

Bottom line JWT is for more than access tokens.

John B.

On 2013-02-28, at 9:28 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

Are you saying jwt is not an access token type?

Phil

Sent from my phone.

On 2013-02-28, at 8:58, John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes, defining scope in JWT is the wrong place. &n=
bsp; JWT needs to stick to the security claims needed to process JWT.

I also don't know how far you get requiring a specific authorization f=
ormat for JWT, some AS will wan to use a opaque reference, some might want =
to use a user claim or role claim, others may use scopes,  combining s=
copes and claims is also possible.

Right now it is up to a AS RS pair to agree on how to communicate auth=
orization.   I don't want MAC to be more restrictive than bearer when =
it comes to authorization between AS and RS.

Hannes wanted to know why JWT didn't define scope.  The simple an=
swer is that it is out of scope for JWT itself.   It might be defined =
in a OAuth access token profile for JWT but it should not be specific to MA=
C.

John B.

On 2013-02-28, at 8:44 AM, Brian Campbell <bcampbell@pingidentity.com> =
wrote:

I think John's point was more that scope is something rather specific =
to an OAuth access token and, while JWT is can be used to represent an acce=
ss token, it's not the only application of JWT. The 'standard' claims in JW=
T are those that are believed (right
 or wrong) to be widely applicable across different applications of JWT. On=
e could argue about it but scope is probably not one of those.

It would probably make sense to try and build a profile of JWT specifically=
 for OAuth access tokens (though I suspect there are some turtles and drago=
ns in there), which might be the appropriate place to define/register a sco=
pe claim.

On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt 
<phil.hunt@ora=
cle.com> wrote:

Are you advocating TWO systems? That seems like a bad choice.

I would rather fix scope than go to a two system approach.

Phil

Sent from my phone.

On 2013-02-28, at 8:17, John Bradley <ve7jtb@ve7jtb.com> wrote:

> While scope is one method that a AS could communicate authorization to=
 a RS, it is not the only or perhaps even the most likely one.

> Using scope requires a relatively tight binding between the RS and AS,=
  UMA uses a different mechanism that describes finer grained operatio=
ns.

> The AS may include roles, user, or other more abstract claims that the=
 the client may (god help them) pass on to EXCML for processing.

>

> While having a scopes claim is possible, like any other claim it is no=
t part of the JWT core security processing claims, and needs to be defined =
by extension.

>

> John B.

> On 2013-02-28, at 2:29 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net>=
 wrote:

>

>> Hi Mike,

>>

>> when I worked on the MAC specification I noticed that the JWT does=
 not have a claim for the scope. I believe that this would be needed to all=
ow the resource server to verify whether the scope the authorization server=
 authorized is indeed what the client
 is asking for.

>>

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

h=
ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/oauth

--_000_4E1F6AAD24975D4BA5B1680429673943674C4DB1TK5EX14MBXC283r_--

From prateek.mishra@oracle.com  Thu Feb 28 14:56:30 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB98321F8A09 for ; Thu, 28 Feb 2013 14:56:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.571
X-Spam-Level: 
X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.027,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SO+TCwlaQwEN for ; Thu, 28 Feb 2013 14:56:30 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id A3FA621F89B5 for ; Thu, 28 Feb 2013 14:56:29 -0800 (PST)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1SMuM1B015382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 28 Feb 2013 22:56:23 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1SMuMeM029769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 28 Feb 2013 22:56:22 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1SMuMOf018264 for ; Thu, 28 Feb 2013 16:56:22 -0600
Received: from [10.152.55.88] (/10.152.55.88) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 28 Feb 2013 14:56:21 -0800
Message-ID: <512FE091.9030508@oracle.com>
Date: Thu, 28 Feb 2013 17:56:17 -0500
From: prateek mishra 
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: "oauth@ietf.org" 
References: <1361830944.13340.YahooMailNeo@web31812.mail.mud.yahoo.com>  <1361831644.50183.YahooMailNeo@web31801.mail.mud.yahoo.com> <1361832133.97884.YahooMailNeo@web31816.mail.mud.yahoo.com> <140EEABC-2787-4D9A-A1C5-6C973FED5BC8@adobe.com>
In-Reply-To: <140EEABC-2787-4D9A-A1C5-6C973FED5BC8@adobe.com>
Content-Type: multipart/alternative; boundary="------------090104060409020309040405"
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Subject: Re: [OAUTH-WG] OAuth2 attack surface....
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2013 22:56:31 -0000

This is a multi-part message in MIME format.
--------------090104060409020309040405
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Characteristics of both these attacks -

1) Use of implicit flow (access token passed on the URL)
2) changes to redirect uri (specification does allow some flexibility here)
3) applications with long-lived access tokens with broad scope (in one 
case only)

- prateek
> And a different one (still exploiting redirection and still 
> implementation mistake) 
> http://www.nirgoldshlager.com/2013/02/how-i-hacked-facebook-oauth-to-get-full.html 
>
>
> Regards
>
> Antonio
>
> On Feb 25, 2013, at 11:42 PM, William Mills wrote:
>
>>
>>
>> DOH!!! 
>> http://homakov.blogspot.co.uk/2013/02/hacking-facebook-with-oauth2-and-chrome.html
>>
>> ------------------------------------------------------------------------
>> *From:* Phil Hunt >
>> *To:* William Mills > >
>> *Sent:* Monday, February 25, 2013 2:28 PM
>> *Subject:* Re: [OAUTH-WG] OAuth2 attack surface....
>>
>> Whats the link?
>>
>> Phil
>>
>> Sent from my phone.
>>
>> On 2013-02-25, at 14:22, William Mills > > wrote:
>>
>>> I think this is worth a read, I don't have time to dive into this :(
>>> _______________________________________________
>>> 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

--------------090104060409020309040405
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

    Characteristics of both these attacks -

    1) Use of implicit flow (access token passed on the URL)

    2) changes to redirect uri (specification does allow some
    flexibility here)

    3) applications with long-lived access tokens with broad scope (in
    one case only)

    - prateek

    And a different one (still exploiting redirection and
      still implementation mistake) http://www.nirgoldshlager.com/2013/02/how-i-hacked-facebook-oauth-to-get-full.html

      Regards

      Antonio

          On Feb 25, 2013, at 11:42 PM, William Mills wrote:

                          DOH!!!  http://homakov.blogspot.co.uk/2013/02/hacking-facebook-with-oauth2-and-chrome.html

 From:
                                  Phil Hunt <phil.hunt@oracle.com>

                                  To:
                                  William Mills <wmills_92105@yahoo.com>

                                  Sent:
                                  Monday, February 25, 2013 2:28 PM

                                  Subject:
                                  Re: [OAUTH-WG] OAuth2 attack
                                  surface....

                                  Whats the link?

                                    Phil

                                    Sent from my phone.

                                    On 2013-02-25, at 14:22, William
                                    Mills <wmills_92105@yahoo.com>
                                    wrote:

                                        I think this is worth a
                                          read, I don't have time to
                                          dive into this :(

                                    _______________________________________________

                                      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

--------------090104060409020309040405--

From oleg_gryb@yahoo.com  Thu Feb 28 16:26:20 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F4C21F8A3F for ; Thu, 28 Feb 2013 16:26:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5Ah1yFYnXL0 for ; Thu, 28 Feb 2013 16:26:18 -0800 (PST)
Received: from nm16-vm0.bullet.mail.bf1.yahoo.com (nm16-vm0.bullet.mail.bf1.yahoo.com [98.139.212.253]) by ietfa.amsl.com (Postfix) with SMTP id 44FE021F85D7 for ; Thu, 28 Feb 2013 16:26:18 -0800 (PST)
Received: from [98.139.212.147] by nm16.bullet.mail.bf1.yahoo.com with NNFMP; 01 Mar 2013 00:26:17 -0000
Received: from [98.139.212.224] by tm4.bullet.mail.bf1.yahoo.com with NNFMP; 01 Mar 2013 00:26:17 -0000
Received: from [127.0.0.1] by omp1033.mail.bf1.yahoo.com with NNFMP; 01 Mar 2013 00:26:17 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 680698.12576.bm@omp1033.mail.bf1.yahoo.com
Received: (qmail 41683 invoked by uid 60001); 1 Mar 2013 00:26:17 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1362097577; bh=GLygl1IbgL5zBidyyPm5xHK04RlvBal060C3Daq2Aew=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=4TS81MDXrAHXdd0gy2Z8SngqW5qUtZXy0GmjgcWVE9yxY/4aR/bRwQXxH+YjwAkMEbo83vpkoTVENtN3LuS0BPTlgygBjhMLykm74PE0i7WNErSx553PJpwbKNOajA0luJQsrYfREZOtZh5z3lr9uePJuhfx9OzS8avmv2guXtI=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Fr/7gzXC9TD3VNvwUOUHUKSt9zFZl9A8m0WOds3x9uuP6tiNy7ImsbdgJK8qg/U+pm0AOfL/WH3Fl9abZ4gDOyrhfF3XCguqhvL2CkXLDyRdI1TwUOi4ByCTGAJiXPbYVy/dZ4sPa3zhuTpXgL9E/GiuYDq6zqix65QrpdaqMgg=;
X-YMail-OSG: ckskuSkVM1lfxUjMOH.Q6NOoLhFajMT1HXzRwBmEZ4goR9D Ukp769tcl8tJTITEW2f_WvGaykrC4Cqu1MN3EjWf6BBKqiYnADVnczyTgNoH bwml0fv88BLA5fJaGD82PEwQCpx96G5isZxJ8yxvOA_I0MoIQc7Yrn2samsd I3F1c5S1LT4I.yk4XmpcWYgdD61U2gRchPUbO9bWDhUV718sF1PHetddRm2B e9R.aplkcKTD5yqjWr4tbPVACrqHc1h2JgjXOFAXf9JVoWcwQwS9q52oxoB3 4fz7AoUVHz_DBYmSiZjo80ANd9dCTGxdEjvUlDXNgto.7Y7YlumvkFJgEpow 5xqN6Txoo.KD4kn8_TwvhoFh2Tg.1RbOCj_X7vYNLHJWLoNeU8zhTUbwysL8 3S14rYVkk2ImsB.KLxMrM7VWE_NnrlYXJWoKaCBFdj5Yp0iw2igp177ij84M 8rlQNNWxMqBD6QBr9fEsrKx697l9NMXsc86TvRfzLk9_u19PetQ8e5kDA5uJ 3AvVTnjunwT9BbIPuzR4PiVZ1e3bcx4BzfKryMqqUDbPBK0tmW4y7vWhNSFs tkfHuZLxW.VnhrA06RdReFrkwdWxeIGAN_4ciUEiLih5RJoIW03yMSdaZg.G k3GpVOjOSGTBRXZUnZIbvDEnVVUfMG2y6.Z15b.n5JQOr
Received: from [199.16.140.28] by web141006.mail.bf1.yahoo.com via HTTP; Thu, 28 Feb 2013 16:26:17 PST
X-Rocket-MIMEInfo: 001.001, UHJhdGVlaywNCg0KSXQncyBub3Qgc28gbXVjaCBhICJwYXRlbnQgY2xhaW0iIGRpc2N1c3Npb24gYXMgYSBzdWdnZXN0aW9uIHRvIGRvIHNvbWV0aGluZyBkaWZmZXJlbnQgdGhhbiBKV1QgaWYgaXQncyByZWFsbHkgcHJvdGVjdGVkIGJ5IHNvbWVib2R5J3MgcGF0ZW50cy4gSXQncyBhIHB1YmxpYyBzdGFuZGFyZCBhZnRlciBhbGwgYW5kIGl0J3MgaW4gdGhlIGludGVyZXN0cyBvZiBldmVyeW9uZSB0byBrZWVwIGl0IHRoaXMgd2F5LsKgIA0KDQotLS0gT24gVGh1LCAyLzI4LzEzLCBwcmF0ZWVrIG1pc2hyYSABMAEBAQE-
X-Mailer: YahooMailClassic/15.1.4 YahooMailWebService/0.8.135.514
Message-ID: <1362097577.15771.YahooMailClassic@web141006.mail.bf1.yahoo.com>
Date: Thu, 28 Feb 2013 16:26:17 -0800 (PST)
From: Oleg Gryb 
To: Hannes Tschofenig , prateek mishra 
In-Reply-To: <512FD1C5.2070100@oracle.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="1694620066-184547543-1362097577=:15771"
Cc: oleg@gryb.info, oauth@ietf.org
Subject: Re: [OAUTH-WG] Fw:  IPR Disclosure: - What to Do with JWT ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: oleg@gryb.info
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Mar 2013 00:26:20 -0000

--1694620066-184547543-1362097577=:15771
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Prateek,

It's not so much a "patent claim" discussion as a suggestion to do somethin=
g different than JWT if it's really protected by somebody's patents. It's a=
 public standard after all and it's in the interests of everyone to keep it=
 this way.=A0=20

--- On Thu, 2/28/13, prateek mishra  wrote:

From: prateek mishra 
Subject: Re: [OAUTH-WG] Fw:  IPR Disclosure: - What to Do with JWT ?
To: "Hannes Tschofenig" 
Cc: oleg@gryb.info, oauth@ietf.org
Date: Thursday, February 28, 2013, 4:53 PM

Two points=A0 -

1) I request that this mailing list NOT be used for any substantive=20
discussion of patent claims and so on. This will create difficulties for=20
many participants and
I dont believe is within the charter of this effort.

2) I would encourage interested parties to review the following=20
document, which may be relevant to this discussion

http://www.w3.org/2011/xmlsec-pag/

- prateek

> Hi Oleg,
>
> my personal experience with Certicom's IPR disclosures is that they=20
> focus on Elliptic Curve Cryptography. There were several IPR=20
> disclosures on documents in the JOSE WG and some of them contain ECC=20
> algorithms.
>
> The JWT does not list an ECC algorithm but the referenced documents do.
>
> Having said that the two cited IPRs seem to be:
> http://www.google.com/patents/US6704870
> http://www.google.com/patents/US7215773
>
> Take a look at it and make your assessment whether there is anything=20
> we can change.
>
> Ciao
> Hannes
>
>
> On 02/28/2013 09:21 PM, Oleg Gryb wrote:
>> Dear OAuth WG and Chairs,
>>
>> Can somebody please comment the Certicom's disclosure below? If the
>> purpose of this disclosure is to inform us that JWT can be potentially a
>> subject of royalties and other possible legal actions, the value of
>> adopting JWT in the scope of OAuth 2.0 IETF standard would definitely
>> diminish and if this is the case shouldn't we consider replacing it with
>> something similar, but different, which would not be a subject of the
>> future possible litigation?
>>
>> I'm not a lawyer and might not understand the statement below correctly,
>> so please let me know if/where I'm wrong. Please keep in mind also that
>> the popularity of JWT is growing fast along with the implementations, so
>> we need to do something quickly.
>>
>> Thanks,
>> Oleg.
>>
>>
>> --- On *Wed, 2/27/13, IETF Secretariat //* wrote:
>>
>>
>>=A0 =A0=A0=A0From: IETF Secretariat 
>>=A0 =A0=A0=A0Subject: [OAUTH-WG] IPR Disclosure: Certicom Corporation's S=
tatement
>>=A0 =A0=A0=A0about IPR related to draft-ietf-oauth-json-web-token-06 (2)
>>=A0 =A0=A0=A0To: mbj@microsoft.com, ve7jtb@ve7jtb.com, n-sakimura@nri.co.=
jp
>>=A0 =A0=A0=A0Cc: derek@ihtfp.com, oauth@ietf.org, ipr-announce@ietf.org
>>=A0 =A0=A0=A0Date: Wednesday, February 27, 2013, 4:16 PM
>>
>>
>>=A0 =A0=A0=A0Dear Michael Jones, John Bradley, Nat Sakimura:
>>
>>=A0 =A0=A0=A0An IPR disclosure that pertains to your Internet-Draft entit=
led
>>=A0 =A0=A0=A0"JSON Web Token
>>=A0 =A0=A0=A0(JWT)" (draft-ietf-oauth-json-web-token) was submitted to th=
e IETF
>>=A0 =A0=A0=A0Secretariat
>>=A0 =A0=A0=A0on 2013-02-20 and has been posted on the "IETF Page of Intel=
lectual
>>=A0 =A0=A0=A0Property
>>=A0 =A0=A0=A0Rights Disclosures" (https://datatracker.ietf.org/ipr/1968/)=
. The
>>=A0 =A0=A0=A0title of the
>>=A0 =A0=A0=A0IPR disclosure is "Certicom Corporation's Statement about IP=
R
>>=A0 =A0=A0=A0related to draft-
>>=A0 =A0=A0=A0ietf-oauth-json-web-token-06 (2)."");
>>
>>=A0 =A0=A0=A0The IETF Secretariat
>>
>>=A0 =A0=A0=A0_______________________________________________
>>=A0 =A0=A0=A0OAuth mailing list
>>=A0 =A0=A0=A0OAuth@ietf.org 
>>=A0 =A0=A0=A0https://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

--1694620066-184547543-1362097577=:15771
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<=
/tr>Prateek,

It's not so much a "patent cl=
aim" discussion as a suggestion to do something different than JWT if it's =
really protected by somebody's patents. It's a public standard after all an=
d it's in the interests of everyone to keep it this way.  

--- =
On Thu, 2/28/13, prateek mishra <prateek.mishra@oracle.com>=
 wrote:

From: prateek mishra <pratee=
k.mishra@oracle.com>
Subject: Re: [OAUTH-WG] Fw:  IPR Disclosure: - W=
hat to Do with JWT ?
To: "Hannes Tschofenig" <hannes.tschofenig@gmx.n=
et>
Cc: oleg@gryb.info, oauth@ietf.org
Date: Thursday, February 28=
, 2013, 4:53 PM

Two points  -

1=
) I request that this mailing list NOT be used for any substantive 
disc=
ussion
 of patent claims and so on. This will create difficulties for 
many par=
ticipants and
I dont believe is within the charter of this effort.
2) I would encourage interested parties to review the following 
docum=
ent, which may be relevant to this discussion

http://www.w3.org/2011/xmlsec-pa=
g/

- prateek

> Hi Oleg,
>
> my personal ex=
perience with Certicom's IPR disclosures is that they 
> focus on Ell=
iptic Curve Cryptography. There were several IPR 
> disclosures on do=
cuments in the JOSE WG and some of them contain ECC 
> algorithms.>
> The JWT does not list an ECC algorithm but the referenced doc=
uments do.
>
> Having said that the two cited IPRs seem to be:<=
br>> http://www.google.com/patents/US6704870
> http://=
www.google.com/patents/US7215773
>
> Take a look at it and =
make your assessment whether there is anything 
> we can change.
&=
gt;
> Ciao
> Hannes
>
>
> On 02/28/2013 09:21=
 PM, Oleg Gryb wrote:
>> Dear OAuth WG and Chairs,
>>
=
>> Can somebody please comment the Certicom's disclosure below? If th=
e
>> purpose of this disclosure is to inform us that JWT can be po=
tentially a
>> subject of royalties and other possible legal actio=
ns, the value of
>> adopting JWT in the scope of OAuth 2.0 IETF st=
andard would definitely
>> diminish and if this is the case should=
n't we consider replacing it with
>> something similar, but differ=
ent, which would not be a subject of the
>> future possible litiga=
tion?
>>
>> I'm not a lawyer and might not understand
 the statement below correctly,
>> so please let me know if/where =
I'm wrong. Please keep in mind also that
>> the popularity of JWT =
is growing fast along with the implementations, so
>> we need to d=
o something quickly.
>>
>> Thanks,
>> Oleg.
&=
gt;>
>>
>> --- On *Wed, 2/27/13, IETF Secretariat /<=
;ietf-ipr@ietf.org>/* wrote:
>>
>>
>=
;>     From: IETF Secretariat <ietf-ipr@=
ietf.org>
>>     Subject: [OAUTH-WG] IP=
R Disclosure: Certicom Corporation's Statement
>>   &nbs=
p; about IPR related to draft-ietf-oauth-json-web-token-06 (2)
>=
>     To: mbj@microsoft.com, ve7jtb@ve7jtb.com, n-sakimura@nri.co.jp
>>=
;     Cc: derek@ihtfp.com, oauth@ietf.org, ipr-announce@ietf.org
>>   &nbs=
p; Date: Wednesday, February 27, 2013, 4:16 PM
>>
>>=

>>     Dear Michael Jones, John Bradley, Nat =
Sakimura:
>>
>>     An IPR disclosure=
 that pertains to your Internet-Draft entitled
>>   &nbs=
p; "JSON Web
 Token
>>     (JWT)" (draft-ietf-oauth-json-we=
b-token) was submitted to the IETF
>>     Secr=
etariat
>>     on 2013-02-20 and has been post=
ed on the "IETF Page of Intellectual
>>     Pr=
operty
>>     Rights Disclosures" (https://datatrack=
er.ietf.org/ipr/1968/). The
>>     title o=
f the
>>     IPR disclosure is "Certicom Corpo=
ration's Statement about IPR
>>     related to=
 draft-
>>     ietf-oauth-json-web-token-06 (2=
)."");
>>
>>     The IETF Secretariat=

>>
>>     __________________________=
_____________________
>>     OAuth mailing
 list
>>     OAuth@ietf.org </mc/com=
pose?to=3DOAuth@ietf.org>
>>     http=
s://www.ietf.org/mailman/listinfo/oauth
>>
>>
>=
>
>> _______________________________________________
>>=
; OAuth mailing list
>> OAuth@ietf.org
>> https://=
www.ietf.org/mailman/listinfo/oauth
>>
> _______________=
________________________________
> OAuth mailing list
> OAut=
h@ietf.org
> htt=
ps://www.ietf.org/mailman/listinfo/oauth

_______________________=
________________________
OAuth mailing list
OAuth@ietf.org
=
h=
ttps://www.ietf.org/mailman/listinfo/oauth

--1694620066-184547543-1362097577=:15771--

From oleg_gryb@yahoo.com  Thu Feb 28 17:45:51 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349B421F8824 for ; Thu, 28 Feb 2013 17:45:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iuw6m0hQFpM for ; Thu, 28 Feb 2013 17:45:50 -0800 (PST)
Received: from nm22.bullet.mail.bf1.yahoo.com (nm22.bullet.mail.bf1.yahoo.com [98.139.212.181]) by ietfa.amsl.com (Postfix) with ESMTP id E0A9D21F8802 for ; Thu, 28 Feb 2013 17:45:49 -0800 (PST)
Received: from [98.139.212.153] by nm22.bullet.mail.bf1.yahoo.com with NNFMP; 01 Mar 2013 01:45:49 -0000
Received: from [98.139.212.233] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 01 Mar 2013 01:45:49 -0000
Received: from [127.0.0.1] by omp1042.mail.bf1.yahoo.com with NNFMP; 01 Mar 2013 01:45:49 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 242381.11219.bm@omp1042.mail.bf1.yahoo.com
Received: (qmail 44557 invoked by uid 60001); 1 Mar 2013 01:45:49 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1362102349; bh=b6IrXova/1HYfpj5ortLy+lD6RaLOmUR+IARX079lCM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=tNO6DPiA0XeqLRxdy8ejPZwqDWgghJHw6m7xkZTvkjhZNwyowDmQMvhJ1M3YOpfWo3+WjP1j+pr+HDsfcruAZylgzumRapejks6RobbtvjzEf015/PID98QIqgwwDLwf7EsTAO2GiHBSq1HGpDIyuIWq0SN3Ju8fugzhv+bCw4Y=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=2/9BnU7hhqzXMnKlp/iFfOIiMqhl7nh3GoHPxVXuUOBBA25zUTyxxKp3pKKziEAY4XslTo5EMFiBpwZ3VYadIF4nFCZDXnXX4iKss8lY5s3kU7Ac+w0UhdHWZ+va6RlpRETJD3MUmiVxSEstzmXCoNiq8IyRC42YRtVBpWtzC4I=;
X-YMail-OSG: nEb0DIMVM1k9hjo4GlPQwVtDQ6M10IeiN8FhsvZZ9EQkK_k pwEUD8nXEZp5pkvOCEpoZnMq.cgRRKCa9iL5dP29.sdrA107Db6ulGTvg9MG 8AhLWlpirelwA7Mee9_Dj19vN2UP2RO8FMv_R9APSMbPswOdBnbU84x3v6t3 HiTPsWnFVTG_8tqqxyN924M9L2OqrPrGyK_nerUulewViUwNcKdXM7yIejhK 55agan4wcIFLO5jUv4BLLsFa0VUxaYfuVILotbDcEIHkTEGg52dhpgmqnG0C XJklJzVxOOY3Q2XrYn6EXQ5SmoWbv0qkWis6mU..W50yHn4j4mSVwtOeIlh8 yII3q8MsT2b7iH8YTR2gwdghD80pN0.0nWsuBcXEmR5fNqgBQq3m3YZMK5La KU7CN_FyGHPX5Z0vs9z3aeGrOiapjxmwGTaOloS8gGbZeJSFzvYo2c8WKW6X a2x7s8VquAu3bZwHjHdH.utgSeUUmjtN6CwdDItIIYhFyVLKyrZ5y0shS6oS 4tl34fnx1Xx7SihmycI0MNGtggrfpQ0Uth24jC0uKDt2jUXIMbNn6Dq7hQLf rDdRDiAZ69IyhJ2lEwNbUAM9e4NPiIkVrXxrHQXm0_4tQ1tJ9T30hsS3y8zs dVpMBO2aQ.NdLxRnygxj_Nh50eDHEjiu3oLA4xgp91aAgGSXrDdkd_ulHHNp YbHBjglO_2kOoLpgtcjaRxOyEMUwg9ObRePNeLP3iFt31YhyCSyifKabDtdE klp97dhJneiiCTzZsn_oc3vVvlDeCnvBwLSE1VxaMZ6qteb6mvaepUbaAjxS JpeGRX35q5nJTd7_CoSQU
Received: from [199.16.140.28] by web141001.mail.bf1.yahoo.com via HTTP; Thu, 28 Feb 2013 17:45:48 PST
X-Rocket-MIMEInfo: 001.001, SSBkb24ndCBsaWtlIHRoYXQgImltcGxpY2l0IGZsb3ciIG9yIGZvcm1lciB1c2VyLWFnZW50IG11Y2ggYW5kIHdyb3RlIGFib3V0IGl0IDIgeWVhcnMgYWdvLCBidXQgdGhhdCBhdHRhY2sgaXMgcmF0aGVyIHJlbGF0ZWQgdG8gaW1wbGVtZW50YXRpb24gYnVncywgbm90IHRvIHByb3RvY29sIGl0c2VsZi4gQSByb290IGNhdXNlIC0gYSBidWcgaW4gcmVkaXJlY3QgVVJMIHZlcmlmaWNhdGlvbiAocHJvYmFibHnCoCBhIHJlZ2V4cCBmbGF3KS4NCg0KRW5mb3JjaW5nIHRva2VuJ3MgbGlmZSB0aW1lIGF0IGEgcHIBMAEBAQE-
X-Mailer: YahooMailClassic/15.1.4 YahooMailWebService/0.8.135.514
Message-ID: <1362102348.20747.YahooMailClassic@web141001.mail.bf1.yahoo.com>
Date: Thu, 28 Feb 2013 17:45:48 -0800 (PST)
From: Oleg Gryb 
To: "oauth@ietf.org" , prateek mishra 
In-Reply-To: <512FE091.9030508@oracle.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="1278998794-1153535670-1362102348=:20747"
Subject: Re: [OAUTH-WG] OAuth2 attack surface....
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: oleg@gryb.info
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Mar 2013 01:45:51 -0000

--1278998794-1153535670-1362102348=:20747
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I don't like that "implicit flow" or former user-agent much and wrote about=
 it 2 years ago, but that attack is rather related to implementation bugs, =
not to protocol itself. A root cause - a bug in redirect URL verification (=
probably=A0 a regexp flaw).

Enforcing token's life time at a protocol level doesn't make too much sense=
 either, because it should depend on sensitivity of protected data.=20

The same is true about the scope.

I think, the latter two issues have been already reflected in the Torsten's=
 TM.

--- On Thu, 2/28/13, prateek mishra  wrote:

From: prateek mishra 
Subject: Re: [OAUTH-WG] OAuth2 attack surface....
To: "oauth@ietf.org" 
Date: Thursday, February 28, 2013, 5:56 PM

=0A  =0A=0A    =0A  =0A  =0A    Characteristics of both these attacks -
=0A   =20
=0A    1) Use of implicit flow (access token passed on the URL)
=0A    2) changes to redirect uri (specification does allow some=0A    flex=
ibility here)
=0A    3) applications with long-lived access tokens with broad scope (in=
=0A    one case only)
=0A   =20
=0A    - prateek
=0A    And a different one (still exploiting redirection and=0A      still =
implementation mistake)=A0http://www.nirgoldshlager.com/2013/02/how-i-hacke=
d-facebook-oauth-to-get-full.html=0A     =20
=0A      =0A      Regards=0A     =20
=0A      =0A      Antonio=0A     =20
=0A      =0A      =0A        =0A          On Feb 25, 2013, at 11:42 PM, Wil=
liam Mills wrote:=0A         =20
=0A          =0A            =0A              =0A               =20
=0A                =0A                =0A                  =0A             =
        =0A                   =20
=0A                    =0A                      =0A                        =
=0A                          DOH!!! =A0http://homakov.blogspot.co.uk/2013/0=
2/hacking-facebook-with-oauth2-and-chrome.html=0A                         =
=20
=0A                          =0A                          =0A              =
              =0A                               =0A                        =
           From:=0A                                  Phil Hunt 
=0A                                  To:=0A                                =
  William Mills =0A                                =
 =20
=0A                                  Sent:=0A                              =
    Monday, February 25, 2013 2:28 PM
=0A                                  Subject:=0A                           =
       Re: [OAUTH-WG] OAuth2 attack=0A                                  sur=
face....
=0A                                 =0A                             =20
=0A                              =0A                                =0A    =
                              Whats the link?
=0A                                   =20
=0A                                    Phil=0A                             =
      =20
=0A                                    =0A                                 =
   Sent from my phone.=0A                                  =0A             =
                    =20
=0A                                    On 2013-02-25, at 14:22, William=0A =
                                   Mills =0A       =
                             wrote:
=0A                                   =20
=0A                                  =0A                                  =
=0A                                    =0A                                 =
     =0A                                        I think this is worth a=0A =
                                         read, I don't have time to=0A     =
                                     dive into this :(=0A                  =
                    =0A                                    =0A             =
                     =0A                                  =0A              =
                      _______________________________________________
=0A                                      OAuth mailing list
=0A                                      OAuth@ietf.org
=0A                                      https://www.ietf.org/mailman/listi=
nfo/oauth
=0A                                    =0A                                 =
 =0A                                =0A                              =0A   =
                          =20
=0A                             =20
=0A                            =0A                          =0A            =
            =0A                      =0A                    =0A            =
       =20
=0A                   =20
=0A                  =0A                =0A              =0A            =0A=
            _______________________________________________
=0A            OAuth mailing list
=0A            OAuth@ietf.org
=0A            https://www.ietf.org/mailman/listinfo/oauth
=0A          =0A        =0A       =20
=0A      =0A     =20
=0A      =0A     =20
=0A      _______________________________________________=0AOAuth mailing li=
st=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth=0A=0A    =
=0A   =20
=0A  =0A=0A
-----Inline Attachment Follows-----

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--1278998794-1153535670-1362102348=:20747
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I don't like that "implicit flow" or former u=
ser-agent much and wrote about it 2 years ago, but that attack is rather re=
lated to implementation bugs, not to protocol itself. A root cause - a bug =
in redirect URL verification (probably  a regexp flaw).

Enforci=
ng token's life time at a protocol level doesn't make too much sense either=
, because it should depend on sensitivity of protected data. 

The sa=
me is true about the scope.

I think, the latter two issues have been=
 already reflected in the Torsten's TM.

--- On Thu, 2/=
28/13, prateek mishra <prateek.mishra@oracle.com> wrote:
From: prateek mishra <prateek.mishra@orac=
le.com>
Subject: Re: [OAUTH-WG] OAuth2 attack surface....
To:
 "oauth@ietf.org" <oauth@ietf.org>
Date: Thursday, February 28, 20=
13, 5:56 PM

=0A  =0A=0A    =0A  =0A  =
=0A    Characteristics of both these attacks -
=0A    
=0A    1) Use =
of implicit flow (access token passed on the URL)
=0A    2) changes to r=
edirect uri (specification does allow some=0A    flexibility here)
=0A  =
  3) applications with long-lived access tokens with broad scope (in=0A    =
one case only)
=0A    
=0A    - prateek
=0A    And a different one (still exploiting redirection and=0A      still =
implementation mistake) http://www.nirgoldshlager.com/2013/02/how-i-hacked-facebook-oauth-=
to-get-full.html=0A      
=0A      
=0A      Regards<=
/div>=0A      
=0A      
=0A      Antonio=0A      <=
div>
=0A      
=0A      =0A        =0A          On F=
eb 25, 2013, at 11:42 PM, William Mills wrote:
=0A          
=0A          =0A            =0A              =0A                
=0A                =0A                =0A                  =0A                     =0A =

=0A                    =0A=
                      =0A                        =0A                =
          DOH!!!  http://homakov.blogspot.co.u=
k/2013/02/hacking-facebook-with-oauth2-and-chrome.html=0A        =

=0A                          =0A          =
                =0A                            =0A                               =0A                                  
 From:=0A                        =
          Phil Hunt <p=
hil.hunt@oracle.com>
=0A                                  To:=0A                            =
      William Mills <wmills_92105@yahoo.com>=0A                                  
=
=0A                                  S=
ent:=0A                                  Monday, February 25, 20=
13 2:28 PM
=0A                                  Subject:=0A                                  Re: [O=
AUTH-WG] OAuth2 attack=0A                                  surface....
=
=0A                                 =0A                       =

=0A                              =0A  =
                              =0A                                  Whats the link?
=0A                                    
=0A        =
                            Phil=0A                                    
=0A                                    =0A                      =
              Sent from my phone.=0A                            =

=0A                                  
=0A              =
                      On 2013-02-25, at 14:22, William=0A                  =
                  Mills <wmills_92105@yahoo.com>=0A                                   =
 wrote:
=0A                                    
=0A                  =

=0A                                  =0A                                    =0A                  =
                    =0A                                        <=
div>I think this is worth a=0A                                          rea=
d, I don't have time to=0A                                          dive in=
to this :(
=0A                                      =0A         =

=0A                                  =0A                                  =0A =
                                   _____________________________=
__________________
=0A                                      OAuth mailing list
=0A                                      OAuth@ietf.org
=0A   =
                                   https://www.ietf.o=
rg/mailman/listinfo/oauth
=0A                                =

=0A                                  =0A            =

=0A                              =0A       =

=0A                              
=0A        =

=0A                          =0A           =

=0A                      
=0A                    =0A                    
=0A                    
=0A              =

=0A                
=0A              
=0A            =0A            _______________________________________________
=0A  =
          OAuth mailing list
=0A            OAuth@ietf.org
=0A            https://www.ietf.org/mailman/listinfo/o=
auth
=0A          
=0A        
=0A        
=0A  =

=0A      
=0A      
=0A      
=0A      __________________________=
_____________________=0AOAuth mailing list=0AOAuth@ietf.org=
=0Ahttps://ww=
w.ietf.org/mailman/listinfo/oauth=0A
=0A    
=0A    =0A  
=0A=0A

-----Inline Attachment Follows-----

_______________________________________________
OA=
uth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/li=
stinfo/oauth

--1278998794-1153535670-1362102348=:20747--

From Michael.Jones@microsoft.com  Thu Feb 28 18:34:09 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F12021F884F for ; Thu, 28 Feb 2013 18:34:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.587
X-Spam-Level: 
X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIHMlX6DsWya for ; Thu, 28 Feb 2013 18:34:08 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id 4081921F8858 for ; Thu, 28 Feb 2013 18:34:08 -0800 (PST)
Received: from BY2FFO11FD006.protection.gbl (10.1.15.201) by BY2FFO11HUB039.protection.gbl (10.1.14.122) with Microsoft SMTP Server (TLS) id 15.0.620.12; Fri, 1 Mar 2013 02:34:05 +0000
Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD006.mail.protection.outlook.com (10.1.14.127) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Fri, 1 Mar 2013 02:34:05 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Fri, 1 Mar 2013 02:33:34 +0000
From: Mike Jones 
To: prateek mishra , Hannes Tschofenig 
Thread-Topic: [OAUTH-WG] Fw:  IPR Disclosure: - What to Do with JWT ?
Thread-Index: AQHOFejVUFJvFi9ZK06BAjjJMvlNTZiPy5oAgAAEkoCAAE2soA==
Date: Fri, 1 Mar 2013 02:33:33 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943674C7198@TK5EX14MBXC283.redmond.corp.microsoft.com>
References: <1362079266.8952.YahooMailClassic@web141002.mail.bf1.yahoo.com> <512FCDF0.6010807@gmx.net> <512FD1C5.2070100@oracle.com>
In-Reply-To: <512FD1C5.2070100@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.36]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(164054002)(13464002)(189002)(479174001)(24454001)(199002)(51704002)(377424002)(377454001)(56816002)(76482001)(54356001)(15202345001)(23726001)(47736001)(20776003)(33656001)(54316002)(77982001)(5343655001)(46406002)(44976002)(47976001)(5343635001)(74662001)(4396001)(63696002)(47776003)(55846006)(16406001)(50466001)(79102001)(65816001)(66066001)(50986001)(47446002)(74502001)(46102001)(80022001)(51856001)(53806001)(56776001)(31966008)(49866001)(59766001)(16940595002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB039; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0772E5DAD5
Cc: "oleg@gryb.info" , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Fw:  IPR Disclosure: - What to Do with JWT ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Mar 2013 02:34:09 -0000

With the caveat that I have not read the patent disclosures, I will add tha=
t if they pertain to Elliptic Curve Cryptography, RFC 6090 is likely releva=
nt - especially http://tools.ietf.org/html/rfc6090#section-7.1 on ECDH and =
http://tools.ietf.org/html/rfc6090#section-7.2 on ECDSA.

				-- Mike

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of p=
rateek mishra
Sent: Thursday, February 28, 2013 1:53 PM
To: Hannes Tschofenig
Cc: oleg@gryb.info; oauth@ietf.org
Subject: Re: [OAUTH-WG] Fw: IPR Disclosure: - What to Do with JWT ?

Two points  -

1) I request that this mailing list NOT be used for any substantive discuss=
ion of patent claims and so on. This will create difficulties for many part=
icipants and I dont believe is within the charter of this effort.

2) I would encourage interested parties to review the following document, w=
hich may be relevant to this discussion

http://www.w3.org/2011/xmlsec-pag/

- prateek

> Hi Oleg,
>
> my personal experience with Certicom's IPR disclosures is that they=20
> focus on Elliptic Curve Cryptography. There were several IPR=20
> disclosures on documents in the JOSE WG and some of them contain ECC=20
> algorithms.
>
> The JWT does not list an ECC algorithm but the referenced documents do.
>
> Having said that the two cited IPRs seem to be:
> http://www.google.com/patents/US6704870
> http://www.google.com/patents/US7215773
>
> Take a look at it and make your assessment whether there is anything=20
> we can change.
>
> Ciao
> Hannes
>
>
> On 02/28/2013 09:21 PM, Oleg Gryb wrote:
>> Dear OAuth WG and Chairs,
>>
>> Can somebody please comment the Certicom's disclosure below? If the=20
>> purpose of this disclosure is to inform us that JWT can be=20
>> potentially a subject of royalties and other possible legal actions,=20
>> the value of adopting JWT in the scope of OAuth 2.0 IETF standard=20
>> would definitely diminish and if this is the case shouldn't we=20
>> consider replacing it with something similar, but different, which=20
>> would not be a subject of the future possible litigation?
>>
>> I'm not a lawyer and might not understand the statement below=20
>> correctly, so please let me know if/where I'm wrong. Please keep in=20
>> mind also that the popularity of JWT is growing fast along with the=20
>> implementations, so we need to do something quickly.
>>
>> Thanks,
>> Oleg.
>>
>>
>> --- On *Wed, 2/27/13, IETF Secretariat //* wrote:
>>
>>
>>     From: IETF Secretariat 
>>     Subject: [OAUTH-WG] IPR Disclosure: Certicom Corporation's Statement
>>     about IPR related to draft-ietf-oauth-json-web-token-06 (2)
>>     To: mbj@microsoft.com, ve7jtb@ve7jtb.com, n-sakimura@nri.co.jp
>>     Cc: derek@ihtfp.com, oauth@ietf.org, ipr-announce@ietf.org
>>     Date: Wednesday, February 27, 2013, 4:16 PM
>>
>>
>>     Dear Michael Jones, John Bradley, Nat Sakimura:
>>
>>     An IPR disclosure that pertains to your Internet-Draft entitled
>>     "JSON Web Token
>>     (JWT)" (draft-ietf-oauth-json-web-token) was submitted to the IETF
>>     Secretariat
>>     on 2013-02-20 and has been posted on the "IETF Page of Intellectual
>>     Property
>>     Rights Disclosures" (https://datatracker.ietf.org/ipr/1968/). The
>>     title of the
>>     IPR disclosure is "Certicom Corporation's Statement about IPR
>>     related to draft-
>>     ietf-oauth-json-web-token-06 (2)."");
>>
>>     The IETF Secretariat
>>
>>     _______________________________________________
>>     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

From ve7jtb@ve7jtb.com  Thu Feb 28 19:21:51 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC32421F8697 for ; Thu, 28 Feb 2013 19:21:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.462
X-Spam-Level: 
X-Spam-Status: No, score=-3.462 tagged_above=-999 required=5 tests=[AWL=0.136,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rLKdmwao6vp for ; Thu, 28 Feb 2013 19:21:50 -0800 (PST)
Received: from mail-da0-f43.google.com (mail-da0-f43.google.com [209.85.210.43]) by ietfa.amsl.com (Postfix) with ESMTP id 89DD521F8585 for ; Thu, 28 Feb 2013 19:21:50 -0800 (PST)
Received: by mail-da0-f43.google.com with SMTP id u36so1176797dak.30 for ; Thu, 28 Feb 2013 19:21:50 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=DYeAdJ7gr4xMt1Hke3hILEW2bDGMBQldRSN9qwg0kGA=; b=Wc7eENp+mvQyrm/CbO0QIayKvC0s0UQj+s0H638r86rwr+Bs0Fdg7BJSGEzXNivgSk Ad6ApynI1qpd7scqAvSiEVg19HIUTy5KvVOrr2TlStpmMrM/05NILJvu83wak/v3fJbg nqEOyI1D+e1IWi6r3iRg9NNyr3yPU8JgsfpkuKCbCI2BnwTSATUU2q6txrkPvCkynKER MpsvQwsRnsrrb4wwn/38X6IrpRwz7s72bAy/PZvNizOvzzeEQj6HfKohaqQaQylEjUIL 3jKYW78sfVy24p11gIZ/5Jjh0OONNfaCLtGrOW+XR6ANwLKAIHBixEUO7XLGjkzC3RCz ILKQ==
X-Received: by 10.68.211.37 with SMTP id mz5mr12723543pbc.83.1362108110115; Thu, 28 Feb 2013 19:21:50 -0800 (PST)
Received: from [192.168.6.157] (ip-64-134-220-138.public.wayport.net. [64.134.220.138]) by mx.google.com with ESMTPS id gf6sm10397395pbc.24.2013.02.28.19.21.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Feb 2013 19:21:48 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_072EFAA3-E14E-4AE9-B852-EC14BEECF043"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <512FE091.9030508@oracle.com>
Date: Thu, 28 Feb 2013 19:21:45 -0800
Message-Id: <9C445AAF-BEE8-44F5-8FE6-43CA843906CC@ve7jtb.com>
References: <1361830944.13340.YahooMailNeo@web31812.mail.mud.yahoo.com>  <1361831644.50183.YahooMailNeo@web31801.mail.mud.yahoo.com> <1361832133.97884.YahooMailNeo@web31816.mail.mud.yahoo.com> <140EEABC-2787-4D9A-A1C5-6C973FED5BC8@adobe.com> <512FE091.9030508@oracle.com>
To: prateek mishra 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQk/uoIuUKCrzZwdQ01HwhMDHe1wgG4JAzr2aPEI7qRJ9knHWYW5r5SvE1s892ibypdJX1f4
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] OAuth2 attack surface....
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Mar 2013 03:21:52 -0000

--Apple-Mail=_072EFAA3-E14E-4AE9-B852-EC14BEECF043
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_AF284984-FE44-492D-A6BB-C321A4685BA1"

--Apple-Mail=_AF284984-FE44-492D-A6BB-C321A4685BA1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

While implicit is what they are attacking, this is in principal also =
possible to do with a code flow if the client is public.
It is only confidential clients using the code flow that have reasonable =
protection from open redirectors.

In openID Connect we made registered redirect_uri and full comparison of =
the URI including query parameters a requirement.

Allowing path or query parameters outside of the redirect comparison =
leaves too large of an uncontrolled attack surface.

Implementation mistakes are almost inevitable.=20

John B.
On 2013-02-28, at 2:56 PM, prateek mishra  =
wrote:

> Characteristics of both these attacks -
>=20
> 1) Use of implicit flow (access token passed on the URL)
> 2) changes to redirect uri (specification does allow some flexibility =
here)
> 3) applications with long-lived access tokens with broad scope (in one =
case only)
>=20
> - prateek
>> And a different one (still exploiting redirection and still =
implementation mistake) =
http://www.nirgoldshlager.com/2013/02/how-i-hacked-facebook-oauth-to-get-f=
ull.html
>>=20
>> Regards
>>=20
>> Antonio
>>=20
>> On Feb 25, 2013, at 11:42 PM, William Mills wrote:
>>=20
>>>=20
>>>=20
>>> DOH!!!  =
http://homakov.blogspot.co.uk/2013/02/hacking-facebook-with-oauth2-and-chr=
ome.html
>>>=20
>>> From: Phil Hunt 
>>> To: William Mills =20
>>> Sent: Monday, February 25, 2013 2:28 PM
>>> Subject: Re: [OAUTH-WG] OAuth2 attack surface....
>>>=20
>>> Whats the link?
>>>=20
>>> Phil
>>>=20
>>> Sent from my phone.
>>>=20
>>> On 2013-02-25, at 14:22, William Mills  =
wrote:
>>>=20
>>>> I think this is worth a read, I don't have time to dive into this =
:(
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail=_AF284984-FE44-492D-A6BB-C321A4685BA1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

While =
implicit is what they are attacking, this is in principal also possible =
to do with a code flow if the client is public.It is only =
confidential clients using the code flow that have reasonable protection =
from open redirectors.

In openID Connect we =
made registered redirect_uri and full comparison of the URI including =
query parameters a requirement.

Allowing path =
or query parameters outside of the redirect comparison leaves too large =
of an uncontrolled attack =
surface.

Implementation mistakes are almost =
inevitable. 

John =
B.
On 2013-02-28, at 2:56 PM, prateek mishra <prateek.mishra@oracle.com>=
; wrote:

 =20

 =20

    Characteristics of both these attacks -

    1) Use of implicit flow (access token passed on the URL)

    2) changes to redirect uri (specification does allow some
    flexibility here)

    3) applications with long-lived access tokens with broad scope (in
    one case only)

    - prateek

    And a different one (still exploiting redirection and
      still implementation mistake) http://www.nirgoldshlager.com/2013/02/how-i-hacked-faceb=
ook-oauth-to-get-full.html

      Regards

      Antonio

          On Feb 25, 2013, at 11:42 PM, William Mills wrote:

                          DOH!!!  http://homakov.blogspot.co.uk/2013/02/hacking-fa=
cebook-with-oauth2-and-chrome.html

 From:
                                  Phil Hunt <phil.hunt@oracle.com>

                                  To:
                                  William Mills <wmills_92105@yahoo.com>

                                  Sent:
                                  Monday, February 25, 2013 2:28 PM

                                  Subject:
                                  Re: [OAUTH-WG] OAuth2 attack
                                  surface....

                                  Whats the link?

                                    Phil

                                    Sent from my phone.

                                    On 2013-02-25, at 14:22, William
                                    Mills <wmills_92105@yahoo.com>
                                    wrote:

                                        I think this is worth a
                                          read, I don't have time to
                                          dive into this :(

                                    =
_______________________________________________

                                      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

=

--Apple-Mail=_AF284984-FE44-492D-A6BB-C321A4685BA1--

--Apple-Mail=_072EFAA3-E14E-4AE9-B852-EC14BEECF043
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g
AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q
YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5
AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v
eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA
FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM
L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI
p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz
Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5
QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV
HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp
bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t
cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg
d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u
cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny
bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw
AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF
BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC
cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ
4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh
JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC
fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzAxMDMyMTQ2WjAjBgkqhkiG9w0BCQQxFgQUAyHqDXKM
JY2fY5rO+gBni/BmUwcwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAfVt6mp++YShEgW/iUzm67S7h3XAaQg6AQD8/ZYbn
zmnXnsEBJZcX9Rq7oR7ynQPkil0QgAaHu3CYHAyoY0wGGMc/4sLS2bSM3ppldyegcb4axO8DiGKO
2hpPXvVnzq+6RlcHt7+PGwXctrv02pxYAFBbjdO5WAM10E6OkPsEOFlnRMzy6OwKrL0cr2o80hgG
6pdOhkfCI92NioDG135uG0etg4wSqr2v6yj2axdDyGPMfHhMKCVstKMlmAQu40D9qy2mduUxopRY
rRdREeUx/gsQbvWxNShr6q7X839IGLqJpNMoj/B8HTU2teJ2PxfLrWEYDwb2BvCeraDwdvWL8QAA
AAAAAA==

--Apple-Mail=_072EFAA3-E14E-4AE9-B852-EC14BEECF043--

From oleg_gryb@yahoo.com  Thu Feb 28 20:15:57 2013
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD10821F87C5 for ; Thu, 28 Feb 2013 20:15:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJMaWdDPyRre for ; Thu, 28 Feb 2013 20:15:56 -0800 (PST)
Received: from nm13.bullet.mail.bf1.yahoo.com (nm13.bullet.mail.bf1.yahoo.com [98.139.212.172]) by ietfa.amsl.com (Postfix) with SMTP id 209E721F8749 for ; Thu, 28 Feb 2013 20:15:56 -0800 (PST)
Received: from [98.139.215.142] by nm13.bullet.mail.bf1.yahoo.com with NNFMP; 01 Mar 2013 04:15:55 -0000
Received: from [98.139.212.205] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 01 Mar 2013 04:15:54 -0000
Received: from [127.0.0.1] by omp1014.mail.bf1.yahoo.com with NNFMP; 01 Mar 2013 04:15:54 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 800365.93586.bm@omp1014.mail.bf1.yahoo.com
Received: (qmail 99765 invoked by uid 60001); 1 Mar 2013 04:15:54 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1362111354; bh=sRwvubH0sYFg8GzhVoOTJ86GVGyLU2yqqAx8NBuUAEg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=NEIqxecrJhyc/6GIQRyjkIpsyS7cKESfrs09TZjbLi4DoHMzGGFwF7/G1o1bMiX2it6rauU0j8wBleh/BGYvUe3sSArCflwe1nagRHi+/RHsM9QO9fmW2KJCLVg9NsarFh+P/UqHhsifjYvIEUCT/W6Vyq8AGM2wk57cMoNTGUU=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=26ndDkFfbO0mUeZ4CkVOW3C5VOvDTGLImtvzbL7iGsvftmzZgVH7XUOROBnjLOgXU3RnUaurvAPUgX13Uu9t8bXyfKNWgGtUbzOmQQJncRIlfxljuDLXal4UDQvbL1G4pPxk2gD/qt7uo8jGS4e0/qsvJGs4uZviI9yHjvbFHtY=;
X-YMail-OSG: cZxz2xEVM1nrUzAzZEJh2hj9W2UUcfXdfiPhGxfpAqikANT 2Eu.dNrnA1gWkei9ZOzGidYcSjbphQYggW3V_UYh0aTsZ.rEzN22qSRYGtT6 zt0RVHjT_lYE7_O64p99uj_CjYF.yLZCtAJ_GCtHHSMpzwuFp68l_lQVr7jO _2Yqheo_ZWQZMzICvzaco.jpQtOzcu1dqNtkx6eAwC8dmUwTMG9NQ2HlTvQo sr3i45pzz.ovojwE_hNU2VGYb8m2c8oTfjdruXbNiiKL0iD1Od4x0UTvrDTZ WhDccGLfqde5PUhPkMHf4ZOC5Qpn.hLSdM1K1Pb86c2q41J6_p0APHKJiR2G mC3o_7hTdaCVBLACUt818ZqusDJsVcyrCOVtutUwZbXFYmc_h6tdVFdsRyXJ zNM1KqGWXxIGlEANeJe3V.VMn_kQt_eJyLI16c8VRrmXMeM0UdjJGangby9m jhFGLS56SJcstCQMzE8QsObowlDoZVIRGmSedTRuUNlv_uMz.CWsOGcm8_rp VZ.gMF9ZBQqIXeeAW0YzfJa4oPIx7RyM36KgkQlsgdZ8uDhMLHUddNFTNDJK 3MjWOqANkF0QATUTRtgRIcpstMWBCti.Qfl33d0jPxNmwkPYczajWbpys3oa SSVrKgCuWH6pNVSkWTJ85GRy_i32df0I1BfgfWqs7p1TpjA--
Received: from [67.116.255.151] by web141004.mail.bf1.yahoo.com via HTTP; Thu, 28 Feb 2013 20:15:54 PST
X-Rocket-MIMEInfo: 001.001, TWlrZSBhbmQgSGFubmVzLA0KDQpUaGFua3MuIFZlcnkgdXNlZnVsIGluZm8gdGhhdCBuZWVkcyB0byBiZSBleHBsb3JlZCBmdXJ0aGVyLiBJIGFjdHVhbGx5IGxpa2UgdGhlIFczQyBhcHByb2FjaCB0byB0aGUgc2ltaWxhciBwcm9ibGVtLiBJdCdzIGRlc2NyaWJlZCBoZXJlOiBodHRwOi8vd3d3LnczLm9yZy8yMDExL3htbHNlYy1wYWcvcGFncmVwb3J0Lmh0bWwgDQoNCjEuIFRoZXkndmUgY3JlYXRlZCBQQUcuDQoyLiBDb250YWN0ZWQgdGhlIHBhdGVudCBob2xkZXIuIA0KMy4gUmV2aWV3ZWQgcGF0ZW50IGgBMAEBAQE-
X-Mailer: YahooMailClassic/15.1.4 YahooMailWebService/0.8.135.514
Message-ID: <1362111354.59175.YahooMailClassic@web141004.mail.bf1.yahoo.com>
Date: Thu, 28 Feb 2013 20:15:54 -0800 (PST)
From: Oleg Gryb 
To: prateek mishra , Hannes Tschofenig , Mike Jones 
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943674C7198@TK5EX14MBXC283.redmond.corp.microsoft.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-262101065-859756872-1362111354=:59175"
Cc: "oleg@gryb.info" , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Fw:  IPR Disclosure: - What to Do with JWT ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: oleg@gryb.info
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Mar 2013 04:15:57 -0000

---262101065-859756872-1362111354=:59175
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Mike and Hannes,

Thanks. Very useful info that needs to be explored further. I actually like=
 the W3C approach to the similar problem. It's described here: http://www.w=
3.org/2011/xmlsec-pag/pagreport.html=20

1. They've created PAG.
2. Contacted the patent holder.=20
3. Reviewed patent holder's proposal and rejected it as the one that doesn'=
t meet W3C standards.
4. Created recommendations for the standard implementers, which is very imp=
ortant in my view.
5. Announced a decision that the work on the standard should go on.

Can we expect this kind of engagement from IETF and OAuth-WG or are we on o=
ur own and should do our own research as has been suggested below?

--- On Thu, 2/28/13, Mike Jones  wrote:

From: Mike Jones 
Subject: Re: [OAUTH-WG] Fw:  IPR Disclosure: - What to Do with JWT ?
To: "prateek mishra" , "Hannes Tschofenig" 
Cc: "oleg@gryb.info" , "oauth@ietf.org" 
Date: Thursday, February 28, 2013, 9:33 PM

With the caveat that I have not read the patent disclosures, I will add tha=
t if they pertain to Elliptic Curve Cryptography, RFC 6090 is likely releva=
nt - especially http://tools.ietf.org/html/rfc6090#section-7.1 on ECDH and =
http://tools.ietf.org/html/rfc6090#section-7.2 on ECDSA.

=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 -- Mike

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of p=
rateek mishra
Sent: Thursday, February 28, 2013 1:53 PM
To: Hannes Tschofenig
Cc: oleg@gryb.info; oauth@ietf.org
Subject: Re: [OAUTH-WG] Fw: IPR Disclosure: - What to Do with JWT ?

Two points=A0 -

1) I request that this mailing list NOT be used for any substantive discuss=
ion of patent claims and so on. This will create difficulties for many part=
icipants and I dont believe is within the charter of this effort.

2) I would encourage interested parties to review the following document, w=
hich may be relevant to this discussion

http://www.w3.org/2011/xmlsec-pag/

- prateek

> Hi Oleg,
>
> my personal experience with Certicom's IPR disclosures is that they=20
> focus on Elliptic Curve Cryptography. There were several IPR=20
> disclosures on documents in the JOSE WG and some of them contain ECC=20
> algorithms.
>
> The JWT does not list an ECC algorithm but the referenced documents do.
>
> Having said that the two cited IPRs seem to be:
> http://www.google.com/patents/US6704870
> http://www.google.com/patents/US7215773
>
> Take a look at it and make your assessment whether there is anything=20
> we can change.
>
> Ciao
> Hannes
>
>
> On 02/28/2013 09:21 PM, Oleg Gryb wrote:
>> Dear OAuth WG and Chairs,
>>
>> Can somebody please comment the Certicom's disclosure below? If the=20
>> purpose of this disclosure is to inform us that JWT can be=20
>> potentially a subject of royalties and other possible legal actions,=20
>> the value of adopting JWT in the scope of OAuth 2.0 IETF standard=20
>> would definitely diminish and if this is the case shouldn't we=20
>> consider replacing it with something similar, but different, which=20
>> would not be a subject of the future possible litigation?
>>
>> I'm not a lawyer and might not understand the statement below=20
>> correctly, so please let me know if/where I'm wrong. Please keep in=20
>> mind also that the popularity of JWT is growing fast along with the=20
>> implementations, so we need to do something quickly.
>>
>> Thanks,
>> Oleg.
>>
>>
>> --- On *Wed, 2/27/13, IETF Secretariat //* wrote:
>>
>>
>>=A0 =A0=A0=A0From: IETF Secretariat 
>>=A0 =A0=A0=A0Subject: [OAUTH-WG] IPR Disclosure: Certicom Corporation's S=
tatement
>>=A0 =A0=A0=A0about IPR related to draft-ietf-oauth-json-web-token-06 (2)
>>=A0 =A0=A0=A0To: mbj@microsoft.com, ve7jtb@ve7jtb.com, n-sakimura@nri.co.=
jp
>>=A0 =A0=A0=A0Cc: derek@ihtfp.com, oauth@ietf.org, ipr-announce@ietf.org
>>=A0 =A0=A0=A0Date: Wednesday, February 27, 2013, 4:16 PM
>>
>>
>>=A0 =A0=A0=A0Dear Michael Jones, John Bradley, Nat Sakimura:
>>
>>=A0 =A0=A0=A0An IPR disclosure that pertains to your Internet-Draft entit=
led
>>=A0 =A0=A0=A0"JSON Web Token
>>=A0 =A0=A0=A0(JWT)" (draft-ietf-oauth-json-web-token) was submitted to th=
e IETF
>>=A0 =A0=A0=A0Secretariat
>>=A0 =A0=A0=A0on 2013-02-20 and has been posted on the "IETF Page of Intel=
lectual
>>=A0 =A0=A0=A0Property
>>=A0 =A0=A0=A0Rights Disclosures" (https://datatracker.ietf.org/ipr/1968/)=
. The
>>=A0 =A0=A0=A0title of the
>>=A0 =A0=A0=A0IPR disclosure is "Certicom Corporation's Statement about IP=
R
>>=A0 =A0=A0=A0related to draft-
>>=A0 =A0=A0=A0ietf-oauth-json-web-token-06 (2)."");
>>
>>=A0 =A0=A0=A0The IETF Secretariat
>>
>>=A0 =A0=A0=A0_______________________________________________
>>=A0 =A0=A0=A0OAuth mailing list
>>=A0 =A0=A0=A0OAuth@ietf.org 
>>=A0 =A0=A0=A0https://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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

---262101065-859756872-1362111354=:59175
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Mike and Hannes,

Thanks. Very useful i=
nfo that needs to be explored further. I actually like the W3C approach to =
the similar problem. It's described here: http://www.w3.org/2011/xmlsec-pag=
/pagreport.html 

1. They've created PAG.
2. Contacted the patent =
holder. 
3. Reviewed patent holder's proposal and rejected it as the one=
 that doesn't meet W3C standards.
4. Created recommendations for the sta=
ndard implementers, which is very important in my view.
5. Announced a d=
ecision that the work on the standard should go on.

Can we expect th=
is kind of engagement from IETF and OAuth-WG or are we on our own and shoul=
d do our own research as has been suggested below?

--- On Thu, 2/28/13, Mike Jones <Michael.Jones@microsoft.com> wr=
ote:

From: Mike Jones <Michael.Jon=
es@microsoft.com>
Subject: Re: [OAUTH-WG] Fw:  IPR Disclosure: - What=
 to Do with JWT ?
To: "prateek mishra" <prateek.mishra@oracle.com>=
, "Hannes Tschofenig" <hannes.tschofenig@gmx.net>
Cc: "oleg@gryb.i=
nfo" <oleg@gryb.info>, "oauth@ietf.org" <oauth@ietf.org>
Dat=
e: Thursday, February 28, 2013, 9:33 PM

Wit=
h the caveat that I have not read the patent disclosures, I will add that i=
f they pertain to Elliptic Curve Cryptography, RFC 6090 is likely relevant =
- especially http://tools.ietf.org/html/rfc6090#section-7.1 on ECDH a=
nd http://tools.ietf.org/html/rfc6090#section-7.2 on ECDSA.

&n=
bsp;               -=
-
 Mike

-----Original Message-----
From: oauth-b=
ounces@ietf.org [mailto:oauth-bounces@ietf.org] =
On Behalf Of prateek mishra
Sent: Thursday, February 28, 2013 1:53 PMTo: Hannes Tschofenig
Cc: oleg@gryb.info; oauth@ietf.org<=
br>Subject: Re: [OAUTH-WG] Fw: IPR Disclosure: - What to Do with JWT ?
<=
br>Two points  -

1) I request that this mailing list NOT be use=
d for any substantive discussion of patent claims and so on. This will crea=
te difficulties for many participants and I dont believe is within the char=
ter of this effort.

2) I would encourage interested parties to revie=
w the following
 document, which may be relevant to this discussion

http://www.w3.org/2011/xml=
sec-pag/

- prateek

> Hi Oleg,
>
> my perso=
nal experience with Certicom's IPR disclosures is that they 
> focus =
on Elliptic Curve Cryptography. There were several IPR 
> disclosures=
 on documents in the JOSE WG and some of them contain ECC 
> algorith=
ms.
>
> The JWT does not list an ECC algorithm but the referenc=
ed documents do.
>
> Having said that the two cited IPRs seem t=
o be:
> http://www.google.com/patents/US6704870
> http://www.google.c=
om/patents/US7215773
>
> Take a look at it and make your as=
sessment whether there is anything 
> we can change.
>
>
 Ciao
> Hannes
>
>
> On 02/28/2013 09:21 PM, Oleg G=
ryb wrote:
>> Dear OAuth WG and Chairs,
>>
>> Ca=
n somebody please comment the Certicom's disclosure below? If the 
>&=
gt; purpose of this disclosure is to inform us that JWT can be 
>>=
 potentially a subject of royalties and other possible legal actions, 
&=
gt;> the value of adopting JWT in the scope of OAuth 2.0 IETF standard <=
br>>> would definitely diminish and if this is the case shouldn't we =

>> consider replacing it with something similar, but different, w=
hich 
>> would not be a subject of the future possible litigation?=

>>
>> I'm not a lawyer and might not understand the stat=
ement below 
>> correctly, so please let me know if/where I'm wron=
g. Please keep in 
>> mind also that the popularity of JWT is grow=
ing fast along with the 
>> implementations, so we need to
 do something quickly.
>>
>> Thanks,
>> Oleg.>>
>>
>> --- On *Wed, 2/27/13, IETF Secretariat /&=
lt;ietf-ipr@ietf.org>/* wrote:
>>
>>
&=
gt;>     From: IETF Secretariat <ietf-ip=
r@ietf.org>
>>     Subject: [OAUTH-WG] =
IPR Disclosure: Certicom Corporation's Statement
>>   &n=
bsp; about IPR related to draft-ietf-oauth-json-web-token-06 (2)
&g=
t;>     To: mbj@microsoft.com, ve7jtb@ve7jtb.com, n-sakimura@nri.co.jp>>     Cc: derek@ihtfp.com, oauth@i=
etf.org, ipr-announce@ietf.org
>>  &=
nbsp;  Date: Wednesday, February 27, 2013, 4:16 PM
>>>>
>>     Dear Michael Jones, John Brad=
ley, Nat Sakimura:
>>
>>     An IPR d=
isclosure that pertains to your Internet-Draft entitled
>>  &=
nbsp;  "JSON Web Token
>>     (JWT)"=
 (draft-ietf-oauth-json-web-token) was submitted to the IETF
>>&nb=
sp;    Secretariat
>>     on 20=
13-02-20 and has
 been posted on the "IETF Page of Intellectual
>>   &nbs=
p; Property
>>     Rights Disclosures" (<=
a href=3D"https://datatracker.ietf.org/ipr/1968/" target=3D"_blank">https:/=
/datatracker.ietf.org/ipr/1968/). The
>>    &nb=
sp;title of the
>>     IPR disclosure is "Cert=
icom Corporation's Statement about IPR
>>     =
related to draft-
>>     ietf-oauth-json-web-t=
oken-06 (2)."");
>>
>>     The IETF S=
ecretariat
>>
>>     ________________=
_______________________________
>>     OAuth m=
ailing list
>>     OAuth@ietf.org </=
mc/compose?to=3DOAuth@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/mail=
man/listinfo/oauth

_____________________________________________=
__
OAuth mailing
 list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oaut=
h
_______________________________________________
OAuth mailing l=
ist
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<=
/a>

---262101065-859756872-1362111354=:59175--

Utility	=E2=80=9CSmart Meter= s=E2=80=9D Installed
Pacific= Gas & Electric (PG&E)	4,696,000
San Die= go Gas & Electric (SDG&E)	1,364,000
Sou= thern California Edison (SCE)	3,900,000

Utility	=E2=80=9CSmart = Meters=E2=80=9D Installed
Pacific Gas = & Electric (PG&E)	4,696,000=
San Diego Gas = & Electric (SDG&E)	1,364,000=
Southern = California Edison (SCE)	3,900,000=

Utility	“Smart Meters” Installed
Pacific Gas & Electric (PG&E)	4,696,000
San Diego Gas & Electric (SDG&E)	1,364,000
Southern California Edison (SCE)	3,900,000

Utility	=E2=80=9CSmart = Meters=E2=80=9D Installed
Pacific Gas = & Electric (PG&E)	4,696,000=
San Diego Gas = & Electric (SDG&E)	1,364,000=
Southern = California Edison (SCE)	3,900,000=

Utility	=E2=80=9CSmart Meters=E2=80=9D Installed
Pacific Gas & Electric (PG&E) =	4,696,000
San Diego Gas & Electric (SDG&E)	1,364,000
Southern California Edison (SCE)	3,900,000

Subject:	New Version Notification for draft-richer-oauth-introspection-02.txt
Date:	Wed, 6 Feb 2013 11:24:20 -0800
From:	<internet-drafts@ietf.org>
To:	<jricher@mitre.org>

Subjec= t:	New Version Notification for draft-richer-oauth-introspection-02.txt
Date: =	Wed, 6 Feb 2013 11:24:20 -0800
From: =	<internet-drafts@ietf.org>
To:	<jricher@mitre.org>

Subject:	New Version Notification for = draft-richer-oauth-introspection-02.txt
Date:	Wed, 6 Feb 2013 11:24:20 = -0800
From:	<internet-drafts@ietf.org>
To:	<jricher@mitre.org>

Subject:	New Version = Notification for = draft-richer-oauth-introspection-02.txt
Date: =	Wed, 6 Feb 2013 11:24:20 = -0800
From:	<internet-drafts@ietf.org>
To: =	<jricher@mitre.org>

Subject:	New Version Notification for draft-richer-oauth-introspection-02.txt
Date:	Wed, 6 Feb 2013 11:24:20 -0800
From:	<internet-drafts@ietf.org>
To:	<jricher@mitre.org>

Subject: =	New Version Notification for draft-richer-oaut= h-introspection-02.txt
Date:	Wed, 6 Feb 2013 11:24:20 -0800=
From:	<int= ernet-drafts@ietf.org>
To: <= /p>	<jricher@mi= tre.org>

response_type value	grant_types=
code	authorization_code
token	implicit
id_token	implicit
token id_token=	implicit
code token	authorization_code implic= it
code id_token<= /span>	authorization_code implic= it
code token id_token<= /o:p>	authorization_code implic= it
none	none

response_type value	grant_types
code	authorization_code
token	implicit
id_token	implicit
token id_token	implicit
code token	authorization_code implicit
code id_token	authorization_code implicit
code token id_token	authorization_code implicit
none	none

JSON Web Token (JWT) Bearer Token = Profiles for OAuth 2.0

JSON Web Token (JWT) Bearer Token Profiles for OA= uth 2.0

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

JSON Web Token = (JWT) Bearer Token Profiles for OAuth = 2.0

JSON Web Token (JWT) Bearer Token = Profiles for OAuth 2.0

JSON Web Toke= n (JWT) Bearer Token Profiles for OAuth 2.0

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

JSON Web Token (JWT) Bearer Token Profiles = for OAuth 2.0

JSON Web Toke= n (JWT) Bearer Token Profiles for OAuth 2.0

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

JS= ON Web Token (JWT) Bearer Token Profiles for OAuth 2.0=

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

JSON Web Token (JWT) Bear= er Token Profiles for OAuth 2.0

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

JSON Web Token (JWT) Bearer Token Profiles for OAuth = 2.0

JSON Web Token (JWT) Bearer Token Profiles for OAuth = 2.0

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0

JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0