Re: [OAUTH-WG] [Ace] Call for adoption for draft-wahlstroem-ace-cbor-web-token-00

[Kepeng Li]

We got several supports and no objections, so it is concluded that the draft
is adopted as an ACE WG item, with the change that we remove the "web“ from
the name.

Authors: please resubmit the current draft as
draft-ietf-ace-cbor-token-00.txt; we will start processing further changes
in the WG process.(If you already know about technical issues, please use
the WG tracker for now; editorial issues might be tracked easier on github.)

We will also add this item in our ACE charter.

Kind Regards
Kepeng (ACE co-chair)

发件人:  Li Kepeng 
日期:  Thursday, 7 April, 2016 9:34 am
至:  "a...@ietf.org" 
抄送:  Kathleen Moriarty , Hannes
Tschofenig , , ,
Stephen Farrell 
主题:  [Ace] Call for adoption for draft-wahlstroem-ace-cbor-web-token-00

To: ACE WG
Cc: OAuth and COSE WG

Hello all,

This note begins a Call For Adoption for
draft-wahlstroem-ace-cbor-web-token-00 [1]
to be adopted as an ACE working group item, and added in the charter.
The call ends on April 22, 2016.

Keep in mind that adoption of a document does not mean the document
as-is is ready for publication. It is merely acceptance of the
document as a starting point for what will be the final product
of the ACE working group. The working group is free to make changes to
the document according to the normal consensus process.

Please reply on this thread with expressions of support or opposition,
preferably with comments, regarding accepting this as a work item.

Note that this email was also copied to OAuth and COSE WG, in order to
get input from wider audience.

Thanks,

Kind Regards
Kepeng (ACE co-chair)

[1] https://datatracker.ietf.org/doc/draft-wahlstroem-ace-cbor-web-token/

___ Ace mailing list
a...@ietf.org https://www.ietf.org/mailman/listinfo/ace

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

Re: [OAUTH-WG] Proof of Possession Tokens: Next Steps

[Kepeng Li]

> * to make a decision about other extensions. Nat and Kepeng submitted
> the Sender Constrained JWT for OAuth2 2.0 document, see
> https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-06
> We asked the working group for feedback during IETF #93 and we couldn't
> get enough feedback at that time. Please give us feedback whether you
> are interested in exploring that solution direction as part of this
> process. Today, we don't have enough indication of interest for working
> on that solution direction.


Yes, I am interested in this solution direction.

Sender Constrained JWT is already indicated in PoP architecture document
as one of the solutions.

If we don’t specify it in detail, the solution set is incomplete.

And there will be interoperability issues when people implement it in
different ways.

Kind Regards
Kepeng

在 19/1/16 7:45 pm， "Hannes Tschofenig"  写入:

>Hi all,
>
>I wanted to drop a high level message about possible next steps for the
>PoP work.
>
>As you have seen from my status update, see
>http://www.ietf.org/mail-archive/web/oauth/current/msg15327.html, the
>PoP architecture document was already in IESG processing but I have had
>asked Kathleen to delay the publication given that we ran into scoping
>issues, as discussed on the list. See
>http://www.ietf.org/mail-archive/web/oauth/current/msg15177.html
>
>The change of scope related to desire to not just binding a key to the
>access token but also to other parts of the OAuth system to avoid cases
>where an attacker can just obtain attack other parts of the system
>instead (for example, by obtaining an bearer-based refresh token to then
>obtain a new PoP access token).
>
>The recently discovered security problems tell us that we need to
>simplify our solutions a bit as well to ensure that we get the security
>analysed properly. More options means more time to analyse all the
>different options.
>
>What does this mean to simplify when I talk about expanding the scope in
>the earlier paragraph?
>
>I am suggesting to
>
>* to consider focusing on a public key-based only solution for the
>web/smart phone app space. (The ACE working group will have to develop a
>symmetric key-based version on their own, if desired.)
>
>* to extend the support of PoP token functionality throughout the entire
>solution. This means that we have to include support for a asymmetric
>version of PKCE into account (which had been discussed in the group
>already earlier already).
>
>* to define at least a TLS-based security security solution for the
>communication between the client and the resource server.
>
>* to rethink the work on the application layer security solution. The
>HTTP signing draft, which defines the application layer security
>solution for use between the client and the resource server, has expired
>and we will have to find new authors. I believe we got stuck a bit.
>Luckily new persons came along and volunteered to help, namely Fredrik
>Ljunggren and Jakob Schlyter. Nevertheless, the group will have to judge
>whether a newly developed application layer security solution is
>promising. My impression is that it is a very difficult to come up with
>a solution that satisfies the security requirements and, at the same
>time, also takes the deployment status of proxies and other middleware
>into account.
>
>* to make a decision about other extensions. Nat and Kepeng submitted
>the Sender Constrained JWT for OAuth2 2.0 document, see
>https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-06
>We asked the working group for feedback during IETF #93 and we couldn't
>get enough feedback at that time. Please give us feedback whether you
>are interested in exploring that solution direction as part of this
>process. Today, we don't have enough indication of interest for working
>on that solution direction.
>
>Before making any changes to the PoP document set we would like to hear
>your thoughts.
>
>Ciao
>Hannes
>
>___
>OAuth mailing list
>OAuth@ietf.org
>https://www.ietf.org/mailman/listinfo/oauth


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

