Re: [OAUTH-WG] Corona Virus and Vancouver

[n-sakimura]

I probably will not be there in person unless the situation improves 
dramatically

iPhoneから送信

2020/03/10 10:09、Sascha Preibisch のメール:


I will be there if it is not getting worse. But in any case I am in Vancouver.

Regards,
Sascha

On Mon., Mar. 9, 2020, 11:35 Daniel Fett, 
mailto:f...@danielfett.de>> wrote:

Hi all,

can we do a quick roll call on who is coming or not coming to Vancouver?

For me, at the current point in time, it depends on whether a significant 
portion of the working group is attending in-person.

-Daniel

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

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

[n-sakimura]

Up until -12 (Feb 13, 2017), it was using merge + JAR precedence if duplicated.
As of -13 (Mar 30, 2017), it was changed that the server does not have to do 
the merge, at least for OAuth Authorization request parameters. It says nothing 
about other parameters.
As of -14 (Jul 21, 2017), the wording was further strengthened by adding

The Authorization Server MUST only use the parameters in the Request Object 
even if the same parameter is provided in the query parameter.

So, the entire 6.3 now became
6.3.  
Request Parameter Assembly and Validation

   The Authorization Server MUST extract the set of Authorization

   Request parameters from the Request Object value.  The Authorization

   Server MUST only use the parameters in the Request Object even if the

   same parameter is provided in the query parameter.  The Authorization

   Server then validates the request as specified in OAuth 2.0

   [RFC6749].

It says nothing on the non-OAuth parameters that came with the authorization 
request.
My take on the text is that all OAuth Authorization Request parameters MUST be 
in the request object.
Behaviors towards other parameters that happens to have come together with the 
authorization request outside of request object will be treated as non-OAuth 
parameters.

Nat Sakimura
Research Fellow, Nomura Research Institute
E: n-sakim...@nri.co.jp
T: +81(90)60136276
-
PLEASE READ:This e-mail is confidential and intended for the named recipient 
only.
If you are not an intended recipient, please notify the sender and delete this 
e-mail.

From: OAuth  On Behalf Of Justin Richer
Sent: Friday, January 3, 2020 2:35 AM
To: Takahiko Kawasaki 
Cc: Brian Campbell ; oauth 
; Nat Sakimura 
Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request 
object

For solution [2], this is the behavior that’s required for OIDC today, so I 
would say that’s the New Client behaving like an Old Client in order to talk to 
an Old Server. So in reality, (2) causes the request to be rejected, and that’s 
OK.

I don’t think it’s viable to require parameters to exist inside the request 
object at all times. Nor should we try to enumerate which parameters go inside 
and outside at all times — at least from the JAR/OAuth level of things. I think 
there are too many things that are application and deployment specific for us 
to make this call. The very nature of the request object changes for people — 
some have a static object that’s deployed with clients and some have something 
that the client creates at runtime for each request.

If the instead the New Server requires that any parameters duplicated between 
the two places have to match (the OIDC method) or that in a conflict the 
request object values take precedence (the merge method), then problems 3-1 and 
3-2 go away.

With the merge-and-precedence behavior, which is what I thought that JAR had 
during WGLC, [3-1] is well-defined. The request is processed the same way every 
time because this is a New Server. The client is going to do OIDC’s “duplicate” 
method, so “merge with precedence” is effectively a no-op.

With the merge-and-precedence behavior, [3-2] doesn’t happen because the 
required parameters aren’t required to be in the request object itself. As long 
as the request object is valid, it protects all parameters within it. I don’t 
think it’s up to us to determine what makes sense to put in that object. 
Security guidance is probably a good idea here.

Solution [3] is what Old Clients already do in OIDC today, so that’s what 
already happens and why problem space (3) isn’t a problem.

 — Justin


On Jan 2, 2020, at 12:24 PM, Takahiko Kawasaki 
mailto:t...@authlete.com>> wrote:

Thank you, Justin. Actually, I wanted to see someone write a summary about what 
happens in each combination from a viewpoint of both RP and AS with regard to 
backward compatibility (as I told you in other channel just before you posted 
your email ^_^).

So,

(1) New Client + New Server
No problem will happen.

(2) New Client + Old Server
[Problem 2-1] If an authorization request contains 'request' or 'request_uri' 
but doesn't have old mandatory request parameters ('client_id' and 
'response_type') outside the request object, the request is rejected.

[Solution 2] New Client should include the old mandatory request parameters 
duplicately outside the request object. This means that New Client should 
always send old mandatory request parameters duplicately outside the request 
object if it wants to get maximum compatibility.

(3) Old Client + New Server
[Problem 3-1] If an authorization request contains 'request' or 'request_uri' 
and some "optional" request parameters are not included in the request object, 
AS will interpret the request differently. Imagine what happens when optional 
parameters such as 'scope', 

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Pushed Authorization Requests

[n-sakimura]

+1

野村総合研究所　IT基盤技術戦略室
上席研究員　崎村夏彦
E: n-sakim...@nri.co.jp
T: +81(90)60136276
-
このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、送信者にご連絡のうえ、このメールを削除してくださいますようお願い申し上げます。
PLEASE READ:This e-mail is confidential and intended for the named recipient 
only. If you are not an intended recipient, please notify the sender and delete 
this e-mail.

From: OAuth  On Behalf Of John Bradley
Sent: Tuesday, December 17, 2019 11:15 PM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Pushed Authorization 
Requests


I support addoption
On 12/17/2019 11:01 AM, Aaron Parecki wrote:
I support the adoption of PAR.

Aaron Parecki


On Tue, Dec 17, 2019 at 4:59 AM Rifaat Shekh-Yusef 
mailto:rifaat.i...@gmail.com>> wrote:
All,

This is a call for adoption of for the OAuth 2.0 Pushed Authorization Requests 
document.
https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/

There was a good support for this document during the Singapore meeting, and on 
the mailing list in the Meeting Minutes thread.

Please, let us know if you support or object to adopting this document as a 
working group document by Dec 27th.

If you have already indicated your support on the Meeting Minutes thread, you 
do not need to do it again on this thread.

Regards,
 Rifaat & Hannes



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

Aaron Parecki
aaronparecki.com
@aaronpk




___

OAuth mailing 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] WGLC for "OAuth 2.0 Security Best Current Practice"

[n-sakimura]

Sorry to chime in so late as well as I have not been able to follow up all the 
mail in the tread, so it may have come up before but just for the sake... 

1) Spelling of "OpenID"
"OpenID" is sometimes spelled "OpenID" and sometimes " OpenId". 
Please unify to "OpenID" as that is the official way of expressing it. 
Of course, it does not apply to the URIs. 

2) Has WPAD/PAC attack been mitigated in all user-agents? 

WPAD/PAC used to trivially leak the request URIs (in terms of HTTP, not OAuth) 
in some browsers that were configured to use proxy auto-config. So, in that 
kind of scenario, both Authorization Request URI and Authorization Response URI 
would have leaked. 
(Depending on the HTTP agent that the client uses, it would have leaked its 
requests as well though they are typically not auto-configured so are save in 
most cases.) 
Did those browsers disappeared? (Hopefully yes but not sure.) 
If not, it might be worth adding it. 

Best, 

Nat Sakimura
-
PLEASE READ:This e-mail is confidential and intended for the named recipient 
only. If you are not an intended recipient, please notify the sender and delete 
this e-mail.

-Original Message-
From: OAuth  On Behalf Of Hannes Tschofenig
Sent: Wednesday, November 6, 2019 5:27 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best Current Practice"

Hi all,

this is a working group last call for "OAuth 2.0 Security Best Current 
Practice".

Here is the document:
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13

Please send you comments to the OAuth mailing list by Nov. 27, 2019.
(We use a three week WGLC because of the IETF meeting.)

Ciao
Hannes & Rifaat

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

___
OAuth mailing 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] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)

[n-sakimura]

Brian,

You are the expert on the particular IANA registries so I probably are missing 
something.

I was thinking that registering JWT claims to OAuth registry is sufficient till 
seeing Ben’s comment, and I was tracking that it is being done by Mike as part 
of the errata process for OIDC Core. However, after reading Ben’s comment that 
mentioning the OAuth extensions, and I checked that quite a few claims are now 
being registered to JWT Claims Registry from outside the OAuth community, I 
started to feel that it may not be sufficient. But I must be missing something 
as you point out that is still sufficient.

Could you please explain how the collision between the future OAuth extension 
and JWT claims can be avoided by registering main JWT claims to the OAuth 
Parameter registry?
If that is the case, I am all for it as then we do not get back to IANA process.

Best,

Nat

Nat Sakimura | 崎村夏彦
Nomura Research Institute

このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、送信者にご連絡のうえ、このメールを削除してくださいますようお願い申し上げます。

PLEASE READ：This e-mail is confidential and intended for the named recipient 
only. If you are not an intended recipient, please notify the sender and delete 
this e-mail.


差出人: Brian Campbell 
送信日時: Saturday, July 27, 2019 5:47:15 AM
宛先: Nat Sakimura 
CC: Benjamin Kaduk ; draft-ietf-oauth-jws...@ietf.org 
; oauth-cha...@ietf.org 
; The IESG ; oauth 
件名: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: 
(with DISCUSS and COMMENT)

