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

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

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

[Nat Sakimura]

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 
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 :
> >
> > 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,
> >> Torsten.
> >>
> >>> Am 27.11.2018 um 20:54 schrieb John Bradley :
> >>>
> >>> I talked to Nat about this a bit today.
> >>>
> >>> The thing he is concerned about is mostly around the self issued IDP
> that doesn't have a token endpoint(atleast not easaly).
> >>>
> >>> The main use case for that is the id_token response type where claims
> are retuned in the id_token.
> >>>
> >>> Because it is fragment encoded some people call that implicit.   That
> is not what we are trying to stop.
> >>>
> >>> In some cases in that flow there may be distributed claims returned
> with access Token inside the id_token.I think most people would agree
> that those should be pop or sender constrained tokens.
> >>>
> >>> In the case of self issued the RP would be a server and could do
> sender constrained via some mechinisim that is yet to be defined.
> >>>
> >>> So if someone wanted to return a access token in a id_token to do
> distributed claims I don't think we have a problem with that as long as the
> token is protected by being sender constrained in some reasonable way.
> >>>
> >>> This is a touch hypothetical from the basic OAuth perspective, so I
> don't know how deep we want to go into it.
> >>>
> >>> I think the point is not to accidently prohibit something that could
> be done in future.
> >>>
> >>> I also think we should not conflate confidential clients that can
> authenticate to the token endpoint with sender constrained/PoP clients that
> can deal with bound tokens.   Yes both have keys but it is better to
> describe them separately.
> >>>
> >>> John B.
> >>>
> >>> On Tue, Nov 27, 2018, 4:30 PM Torsten Lodderstedt via Openid-specs-ab <
> openid-specs...@lists.openid.net wrote:
> >>> Hi Nat,
> >>>
> >>> I understand you are saying your draft could provide clients with an
> application level mechanism to sender constrain access tokens. That’s great!
> >>>
> >>> But I don’t see a binding to response type „token id_token“. Why do
> you want to expose the tokens via the URL to attackers?
> >>>
> >>> You could easily use your mechanism with code. That would also give
> you the chance to really authenticate the confidential client before you
> issue the token.
> >>>
> >>> kind regards,
> >>> Torsten.
> >>>
>  Am 27.11.2018 um 16:57 schrieb Nat Sakimura :
> 
>  I am not talking about SPA.
>  The client is a regular confidential client that is running on a
> server.
> 
>  Best,
> 
>  Nat Sakimura
> 
> 
>  2018年11月27日(火) 16:55 Jim Manico :
>  Nat,
> 
>  How is proof of possession established in a modern web browser in the
> implicit flow?
> 
>  My understanding is that token binding was removed from Chrome
> recently effectively killing browser-based PoP tokens.
> 
> 
> https://identiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/
> 

[OAUTH-WG] Remark on OAuth 2.0 Device Flow name

[Kristian Antic]

Dear all,

I've been working through the OAuth 2.0 Device Flow spec since early
draft versions
and noticed the name change in draft-ietf-oauth-device-flow-04.

As the OAuth 2.0 Device flow is an OAuth 2.0 authorization grant/OAuth
2.0 extension grant, I always wonder why it is called OAuth 2.0 Device
flow.

Could you tell me why you called it OAuth 2.0 Device Flow for
Browserless and Input Constrained Devices and not OAuth 2.0 Device
Grant for Browserless and Input Constrained Devices?

>From my point of view this would better fit into the naming scheme of
the OAuth 2.0 framework.

Best regards,

Kristian

___
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