Re: [OAUTH-WG] OAuth Recharting

[Kepeng Li]

Hi Hannes,

Thanks for putting this together.

>and specifications that mitigate security attacks, such as Proof Key for
>Code Exchange.


I propose to change it to:

and specifications that mitigate security attacks, such as Proof Key for
Code Exchange, and Sender Constraint JSON Web Token.


Sender Constaint JWT is mentioned in PoP architecture document, but it is
not 
specified in detail. That is why we provided a separate draft for that.


Thanks,

Kind Regards
Kepeng

在 17/12/15 11:59 pm， "Hannes Tschofenig"  写入:

>Hi all,
>
>at the last IETF meeting in Yokohama we had a rechartering discussion
>and below is proposed text for the new charter. Please take a look at it
>and tell me whether it appropriately covers the discussions from our
>last meeting.
>
>---
>
>Charter Text
>
>The Web Authorization (OAuth) protocol allows a user to grant a
>third-party Web site or application access to the user's protected
>resources, without necessarily revealing their long-term credentials,
>or even their identity. For example, a photo-sharing site that
>supports OAuth could allow its users to use a third-party printing Web
>site to print their private pictures, without allowing the printing
>site to gain full control of the user's account and without having the
>user share his or her photo-sharing sites' long-term credential with
>the printing site.
>
>The OAuth 2.0 protocol suite already includes
>
>* a procedure for enabling a client to register with an authorization
>server,
>* a protocol for obtaining authorization tokens from an authorization
>server with the resource owner's consent, and
>* protocols for presenting these authorization tokens to protected
>resources for access to a resource.
>
>This protocol suite has been enhanced with functionality for
>interworking with legacy identity infrastructure (e.g., SAML), token
>revocation, token exchange, dynamic client registration, token
>introspection, a standardized token format with the JSON Web Token, and
>specifications that mitigate security attacks, such as Proof Key for
>Code Exchange.
>
>The ongoing standardization efforts within the OAuth working group
>focus on increasing interoperability of OAuth deployments and to
>improve security. More specifically, the working group is defining proof
>of possession tokens, developing a discovery mechanism,
>providing guidance for the use of OAuth with native apps, re-introducing
>the device flow used by devices with limited user interfaces, additional
>security enhancements for clients communicating with multiple service
>providers, definition of claims used with JSON Web Tokens, techniques to
>mitigate open redirector attacks, as well as guidance on encoding state
>information.
>
>For feedback and discussion about our specifications please
>subscribe to our public mailing list.
>
>For security related bug reports that relate to our specifications
>please contact <>. If the reported bug
>report turns out to be implementation-specific we will
>attempt to forward it to the appropriate developers.
>
>---
>
>
>Ciao
>Hannes
>
>___
>OAuth mailing list
>OAuth@ietf.org
>https://www.ietf.org/mailman/listinfo/oauth


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

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