Nat, you suggest that the "simplest solution probably is to register the
authorization request parameters to the JWT Claims registry." However, as
I've attempted to articulate several times this week (
https://mailarchive.ietf.org/arch/msg/oauth/0EenxmThjII52SAr9atpBStRtcs and
muliple comments on https://bitbucket.org/openid/connect/issues/1019) and
even back in 2017 (
https://mailarchive.ietf.org/arch/msg/oauth/_E14Trqu962cReu3t6FquPEyigY), I
believe the pragmatic solution to this is to register some of the main JWT
claims into the OAuth parameters registry (not the other way around, as
you're suggesting which wouldn't even have caught the one name collision
we've actually had where a draft, more than one actually, wanted to call an
authorization request parameter "aud", which would conflicted with the JWT
claim of the same name and cause big problems when used together with JAR).
I suppose the iron clad way to "fix" this would be to merge the two
registries and keep them in sync forever. But that seems awfully heavy
handed and unnecessary. JAR is a specific application of JWT being used to
convey an OAuth authz request. JAR explicitly uses a few core JWT claims
(aud, iss) and one could reasonably imagine other core ones being used as
well (exp, iat, nbf, jti, etc). An authorization request parameter being
introduced that uses one of those names is far and away the most likely
point of collision (and has already happened, as noted previously). A new
JWT claim being introduced that collides with an existing authorization
request parameter name AND would be used in the context of JAR is far far
less likely to happen. So unlikely, in fact, that I don't think it's
necessary or even useful to pollute the JWT claims registry with the names
of all the authorization request parameters. I happen to be one of the DEs
on the JWT claims registry so, in theory, I have some idea what I'm talking
about here. In theory. And I do have to be upfront at this point and say
that I will push back on a request for registration of a bunch of
authorization request parameters into the JWT claims registry without
without more compelling reason.

On Fri, Jul 26, 2019 at 12:23 PM Nat Sakimura  wrote:

>
> Thanks very much for the comments.
> Here are my responses to your comments.
>
> On Wed, Jul 3, 2019 at 2:59 PM Benjamin Kaduk via Datatracker <
> nore...@ietf.org> wrote:
> >
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-oauth-jwsreq-19: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
> >
> >
> >
> > --
> > DISCUSS:
> > --
> >
> > My apologies; my previous position was incomplete.  Updated to note
> > namespacing issues, and one minor terminology nit about "DNS-ID".
> >
> > There seem to be some pretty serious namespacing issues that are not
> > discussed at all in this document.  Specifically, using JWT as a
> > container for OAut

Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

[n-sakimura]

Agreed.

On the related issue, issue of exporting the access token that a confidential 
client got to a public client is there as it was discussed in the Friday’s 
Oauth WG meeting. Though I did not make any comment on Friday as we were 
running out of time, I think that is a bad idea as the AuthZ server has issued 
it assuming that it is kept by a confidential client.

Hybrid response type was made because of the view that the public client should 
get less privilege.

If we are getting rid of Implicit flow, this aspect need to be addressed.

Having said that: if SPA is using the code flow, is it not acting as a public 
client without a client secret?

Nat

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer
Sent: Thursday, July 25, 2019 8:45 PM
To: David Waite 
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

This raises an interesting question that I don’t think we’ve addressed yet: how 
to appropriately vary token lifetimes and access for different clients.

Previously, an AS could see that a client was using the implicit flow and 
decide to limit token lifetimes or scopes based on that alone. Similarly, I 
know of at least some AS implementations that let you limit what scopes you 
allow under the client credentials grant. The key issue is that if all your 
clients are using the auth code flow (which I agree they should), then how does 
an AS tell the difference in capabilities between incoming clients?

Obviously it can do it on a per-client basis still, but now an AS is going to 
have to know a bit more about the app itself. Perhaps we finally need a few 
more entries in the “application_type” metadata parameter from OIDC’s extension 
RFC7591 beyond “native” and “web”? But we at least probably want to point out 
to AS implementors that this is something they want to consider tracking in 
their data model for clients.

— Justin


On Jul 25, 2019, at 4:04 AM, David Waite 
mailto:da...@alkaline-solutions.com>> wrote:





On Jul 24, 2019, at 3:03 PM, Aaron Parecki 
mailto:aa...@parecki.com>> wrote:

On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier
mailto:dba...@leastprivilege.com>> wrote:



I would rather say that ANY JS app should use CSP to lock down the browser 
features to a minimal attack surface. In addition, if refresh or access tokens 
are involved - further settings like disabling inline scripting (unsafe inline) 
and eval should be disabled.

I'm not sure what to do with this suggestion. It feels like a blanket
recommendation of enabling CSP will likely be ignored since it's too
broad, and recommending disabling inline scripts is overreaching
unless backed up by a specific threat it's protecting against. Did you
have a particular threat in mind?

I would say that browser applications should take measures to harden their 
applications again code injection and arbitrary code execution. Examples 
include eliminating inline script (and limiting embeddable objects as much as 
possible) via CSP, and versioning third party resources via techniques like 
subresource integrity.  Mechanisms such as augmenting the codebase to make sure 
all appropriate user input, data storage, and output properly sanitize data may 
be used - although they may be more expensive to implement and audit.

The AS should likewise take into account an application’s overall security 
posture when deciding appropriate policies around delegated authorization 
scopes and token lifetimes.

Best current practices include turning the screws tightly around CSP. But it is 
(theoretically) possible to accomplish the same with brute-force sanitization, 
which has been made simpler with framework support. It is still ultimately the 
AS job to decide which clients have which capabilities.

-DW
___
OAuth mailing 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] Fwd: New Version Notification for draft-sakimura-oauth-jpop-05.txt

[n-sakimura]

Just refreshed the JPOP draft as it may be pertinent to both DPOP and access 
token JWT discussion.

Nat Sakimura
Nomura Research Institute

PLEASE READ：This e-mail is confidential and intended for the named recipient 
only. If you are not an intended recipient, please notify the sender and delete 
this e-mail.

差出人: internet-dra...@ietf.org 
送信日時: 月曜日, 7月 22, 2019 11:33 午前
宛先: Nat Sakimura; Kepeng Li; John Bradley
件名: New Version Notification for draft-sakimura-oauth-jpop-05.txt


A new version of I-D, draft-sakimura-oauth-jpop-05.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Name:   draft-sakimura-oauth-jpop
Revision:   05
Title:  The OAuth 2.0 Authorization Framework: JWT Pop Token Usage
Document date:  2019-07-22
Group:  Individual Submission
Pages:  12
URL:
https://www.ietf.org/internet-drafts/draft-sakimura-oauth-jpop-05.txt
Status: https://datatracker.ietf.org/doc/draft-sakimura-oauth-jpop/
Htmlized:   https://tools.ietf.org/html/draft-sakimura-oauth-jpop-05
Htmlized:   https://datatracker.ietf.org/doc/html/draft-sakimura-oauth-jpop
Diff:   https://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-jpop-05

Abstract:
   This specification describes how to use JWT POP (Jpop) tokens that
   were obtained through [POPKD] in HTTP requests to access OAuth 2.0
   protected resources.  Only the party in possession of the
   corresponding cryptographic key for the Jpop token can use it to get
   access to the associated resources unlike in the case of the bearer
   token described in [RFC6750] where any party in posession of the
   access token can access the resource.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens

[n-sakimura]

+1 

For that matter, explicit typing is good and I am a bit ambivalent on the use 
of `sub`. 

Also, I need to add the 4th consideration: Although the current privacy 
consideration is stating about the encryption, it is in relation to the end 
user exposure. In fact, the by-value access token when involving some PII is by 
definition leaking information and violating the data minimization principle. 
This should be clearly delineated. My gut feeling is that it should be 
encrypted unless it is certain that it does not include sensitive PII as 
judging whether a claim may form a PII is too hard for an average developer. 

-Original Message-
From: OAuth  On Behalf Of Anthony Nadalin
Sent: Wednesday, April 10, 2019 8:12 PM
To: Hannes Tschofenig ; oauth@ietf.org
Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens

I support adoption of this draft as a working group document with the following 
caveats:

1. These are not to be used as ID Tokens/authentication tokens 2. The privacy 
issues must be addressed 3. Needs to be extensible, much like ID-Token, can't 
be 100% fixed 


-Original Message-
From: OAuth  On Behalf Of Hannes Tschofenig
Sent: Monday, April 8, 2019 10:07 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens

Hi all,

this is the call for adoption of the 'JWT Usage in OAuth2 Access Tokens'  
document following the positive feedback at the last IETF meeting in Prague.

Here is the document:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-bertocci-oauth-access-token-jwt-00&data=02%7C01%7Ctonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636903400616347061&sdata=ePmwaD%2FHCRZhRx%2FwZbb3U72%2FhBalPoFPKtQ67QTxIRw%3D&reserved=0

Please let us know by April 22nd whether you accept / object to the adoption of 
this document as a starting point for work in the OAuth working group.

Ciao
Hannes & Rifaat

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

___
OAuth mailing list
OAuth@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7Ctonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636903400616357060&sdata=zcxw1IR3kNbuZ9u58OOJDv9pLb7cUCooDtlIUH7tS%2Fw%3D&reserved=0

___
OAuth mailing 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 Security Topics -- Recommend authorization code instead of implicit

[n-sakimura]

OAuth MTLS has been implemented in Banking industry so we have at least an 
alternative.

Sender Constrained includes cases where it is not key bound but name bound as I 
understand and it may have some utility so we f there are doubts, mentioning 
the both may be good.

Outlook for iOS<https://aka.ms/o0ukef> を入手


差出人: OAuth  (Hannes Tschofenig 
 の代理)
送信日時: 土曜日, 12月 1, 2018 6:07 午後
宛先: Aaron Parecki; Torsten Lodderstedt
Cc: Daniel Fett; IETF oauth WG
件名: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code 
instead of implicit

I agree with Aaron here and I think Section 
3.8.1.2<https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-3.8.1.2>
 of draft-ietf-oauth-security-topics-10  already does a pretty good job.
I was, however, wondering about the subtle implication of the requirement for 
sender constrained tokens. My understanding of the token binding discussion, 
which is one of the ways to provide sender-constrained tokens, is that we don’t 
have good faith in seeing deployment anytime soon. Hence, we are essentially 
(reading in between the lines of Section 3.8.1.2) saying that you cannot use 
implicit grant in a practical setup for the web*.

Am I misunderstanding it?

Ciao
Hannes

PS: The IoT case is likely different.

From: OAuth  On Behalf Of Aaron Parecki
Sent: Saturday, December 1, 2018 3:18 AM
To: Torsten Lodderstedt 
Cc: Daniel Fett ; IETF oauth WG 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code 
instead of implicit

+1

I would also like to ensure there is a clear definition of "sender constrained" 
tokens in this BCP.

Aaron


On Thu, Nov 29, 2018 at 10:06 AM Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>> wrote:
Hi all,

based on your feedback on the list and off list, Daniel and I polished the 
text. That’s our proposal:

—
In order to avoid these issues, clients MUST NOT use the implicit
grant (response type "token") or any other response type issuing access
tokens in the authorization response, such as "token id_token" and "code token 
id_token“,
unless the issued access tokens are sender-constrained and access token 
injection in
the authorization response is prevented.
—

Explantation:
- we wanted to have the right balance between a generic definition of the 
response types we do not recommend/allow to be used and a concrete/actionable 
list of the affected response types.
- we changed from SHOULD NOT to MUST NOT as suggested by Nat and supported by 
William

We look forward to seeing your feedback.

kind regards,
Torsten.