[Torsten Lodderstedt]

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 :
> 
> 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,
>> Torsten.
>> 
>>> Am 27.11.2018 um 20:54 schrieb John Bradley :
>>> 
>>> I talked to Nat about this a bit today.
>>> 
>>> The thing he is concerned about is mostly around the self issued IDP that 
>>> doesn't have a token endpoint(atleast not easaly).
>>> 
>>> The main use case for that is the id_token response type where claims are 
>>> retuned in the id_token.
>>> 
>>> Because it is fragment encoded some people call that implicit.   That is 
>>> not what we are trying to stop.
>>> 
>>> In some cases in that flow there may be distributed claims returned with 
>>> access Token inside the id_token.I think most people would agree that 
>>> those should be pop or sender constrained tokens.
>>> 
>>> In the case of self issued the RP would be a server and could do sender 
>>> constrained via some mechinisim that is yet to be defined.
>>> 
>>> So if someone wanted to return a access token in a id_token to do 
>>> distributed claims I don't think we have a problem with that as long as the 
>>> token is protected by being sender constrained in some reasonable way.
>>> 
>>> This is a touch hypothetical from the basic OAuth perspective, so I don't 
>>> know how deep we want to go into it.
>>> 
>>> I think the point is not to accidently prohibit something that could be 
>>> done in future.
>>> 
>>> I also think we should not conflate confidential clients that can 
>>> authenticate to the token endpoint with sender constrained/PoP clients that 
>>> can deal with bound tokens.   Yes both have keys but it is better to 
>>> describe them separately.
>>> 
>>> John B.
>>> 
>>> On Tue, Nov 27, 2018, 4:30 PM Torsten Lodderstedt via Openid-specs-ab 
>>> >> Hi Nat,
>>> 
>>> I understand you are saying your draft could provide clients with an 
>>> application level mechanism to sender constrain access tokens. That’s great!
>>> 
>>> But I don’t see a binding to response type „token id_token“. Why do you 
>>> want to expose the tokens via the URL to attackers?
>>> 
>>> You could easily use your mechanism with code. That would also give you the 
>>> chance to really authenticate the confidential client before you issue the 
>>> token.
>>> 
>>> kind regards,
>>> Torsten.
>>> 
 Am 27.11.2018 um 16:57 schrieb Nat Sakimura :
 
 I am not talking about SPA.
 The client is a regular confidential client that is running on a server..
 
 Best,
 
 Nat Sakimura
 
 
 2018年11月27日(火) 16:55 Jim Manico :
 Nat,
 
 How is proof of possession established in a modern web browser in the 
 implicit flow?
 
 My understanding is that token binding was removed from Chrome recently 
 effectively killing browser-based PoP tokens.
 
 https://identiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/
 
 Am I missing something?
 
 Aloha, Jim
 
 
 
> On 11/27/18 9:00 PM, Nat Sakimura wrote:
> I am actually -1.
> 
> +1 for public client and the tokens that are not sender/key constrained.
> 
> Just not being used right now does not mean that it is not useful.. In 
> fact, I see it coming.
> Implicit (well, Hybrid “token id_token” really) is very useful in certain 
> cases.
> Specifically, when the client is confidential (based on public key pair), 
> and uses sender constrained (key-constrained) token such as the one 
> explained in 
> https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5, it is 
> very useful.
> (Key-constrained token is the remaining portion of this draft that did 
> not get incorporated in the MTLS draft. )
> In fact it is the only viable method for Self-Issued OpenID Provider.
> 
> So, the text is generally good but it needs to be 

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

[Torsten Lodderstedt]

