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
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
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
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
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
> 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
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
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
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
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
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
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
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
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
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
+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
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!
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
>
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
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
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
21 matches
Mail list logo