> Am 29.11.2018 um 15:15 schrieb John Bradley 
> mailto:ve7...@ve7jtb.com>>:
>
> I am ok with that.
>
> On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt 
> mailto:tors...@lodderstedt.net> wrote:
>
> > Am 28.11.2018 um 23:50 schrieb n-sakimura 
> > mailto:n-sakim...@nri.co.jp>>:
> >
> > That works.
>
> Good!
>
> I just realized this text has an issue with „token“ (only). It would allow 
> „token“ to be used if the token would sender constrained. This completely 
> ignores the fact implicit also shall be abandoned because of its 
> vulnerability for access token injection.
>
> I therefore propose a modified text:
>
>In order to avoid these issues, Clients SHOULD NOT use the implicit
>grant. Furthermore, clients SHOULD only use other response types causing 
> the authorization server to
>issue an access token in the authorization response, if the particular 
> response type detects access token
>injection and the issued access tokens are sender-constrained.
>
> Or we just state:
>
>   In order to avoid these issues, Clients SHOULD NOT use the response type 
> „token". The response types
> „token id_token“ and „code token id_token“ SOULD NOT be used, if the issued 
> access tokens are not
> sender-constrained.
>
> >
> > In fact, I would further go and say MUST NOT but that probably is too much 
> > for a security consideration.
> >
>
> Mike suggested to go with a SHOULD NOT to get the message out but give 
> implementors time to move/change.
>
> > Best,
> >
> > Nat
> >
> > Nat Sakimura / n-sakim...@nri.co.jp<mailto:n-sakim...@nri.co.jp> / 
> > +81-90-6013-6276
> >
> > このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、誠に申し訳ございませんが、送信者までお知らせ頂き、また受信されたメールは削除してくださいますようお願い申し上げます。
> >
> > PLEASE READ :This e-mail is confidential and intended for the named 
> > recipient only.
> > If you are not an intended recipient, please notify the sender and delete 
> > this e-mail.
> >
> > 差出人: Torsten Lodderstedt 
> > mailto:tors...@lodderstedt.net>>
> > 送信日時: 水曜日, 11月 28, 2018 11:38 午後
> > 宛先: n-sakimura
> &g

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

[n-sakimura]

+1

Nat Sakimura / n-sakim...@nri.co.jp / +81-90-6013-6276

このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、誠に申し訳ございませんが、送信者までお知らせ頂き、また受信されたメールは削除してくださいますようお願い申し上げます。

PLEASE READ :This e-mail is confidential and intended for the named recipient 
only.
If you are not an intended recipient, please notify the sender and delete this 
e-mail.

From: OAuth  on behalf of John Bradley 

Sent: Thursday, November 29, 2018 7:33:57 PM
To: Torsten Lodderstedt
Cc: Daniel Fett; IETF oauth WG
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code 
instead of implicit

+1

On Thu, Nov 29, 2018, 3:06 PM Torsten Lodderstedt 
mailto:tors...@lodderstedt.net> wrote:
Hi all,

based on your feedback on the list and off list, Daniel and I polished the 
text. That’s our proposal:

—
In order to avoid these issues, clients MUST NOT use the implicit
grant (response type "token") or any other response type issuing access
tokens in the authorization response, such as "token id_token" and "code token 
id_token“,
unless the issued access tokens are sender-constrained and access token 
injection in
the authorization response is prevented.
—

Explantation:
- we wanted to have the right balance between a generic definition of the 
response types we do not recommend/allow to be used and a concrete/actionable 
list of the affected response types.
- we changed from SHOULD NOT to MUST NOT as suggested by Nat and supported by 
William

We look forward to seeing your feedback.

kind regards,
Torsten.

> Am 29.11.2018 um 15:15 schrieb John Bradley 
> mailto:ve7...@ve7jtb.com>>:
>
> I am ok with that.
>
> On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt 
> mailto:tors...@lodderstedt.net> wrote:
>
> > Am 28.11.2018 um 23:50 schrieb n-sakimura 
> > mailto:n-sakim...@nri.co.jp>>:
> >
> > That works.
>
> Good!
>
> I just realized this text has an issue with „token“ (only). It would allow 
> „token“ to be used if the token would sender constrained. This completely 
> ignores the fact implicit also shall be abandoned because of its 
> vulnerability for access token injection.
>
> I therefore propose a modified text:
>
>In order to avoid these issues, Clients SHOULD NOT use the implicit
>grant. Furthermore, clients SHOULD only use other response types causing 
> the authorization server to
>issue an access token in the authorization response, if the particular 
> response type detects access token
>injection and the issued access tokens are sender-constrained.
>
> Or we just state:
>
>   In order to avoid these issues, Clients SHOULD NOT use the response type 
> „token". The response types
> „token id_token“ and „code token id_token“ SOULD NOT be used, if the issued 
> access tokens are not
> sender-constrained.
>
> >
> > In fact, I would further go and say MUST NOT but that probably is too much 
> > for a security consideration.
> >
>
> Mike suggested to go with a SHOULD NOT to get the message out but give 
> implementors time to move/change.
>
> > Best,
> >
> > Nat
> >
> > Nat Sakimura / n-sakim...@nri.co.jp<mailto:n-sakim...@nri.co.jp> / 
> > +81-90-6013-6276
> >
> > このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、誠に申し訳ございませんが、送信者までお知らせ頂き、また受信されたメールは削除してくださいますようお願い申し上げます。
> >
> > PLEASE READ :This e-mail is confidential and intended for the named 
> > recipient only.
> > If you are not an intended recipient, please notify the sender and delete 
> > this e-mail.
> >
> > 差出人: Torsten Lodderstedt 
> > mailto:tors...@lodderstedt.net>>
> > 送信日時: 水曜日, 11月 28, 2018 11:38 午後
> > 宛先: n-sakimura
> > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org<mailto:oauth@ietf.org>
> > 件名: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code 
> > instead of implicit
> >
> > Hi Nat,
> >
> >> Am 28.11.2018 um 21:10 schrieb n-sakimura 
> >> mailto:n-sakim...@nri.co.jp>>:
> >>
> >> I would support
> >>
> >> 1) clearly defining Implicit as the flow that returns access token from 
> >> the authorization endpoint ( some people confuses implicit as the flow 
> >> that returns ID Token in the front channel)
> >
> > That’s the current text:
> >
> > In order to avoid these issues, Clients SHOULD NOT use the implicit
> >grant or any other response type causing the authorization server to
> >issue an access token in the authorization response.
> >
> > What would you like to modify?
> >
> >>
> >> 2) Banning the returning of the access token that are not se

Re: [OAUTH-WG] Dynamic Client Registration with Native Apps

[n-sakimura]

In the case of dynamic client registration for apps, I suppose the 
implementations will use other techniques (many of them are proprietary) to 
test if the app is the one created by themselves or not. Otherwise, it would 
not improve the situation very much.

Nat

Nat Sakimura / n-sakim...@nri.co.jp / +81-90-6013-6276

このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、誠に申し訳ございませんが、送信者までお知らせ頂き、また受信されたメールは削除してくださいますようお願い申し上げます。

PLEASE READ :This e-mail is confidential and intended for the named recipient 
only.
If you are not an intended recipient, please notify the sender and delete this 
e-mail.


差出人: OAuth  (Joseph Heenan  の代理)
送信日時: 木曜日, 11月 29, 2018 5:19 午後
宛先: oauth
件名: Re: [OAUTH-WG] Dynamic Client Registration with Native Apps

Hi all,

It’s worth adding that a per-instance dynamic registration of a native client 
can still imply a higher level of trust than a public client and registration 
isn’t necessarily unauthenticated. https://tools.ietf.org/html/rfc7591 defines 
an “initial access token”:


OAuth 2.0 access token optionally issued by an authorization
server to a developer or client and used to authorize calls to the
client registration endpoint.  The type and format of this token
are likely service specific and are out of scope for this
specification.  The means by which the authorization server issues
this token as well as the means by which the registration endpoint
validates this token are out of scope for this specification.  Use
of an initial access token is required when the authorization
server limits the parties that can register a client.

This can be used [for example] to bind a client to a specific user, though the 
bootstrapping can be a little involved and potentially the bootstrapping still 
has weaknesses. Use of white box crypto (or other tools like device 
attestations) can potentially also bring dynamically registered native apps up 
to a sufficiently trusted level.

Joseph


On 29 Nov 2018, at 14:02, Christian Mainka 
mailto:Christian.Mainka=40rub...@dmarc.ietf.org>>
 wrote:

Hi,

thanks for pointing this out!
This was exactly what confused us during reading - the main threat we see and 
which is not addressed is related to the app impersonation attack.
Even PKCE does not help against the app impersonation attack.

So a "Native App + Dynamic Client Registration" can be seen at a different 
"confidentiality level" than a "public client", because every native App can 
dynamically register itself on the IdP.
The IdP cannot distinguish, for example, an honest native client from an 
malicious client starting an app impersonation attack.

We agree that, e.g., a leaked code cannot be redeemed unless you have the 
respective client_id/client_secret.

But... we asked ourselfs, in which cases does a code leak?

1) In the front-channel. In this case, it is true that no client credentials 
leak and an attacker cannot redeem the code.

2) In the back-channel. But if this channel is insecure, you directly get 
client credentials (unless client_secret_jwt is used as pointed out by George).

So, Dynamic Client Registration only helps if the code leaks alone (as in 1.), 
or if it leaks on different levels (e.g. logfiles).

On the opposite site, if Dynamic Registration is available, an attacker can 
very easily do an app impersonation attack by registering on the IdP. To be 
clear, it is not "impersonation" as in the "one secret per software" scenario, 
because different client_id and client_secret is used, but to the best of my 
knowledge, the IdP cannot distinguish between an honest app and an app 
impersonation client that has simply registered.

In addition, if the IdP supports the dynamic client registration:
How can the IdP distinguish between confidential and public/native clients?
With respect to the consent page, which must be shown every time for native 
apps, this is an important issue, which should be addressed properly.

Best Regards
Vladi/Christian

Am 29.11.18 um 00:38 schrieb Richard Backman, Annabelle:

It should be noted that “traditional” confidential clients with registered 
return URLs and server-side secrets may provide a higher degree of confidence 
in the true identity of the client that doesn’t carry over to confidential 
native app clients. A native app instance’s registration call is necessarily 
unauthenticated (for the same reasons that statically registered native app 
clients are public clients), so the Client Impersonation concerns described in 
section 8.6 of 
RFC8252
 still apply.
--
Annabelle Richard Backman
AWS Identity


From: OAuth  on behalf 
of Filip Skokan 
Date: Wednesday, November 28, 2018 at 9:11 AM
To: George Fletcher 
Cc: oauth 
Subject: Re: [OAUTH-WG] Dynamic Client Registration with Native Apps

Apologie

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

[n-sakimura]

That works.

In fact, I would further go and say MUST NOT but that probably is too much for 
a security consideration.

Best,

Nat

Nat Sakimura / n-sakim...@nri.co.jp / +81-90-6013-6276

このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、誠に申し訳ございませんが、送信者までお知らせ頂き、また受信されたメールは削除してくださいますようお願い申し上げます。