> Am 27.11.2018 um 21:54 schrieb William Denniss :
> 
> +1 to have language recommending against the use in most cases (without 
> needing to exclude Nat's use-case).

Can you (or someone else) propose text?

smime.p7s
Description: S/MIME cryptographic signature
___
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

[William Denniss]

In BCP 212 we currently recommend against using implicit flow for native
apps (Section 8.2), due to the inability to protect against interception
with PKCE. AppAuth iOS & Android don't implement it, and the JS version
didn't initially although it was requested by users who needed to do
implicit auth and was eventually supported.

To me the usefulness of implicit on the web is limited, as the code flow
can be used for public clients anyway. The one place I've seen implicit
come up in discussions was for situations where reducing complexity for
third-party developers who needed to implement an OAuth server was a high
priority (one less endpoint to implement).

+1 to have language recommending against the use in most cases (without
needing to exclude Nat's use-case). The code flow has better security
properties, and reducing optionality in the spec reduces the surface area
and simplifies implementations.


On Tue, Nov 27, 2018 at 12:36 PM, John Bradley via Openid-specs-ab <
openid-specs...@lists.openid.net> wrote:

> 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/open
>> id-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,
>> Torsten.
>>
>> Am 27.11.2018 um 20:54 schrieb John Bradley :
>>>
>>> I talked to Nat about this a bit today.
>>>
>>> The thing he is concerned about is mostly around the self issued IDP
>>> that doesn't have a token endpoint(atleast not easaly).
>>>
>>> The main use case for that is the id_token response type where claims
>>> are retuned in the id_token.
>>>
>>> Because it is fragment encoded some people call that implicit.   That is
>>> not what we are trying to stop.
>>>
>>> In some cases in that flow there may be distributed claims returned with
>>> access Token inside the id_token.I think most people would agree that
>>> those should be pop or sender constrained tokens.
>>>
>>> In the case of self issued the RP would be a server and could do sender
>>> constrained via some mechinisim that is yet to be defined.
>>>
>>> So if someone wanted to return a access token in a id_token to do
>>> distributed claims I don't think we have a problem with that as long as the
>>> token is protected by being sender constrained in some reasonable way.
>>>
>>> This is a touch hypothetical from the basic OAuth perspective, so I
>>> don't know how deep we want to go into it.
>>>
>>> I think the point is not to accidently prohibit something that could be
>>> done in future.
>>>
>>> I also think we should not conflate confidential clients that can
>>> authenticate to the token endpoint with sender constrained/PoP clients that
>>> can deal with bound tokens.   Yes both have keys but it is better to
>>> describe them separately.
>>>
>>> John B.
>>>
>>> On Tue, Nov 27, 2018, 4:30 PM Torsten Lodderstedt via Openid-specs-ab <
>>> openid-specs...@lists.openid.net wrote:
>>> Hi Nat,
>>>
>>> I understand you are saying your draft could provide clients with an
>>> application level mechanism to sender constrain access tokens. That’s great!
>>>
>>> But I don’t see a binding to response type „token id_token“. Why do you
>>> want to expose the tokens via the URL to attackers?
>>>
>>> You could easily use your mechanism with code. That would also give you
>>> the chance to really authenticate the confidential client before you issue
>>> the token.
>>>
>>> kind regards,
>>> Torsten.
>>>
>>> Am 27.11.2018 um 16:57 schrieb Nat Sakimura :

 I am not talking about SPA.
 The client is a regular confidential client that is running on a server.

 Best,

 Nat Sakimura


 2018年11月27日(火) 16:55 Jim Manico :
 Nat,

 How is proof of possession established in a modern web browser in the
 implicit flow?

 My understanding is that token binding was removed from Chrome recently
 effectively killing browser-based PoP tokens.

 https://identiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/

 Am I missing something?

 Aloha, Jim



 On 11/27/18 9:00 PM, Nat Sakimura wrote:

> I am actually -1.
>
> +1 for public client and the tokens that are not sender/key
> constrained.
>

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

[John Bradley]

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,
Torsten.


Am 27.11.2018 um 20:54 schrieb John Bradley :

I talked to Nat about this a bit today.

The thing he is concerned about is mostly around the self issued IDP that 
doesn't have a token endpoint(atleast not easaly).

The main use case for that is the id_token response type where claims are 
retuned in the id_token.

Because it is fragment encoded some people call that implicit.   That is not 
what we are trying to stop.

In some cases in that flow there may be distributed claims returned with access 
Token inside the id_token.I think most people would agree that those should 
be pop or sender constrained tokens.

In the case of self issued the RP would be a server and could do sender 
constrained via some mechinisim that is yet to be defined.

So if someone wanted to return a access token in a id_token to do distributed 
claims I don't think we have a problem with that as long as the token is 
protected by being sender constrained in some reasonable way.

This is a touch hypothetical from the basic OAuth perspective, so I don't know 
how deep we want to go into it.

I think the point is not to accidently prohibit something that could be done in 
future.

I also think we should not conflate confidential clients that can authenticate 
to the token endpoint with sender constrained/PoP clients that can deal with 
bound tokens.   Yes both have keys but it is better to describe them separately.

John B.

On Tue, Nov 27, 2018, 4:30 PM Torsten Lodderstedt via Openid-specs-ab 

Am 27.11.2018 um 16:57 schrieb Nat Sakimura :

I am not talking about SPA.
The client is a regular confidential client that is running on a server.

Best,

Nat Sakimura


2018年11月27日(火) 16:55 Jim Manico :
Nat,

How is proof of possession established in a modern web browser in the implicit 
flow?

My understanding is that token binding was removed from Chrome recently 
effectively killing browser-based PoP tokens.

https://identiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/

Am I missing something?

Aloha, Jim



On 11/27/18 9:00 PM, Nat Sakimura wrote:

I am actually -1.

+1 for public client and the tokens that are not sender/key constrained.

Just not being used right now does not mean that it is not useful.. In fact, I 
see it coming.
Implicit (well, Hybrid “token id_token” really) is very useful in certain cases.
Specifically, when the client is confidential (based on public key pair), and 
uses sender constrained (key-constrained) token such as the one explained in 
https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5, it is very 
useful.
(Key-constrained token is the remaining portion of this draft that did not get 
incorporated in the MTLS draft. )
In fact it is the only viable method for Self-Issued OpenID Provider.

So, the text is generally good but it needs to be constrained like “Unless the 
client is confidential and the access token issued is key constrained, ... “

Best,

Nat Sakimura


2018年11月27日(火) 16:01 Vladimir Dzhuvinov :
+1 to recommend the deprecation of implicit.

I don't see a compelling reason to keep implicit when there is an
established alternative that is more secure.

Our duty as WG is to give developers the best and most sensible practice.

CORS adoption is currently at 94% according to
https://caniuse.com/#feat=cors

Vladimir


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat..sakimura.org/
@_nat_en


___
OAuth mailing list

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

--
Jim Manico
Manicode Security

https://www.manicode.com
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
Openid-specs-ab mailing list
openid-specs...@lists.openid.net

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

[William Denniss]

If the secret is dynamically provisioned then you have a confidential
client. Anyone reverse engineering their own installation of the native app
would only extract their own client's credentials, as opposed to the shared
secret of all installations. Having a confidential client means that
requests to the token endpoint (code, refresh) are client authenticated, so
PKCE wouldn't be needed.

On Tue, Nov 27, 2018 at 1:44 AM, Christian Mainka <
Christian.Mainka=40rub...@dmarc.ietf.org> wrote:

> Hi,
>
> we just stumbled upon this [1] statement:
> "Except when using a mechanism like Dynamic Client Registration
>[RFC7591] to provision per-instance secrets, native apps are
>classified as public clients ..."
>
> What does this mean for us? Native App + Dynamic Client Registration =
> Confidential Client?
> Which threats are covered if Dynamic Client Registration is used on
> Native Apps?
>
> Best Regards,
> Vladi/Christian
>
> [1]: https://tools.ietf.org/html/rfc8252#section-8.4
>
> --
> Dr.-Ing. Christian Mainka
> Horst Görtz Institute for IT-Security
> Chair for Network and Data Security
> Ruhr-University Bochum, Germany
>
> Universitätsstr. 150, ID 2/463
> D-44801 Bochum, Germany
>
> Telefon: +49 (0) 234 / 32-26796
> Fax: +49 (0) 234 / 32-14347
> http://nds.rub.de/chair/people/cmainka/
> @CheariX
>
>
> ___
> OAuth mailing 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

[Torsten Lodderstedt]

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,
Torsten. 

> Am 27.11.2018 um 20:54 schrieb John Bradley :
> 
> I talked to Nat about this a bit today.  
> 
> The thing he is concerned about is mostly around the self issued IDP that 
> doesn't have a token endpoint(atleast not easaly).  
> 
> The main use case for that is the id_token response type where claims are 
> retuned in the id_token.  
> 
> Because it is fragment encoded some people call that implicit.   That is not 
> what we are trying to stop.   
> 
> In some cases in that flow there may be distributed claims returned with 
> access Token inside the id_token.I think most people would agree that 
> those should be pop or sender constrained tokens.  
> 
> In the case of self issued the RP would be a server and could do sender 
> constrained via some mechinisim that is yet to be defined.  
> 
> So if someone wanted to return a access token in a id_token to do distributed 
> claims I don't think we have a problem with that as long as the token is 
> protected by being sender constrained in some reasonable way.
> 
> This is a touch hypothetical from the basic OAuth perspective, so I don't 
> know how deep we want to go into it.
> 
> I think the point is not to accidently prohibit something that could be done 
> in future.  
> 
> I also think we should not conflate confidential clients that can 
> authenticate to the token endpoint with sender constrained/PoP clients that 
> can deal with bound tokens.   Yes both have keys but it is better to describe 
> them separately.  
> 
> John B. 
> 
> On Tue, Nov 27, 2018, 4:30 PM Torsten Lodderstedt via Openid-specs-ab 
>  Hi Nat, 
> 
> I understand you are saying your draft could provide clients with an 
> application level mechanism to sender constrain access tokens. That’s great! 
> 
> But I don’t see a binding to response type „token id_token“. Why do you want 
> to expose the tokens via the URL to attackers? 
> 
> You could easily use your mechanism with code. That would also give you the 
> chance to really authenticate the confidential client before you issue the 
> token.
> 
> kind regards,
> Torsten.
> 
> > Am 27.11.2018 um 16:57 schrieb Nat Sakimura :
> > 
> > I am not talking about SPA. 
> > The client is a regular confidential client that is running on a server. 
> > 
> > Best, 
> > 
> > Nat Sakimura
> > 
> > 
> > 2018年11月27日(火) 16:55 Jim Manico :
> > Nat,
> > 
> > How is proof of possession established in a modern web browser in the 
> > implicit flow?
> > 
> > My understanding is that token binding was removed from Chrome recently 
> > effectively killing browser-based PoP tokens.
> > 
> > https://identiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/
> > 
> > Am I missing something?
> > 
> > Aloha, Jim
> > 
> > 
> > 
> > On 11/27/18 9:00 PM, Nat Sakimura wrote:
> >> I am actually -1. 
> >> 
> >> +1 for public client and the tokens that are not sender/key constrained. 
> >> 
> >> Just not being used right now does not mean that it is not useful.. In 
> >> fact, I see it coming. 
> >> Implicit (well, Hybrid “token id_token” really) is very useful in certain 
> >> cases. 
> >> Specifically, when the client is confidential (based on public key pair), 
> >> and uses sender constrained (key-constrained) token such as the one 
> >> explained in 
> >> https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5, it is 
> >> very useful. 
> >> (Key-constrained token is the remaining portion of this draft that did not 
> >> get incorporated in the MTLS draft. )
> >> In fact it is the only viable method for Self-Issued OpenID Provider. 
> >> 
> >> So, the text is generally good but it needs to be constrained like “Unless 
> >> the client is confidential and the access token issued is key constrained, 
> >> ... “
> >> 
> >> Best, 
> >> 
> >> Nat Sakimura
> >> 
> >> 
> >> 2018年11月27日(火) 16:01 Vladimir Dzhuvinov :
> >> +1 to recommend the deprecation of implicit.
> >> 
> >> I don't see a compelling reason to keep implicit when there is an
> >> established alternative that is more secure.
> >> 
> >> Our duty as WG is to give developers the best and most sensible practice.
> >> 
> >> CORS adoption is currently at 94% according to
> >> https://caniuse.com/#feat=cors
> >> 
> >> Vladimir
> >> 
> >> 
> >> ___
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >> -- 
> >> Nat Sakimura (=nat)
> >> Chairman, OpenID Foundation
> >> http://nat..sakimura.org/
> >> @_nat_en
> >> 
> >> 
> >> ___
> >> OAuth mailing list
> >> 
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> > -- 
> > Jim Manico
> > Manicode Security
> > 
> > 

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

[John Bradley]

I talked to Nat about this a bit today.

The thing he is concerned about is mostly around the self issued IDP that
doesn't have a token endpoint(atleast not easaly).

The main use case for that is the id_token response type where claims are
retuned in the id_token.

Because it is fragment encoded some people call that implicit.   That is
not what we are trying to stop.

In some cases in that flow there may be distributed claims returned with
access Token inside the id_token.I think most people would agree that
those should be pop or sender constrained tokens.

In the case of self issued the RP would be a server and could do sender
constrained via some mechinisim that is yet to be defined.

So if someone wanted to return a access token in a id_token to do
distributed claims I don't think we have a problem with that as long as the
token is protected by being sender constrained in some reasonable way.

This is a touch hypothetical from the basic OAuth perspective, so I don't
know how deep we want to go into it.

I think the point is not to accidently prohibit something that could be
done in future.

I also think we should not conflate confidential clients that can
authenticate to the token endpoint with sender constrained/PoP clients that
can deal with bound tokens.   Yes both have keys but it is better to
describe them separately.

John B.

On Tue, Nov 27, 2018, 4:30 PM Torsten Lodderstedt via Openid-specs-ab <
openid-specs...@lists.openid.net wrote:

> Hi Nat,
>
> I understand you are saying your draft could provide clients with an
> application level mechanism to sender constrain access tokens. That’s
> great!
>
> But I don’t see a binding to response type „token id_token“. Why do you
> want to expose the tokens via the URL to attackers?
>
> You could easily use your mechanism with code. That would also give you
> the chance to really authenticate the confidential client before you issue
> the token.
>
> kind regards,
> Torsten.
>
> > Am 27.11.2018 um 16:57 schrieb Nat Sakimura :
> >
> > I am not talking about SPA.
> > The client is a regular confidential client that is running on a server..
> >
> > Best,
> >
> > Nat Sakimura
> >
> >
> > 2018年11月27日(火) 16:55 Jim Manico :
> > Nat,
> >
> > How is proof of possession established in a modern web browser in the
> implicit flow?
> >
> > My understanding is that token binding was removed from Chrome recently
> effectively killing browser-based PoP tokens.
> >
> > https://identiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/
> >
> > Am I missing something?
> >
> > Aloha, Jim
> >
> >
> >
> > On 11/27/18 9:00 PM, Nat Sakimura wrote:
> >> I am actually -1.
> >>
> >> +1 for public client and the tokens that are not sender/key
> constrained.
> >>
> >> Just not being used right now does not mean that it is not useful.. In
> fact, I see it coming.
> >> Implicit (well, Hybrid “token id_token” really) is very useful in
> certain cases.
> >> Specifically, when the client is confidential (based on public key
> pair), and uses sender constrained (key-constrained) token such as the one
> explained in
> https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5, it is
> very useful.
> >> (Key-constrained token is the remaining portion of this draft that did
> not get incorporated in the MTLS draft. )
> >> In fact it is the only viable method for Self-Issued OpenID Provider.
> >>
> >> So, the text is generally good but it needs to be constrained like
> “Unless the client is confidential and the access token issued is key
> constrained, ... “
> >>
> >> Best,
> >>
> >> Nat Sakimura
> >>
> >>
> >> 2018年11月27日(火) 16:01 Vladimir Dzhuvinov :
> >> +1 to recommend the deprecation of implicit.
> >>
> >> I don't see a compelling reason to keep implicit when there is an
> >> established alternative that is more secure.
> >>
> >> Our duty as WG is to give developers the best and most sensible
> practice.
> >>
> >> CORS adoption is currently at 94% according to
> >> https://caniuse.com/#feat=cors
> >>
> >> Vladimir
> >>
> >>
> >> ___
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >> --
> >> Nat Sakimura (=nat)
> >> Chairman, OpenID Foundation
> >> http://nat..sakimura.org/
> >> @_nat_en
> >>
> >>
> >> ___
> >> OAuth mailing list
> >>
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> > --
> > Jim Manico
> > Manicode Security
> >
> > https://www.manicode.com
> > --
> > Nat Sakimura (=nat)
> > Chairman, OpenID Foundation
> > http://nat.sakimura.org/
> > @_nat_en
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> ___
> Openid-specs-ab mailing list
> openid-specs...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>

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

[Torsten Lodderstedt]

Hi Nat, 

I understand you are saying your draft could provide clients with an 
application level mechanism to sender constrain access tokens. That’s great! 

But I don’t see a binding to response type „token id_token“. Why do you want to 
expose the tokens via the URL to attackers? 

You could easily use your mechanism with code. That would also give you the 
chance to really authenticate the confidential client before you issue the 
token.

kind regards,
Torsten.

> Am 27.11.2018 um 16:57 schrieb Nat Sakimura :
> 
> I am not talking about SPA. 
> The client is a regular confidential client that is running on a server. 
> 
> Best, 
> 
> Nat Sakimura
> 
> 
> 2018年11月27日(火) 16:55 Jim Manico :
> Nat,
> 
> How is proof of possession established in a modern web browser in the 
> implicit flow?
> 
> My understanding is that token binding was removed from Chrome recently 
> effectively killing browser-based PoP tokens.
> 
> https://identiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/
> 
> Am I missing something?
> 
> Aloha, Jim
> 
> 
> 
> On 11/27/18 9:00 PM, Nat Sakimura wrote:
>> I am actually -1. 
>> 
>> +1 for public client and the tokens that are not sender/key constrained. 
>> 
>> Just not being used right now does not mean that it is not useful.. In fact, 
>> I see it coming. 
>> Implicit (well, Hybrid “token id_token” really) is very useful in certain 
>> cases. 
>> Specifically, when the client is confidential (based on public key pair), 
>> and uses sender constrained (key-constrained) token such as the one 
>> explained in 
>> https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5, it is 
>> very useful. 
>> (Key-constrained token is the remaining portion of this draft that did not 
>> get incorporated in the MTLS draft. )
>> In fact it is the only viable method for Self-Issued OpenID Provider. 
>> 
>> So, the text is generally good but it needs to be constrained like “Unless 
>> the client is confidential and the access token issued is key constrained, 
>> ... “
>> 
>> Best, 
>> 
>> Nat Sakimura
>> 
>> 
>> 2018年11月27日(火) 16:01 Vladimir Dzhuvinov :
>> +1 to recommend the deprecation of implicit.
>> 
>> I don't see a compelling reason to keep implicit when there is an
>> established alternative that is more secure.
>> 
>> Our duty as WG is to give developers the best and most sensible practice.
>> 
>> CORS adoption is currently at 94% according to
>> https://caniuse.com/#feat=cors
>> 
>> Vladimir
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> -- 
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat..sakimura.org/
>> @_nat_en
>> 
>> 
>> ___
>> OAuth mailing list
>> 
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> -- 
> Jim Manico
> Manicode Security
> 
> https://www.manicode.com
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
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

[Nat Sakimura]

I am not talking about SPA.
The client is a regular confidential client that is running on a server.

Best,

Nat Sakimura


2018年11月27日(火) 16:55 Jim Manico :

> Nat,
>
> How is proof of possession established in a modern web browser in the
> implicit flow?
>
> My understanding is that token binding was removed from Chrome recently
> effectively killing browser-based PoP tokens.
>
> https://identiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/
>
> Am I missing something?
>
> Aloha, Jim
>
>
> On 11/27/18 9:00 PM, Nat Sakimura wrote:
>
> I am actually -1.
>
> +1 for public client and the tokens that are not sender/key constrained.
>
> Just not being used right now does not mean that it is not useful.. In
> fact, I see it coming.
>
> Implicit (well, Hybrid “token id_token” really) is very useful in certain
> cases.
> Specifically, when the client is confidential (based on public key pair),
> and uses sender constrained (key-constrained) token such as the one
> explained in
> https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5, it is
> very useful.
> (Key-constrained token is the remaining portion of this draft that did not
> get incorporated in the MTLS draft. )
> In fact it is the only viable method for Self-Issued OpenID Provider.
>
> So, the text is generally good but it needs to be constrained like “Unless
> the client is confidential and the access token issued is key constrained,
> ... “
>
> Best,
>
> Nat Sakimura
>
>
> 2018年11月27日(火) 16:01 Vladimir Dzhuvinov :
>
>> +1 to recommend the deprecation of implicit.
>>
>> I don't see a compelling reason to keep implicit when there is an
>> established alternative that is more secure.
>>
>> Our duty as WG is to give developers the best and most sensible practice..
>>
>> CORS adoption is currently at 94% according to
>> https://caniuse.com/#feat=cors
>>
>> Vladimir
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> --
> Jim Manico
> Manicode Securityhttps://www.manicode.com
>
> --
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Jim Manico]

Nat,

How is proof of possession established in a modern web browser in the
implicit flow?

My understanding is that token binding was removed from Chrome recently
effectively killing browser-based PoP tokens.

https://identiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/

Am I missing something?

Aloha, Jim


On 11/27/18 9:00 PM, Nat Sakimura wrote:
> I am actually -1. 
>
> +1 for public client and the tokens that are not sender/key constrained. 
>
> Just not being used right now does not mean that it is not useful.. In
> fact, I see it coming. 
> Implicit (well, Hybrid “token id_token” really) is very useful in
> certain cases. 
> Specifically, when the client is confidential (based on public key
> pair), and uses sender constrained (key-constrained) token such as the
> one explained in
> https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5, it
> is very useful. 
> (Key-constrained token is the remaining portion of this draft that did
> not get incorporated in the MTLS draft. )
> In fact it is the only viable method for Self-Issued OpenID Provider. 
>
> So, the text is generally good but it needs to be constrained like
> “Unless the client is confidential and the access token issued is key
> constrained, ... “
>
> Best, 
>
> Nat Sakimura
>
>
> 2018年11月27日(火) 16:01 Vladimir Dzhuvinov  >:
>
> +1 to recommend the deprecation of implicit.
>
> I don't see a compelling reason to keep implicit when there is an
> established alternative that is more secure.
>
> Our duty as WG is to give developers the best and most sensible
> practice.
>
> CORS adoption is currently at 94% according to
> https://caniuse.com/#feat=cors
>
> Vladimir
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth
>
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Jim Manico
Manicode Security
https://www.manicode.com

___
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

[Nat Sakimura]

I am actually -1.

+1 for public client and the tokens that are not sender/key constrained.

Just not being used right now does not mean that it is not useful. In fact,
I see it coming.
Implicit (well, Hybrid “token id_token” really) is very useful in certain
cases.
Specifically, when the client is confidential (based on public key pair),
and uses sender constrained (key-constrained) token such as the one
explained in
https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5, it is
very useful.
(Key-constrained token is the remaining portion of this draft that did not
get incorporated in the MTLS draft. )
In fact it is the only viable method for Self-Issued OpenID Provider.

So, the text is generally good but it needs to be constrained like “Unless
the client is confidential and the access token issued is key constrained,
 “

Best,

Nat Sakimura


2018年11月27日(火) 16:01 Vladimir Dzhuvinov :

> +1 to recommend the deprecation of implicit.
>
> I don't see a compelling reason to keep implicit when there is an
> established alternative that is more secure.
>
> Our duty as WG is to give developers the best and most sensible practice.
>
> CORS adoption is currently at 94% according to
> https://caniuse.com/#feat=cors
>
> Vladimir
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Vladimir Dzhuvinov]