[Kepeng Li]

Thank you Mike.

The diagrams look good to me.

Kind Regards
Kepeng

发件人:  Mike Jones 
日期:  Thursday, 5 November, 2015 12:32 am
至:  "oauth@ietf.org" 
抄送:  Li Kepeng 
主题:  Proof-of-Possession Key Semantics for JWTs spec addressing final
shepherd comment

Proof-of-Possession Key Semantics for JWTs draft -06 addresses the remaining
document shepherd comment – adding use case diagrams to the introduction.
 
The updated specification is available at:
·   http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-06

 
An HTML formatted version is also available at:
·   
https://self-issued.info/docs/draft-ietf-oauth-proof-of-possession-06.html

 
-- Mike
 
P.S.  This note was also posted at http://self-issued.info/?p=1471 and as
@selfissued  .


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

[OAUTH-WG] FW: New Version Notification for draft-sakimura-oauth-rjwtprof-06.txt

[Kepeng Li]

Hi Mike,

Thanks for your review. It is very helpful, and I also forward it to the
whole list.

We will make a update when the submission window opens.

Kind Regards
Kepeng

发件人:  Mike Jones 
日期:  Wednesday, 21 October, 2015 1:07 am
至:  Li Kepeng 
抄送:  Nat Sakimura 
主题:  RE: New Version Notification for draft-sakimura-oauth-rjwtprof-06.txt

Hi Kepeng,
 
Thanks for the pointer to the current version of the document.  Review
comments follow…
 
Abstract – Remove the reference, since they aren’t allowed in IETF
abstracts.
 
Introduction.  I would replace this text:
   While Proof-Of-Possession Semantics for JSON Web Tokens
   (JWTs) [POPS 
 ]
touches briefly on the Sender Constraint, it is only
   one paragraph within a introductory text and does not discuss it in
   detail.  Instead, it devotes much of the discussion to the Key
   Confirmation method.  It also is making the usage of such token
   against the resource server out of scope.
with something closer to this:
While Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) [POPS]
specifies how to use key confirmation with JWTs, it does not specify how to
use a sender constraint.
And then maybe merge this paragraph with the following one, which starts
“This discussion draft”…
 
I have no idea what the last sentence above was referring to.  I’d just
delete it.
 
Everyplace you say “Proof-Of-Possession Semantics for JSON Web Tokens
(JWTs)” you should change this to the current title “Proof-of-Possession Key
Semantics for JSON Web Tokens (JWTs)”.
 
I would delete the term “Authorized Presenter” and instead refer to the
“Presenter” term in [POPS] by reference.  The term “Authorized Presenter”
has a bad history and tends to cause more confusion than clarity when it
appears.  When you want to talk about the legitimate presenter, I would just
use a phrase such as “intended presenter” or “legitimate presenter”.  (I
would refer to an unauthorized presenter in your discussion as “the
attacker”.)
 
s/use-case/use case/
 
Delete this sentence, since Sender Constraint isn’t in scope for POPS, and
the sentence makes it sound like it is:
   Key Confirmation mechanism is
   described in OAuth 2.0 Proof-Of-Possession Semantics for JSON Web
   Tokens (JWTs) [POPS
 ]
specification in detail, but Sender Constraint
   mechanism is not explained in detail.
 
Justification – Some places in the draft you talk about “.well-known/jwks”
(plural) and other places you talk about “.well-known/jwk” (singular).  I
suspect that multiple keys have to be published in the general case in order
to enable key rotation, with the right key selected by the “kid”.  See
http://openid.net/specs/openid-connect-core-1_0.html#RotateSigKeys for a
description of how keys are rotated in OpenID Connect.  This spec should do
the same or something similar.
 