PLEASE READ :This e-mail is confidential and intended for the named recipient 
only.
If you are not an intended recipient, please notify the sender and delete this 
e-mail.


差出人: Torsten Lodderstedt 
送信日時: 水曜日, 11月 28, 2018 11:38 午後
宛先: n-sakimura
Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org
件名: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code 
instead of implicit

Hi Nat,

Am 28.11.2018 um 21:10 schrieb n-sakimura 
mailto:n-sakim...@nri.co.jp>>:

I would support

1) clearly defining Implicit as the flow that returns access token from the 
authorization endpoint ( some people confuses implicit as the flow that returns 
ID Token in the front channel)

That’s the current text:

In order to avoid these issues, Clients SHOULD NOT use the implicit
   grant or any other response type causing the authorization server to
   issue an access token in the authorization response.

What would you like to modify?


2) Banning the returning of the access token that are not sender constrained 
from the authorization endpoint

In order to avoid these issues, Clients SHOULD NOT use the implicit
   grant or any other response type causing the authorization server to
   issue an access token in the authorization response, if this access tokens 
is not sender-constraint.

What about this?

kind regards,
Torsten.


Best,

Nat


Outlook for iOS を入手

差出人: OAuth mailto:oauth-boun...@ietf..org>> (Dick Hardt 
mailto:dick.ha...@gmail.com>> の代理)
送信日時: 水曜日, 11月 28, 2018 8:58 午後
宛先: Hannes Tschofenig
Cc: oauth@ietf.org<mailto:oauth@ietf.org>
件名: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code 
instead of implicit

+1

While there are various mechanisms to alleviate some of the issues of implicit, 
I don't think we can recommend specifics, and there may be future ones in the 
future. I think we all agree that implicit without any mitigation is 
problematic.

How about we recommend against using implicit alone?


On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>> wrote:
Hi all,

The authors of the OAuth Security Topics draft came to the conclusion that it 
is not possible to adequately secure the implicit flow against token injection 
since potential solutions like token binding or JARM are in an early stage of 
adoption. For this reason, and since CORS allows browser-based apps to send 
requests to the token endpoint, Torsten suggested to use the authorization code 
instead of the implicit grant in call cases in his presentation (see 
https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).

A hum in the room at IETF#103 concluded strong support for his recommendations. 
We would like to confirm the discussion on the list.

Please provide a response by December 3rd.

Ciao

Hannes & Rifaat



IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

[n-sakimura]

I would support

1) clearly defining Implicit as the flow that returns access token from the 
authorization endpoint ( some people confuses implicit as the flow that returns 
ID Token in the front channel)

2) Banning the returning of the access token that are not sender constrained 
from the authorization endpoint

Best,

Nat


Outlook for iOS を入手


差出人: OAuth  (Dick Hardt  の代理)
送信日時: 水曜日, 11月 28, 2018 8:58 午後
宛先: Hannes Tschofenig
Cc: oauth@ietf.org
件名: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code 
instead of implicit

+1

While there are various mechanisms to alleviate some of the issues of implicit, 
I don't think we can recommend specifics, and there may be future ones in the 
future. I think we all agree that implicit without any mitigation is 
problematic.

How about we recommend against using implicit alone?


On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig 
mailto:hannes..tschofe...@arm.com>> wrote:

Hi all,

The authors of the OAuth Security Topics draft came to the conclusion that it 
is not possible to adequately secure the implicit flow against token injection 
since potential solutions like token binding or JARM are in an early stage of 
adoption. For this reason, and since CORS allows browser-based apps to send 
requests to the token endpoint, Torsten suggested to use the authorization code 
instead of the implicit grant in call cases in his presentation (see 
https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).

A hum in the room at IETF#103 concluded strong support for his recommendations. 
We would like to confirm the discussion on the list.

Please provide a response by December 3rd.

Ciao

Hannes & Rifaat

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
OAuth mailing 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] [Openid-specs-ab] OAuth Security Topics -- Recommend authorization code instead of implicit

[n-sakimura]

Not really.

It is not a requirement of SIOP to leverage the device’s secure element to 
create key-pairs. So, the keys can be exported and ported to other devices as 
well. There could be key syncing mechanism as well, like 1password, but it is 
not standardized.

Re: discovery
In the use-case of SIOP, from the client’s point of view, SIOP is always in the 
user’s device, i.e., localhost. So, there is no need for discovery.

Having said that: SIOP spec is a bit old and depends on custom scheme on iOS. 
Now iOS has newer capability like claimed URI, which is more secure. So, having 
a discovery mechanism that returns  [Self-issued Identifier – device type – 
claimed URI] triple kind of thing may be useful. (Note, I just came up with it 
now and it’s 2 AM here so it may be a bad idea after all.)


Nat Sakimura mailto:n-sakim...@nri.co.jp>>

PLEASE READ :This e-mail is confidential and intended for the named recipient 
only. If you are not an intended recipient, please notify the sender and delete 
this e-mail.



From: Tom Jones 
Sent: Wednesday, November 28, 2018 9:14 AM
To: Nat Sakimura 
Cc: Artifact Binding/Connect Working Group ; 
oauth@ietf.org; j...@manicode.com
Subject: Re: [Openid-specs-ab] [OAUTH-WG] OAuth Security Topics -- Recommend 
authorization code instead of implicit

I see, so then the self-issued ID is device-locked? it sounds more like a 
device ID than a user ID.  Which is useful, but not too helpful in a multiple 
device world. The screen i am using right now has 3 devices driving it in one 
form or another. Is there any way that a self-issued ID of this form can be 
made useful in today's world?  BTW - i like the idea of URN's rather than 
URL's, but some resolver capability seems to be a requirement?
Peace ..tom


On Tue, Nov 27, 2018 at 3:50 PM n-sakimura 
mailto:n-sakim...@nri.co.jp>> wrote:
Tom,

It is good to hear that you will be there.
I understand John will also be there.

To your question, self-issued ID does not require a (semi-)permanent URL as the 
user’s identifier, as it is always “localhost”.
The identifier is derived as the hash of the public key that was generated by 
the Self-issued OP.
If your question was “URI”, then yes. Its issuer is always 
https://self-issued.me and there is a `sub` for that identity, so synthesized 
URI for the user would be something like 
https://self-issued.me/{sub}<https://self-issued.me/%7bsub%7d> where {sub} 
represents the value of the `sub` claim. `sub` claim value is defined as 
follows:

sub (subject) Claim value is the base64url encoded representation of the 
thumbprint of the key in the sub_jwk Claim. This thumbprint value is computed 
as the SHA-256 hash of the octets of the UTF-8 representation of a JWK 
constructed containing only the REQUIRED members to represent the key, with the 
member names sorted into lexicographic order, and with no white space or line 
breaks. For instance, when the kty value is RSA, the member names e, kty, and n 
are the ones present in the constructed JWK used in the thumbprint computation 
and appear in that order; when the kty value is EC, the member names crv, kty, 
x, and y are present in that order. Note that this thumbprint calculation is 
the same as that defined in the JWK Thumbprint [JWK.Thumbprint]Jones, M., “JSON 
Web Key (JWK) Thumbprint,” July 
2014.<https://openid.net/specs/openid-connect-core-1_0.html#JWK.Thumbprint> 
specification.

So, yes. The string 
https://self-issued.me/{sub}<https://self-issued.me/%7bsub%7d> is 
probabilistically unique and “persistent” (better to phrase it as ‘never 
re-assigned’).

The reason it is not a “URL” is that you cannot reach it. However, It is a 
“URI”.

Cheers,


Nat Sakimura mailto:n-sakim...@nri.co.jp>>

PLEASE READ :This e-mail is confidential and intended for the named recipient 
only. If you are not an intended recipient, please notify the sender and delete 
this e-mail.



From: Openid-specs-ab 
mailto:openid-specs-ab-boun...@lists.openid.net>>
 On Behalf Of Tom Jones via Openid-specs-ab
Sent: Wednesday, November 28, 2018 8:16 AM
To: Artifact Binding/Connect Working Group 
mailto:openid-specs...@lists.openid.net>>
Cc: Tom Jones 
mailto:thomasclinganjo...@gmail.com>>; 
oauth@ietf.org<mailto:oauth@ietf.org>; 
j...@manicode.com<mailto:j...@manicode.com>
Subject: Re: [Openid-specs-ab] [OAUTH-WG] OAuth Security Topics -- Recommend 
authorization code instead of implicit

I am headed to a w3c meeting that will talk about DIDs for the future. I would 
like to understand if the self-issued ID requires (or should require) some sort 
of (semi) permanent URL on the internet. (including on a block-chain, for 
example.)  Without that i cannot understand what a self-issued ID might even 
mean.

Peace ..tom


On Tue, Nov 27, 2018 at 3:06 PM Nat Sakimura via Openid-specs-ab 
mailto:openid-specs...@lists.openid.net>> 
wrote:
Self Issued OP is described in Chapter 7 of the 

Re: [OAUTH-WG] [Openid-specs-ab] OAuth Security Topics -- Recommend authorization code instead of implicit

[n-sakimura]

Tom,

It is good to hear that you will be there.
I understand John will also be there.

To your question, self-issued ID does not require a (semi-)permanent URL as the 
user’s identifier, as it is always “localhost”.
The identifier is derived as the hash of the public key that was generated by 
the Self-issued OP.
If your question was “URI”, then yes. Its issuer is always 
https://self-issued.me and there is a `sub` for that identity, so synthesized 
URI for the user would be something like 
https://self-issued.me/{sub} where {sub} 
represents the value of the `sub` claim. `sub` claim value is defined as 
follows:

sub (subject) Claim value is the base64url encoded representation of the 
thumbprint of the key in the sub_jwk Claim. This thumbprint value is computed 
as the SHA-256 hash of the octets of the UTF-8 representation of a JWK 
constructed containing only the REQUIRED members to represent the key, with the 
member names sorted into lexicographic order, and with no white space or line 
breaks. For instance, when the kty value is RSA, the member names e, kty, and n 
are the ones present in the constructed JWK used in the thumbprint computation 
and appear in that order; when the kty value is EC, the member names crv, kty, 
x, and y are present in that order. Note that this thumbprint calculation is 
the same as that defined in the JWK Thumbprint [JWK.Thumbprint]Jones, M., “JSON 
Web Key (JWK) Thumbprint,” July 
2014. 
specification.

So, yes. The string 
https://self-issued.me/{sub} is 
probabilistically unique and “persistent” (better to phrase it as ‘never 
re-assigned’).

The reason it is not a “URL” is that you cannot reach it. However, It is a 
“URI”.

Cheers,


Nat Sakimura mailto:n-sakim...@nri.co.jp>>

