ct: 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
enid-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
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
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
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