+1 to recommend the deprecation of implicit.

I don't see a compelling reason to keep implicit when there is an
established alternative that is more secure.

Our duty as WG is to give developers the best and most sensible practice.

CORS adoption is currently at 94% according to
https://caniuse.com/#feat=cors

Vladimir


___
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

[Jim Manico]

Manicode Security is strongly in favor of deprecating the implicit flow in 
favor of the authorization code flow as suggested by this recommendation.

We're also eager to see secure implementations for SPA delegation be clarified 
by the working group as well.

Thank you for this important work!

Aloha and Well Wishes,
-- 
Jim Manico
Manicode Security
https://www.manicode.com

On 11/19/18 4:04 PM, Hannes Tschofenig 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] OAuth Security Topics -- Recommend authorization code instead of implicit

[Neil Madden]

On 19 Nov 2018, at 10:34, Hannes Tschofenig  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 
> (seehttps://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.


ForgeRock are in favour of deprecating the implicit flow in favour of the 
authorization code flow as suggested.

In our opinion, it is more secure and more consistent to prefer the 
authorization code in all such cases.

Kind regards,

Neil Madden
Security Director, ForgeRock Engineering
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] draft-parecki-oauth-browser-based-apps-01

[Christian Mainka]

Hi Aaron,

I just reviewed the latest update. Thank you for this very interesting
guideline!

