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 <n-sakim...@nri.co.jp<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 <thomasclinganjo...@gmail.com> Sent: Wednesday, November 28, 2018 9:14 AM To: Nat Sakimura <n-sakim...@nri.co.jp> Cc: Artifact Binding/Connect Working Group <openid-specs...@lists.openid.net>; 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 <n-sakim...@nri.co.jp<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 <n-sakim...@nri.co.jp<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 <openid-specs-ab-boun...@lists.openid.net<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 <openid-specs...@lists.openid.net<mailto:openid-specs...@lists.openid.net>> Cc: Tom Jones <thomasclinganjo...@gmail.com<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 <openid-specs...@lists.openid.net<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 <tors...@lodderstedt.net<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 > <ve7...@ve7jtb.com<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, >> Torsten. >> >>> Am 27.11.2018 um 20:54 schrieb John Bradley >>> <ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>>: >>> >>> 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<mailto: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 >>>> <sakim...@gmail.com<mailto:sakim...@gmail.com>>: >>>> >>>> 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 >>>> <j...@manicode.com<mailto:j...@manicode.com>>: >>>> 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 >>>>> <vladi...@connect2id.com<mailto:vladi...@connect2id.com>>: >>>>> +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<mailto:OAuth@ietf.org> >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> -- >>>>> Nat Sakimura (=nat) >>>>> Chairman, OpenID Foundation >>>>> http://nat..sakimura.org/<http://sakimura.org/> >>>>> @_nat_en >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> >>>>> OAuth@ietf.org<mailto: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<mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> Openid-specs-ab mailing list >>> openid-specs...@lists.openid.net<mailto:openid-specs...@lists.openid.net> >>> http://lists.openid.net/mailman/listinfo/openid-specs-ab -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ Openid-specs-ab mailing list openid-specs...@lists.openid.net<mailto:openid-specs...@lists.openid.net> http://lists.openid.net/mailman/listinfo/openid-specs-ab
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