PLEASE READ :This e-mail is confidential and intended for the named recipient 
only. If you are not an intended recipient, please notify the sender and delete 
this e-mail.



From: Openid-specs-ab  On Behalf Of 
Tom Jones via Openid-specs-ab
Sent: Wednesday, November 28, 2018 8:16 AM
To: Artifact Binding/Connect Working Group 
Cc: Tom Jones ; oauth@ietf.org; j...@manicode.com
Subject: Re: [Openid-specs-ab] [OAUTH-WG] OAuth Security Topics -- Recommend 
authorization code instead of implicit

I am headed to a w3c meeting that will talk about DIDs for the future. I would 
like to understand if the self-issued ID requires (or should require) some sort 
of (semi) permanent URL on the internet. (including on a block-chain, for 
example.)  Without that i cannot understand what a self-issued ID might even 
mean.

Peace ..tom


On Tue, Nov 27, 2018 at 3:06 PM Nat Sakimura via Openid-specs-ab 
mailto:openid-specs...@lists.openid.net>> 
wrote:
Self Issued OP is described in Chapter 7 of the OpenID Connect Core 1.0.
It lives on a local machine, typically a phone. Even if it did provide an 
authorization code to the client, the client cannot establish a direct 
connection to the local machine (phone) as it is not addressable. Therefore, a 
token endpoint cannot be provided unless it is coupled with some kind of 
cloud-based service, which would negate some of the very reason for having the 
Self-issued OP. In other words, only the viable communication channel between 
the SIOP and the client is the front channel. The situation could be true to 
other "wallet" type of implementations.

This is one of the exotic features of OpenID Connect that never got a traction 
but it is getting a renewed interest as "Self-sovereign Identity" gained some 
interest.



On Wed, Nov 28, 2018 at 6:03 AM Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>> wrote:
I still don’t understand why the use case must be solved using a flow issuing 
something in the front channel.

I would also like to take a closer look. Can you or Nat provide pointers to 
existing implementations?

> Am 27.11.2018 um 21:36 schrieb John Bradley 
> mailto:ve7...@ve7jtb.com>>:
>
> I understand that, but hat is Nat's concern as I understand it.
>
> When we say no implicit people, have a problem because implicit is imprecise.
>
> We are saying no AT returned in the response from the authorization endpoint.
>
> Nat points out that id_token may contain AT for the self issued client.
>
> So unless we say that is OK if the AT are sender constrained we wind up 
> implying that a OpenID profile of OAuth is in violation of the BCP.
>
> I am just trying to make sure everyone is on the same page with why Nat was 
> -1.
>
> It really has nothing to do with the SPA use case.
>
> John B.
>
>> On 11/27/2018 5:28 PM, Torsten Lodderstedt wrote:
>> Hi John,
>>
>> as you said, self issued IDPs 
>> (https://openid.net/specs/openid-connect-core-1_0.html#SelfIssued) are 
>> supposed to provide the response type „id_token“ only. I don’t think the 
>> proposal being discussed here is related to this OIDC mode.
>>
>> best regards,
>> Torst

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

[n-sakimura]

I am not sure about it. There are no confidential implicit grant client that 
uses bearer token is correct, but if the token is sender constrained, it can 
act as a confidential client.

Think of the case where an OP that is unreacheable directly from the client but 
only indirectly through the browser, e.g., Self-Issued OP and AS that are 
behind the corporate firewall. Then, such OP/AS can return a sender constrained 
token to the full confidential client that can use its keys to authenticate 
against the resource server when using the sender constrained access token. I 
categorize it as a confidential client.

So, IMHO, Rifaat’s point is correct.

Nat

From: OAuth  On Behalf Of John Bradley
Sent: Monday, November 26, 2018 5:56 AM
To: Rifaat Shekh-Yusef 
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code 
instead of implicit

There is no such thing as a implicit confidential client.

Implicit clients are not authenticated, so are not confidential.

You could have a hybrid client using the "code token" response type that is 
confidential for the code flow but i don't think anyone would consider the 
token returned from the authorization endpoint as confidential.

That should have been hybrid rather than confidential I suspect.  Perhaps a 
errata could be looked at.

John B.

On Sun, Nov 25, 2018, 4:55 PM Rifaat Shekh-Yusef 
mailto:rifaat.i...@gmail.com> wrote:
RFC6749, Section 3.1.2.2, implies that Implicit is not limited to public 
clients:

3.1.2.2.  Registration 
Requirements

   The authorization server MUST require the following clients to

   register their redirection endpoint:

   o  Public clients.

   o  Confidential clients utilizing the implicit grant type...


I do not know if anybody is using Implicit with Confidential clients, but just 
in case, you might want to make it clear that your recommendations are 
specifically for public clients.

Regards,
 Rifaat




On Sun, Nov 25, 2018 at 1:41 PM Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>> wrote:
Hi Rifaat,

this is a recommendation to anyone using implicit now. Implicit can only be 
used with public clients, so one could interpret it that way. I could also 
envision a SPA to use a backend, which in turn is a confidential client. There 
were some posts about this topic on the list recently.

Does this answer your question?

kind regards,
Torsten.

> Am 25.11.2018 um 19:22 schrieb Rifaat Shekh-Yusef 
> mailto:rifaat.i...@gmail.com>>:
>
> Hi Torsten,
>
> I am assuming that these recommendations are mainly for Public Clients, not 
> Confidential Clients; is that correct?
>
> Regards,
>  Rifaat
>
>
> On Sun, Nov 25, 2018 at 12:33 PM Torsten Lodderstedt 
> mailto:tors...@lodderstedt.net>> wrote:
> Hi all,
>
> I would like to state again what the proposal of the authors of the Security 
> BCP is:
>
> Here is the respective text from the draft:
>
> ——
>
> 2.1.2.  Implicit Grant
>
>The implicit grant (response type "token") and other response types
>causing the authorization server to issue access tokens in the
>authorization response are vulnerable to access token leakage and
>access token replay as described in Section 3.1, Section 3.2, Section 3.3, 
> and Section 3.6.
>
>Moreover, no viable mechanism exists to cryptographically bind access
>tokens issued in the authorization response to a certain client as it
>is recommended in Section 2.2.  This makes replay detection for such
>access tokens at resource servers impossible.
>
>In order to avoid these issues, Clients SHOULD NOT use the implicit
>grant or any other response type causing the authorization server to
>issue an access token in the authorization response.
>
>Clients SHOULD instead use the response type "code" (aka
>authorization code grant type) as specified in Section 2.1.1 or any
>other response type that causes the authorization server to issue
>access tokens in the token response.  This allows the authorization
>server to detect replay attempts and generally reduces the attack
>surface since access tokens are not exposed in URLs.  It also allows
>the authorization server to sender-constrain the issued tokens.
> ——
>
> In my observation, discouraging implicit seems to be the less controversial 
> issue.
>
> „or any other response type causing the authorization server to issue an 
> access token in the authorization response.“ in the 3rd paragraph caused 
> discussions because it suggests to discourage developers from using ANY 
> response type issuing access tokens in the authorization response. This 
> includes OIDC’s response types „token id_token“, „code token“ & „code token 
> id_token“, where at least  „token id_token“ is used in the wild to implement 
> SPAs.
>
> Why did we come up with this proposal given at least „token id_token“ & „code 
> token id_token“ protect against injection?
>
> Two reasons:
>

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[n-sakimura]

Good points.

Also, while it may be off-topic, I do see values in implicit flows. In some 
cases, such as when the AS is inside the firewall or on a localhost (e.g., 
smartphone), “code flow” is not possible as the client cannot reach the AS 
directly. Banning implicit (and thus “token id_token” as well) has this 
repercussion and I would not agree to it.

Best,

Nat Sakimura

From: OAuth  On Behalf Of Brock Allen
Sent: Friday, November 16, 2018 7:01 AM
To: Torsten Lodderstedt 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

> It still lacks the ability to issue sender constraint access tokens.

So you mean at the resource server ensuring the token was really issued to the 
client? Isn't that an inherent limitation of all bearer tokens (modulo HTTP 
token binding, which is still some time off)? Resource servers don't know the 
flow the clients might use, especially if/when they have many clients.

> The AS can bind the lifetime of the refresh tokens to the session lifetime, 
> i.e. automatically revoke it on logout.

Yea, I saw your other email asking about refresh token revocation relating to 
session management. Obviously for certain clients, this won't make sense, but 
for implicit/browser-based ones it's a nice feature to have.

The alternative, as you mentioned, is to not issue refresh tokens and do token 
renewal the "same old way" via iframe with prompt=none, while still using code 
flow.

> The only potential „baby step“ I would see is to move towards „token 
> id_token“. Since this requires signature/at_hash checks etc. I doubt this is 
> really easier than moving to code and exchange the code for an access token. 
> What’s your opinion?

Even since OIDC arrived, this is the only flow I use for JS/browser-based 
clients (anything less has always seemed so obviously inferior). So for me and 
my customers, all browser-based clients I am involved in are already there. 
Perhaps this is the reason for all of my questions/comments about the recent 
BCP doc. Given "id_token token", CSP, and using the browser history API to wipe 
the access token from browser history, we already have a decent set of tools to 
mitigate attacks. As I already conceded, the only remaining issue (IMO) is the 
short window of time the access token is in the URL.

Given that it seems to me that OIDC and OAuth2 are typically used together (at 
least when a user is involved with authentication), I always wonder why the 
OAuth and OIDC WGs are separate. Given that so much effort of the two sets of 
specs overlap, it seems odd to keep adding onto the OAuth specs and ignoring 
the added features that OIDC provides. I don't mean to derail this thread, or 
step on any political toes, so apologies in advance.


-Brock

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

Re: [OAUTH-WG] AS Discovery in Distributed Draft

[n-sakimura]

Hmmm. But the Link-header is the generalized discovery method which is pretty 
widely used outside of OAuth community with the added benefit of being able to 
find things without linking to authentication.

From: OAuth  On Behalf Of George Fletcher
Sent: Friday, November 09, 2018 12:12 AM
To: Dick Hardt ; gffletch=40aol@dmarc.ietf.org
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] AS Discovery in Distributed Draft

Cool! Sorry I couldn't make the meeting. One benefit of using WWW-Authenticate 
is that UMA has basically the same discovery logic (from RS to AS) and uses the 
WWW-Authenticate header. Keeping this discovery method the same (since UMA is 
just a profile of OAuth anyway) will help all developers.
On 11/8/18 5:16 AM, Dick Hardt wrote:
George: in the WG meeting we discussed this topic of where to put the discovery 
information. No one at the meeting advocated for using Link response (Nat was 
the one who was advocating for this). Many others preferred using the 
www-authenticate header similar to how you propose.