Here are my thoughts:

- Section 4: "For authorizing users within a browser-based application"
I would like to know whether this guide is for JavaScript Applications
(such as SPas), for Browser Extensions, or for both?

- Section 5: "applicaiton" -> "application"; "an web email" -> "a web email"

- Section 6: "and MUST use a unique value for each authorization request."
I would prefer:
'The "state" parameter MUST be a unique value for each authorization
request, which is bound to the end-user's HTTP session, and must be
verified upon receiving it in the authorization response.'
Otherwise, it sounds like a nonce for me.

- Section 7.3: "If authorization servers restrict redirect URIs to a
fixed set of absolute HTTPS URIs without wildcard domains or paths"
Covert redirect can be used by abusing unprotected GET parameters (which
are technically not the PATH).
So maybe it would be better to say simply "without wildcards" or
"without wildcard domains, paths, or querys"?

- Section 7.6: "dynamic registration" -> "dynamic client registration"

Best Regards
Christian

-- 
Dr.-Ing. Christian Mainka
Horst Görtz Institute for IT-Security 
Chair for Network and Data Security 
Ruhr-University Bochum, Germany

Universitätsstr. 150, ID 2/463
D-44801 Bochum, Germany

Telefon: +49 (0) 234 / 32-26796
Fax: +49 (0) 234 / 32-14347
http://nds.rub.de/chair/people/cmainka/
@CheariX

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

[OAUTH-WG] Dynamic Client Registration with Native Apps

[Christian Mainka]

Hi,

we just stumbled upon this [1] statement:
"Except when using a mechanism like Dynamic Client Registration
   [RFC7591] to provision per-instance secrets, native apps are
   classified as public clients ..."

What does this mean for us? Native App + Dynamic Client Registration =
Confidential Client?
Which threats are covered if Dynamic Client Registration is used on
Native Apps?

Best Regards,
Vladi/Christian

[1]: https://tools.ietf.org/html/rfc8252#section-8.4

-- 
Dr.-Ing. Christian Mainka
Horst Görtz Institute for IT-Security 
Chair for Network and Data Security 
Ruhr-University Bochum, Germany

Universitätsstr. 150, ID 2/463
D-44801 Bochum, Germany

Telefon: +49 (0) 234 / 32-26796
Fax: +49 (0) 234 / 32-14347
http://nds.rub.de/chair/people/cmainka/
@CheariX


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