Sender Constraint Representation – I would not overload the “azp” claim
specified in http://openid.net/specs/openid-connect-core-1_0.html#IDToken
with a different meaning.  There’s a widespread agreement in the OpenID
Connect working group that “azp” is confusing – see
https://bitbucket.org/openid/connect/issues/973/core-2-3137-azp-claim-unders
pecified-and.  John Bradley has also stated that the use you’re making of it
is different than Google’s usage (which is the only party using “azp” that
I’m aware of), and should use a different claim name.  Rather, I’d suggest
adding a new parameter name under the “cnf” claim defined by POPS to express
the presenter – possible “prsnt”.  So the syntax would be:
 
“cnf”: {“prsnt”: “presenter identifier”}
 
and when a Key ID is needed to select from among multiple keys, the syntax
would be:
 
“cnf”: {“prsnt”: “presenter identifier”, “kid”: “key identifier”}
 
This syntax would be more harmonized with POPS, and is the kind of extension
to “cnf” that were anticipated and enabled by the JWT Confirmation Methods
Registry in Section 6.2 of POPS.
 
Client Authentication – In (1), why is a “HEAD” request listed as a
possibility?  Why not just “GET”?
 
In (2), where is the “named” Authorization header value defined?  Please
provide a reference where you first use it.  (Oh – I just realized when I
got to 7.1 that you are defining the scheme in this specification.  I
couldn’t tell for sure until then.  I would have a separate section that’s
just about defining “named” and how it works before you use it.)
 
In (3), do you mean that the nonce is signed using the JWS Compact
Serialization, with the nonce being the JWS Payload value?  What key is used
for signing?
 
In (4), I’d rename “at” to “access_token” for consistency with other specs
and rename “s” to “signature”.
 
In (5), I’d cite RFC 7591 when you refer to Dynamic Client Registration.
Also, people won’t like the “may have been”.  You should 

Re: [OAUTH-WG] Review comments to PoP document

[Kepeng Li]

Hi Mike,

Thanks for your responses.

About the first paragraph in the introduction, I would prefer to make it
different from the same one in the abstract.

I am fine with others.

Kind Regards
Kepeng

发件人:  Mike Jones <michael.jo...@microsoft.com>
日期:  Friday, 9 October, 2015 1:58 am
至:  Li Kepeng <kepeng@alibaba-inc.com>, "oauth@ietf.org"
<oauth@ietf.org>
主题:  RE: Review comments to PoP document

Thanks for the useful review, Kepeng.  Responses inline…
 

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Kepeng Li
Sent: Wednesday, October 07, 2015 7:30 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Review comments to PoP document
 

Hello all,

 

Please find my review comments to PoP document:

http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-04
<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftools.ietf.
org%2fhtml%2fdraft-ietf-oauth-proof-of-possession-04=01%7c01%7cMichael.
Jones%40microsoft.com%7c39fc367bfc044fe9243c08d2cf23d95b%7c72f988bf86f141af9
1ab2d7cd011db47%7c1=XNX89l21GzCoKDzkQufdN1vF9VsGqOpNpWp9M6yyqAQ%3d>

 

1、 Title:

Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)
[Kepeng] Should we add OAuth 2.0 in the title? Also, in the whole document,
we use JWT, but in the title, we use “JWTs”. Is there a reason for this?
 
I wouldn’t suggest adding “OAuth 2.0” to the title, in part, because JWTs
are used in contexts outside of OAuth.  As for why JWTs is plural here, the
title is saying that PoP keys can be communicated in JSON Web Tokens.  If it
were singular, it would sound like you could only use PoP keys in a single
JWT, which isn’t right.
 
2、 Abstract：

1) This specification defines how to express a declaration in a JSON Web
Token (JWT) that the presenter of the JWT possesses a particular key and
that the recipient can cryptographically confirm proof-of-possession of the
key by the presenter.
[Kepeng] Add reference to JWT.
 
I’ve been told when editing other drafts to remove references that I’d
placed in abstracts, since IETF abstracts don’t include references.
 
2) This property is also sometimes described as the presenter being a
holder-of-key.
[Kepeng] I am not sure what is “this property”. Do you mean “the key”? If
yes, just use the key. And change the sentence to something like: This key
is also sometimes described as a holder-of-key by the presenter.
 
I can change “This property” to “Being able to prove possession of a key”.
 