On Thu, Nov 8, 2018 at 4:08 AM George Fletcher 
mailto:40aol@dmarc.ietf..org>> wrote:
Related to this discussion of AS discovery... what is the value of using the 
Link response header over just returning the variables in the WWW-Authenticate 
header? Could we not use...

WWW-Authenticate: OAuth realm="example_realm", scope="example_scope", 
error="invalid_token", 
rs_uri="https://api.example.com/resource";, 
as_uri="https://as1.example.com,https://as2.example.com";

Thanks,
George
On 11/6/18 12:19 AM, Justin P Richer wrote:
In the meeting tonight I brought up a response to the question of whether to 
have full URL or plain issuer for the auth server in the RS response’s header. 
My suggestion was that we have two different parameters to the header to 
represent the AS: one of them being the full URL (as_uri) and one of them being 
the issuer to be constructed somehow (as_issuer). I ran into a similar problem 
on a system that I built last year where all of our servers had discovery 
documents but not all of them were easily constructed from an issuer style URL 
(using OIDC patterns anyway). So we solved it by having two different 
variables. If the full URL was set, we used that; if it wasn’t, we tried the 
issuer; if neither was set we didn’t do any discovery.

I’m sensitive to Torsten’s concerns about complexity, but I think this is a 
simple and deterministic solution that sidesteps much of the issue. No pun 
intended.

— 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
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-jwsreq-17.txt

[n-sakimura]

Just updated a typo that was pointed out.
BTW, the spec has not progressed for a long time. I wonder what can I do to 
push it through.

Nat

差出人: internet-dra...@ietf.org
送信日時: 日曜日, 10月 21, 2018 11:17 午後
宛先: Nat Sakimura; John Bradley
件名: New Version Notification for draft-ietf-oauth-jwsreq-17.txt


A new version of I-D, draft-ietf-oauth-jwsreq-17.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Name: draft-ietf-oauth-jwsreq
Revision: 17
Title: The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request 
(JAR)
Document date: 2018-10-21
Group: oauth
Pages: 27
URL: https://www.ietf.org/internet-drafts/draft-ietf-oauth-jwsreq-17.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
Htmlized: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17
Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq
Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-17

Abstract:
The authorization request in OAuth 2.0 described in RFC 6749 utilizes
query parameter serialization, which means that Authorization Request
parameters are encoded in the URI of the request and sent through
user agents such as web browsers. While it is easy to implement, it
means that (a) the communication through the user agents are not
integrity protected and thus the parameters can be tainted, and (b)
the source of the communication is not authenticated. Because of
these weaknesses, several attacks to the protocol have now been put
forward.

This document introduces the ability to send request parameters in a
JSON Web Token (JWT) instead, which allows the request to be signed
with JSON Web Signature (JWS) and encrypted with JSON Web Encryption
(JWE) so that the integrity, source authentication and
confidentiality property of the Authorization Request is attained.
The request can be sent by value or by reference.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

Re: [OAUTH-WG] updated Distributed OAuth ID

[n-sakimura]

Hi David,

Thanks for the comment, and sorry for the delay in my reply.

Doing it with Web Linking [RFC8288]  has several advantages.


  1.  It is standard based ☺ It is just a matter of registering link relations 
to the IANA Link Relation Type Registry, and it is quite widely used.
  2.  No or very little coding needed: Other than adding some HTTP server 
configuration, the rest stays the same as RFC6750.
  3.  Standard interface: this kind of metadata is applicable not only for 
letting the client find the appropriate authorization server but for other 
metadata as well. Also, other endpoints as long as it is supporting the direct 
communication with the client, can provide relevant metadata with it without 
going through the client authorization.

I did not quite follow why CORS is relevant here. We are just talking about the 
client to server communication, and there are no embedded resources in the 
response. Could you kindly elaborate a little, please?

For the second point, since it was discussed in the WG meeting yesterday, I 
will defer to that discussion.

Best,

Nat Sakimura


From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of David Waite
Sent: Thursday, July 19, 2018 4:55 PM
To: Dick Hardt 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] updated Distributed OAuth ID

Four comments.

First: What is the rationale for including the parameters as Link headers 
rather than part of the WWW-Authenticate challenge, e.g.:

WWW-Authenticate: Bearer realm="example_realm",
 scope="example_scope",
 error=“invalid_token",
resource_uri="https://api.example.com/resource";,

oauth_server_metadata_uris="https://as.example.com/.well-known/oauth-authorization-server
 https://different-as.example.com/.well-known/oauth-authorization-server";

My understanding is that the RFC6750 auth-params are extensible (but not 
currently part of any managed registry.)

One reason to go with this vs Link headers is CORS policy - exposing Link 
headers to a remote client must be done all or nothing as part of the CORS 
policy, and can’t be limited by the kind of link.

Second: (retaining link format) Is there a reason the metadata location is 
specified the way it is? It seems like

; 
rel=“oauth_server_metadata_uri"

should be

; rel=“oauth_issuer"

OAuth defines the location of metadata under the .well-known endpoint as a 
MUST. An extension of OAuth may choose from at least three different methods 
for handling extensions beyond this:
1. Add additional keys to the oauth-authorization-server metadata
2. Add additional resources to .well-known for clients to supporting their 
extensions to attempt to resolve, treating ‘regular’ OAuth as a fallback.
3. Define their own parameter, such as rel=“specialauth_issuer”, potentially 
using a different mechanism for specifying metadata

Given all this, it seems appropriate to only support specifying of 
metadata-supplying issuers, not metadata uris.

Third: I have doubts of the usefulness of resource_uri in parallel to both the 
client requested URI and the Authorization “realm” parameter.

As currently defined, the client would be the one enforcing (or possibly 
ignoring) static policy around resource URIs - that a resource URI is arbitrary 
except in that it must match the host (and scheme/port?) of the requested URI. 
The information on the requested URI by the client is not shared between the 
client and AS for it to do its own policy verification. It would seem better to 
send the client origin to the AS for it to do (potential) policy verification, 
rather than relying on clients to implement it for them based on static spec 
policy.

The name “resource URI” is also confusing, as I would expect it to be the URI 
that was requested by the client. The purpose of this parameter is a bit 
confusing, as it is only defined as “An OAuth 2.0 Resource Endpoint specified 
in [RFC6750] section 3.2 - where the term doesn’t appear in 6750 and there does 
not appear to be a section 3.2 ;-)

It seems that:
a. If the resource_uri is a direct match for the URI requested for the client, 
it is redundant and should be dropped
(If the resource URI is *not* a direct match with the URI of the resource 
requested by the client, it might need a better name).
b. If the resource URI is meant to provide a certain arbitrary grouping for 
applying tokens within the origin of the resource server, what is its value 
over the preexisting “ realm” parameter?
c. If the resource URI is meant to provide a way for an AS to allow resources 
to be independent, identified entities on a single origin - I’m unsure how a 
client would understand it is meant to treat these resource URIs as independent 
entities (e.g. be sure not to send bearer tokens minted for resource /entity1 
to /entity2, or for that matter prevent /entity1 from requesting tokens for 
/entity2).

Admi

Re: [OAUTH-WG] Call for adoption for "Distributed OAuth"

[n-sakimura]

And if it were not obvious, YES ☺

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Dick Hardt
Sent: Friday, July 20, 2018 6:12 AM
To: Rifaat Shekh-Yusef 
Cc: oauth 
Subject: Re: [OAUTH-WG] Call for adoption for "Distributed OAuth"

I'm supportive. :)

On Thu, Jul 19, 2018 at 4:05 PM, Rifaat Shekh-Yusef 
mailto:rifaat.i...@gmail.com>> wrote:
Hi all,

This is the call for adoption of the 'Distributed OAuth' document
following the positive call for adoption at the Montreal IETF meeting.

Here is the document:
https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/

Please let us know by August 2nd whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Regards,
Hannes & Rifaat


___
OAuth mailing 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] Call for adoption for "Resource Indicators for OAuth 2.0"

[n-sakimura]

+1

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Friday, July 20, 2018 7:42 AM
To: Rifaat Shekh-Yusef 
Cc: oauth 
Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 
2.0"

I support adoption of this document.

On Thu, Jul 19, 2018 at 4:01 PM, Rifaat Shekh-Yusef 
mailto:rifaat.i...@gmail.com>> wrote:
Hi all,

This is the call for adoption of the 'Resource Indicators for OAuth 2.0' 
document
following the positive call for adoption at the Montreal IETF meeting.

Here is the document:
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02

Please let us know by August 2nd whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Regards,
Rifaat

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


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited..  If you have 
received this communication in error, please notify the sender immediately by 
e-mail and delete the message and any file attachments from your computer. 
Thank you.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Dynamic Scopes

[n-sakimura]

Torsten,

For the digital signature case, I feel a bit uneasy to sign the hash that was 
sent by the client. The signing mechanism, a bank in this case, should display 
what is being signed to the user before the user makes a signature. The staging 
strategy works here as well. The client sends the signed document to the 
staging server and the bank verifies the signature and shows the document to 
the user, where the user can view the document and when he decides to sign it, 
the signature over the document’s hash will be made so that it will result in a 
mutually signed document.

Best,

Nat

Nat Sakimura
このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、送信者にご連絡のうえ、このメールを削除してくださいますようお願い申し上げます。

PLEASE READ：This e-mail is confidential and intended for the named recipient 
only. If you are not an intended recipient, please notify the sender and delete 
this e-mail.

From: OAuth  on behalf of Torsten Lodderstedt 

Sent: Saturday, June 23, 2018 3:43:50 AM
To: George Fletcher
Cc: Brian Campbell; oauth
Subject: Re: [OAUTH-WG] Dynamic Scopes



> Am 22.06.2018 um 23:08 schrieb George Fletcher :
>
> I would think that the scope issued to the refresh_token could represent the 
> category or class of authorizations the refresh_token should be able to 
> perform. For example, the kind of transactions that can be bound to access 
> tokens. The scope issued into the access_token could be one of the 
> "parameterized" ones. But maybe I'm not fully understanding the use case :)

Let me try to explain ;-)

The client is an issuance company wanting the customer to electronically sign a 
new contract (legally binding!). Signing in the end means to send a request 
containing the hash of the document to an API. The API will respond with an 
CM/S Object containing signature, certificate etc that the client will embedded 
in the contract document (typical PDF).

We want the user to authorize the signing request using their bank as IDP/AS.. 
Therefore the client sends the OAuth authorization request to the AS. The 
actual signing request needs to be bound to client, user AND hash (document) in 
order to prevent fraud. Regulation (eIDAS) requires to always demonstrate the 
sole control of the user over the whole process. The AS therefore binds 
(scopes) the access token to exactly this single document/signing request. If 
the client wants the user to sign another document, it needs to got through the 
whole process again.

