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
the
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 to
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 i
> 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 aut
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.
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
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 s