3. Introduction
1) The first paragraph is the same as the abstract. I suggest to reword it a
little bit or remove it, to avoid the redundancy.
 
The rest of the introduction builds on the ideas introduced in the first two
sentences (the content of the abstract). If they were to be removed, it
would make the introduction confusing, as many people won’t start by reading
the abstract, but will read the introduction independently.  (The
introduction does add references, which cannot be present in the abstract.)
I’ll work with the other editors to see if they want to reword the first two
sentences of the introduction and/or abstract to make them different from
one another.
 
2) See [I-D.ietf-oauth-pop-architecture] for a further discussion of key
confirmation.
[Kepeng] I suggest to mention a little bit more about the relationship
between PoP architecture document and this document. In my understanding, in
PoP architecture document, it mentions several mechanisms: confidentiality
protection, key confirmation and sender constraint. This document introduces
the key semantics for the key confirmation mechanism.
 
OK – we can say that [I-D.ietf-oauth-pop-architecture] describes key
confirmation, among other conformation mechanisms, and that this
specification defines how to communicate key confirmation key information in
JWTs.
 
3) About the two use cases, it will be useful to use two diagrams or flows
to indicate how it works. Maybe put these two flows in a separate section.
Also it will be useful to mention which step is in scope, and which is out
of scope, e.g. how to convey symmetric key from the issuer to the presenter.
 
Both are in scope, which is why they’re both described in the introduction.
I’ll work with the other editors on trying to create appropriate diagrams.
 
4. Section 3:
1) It will be useful to put a reference to "sub" (subject) claim, and "iss"
(issuer) claim.
 
OK
 
2) Note that if an application needs to represent multiple proof-of-
   possession keys in the same JWT, one way for it to achieve this is to
   use other claim names, in addition to "cnf", to hold the additional
   proof-of-possession key information.
[Kepeng] It is not clear, what are the other claim names?
 
Fair point.  We can say that those claim names would be defined by
applications and could be registered in the JWT Claims Registry.
 
Kind Regards
Kepeng
 
Thanks again!
   

[OAUTH-WG] Review comments to PoP document

[Kepeng Li]

Hello all,

Please find my review comments to PoP document:
http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-04
 
1、Title:

Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)
[Kepeng] Should we add OAuth 2.0 in the title? Also, in the whole document,
we use JWT, but in the title, we use “JWTs”. Is there a reason for this?
 
2、Abstract：

1) This specification defines how to express a declaration in a JSON Web
Token (JWT) that the presenter of the JWT possesses a particular key and
that the recipient can cryptographically confirm proof-of-possession of the
key by the presenter.
[Kepeng] Add reference to JWT.
 
2) This property is also sometimes described as the presenter being a
holder-of-key.
[Kepeng] I am not sure what is “this property”. Do you mean “the key”? If
yes, just use the key. And change the sentence to something like: This key
is also sometimes described as a holder-of-key by the presenter.
 
3. Introduction
1) The first paragraph is the same as the abstract. I suggest to reword it a
little bit or remove it, to avoid the redundancy.
 
2) See [I-D.ietf-oauth-pop-architecture] for a further discussion of key
confirmation.
[Kepeng] I suggest to mention a little bit more about the relationship
between PoP architecture document and this document. In my understanding, in
PoP architecture document, it mentions several mechanisms: confidentiality
protection, key confirmation and sender constraint. This document introduces
the key semantics for the key confirmation mechanism.
 
3) About the two use cases, it will be useful to use two diagrams or flows
to indicate how it works. Maybe put these two flows in a separate section.
Also it will be useful to mention which step is in scope, and which is out
of scope, e.g. how to convey symmetric key from the issuer to the presenter.
 
4. Section 3:
1) It will be useful to put a reference to "sub" (subject) claim, and "iss"
(issuer) claim.
 
2) Note that if an application needs to represent multiple proof-of-
  possession keys in the same JWT, one way for it to achieve this is to
   use other claim names, in addition to "cnf", to hold the additional
  proof-of-possession key information.
[Kepeng] It is not clear, what are the other claim names?