One could think about a general signing permission represented by a refresh 
token, but not in the high assurance level cases I‘m looking into.

Hope that helps,
Torsten.


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

Re: [OAUTH-WG] Call for agenda items

[n-sakimura]

I support the idea. Adding to it, perhaps we can do an ad-hoc before Montreal 
so that we can come up with a combined draft.

Nat Sakimura
--
PLEASE READ: This e-mail is confidential and intended for the named recipient 
only. If you are not an intended recipient, please notify the sender and delete 
this e-mail.






差出人: Dick Hardt 
送信日時: 2018年4月18日 0:40:20
宛先: n-sakimura
CC: Rifaat Shekh-Yusef; oauth
件名: Re: [OAUTH-WG] Call for agenda items

**
本メールはフリーメールから届いています。標的型攻撃メールはフリーメ
ールから届くことがありますのでご注意ください。身に覚えのないメール
であれば添付ファイルやURLを開かず、以下に掲載されている手順に従っ
て対応をお願いします。

共有情報>情報セキュリティトピックス>怪しいメールが届いたら
または、
NRI Group Security Portal>情報セキュリティトピックス
>怪しいメールが届いたら
**
I'd like to coordinate a side meeting with Nat, Brian, myself and other 
interested parties in Montreal to discuss Distributed OAuth.

If we have two meetings, I'd like a timeslot in the second to summarize the 
side meeting and discuss next steps (if any).

Separately, I'd like a time slot for an update on Reciprocal OAuth.

On Wed, Mar 7, 2018 at 5:52 PM, n-sakimura 
mailto:n-sakim...@nri.co.jp>> wrote:

No, not really. I was thinking of more informal thing. The session is supposed 
to be Wednesday afternoon, so I was thinking that it might be a good idea to do 
a bit of recap among contributors to draw up a battle plan towards IETF 102.



Nat



From: Rifaat Shekh-Yusef 
[mailto:rifaat.i...@gmail.com<mailto:rifaat.i...@gmail.com>]
Sent: Wednesday, March 07, 2018 9:22 PM
To: n-sakimura mailto:n-sakim...@nri.co.jp>>
Cc: Brian Campbell 
mailto:bcampb...@pingidentity.com>>; oauth 
mailto:oauth@ietf.org>>

Subject: Re: [OAUTH-WG] Call for agenda items



Nat,



Are you asking for an interim meeting?

We could schedule the Distributed OAuth discussion for the Wednesday meeting; 
that will give you guys sometime to discuss these face-to-face in London..



Regards,

 Rifaat







On Wed, Mar 7, 2018 at 2:00 AM, n-sakimura 
mailto:n-sakim...@nri.co.jp>> wrote:

Then let us do it. We need to put all the proposals on the table and strategize 
the design.

Perhaps we need a side meeting as well.



nat