Kind Regards
Kepeng


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

[OAUTH-WG] PoP document: IPR Confirmation

[Kepeng Li]

Hi Mike, John and Hannes,
I am working on the shepherd writeup for the PoP document:
http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-04

One item in the template requires me to indicate whether
each document author has confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.

Could you please confirm?

Kind Regards
Kepeng



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

Re: [OAUTH-WG] Review comments to PoP Architecture

[Kepeng Li]

Additional comments:

6. Section 4:
1) An attacker may generate a bogus tokens …
[Kepeng] Change “tokens” to “token”.
 
2) A client may also re-use access tokens for some other resource servers.
[Kepeng] Change “re-use” to “reuse”. The pragraph title says “reuse”. Also
in other places. 
 
3) To illustrate key confirmation the first examples borrow from Kerberos
and use symmetric key cryptography.
[Kepeng] Change “the first examples borrow” to “the first example is
borrowed”.
 
7. Section 5.4
1) As a high level message, there are various ways how the threats can be
mitigated and while the details of each solution is somewhat different they
all ultimately accomplish the goal.
[Kepeng] Change the last sentence to: the details of each solution are
somewhat different even they all can ultimately accomplish the goal.
 
2) Depending on the chosen layer for providing client-side authentication
there may be additional challenges due Web server load balancing, lack of
API access to identity information, etc.
[Kepeng] Change “due” to “due to”.
 
8. Section 6:
[Kepeng] It will be better if we can divide this section into several
sub-sections, e.g. each sub-section can be related to each figure.
 
9. Section 7:
1) [Kepeng] Usually the order for a specification is: use cases,
requirements, then architecture. Why do we have requirements after
architecture? Should we move this section ahead?
 
2) The authorization checking prevents an elevation of privilege attack, and
it ensures that an unauthorized authorized is detected.
[Kepeng] What is “an unauthorized authorized”? Should it be “an unauthorized
access”?


Kind Regards
Kepeng

发件人:  Li Kepeng 
日期:  Saturday, 19 September, 2015 12:55 am
至:  
主题:  [OAUTH-WG] Review comments to PoP Architecture

Hello authors,



Please find my review comments to PoP Architecture document:

https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-02



1.Introduction:

At the time of writing the OAuth 2.0 protocol family ([RFC6749],
[RFC6750], and [RFC6819]) offer a single standardized security mechanism to
access protected resources, namely the bearer token.
[Kepeng]  This sentences seem to be incomplete. What offers a security
mechanism? Also why do we mention “at the time of writing”? Is the situation
changed now?
 

2. Section 3:
The main use case that motivates better-than-bearer token security isthe
desire of resource servers to obtain additional assurance that   the client
is indeed authorized to present an access token.
[Kepeng] About “better-than-bear”, is it a word? Maybe reword the sentence a
little bit.
 
3.Section 3.1
1) In a legitimate use case consider chaining of computations whereby a
resource server needs to consult other third party resource servers to
complete the requested operation.
[Kepeng] This sentence seems to be incomplete. Maybe reword it a little bit?
 
2) In this use case additional information is conveyed to the resource
server to ensure that no entity entity has tampered with the TLS connection.
[Kepeng] Change “is conveyed” to “should be conveyed”?
 
4. Section 3.3:
First, an eavesdropper may steal an access token and represent it at a
different resource server.
[Kepeng] Change “represent it at” to “present it to”?
 
5. Section 3.4:
These load balancers may terminate the TLS connection setup and HTTP traffic
is transmitted in the clear from the load balancer to the resource server.
[Kepeng] Don’t understand “in the clear”. Should it be “in the wire”?


Kind Regards
Kepeng
___ OAuth mailing list
OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

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

[OAUTH-WG] Review comments to PoP Architecture

[Kepeng Li]

Hello authors,



Please find my review comments to PoP Architecture document:

https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-02



1.Introduction:

At the time of writing the OAuth 2.0 protocol family ([RFC6749],
[RFC6750], and [RFC6819]) offer a single standardized security mechanism to
access protected resources, namely the bearer token.
[Kepeng]  This sentences seem to be incomplete. What offers a security
mechanism? Also why do we mention “at the time of writing”? Is the situation
changed now?
 

2. Section 3:
The main use case that motivates better-than-bearer token security isthe
desire of resource servers to obtain additional assurance that   the client
is indeed authorized to present an access token.
[Kepeng] About “better-than-bear”, is it a word? Maybe reword the sentence a
little bit.
 
3.Section 3.1
1) In a legitimate use case consider chaining of computations whereby a
resource server needs to consult other third party resource servers to
complete the requested operation.
[Kepeng] This sentence seems to be incomplete. Maybe reword it a little bit?
 
2) In this use case additional information is conveyed to the resource
server to ensure that no entity entity has tampered with the TLS connection.
[Kepeng] Change “is conveyed” to “should be conveyed”?
 
4. Section 3.3:
First, an eavesdropper may steal an access token and represent it at a
different resource server.
[Kepeng] Change “represent it at” to “present it to”?
 
5. Section 3.4:
These load balancers may terminate the TLS connection setup and HTTP traffic
is transmitted in the clear from the load balancer to the resource server.
[Kepeng] Don’t understand “in the clear”. Should it be “in the wire”?


Kind Regards
Kepeng


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

[OAUTH-WG] PoP Architecture: IPR Confirmation

[Kepeng Li]

Hi Phil, Justin, William, Prateek ahd Hannes,

I am working on the shepherd writeup for the PoP Architecture document:
https://www.ietf.org/id/draft-ietf-oauth-pop-architecture-02.txt

One item in the template requires me to indicate whether
each document author has confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.

Could you please confirm?

Kind Regards
Kepeng


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

Re: [OAUTH-WG] RS as a client guidance

[Kepeng Li]

 From what I see, authorized presenter is a subset of authorized party.

That is also my understanding.

Kind Regards
Kepeng

发件人:  Nat Sakimura sakim...@gmail.com
日期:  Thursday, 20 August, 2015 9:01 am
至:  Mike Jones michael.jo...@microsoft.com
抄送:  OAuth WG oauth@ietf.org
主题:  Re: [OAUTH-WG] RS as a client guidance

And while we are at the history, my original draft idea (on my blog) on Aug.
3, 2012 had nau -- named authorized user.
So, three of us came up with a similar idea independently with more or less
the same idea, and it was unified to azp -- authorized presenter.

The name change to authorized party took later to expand the meaning of it.

From what I see, authorized presenter is a subset of authorized party.