From: OAuth [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On 
Behalf Of Brian Campbell
Sent: Wednesday, March 07, 2018 1:31 AM
To: Rifaat Shekh-Yusef mailto:rifaat.i...@gmail.com>>
Cc: oauth mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Call for agenda items



I hadn't previously been planning on it but am happy to do so.



On Tue, Mar 6, 2018 at 8:22 AM, Rifaat Shekh-Yusef 
mailto:rifaat.i...@gmail.com>> wrote:

Nat,



During the interim meeting, 3 drafts mentioned in the context of Distributed 
OAuth:



https://tools.ietf.org/html/draft-sakimura-oauth-meta-08

https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02

https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00





Brian, Hannes,



Are you planning on presenting your documents?



Regards,

 Rifaat













On Mon, Mar 5, 2018 at 8:09 PM, Nat Sakimura 
mailto:sakim...@gmail.com>> wrote:

I would be interested in hearing that.



Also, as part of "Distributed OAuth", can we do a bit of re-cap on some of the 
previous drafts on the similar topic as we discussed in the interim? i.e., 
Brian's draft (where is the link now?) and my draft 
(draft-sakimura-oauth-meta<https://tools.ietf.org/id/draft-sakimura-oauth-meta-08.txt>)?



Best,



Nat



On Tue, Mar 6, 2018 at 3:30 AM William Denniss 
mailto:wdenn...@google.com>> wrote:

Hannes & Rifaat,

I would like the opportunity to present on OAuth 2.0 Incremental Authorization 
(draft-wdenniss-oauth-incremental-auth) [an update for which will be posted 
today] and "OAuth 2.0 Device Posture Signals" 
(draft-wdenniss-oauth-device-posture).



I can also give an update on the status of Device Flow 
(draft-ietf-oauth-device-flow). I expect that to be short now that WGLC has 
concluded and the document has advanced.



Little late to this thread and I see we already have 2 sessions in the draft 
agenda, but I'd like to add my support to keeping both sessions, there's always 
a lot to discuss and in the past we've been able to use any spare time to 
discuss the security topics of the day.



Regards,

William







On Tue, Jan 30, 2018 at 4:40 AM Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>> wrote:

Hi all,



It is time already to think about the agenda for the next IETF meeting. Rifaat 
and I were wondering whether we need one or two sessions. We would like to make 
the decision based on the topics we will discuss. Below you can find a first 
version of the agenda with a few remarks. Let us know if you have comments or 
suggestions for additional agenda items.



Ciao
Hannes & Rifaat

Re: [OAUTH-WG] Call for agenda items

[n-sakimura]

No, not really. I was thinking of more informal thing. The session is supposed 
to be Wednesday afternoon, so I was thinking that it might be a good idea to do 
a bit of recap among contributors to draw up a battle plan towards IETF 102.

Nat

From: Rifaat Shekh-Yusef [mailto:rifaat.i...@gmail.com]
Sent: Wednesday, March 07, 2018 9:22 PM
To: n-sakimura 
Cc: Brian Campbell ; oauth 
Subject: Re: [OAUTH-WG] Call for agenda items

Nat,

Are you asking for an interim meeting?
We could schedule the Distributed OAuth discussion for the Wednesday meeting; 
that will give you guys sometime to discuss these face-to-face in London.

Regards,
 Rifaat



On Wed, Mar 7, 2018 at 2:00 AM, n-sakimura 
mailto:n-sakim...@nri.co.jp>> wrote:
Then let us do it. We need to put all the proposals on the table and strategize 
the design.
Perhaps we need a side meeting as well.

nat

From: OAuth [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On 
Behalf Of Brian Campbell
Sent: Wednesday, March 07, 2018 1:31 AM
To: Rifaat Shekh-Yusef mailto:rifaat.i...@gmail.com>>
Cc: oauth mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Call for agenda items

I hadn't previously been planning on it but am happy to do so.

On Tue, Mar 6, 2018 at 8:22 AM, Rifaat Shekh-Yusef 
mailto:rifaat.i...@gmail.com>> wrote:
Nat,

During the interim meeting, 3 drafts mentioned in the context of Distributed 
OAuth:

https://tools.ietf.org/html/draft-sakimura-oauth-meta-08
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02
https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00


Brian, Hannes,

Are you planning on presenting your documents?

Regards,
 Rifaat






On Mon, Mar 5, 2018 at 8:09 PM, Nat Sakimura 
mailto:sakim...@gmail.com>> wrote:
I would be interested in hearing that.

Also, as part of "Distributed OAuth", can we do a bit of re-cap on some of the 
previous drafts on the similar topic as we discussed in the interim? i.e., 
Brian's draft (where is the link now?) and my draft 
(draft-sakimura-oauth-meta<https://tools.ietf.org/id/draft-sakimura-oauth-meta-08.txt>)?

Best,

Nat

On Tue, Mar 6, 2018 at 3:30 AM William Denniss 
mailto:wdenn...@google.com>> wrote:
Hannes & Rifaat,

I would like the opportunity to present on OAuth 2.0 Incremental Authorization 
(draft-wdenniss-oauth-incremental-auth) [an update for which will be posted 
today] and "OAuth 2.0 Device Posture Signals" 
(draft-wdenniss-oauth-device-posture).

I can also give an update on the status of Device Flow 
(draft-ietf-oauth-device-flow). I expect that to be short now that WGLC has 
concluded and the document has advanced.

Little late to this thread and I see we already have 2 sessions in the draft 
agenda, but I'd like to add my support to keeping both sessions, there's always 
a lot to discuss and in the past we've been able to use any spare time to 
discuss the security topics of the day.

Regards,
William



On Tue, Jan 30, 2018 at 4:40 AM Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>> wrote:
Hi all,

It is time already to think about the agenda for the next IETF meeting. Rifaat 
and I were wondering whether we need one or two sessions. We would like to make 
the decision based on the topics we will discuss. Below you can find a first 
version of the agenda with a few remarks. Let us know if you have comments or 
suggestions for additional agenda items.

Ciao
Hannes & Rifaat

OAuth Agenda


- Welcome and Status Update  (Chairs)

  * OAuth Security Workshop Report

  * Documents in IESG processing
 # draft-ietf-oauth-device-flow-07
 # draft-ietf-oauth-discovery-08
 # draft-ietf-oauth-jwsreq-15
 # draft-ietf-oauth-token-exchange-11

   Remark: Status updates only if needed.

-  JSON Web Token Best Current Practices
   # draft-ietf-oauth-jwt-bcp-00

   Remark: We are lacking reviews on this document.
   Most likely we will not get them during the f2f meeting
   but rather by reaching out to individuals ahead of time.

-  OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access 
Tokens
   # draft-ietf-oauth-mtls-06

   Remark: Could be completed by the time of the IETF meeting.

- OAuth Security Topics
  # draft-ietf-oauth-security-topics-04

  Remark: We could do a consensus call on parts of the document soon.

- OAuth 2.0 Token Binding
  # draft-ietf-oauth-token-binding-05

  Remark: Document is moving along but we are lacking implementations.

- OAuth 2.0 Device Posture Signals
  # draft-wdenniss-oauth-device-posture-01

  Remark: Interest in the work but we are lacking content (maybe even
  expertise in the group)

- Reciprocal OAuth
  # draft-hardt-oauth-mutual-02

  Remark: We had a virtual interim meeting on this topic and there is
  interest in this work and apparently no competing solutions. The plan
  is to run a call for adoption once we are allowed to add a new milestone
  to

Re: [OAUTH-WG] Call for agenda items

[n-sakimura]

Then let us do it. We need to put all the proposals on the table and strategize 
the design.
Perhaps we need a side meeting as well.

nat

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Wednesday, March 07, 2018 1:31 AM
To: Rifaat Shekh-Yusef 
Cc: oauth 
Subject: Re: [OAUTH-WG] Call for agenda items

I hadn't previously been planning on it but am happy to do so.

On Tue, Mar 6, 2018 at 8:22 AM, Rifaat Shekh-Yusef 
mailto:rifaat.i...@gmail.com>> wrote:
Nat,

During the interim meeting, 3 drafts mentioned in the context of Distributed 
OAuth:

https://tools.ietf.org/html/draft-sakimura-oauth-meta-08
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02
https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00


Brian, Hannes,

Are you planning on presenting your documents?

Regards,
 Rifaat






On Mon, Mar 5, 2018 at 8:09 PM, Nat Sakimura 
mailto:sakim...@gmail.com>> wrote:
I would be interested in hearing that.

Also, as part of "Distributed OAuth", can we do a bit of re-cap on some of the 
previous drafts on the similar topic as we discussed in the interim? i.e., 
Brian's draft (where is the link now?) and my draft 
(draft-sakimura-oauth-meta)?

Best,

Nat

On Tue, Mar 6, 2018 at 3:30 AM William Denniss 
mailto:wdenn...@google.com>> wrote:
Hannes & Rifaat,

I would like the opportunity to present on OAuth 2.0 Incremental Authorization 
(draft-wdenniss-oauth-incremental-auth) [an update for which will be posted 
today] and "OAuth 2.0 Device Posture Signals" 
(draft-wdenniss-oauth-device-posture).

I can also give an update on the status of Device Flow 
(draft-ietf-oauth-device-flow). I expect that to be short now that WGLC has 
concluded and the document has advanced.

Little late to this thread and I see we already have 2 sessions in the draft 
agenda, but I'd like to add my support to keeping both sessions, there's always 
a lot to discuss and in the past we've been able to use any spare time to 
discuss the security topics of the day.

Regards,
William



On Tue, Jan 30, 2018 at 4:40 AM Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>> wrote:
Hi all,

It is time already to think about the agenda for the next IETF meeting. Rifaat 
and I were wondering whether we need one or two sessions. We would like to make 
the decision based on the topics we will discuss. Below you can find a first 
version of the agenda with a few remarks. Let us know if you have comments or 
suggestions for additional agenda items.

Ciao
Hannes & Rifaat

OAuth Agenda


- Welcome and Status Update  (Chairs)

  * OAuth Security Workshop Report

  * Documents in IESG processing
 # draft-ietf-oauth-device-flow-07
 # draft-ietf-oauth-discovery-08
 # draft-ietf-oauth-jwsreq-15
 # draft-ietf-oauth-token-exchange-11

   Remark: Status updates only if needed.

-  JSON Web Token Best Current Practices
   # draft-ietf-oauth-jwt-bcp-00

   Remark: We are lacking reviews on this document.
   Most likely we will not get them during the f2f meeting
   but rather by reaching out to individuals ahead of time.

-  OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access 
Tokens
   # draft-ietf-oauth-mtls-06

   Remark: Could be completed by the time of the IETF meeting.

- OAuth Security Topics
  # draft-ietf-oauth-security-topics-04

  Remark: We could do a consensus call on parts of the document soon.

- OAuth 2.0 Token Binding
  # draft-ietf-oauth-token-binding-05

  Remark: Document is moving along but we are lacking implementations.

- OAuth 2.0 Device Posture Signals
  # draft-wdenniss-oauth-device-posture-01

  Remark: Interest in the work but we are lacking content (maybe even
  expertise in the group)

- Reciprocal OAuth
  # draft-hardt-oauth-mutual-02

  Remark: We had a virtual interim meeting on this topic and there is
  interest in this work and apparently no competing solutions. The plan
  is to run a call for adoption once we are allowed to add a new milestone
  to our charter.

- Distributed OAuth
  # draft-hardt-oauth-distributed-00

  Remark: We had a virtual interim meeting on this topic and there is
  interest in this work. Further work on the scope is needed.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
OAuth mailing 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

Chairman of the Board, OpenID Foundation

___

[OAUTH-WG] FW: Call for Participation - Third OAuth Security Workshop (OSW 2018)

[n-sakimura]

FYI. It is on the week before the IETF 101 London. 

Bunch of us are going to be there discussing security aspect of OAuth. 

Nat

-Original Message-
From: Roberto Carbone  
Sent: Tuesday, March 06, 2018 3:07 AM

Subject: Call for Participation - Third OAuth Security Workshop (OSW 2018)

Dear all,

let me remind you that the OAuth Security Workshop 2018 will take place next 
week in Trento (Italy).
Please find below the call for participation.
See you in Trento,

Best regards,
Roberto

---

Call for Participation


Third OAuth Security Workshop (OSW 2018) Fondazione Bruno Kessler Trento, Italy 
March 14-16, 2018 Workshop website: https://st.fbk.eu/osw2018


== About OSW 2018 ==

The OAuth Security Workshop (OSW) aim is to improve the security of OAuth and 
related Internet protocols by a direct exchange of views between academic 
researchers, IETF OAuth Working Group members and industry. The workshop is 
hosted by the Security and Trust research unit of the Bruno Kessler Foundation 
(FBK).

While the standardization process of OAuth ensures extensive reviews (both 
security and non-security related), further analysis by security experts from 
academia and industry is essential to ensure high quality specifications. 
Contributions to this workshop can help to improve the security of the Web and 
the Internet.


==Program==

The program is available at https://st.fbk.eu/osw2018/program


==Registration==

Registration information is available at https://st.fbk.eu/osw2018/registration


== Important Dates ==

- Online Registration: until March 11, 2018
- Workshop: Wed, March 14, 2018 (half-day), Thu, March 15, 2018 (full-day),
  and Fri, March 16, 2018 (half day)


== Workshop Chair ==

- Silvio Ranise (Security & Trust, Fondazione Bruno Kessler)


== Program Committee ==

Chairs
- Roberto Carbone (Security & Trust, Fondazione Bruno Kessler)
- Hannes Tschofenig (IETF OAuth Working Group Co-Chair)

Members
- Michael Jones (Microsoft)
- Ralf Kuesters (University of Stuttgart)
- Torsten Lodderstedt (YES Europe AG)
- Chris Mitchell (Royal Holloway, University of London)
- Anthony Nadalin (Microsoft)
- Nat Sakimura (Nomura Research Institute)
- Antonio Sanso (Adobe)
- Ralf Sasse (ETH Zurich)
- Joerg Schwenk (Ruhr-Universität Bochum)
- Giada Sciarretta (Security & Trust, Fondazione Bruno Kessler and Univ. of 
Trento)


== Conference site and contacts ==

For more detailed information please refer to the workshop web site:
https://st.fbk.eu/osw2018

If you have any questions on OSW18, please contact carbone [at] fbk [dot] eu, 
giada.sciarretta [at] fbk [dot] eu

--
--
Le informazioni contenute nella presente comunicazione sono di natura privata e 
come tali sono da considerarsi riservate ed indirizzate esclusivamente ai 
destinatari indicati e per le finalità strettamente legate al relativo 
contenuto. Se avete ricevuto questo messaggio per errore, vi preghiamo di 
eliminarlo e di inviare una comunicazione all’indirizzo e-mail del mittente.
--
The information transmitted is intended only for the person or entity to which 
it is addressed and may contain confidential and/or privileged material. If you 
received this in error, please contact the sender and delete the material.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] FW: New Version Notification for draft-ietf-oauth-jwsreq-15.txt

[n-sakimura]

Right. It has been hanging there since July... 

Nat

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Vladimir Dzhuvinov
Sent: Friday, February 09, 2018 5:03 PM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] FW: New Version Notification for 
draft-ietf-oauth-jwsreq-15.txt

Hi Nat,

I suppose you saw the FAPI WG ticket to consider adding an AS metadata 
parameter for the request object endpoint:

https://bitbucket.org/openid/fapi/issues/134/

Perhaps that issue should be addressed here, in the OAuth WG. But I'm not sure 
what can be done at this stage, with draft-ietf-oauth-jwsreq-15 have gone to 
the IESG.

Vladimir


On 21/07/17 16:25, Nat Sakimura wrote:
> Hi
>
> This version hopefully have addressed all the comments that I received during 
> IESG review. 
> I also added RFC8141 as the reference to URN. 
>
> The main difference from -12 that was posted in March are: 
>
> 1) Now, all the parameters to be used MUST reside within the request object. 
>(It is still possible to be duplicated but they are ignored from 
> the security point of view by the server that supports this spec.)
> 2) Clarified that when request object is stored by the authorization server, 
> `request_uri` can be a URN. 
> 3) Added text on the security risks of using `request_uri` in the security 
> consideration. 
>
> Best,
>
> Nat Sakimura
>
> --
> PLEASE READ :This e-mail is confidential and intended for the named recipient 
> only. If you are not an intended recipient, please notify the sender  and 
> delete this e-mail.
>
>
>> -Original Message-
>> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
>> Sent: Friday, July 21, 2017 10:14 PM
>> To: Nat Sakimura ; John Bradley 
>> 
>> Subject: New Version Notification for draft-ietf-oauth-jwsreq-15.txt
>>
>>
>> A new version of I-D, draft-ietf-oauth-jwsreq-15.txt has been 
>> successfully submitted by Nat Sakimura and posted to the IETF repository.
>>
>> Name:draft-ietf-oauth-jwsreq
>> Revision:15
>> Title:   The OAuth 2.0 Authorization Framework: JWT Secured
>> Authorization Request (JAR)
>> Document date:   2017-07-21
>> Group:   oauth
>> Pages:   26
>> URL:
>> https://www.ietf.org/internet-drafts/draft-ietf-oauth-jwsreq-15.txt
>> Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
>> Htmlized:   https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-15
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-15
>> Diff:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-15
>>
>> Abstract:
>>The authorization request in OAuth 2.0 described in RFC 6749 utilizes
>>query parameter serialization, which means that Authorization Request
>>parameters are encoded in the URI of the request and sent through
>>user agents such as web browsers.  While it is easy to implement, it
>>means that (a) the communication through the user agents are not
>>integrity protected and thus the parameters can be tainted, and (b)
>>the source of the communication is not authenticated.  Because of
>>these weaknesses, several attacks to the protocol have now been put
>>forward.
>>
>>This document introduces the ability to send request parameters in a
>>JSON Web Token (JWT) instead, which allows the request to be signed
>>with JSON Web Signature (JWS) and encrypted with JSON Web Encryption
>>(JWE) so that the integrity, source authentication and
>>confidentiality property of the Authorization Request is attained.
>>The request can be sent by value or by reference.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of 
>> submission until the htmlized version and diff are available at 
>> tools.ietf.org.
>>
>> 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