2015-08-20 9:52 GMT+09:00 Mike Jones michael.jo...@microsoft.com:
 Just to complete the history, I believe the original Google deployed claim
 name for this purpose was “cid” (Client ID) – a name that seemed ripe with
 ambiguity.
  
 
 From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
 Sent: Wednesday, August 19, 2015 5:50 PM
 To: Justin Richer
 
 
 Cc: OAuth WG
 Subject: Re: [OAUTH-WG] RS as a client guidance
  
 Ah yes,  Now I recall that we had Google change the claim once to azp and then
 discussed changing it again once we decided that azp was not the necessarily
 the presenter presenter.  That was what we decided was too cruel getting them
 to change the name again for something that they then had released in
 production.   That caused us to re-acrom “azp”.
 
  
 
 John B.
 
  
 
 On Aug 19, 2015, at 9:39 PM, Justin Richer jric...@mit.edu wrote:
  
 
 Just want to clear up some history: azp did not come from any existing
 claims from Google or otherwise. I very clearly recall proposing that we name
 it prn for presenter, and Mike told me not to be evil[1] because we had
 just changed prn (for principal) in the ID token to sub in order to
 match the more generic JWT. John suggested a-zed-p in the same discussion.
 As such, it clearly was authorized presenter in the first take, then it got
 widened/shifted a little bit in the final definition for reasons I never
 quite followed (nor cared much about at the time).
 
  -- Justin
 
 [1] Being told don't be evil by a Microsoft employee remains one of my
 proudest achievements.
 
 On 8/19/2015 8:35 PM, John Bradley wrote:
 It could, but I remain to be convinced that would be a good idea.   “azp”
 came from a existing Google claim, I am not attached to the name.
 
  
 
 John B.
 
 On Aug 19, 2015, at 9:29 PM, Nat Sakimura sakim...@gmail.com wrote:
  
 
 Well, the abstract meaning is the same, but the practical implications and
 interpretation can vary within the boundaries depending on the context.
 
  
 
 A jku is a URI of a cryptographical key, which can be a uri of a signing
 key or encryption key depending on the context. Similarly the azp in an ID
 Token and an Access Token can share the same abstract concept while the
 concrete meaning in that particular concept can vary.
 
 2015年8月20日木曜日、Mike Jonesmichael.jo...@microsoft.com さんは書きました:
 
 Let me second John’s point that we shouldn’t have two different definitions
 for “azp”.  As I wrote in my friendly review of
 draft-sakimura-oauth-rjwtprof-04 at
 http://www.ietf.org/mail-archive/web/oauth/current/msg14679.html
 https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.o
 rg%2fmail-archive%2fweb%2foauth%2fcurrent%2fmsg14679.htmldata=01%7c01%7cMi
 chael.Jones%40microsoft.com%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86
 f141af91ab2d7cd011db47%7c1sdata=3TbSJzfONy8nvH1hDcjGQPmdeen39IJDHk1R99tD7B
 E%3d , the claim “azp” has already been registered by OpenID Connect Core
 at http://www.iana.org/assignments/jwt/jwt.xhtml
 https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.iana.o
 rg%2fassignments%2fjwt%2fjwt.xhtmldata=01%7c01%7cMichael.Jones%40microsoft
 .com%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%
 7c1sdata=kijVXFcn2du2Ha5xvX%2bTgwohVGOl%2fxmryplQNsWHYzo%3d  and so
 cannot be re-registered.  Given that I believe the intended semantics are
 the same, please cite the existing definition in rjwtprof, rather than
 repeating it or revising it.
 
  
 Thanks,
 -- Mike
 
  
 
 From: John Bradley [mailto:ve7...@ve7jtb.com]
 Sent: Wednesday, August 19, 2015 11:05 AM
 To: Nat Sakimura
 Cc: Mike Jones; OAuth WG
 Subject: Re: [OAUTH-WG] RS as a client guidance
 
  
 Having two azp claims with slightly different definitions is not a good way
 to go,  both access tokens and id_tokens are JWT.
 
 For better or worse the claim was defined for bearer tokens where it was
 only the identity of the requester that was able to be confirmed by the
 token endpoint.
 
 It supported a simple use case where a refresh token is used by client A to
 use as an assertion at AS B.
 
 In the simplest 3 party sase the 

Re: [OAUTH-WG] Proposed OAuth agenda items

[Kepeng Li]

I’d like to add one short agenda item (5 min), to discuss the way forward:
http://datatracker.ietf.org/doc/draft-sakimura-oauth-rjwtprof/

Thanks,

Kind Regards
Kepeng

发件人:  Mike Jones michael.jo...@microsoft.com
日期:  Friday, 10 July, 2015 5:09 am
至:  oauth@ietf.org oauth@ietf.org
主题:  [OAUTH-WG] Proposed OAuth agenda items

I’d like to see us cover the following topics during our meeting in Prague…
 
Issues and Choices for Token Exchange, Brian Campbell and Mike Jones, 30
minutes
 
Next steps to complete the POP documents, 30 minutes?:
draft-ietf-oauth-pop-key-distribution, John Bradley?, 15
minutes?
draft-ietf-oauth-pop-architecture, Phil Hunt?, 10 minutes?
draft-ietf-oauth-proof-of-possession, Mike Jones, 5 minutes
(or less)
 
And if the authors would like to talk about the status of jwsreq,
signed-http-request, etc., I’d welcome that as well.
 
I’m assuming that introspection and spop are far enough along we won’t need
working group time for them?
 
See you in
Prague!
-- Mike
 
___ OAuth mailing list
OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

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