[Openid-specs-ab] TODO list for Self-Issued OP

Nat Sakimura sakimura at gmail.com
Thu Dec 13 21:20:43 UTC 2018


Ah, Ok. The issuer for the Self-issued OP is a vanity string, just trying
to be more in-line with a normal OpenID Connect issuer identifier. It is
just a switch. That means, OP metadata is virtually hard-coded and is a bit
limiting. If we can make it more flexible, it may be an interesting idea.
For example, if we can write the OP metadata to the registry, such as a
blockchain to perform a discovery on it, it might give us more flexibility,
e.g., options on supported cypher-suite, etc.

The downside is that it makes it possible to introduce a correlation to the
SIOP even if it is using a PPID. Also, the risk of misconfiguration becomes
substantially larger, so a right balance has to be stricken considering
especially that SIOP is run by a consumer typically.

On Fri, Dec 14, 2018 at 3:43 AM Anthony Nadalin <tonynad at microsoft.com>
wrote:

> Yes as this is what I’m also looking into right now as I find the current
> constructs are too restrictive with issuer and client-id
>
>
>
> *From:* Tom Jones <thomasclinganjones at gmail.com>
> *Sent:* Thursday, December 13, 2018 10:25 AM
> *To:* Artifact Binding/Connect Working Group <
> openid-specs-ab at lists.openid.net>
> *Cc:* Nat Sakimura <sakimura at gmail.com>; Anthony Nadalin <
> tonynad at microsoft.com>
> *Subject:* Re: [Openid-specs-ab] TODO list for Self-Issued OP
>
>
>
> I have started to look at discovery of id's on the internet following some
> of the ideas in the DID credential community group and would like to try to
> come up with a general resolver.  Is this a good time to explore such an
> idea?  I plan to start a write up now.
>
>
> Peace ..tom
>
>
>
>
>
> On Thu, Dec 13, 2018 at 10:04 AM Anthony Nadalin via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>
> Sorry I was not clear, what I was actually talking about was the issuer,
> as today it’s a URL and uses Web Finger, we need to look at expanding this
> to allow for other types of discovery
>
>
>
> *From:* Nat Sakimura <sakimura at gmail.com>
> *Sent:* Wednesday, December 12, 2018 5:05 PM
> *To:* Anthony Nadalin <tonynad at microsoft.com>
> *Cc:* openid-specs-ab at lists.openid.net Ab <
> openid-specs-ab at lists.openid.net>
> *Subject:* Re: [Openid-specs-ab] TODO list for Self-Issued OP
>
>
>
> Hi Tony,
>
>
>
> Actually, SIOP's identifier is not URL but the hash of the public key.
> That's one of the most common misconceptions about SIOP.
>
>
>
> Having said that, what you have pointed out is true and I am aware of it.
>
> In the list, it corresponds to  2 as an identifier is a claim, and 3 to
> some extent as you may want to establish the binding between that
> identifier and the time.
>
>
>
> Nat
>
>
>
> On Thu, Dec 13, 2018 at 4:14 AM Anthony Nadalin <tonynad at microsoft.com>
> wrote:
>
> So, there may be some ubiquity in the “identifier”, as the current SIOP is
> a URL, but there are many cases where there are actually other identifiers
> that need to be attested to, and the public-key that the identifier may
> have, I don’t expect that the SIOP identifier would be used much other than
> to find the SIOP and related meta-data. I do believe that we should be
> looking at how we do binding to all the other identifiers
>
>
>
> *From:* Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> *On
> Behalf Of *Nat Sakimura via Openid-specs-ab
> *Sent:* Monday, December 10, 2018 11:41 AM
> *To:* openid-specs-ab at lists.openid.net Ab <
> openid-specs-ab at lists.openid.net>
> *Cc:* Nat Sakimura <sakimura at gmail.com>
> *Subject:* [Openid-specs-ab] TODO list for Self-Issued OP
>
>
>
> So, there is a renewed interest to Self-issued OP (SIOP) due to the
> Self-sovereign movement. I believe SIOP can be used to achieve
> Self-sovereign identity, but there are loose ends. Here is the list of
> TODOs that I came up with.
>
> (The most recent version of the following article is available at
> https://nat.sakimura.org/2018/12/11/todo-list-for-self-issued-op/
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnat.sakimura.org%2F2018%2F12%2F11%2Ftodo-list-for-self-issued-op%2F&data=02%7C01%7Ctonynad%40microsoft.com%7C6211dc24a1a14b1a720908d661285835%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636803223259747220&sdata=Cw7yy3tY1VrTDi4wFgXAPYQB5WzNBcoLDuj27%2FA1CgU%3D&reserved=0>
> )
>
> Enjoy,
>
> Nat Sakimura
> TODO LIST FOR SELF-ISSUED OP
>
> Self-issued OP (SIOP) is defined in Chapter 7 of OpenID Connect (2014). If
> we take
>
> 1.    that the Identity (set of data related to the entity) needs to be
> provable as attested at the time of attestation and cannot be taken away;
>
> 2.    to identify himself that he is the PII principal that the identity
> relates to;
>
> as the requirements for Self Sovereign identity, SIOP can be used to
> implement SSID.
>
> In this model, there are four basic actors:
>
> 1.    Data Subject: that is “me”;
>
> 2.    Claims Providers (CPs) that provides attested claims;
>
> 3.    Relying Parties (RPs) that consumes the attested claims in order to
> provide services to the data subject;
>
> 4.    Self-issued OPs (SIOPs) that provide the authenticated identity to
> the
>
> Then, the Data subject can ask the CP to provide the attested claims in
> the form of signed JWT that resembles ID Token and includes it in the ID
> Token that he provides through the SIOP to the RP.
>
> Having said that, a bunch of things are going to be implementation
> specific and need standardization. The list of such features includes a
> standardized method for
>
> 1.    Registering the SIOP to the claims provider so that the SIOP can
> request signed claims to the claims provider;
>
> 2.    Binding the Self-issued identifier (a hash of the public key) and
> the attested claims;
>
> 3.    Attesting the signing key from the past;
>
> 4.    Providing the claims to the RP when the SIOP is offline; and
>
> 5.    Enabling key recovery.
> 1. REGISTERING THE SIOP TO THE CLAIMS PROVIDER
>
> From the point of view of the claims provider, the SIOP will be an OAuth
> client. Assuming that the claims provider has an existing relationship with
> the data subject and has established a credential for the PII principal to
> authenticate against the Claims Provider, the SIOP has to start the regular
> OAuth dance to get authorization to obtain the claims at the Claims
> Provider.
>
> It is a regular OAuth Dance. The SIOP initially has to register itself to
> the Claims Provider using the dynamic client registration, then does the
> OAuth Dance with Code grant type and PKCE. When successful, it will obtain
> the access token and refresh token. The SIOP, acting as the client, can now
> obtain the attested claims from the Claims Provider, in the form of a
> signed JWT.
>
> Note that such attested claims MUST include the subject identifier of the
> data subject that was authenticated at the dance. Thus, the access token
> and the refresh token MUST be bound to the data subject and unique to the
> data subject.
> 2. BINDING THE SELF-ISSUED IDENTIFIER TO THE ATTESTED CLAIMS
>
> The data subject can establish any number of key-pairs at the SIOP to
> manage his identities. He picks one of them to communicate to the RP. Thus,
> there will be one-to-many relationship between the subject identifier at
> the Claims Provider and the Self-issued identifiers(SIID). Noting that the
> key-pairs can be created on the fly and even be ephemeral to achieve the
> anonymous attribute-based authentication, this binding has to be done
> dynamically.
>
> To achieve the goal,
>
> 1.     the SIOP as a client MUST send the SIID to be used against the RP
> in the claims request;
>
> 2.    the CP MUST include the SIID as the value of the siid claim;
> 3. ATTESTING THE SIGNING KEY FROM THE PAST
>
> A claims provider may go out-of-business. However, that does not mean that
> the attestation made in the past is invalid. For example, I may have
> obtained a qualification from a training course that the institution
> provides, but the institution may disappear years later but I may still
> want to prove that I was provided with the qualification.
>
> To achieve this, the public-key corresponding to the private-key MUST be
> timestamped and made available publicly. One way to do this is to write to
> a publicly maintained registry, such as a blockchain. Whenever the key is
> rotated, the CP MUST write it to the registry.
>
> SIOP may also want to rotate the key for various reasons. If the data
> subject is interested in providing the attested claims that it obtained in
> the past, then he has to write the old and new SIIDs as the pair to the
> registry, signed by the key corresponding to the old SIID. This exact
> format also needs to be standardized.
> 4. PROVIDING THE CLAIMS TO THE RP WHEN THE DATA SUBJECT IS OFFLINE
>
> It is often the case that the data subject does not want to reveal where
> the claims are going to be presented. Thus, making it not possible for the
> CP to reasonably link the transaction to the RP where RP and CP are not
> colluding is desirable.
>
> When providing access to the fresh claims while the SIOP is offline, this
> property is not fulfilled any more. Thus, this feature should be evaluated
> carefully before providing, but it can be done using the distributed claims
> model.
>
> In this case, the SIOP MUST provide the link to the endpoint that the CP
> provides together with the token that encodes the fact that the data
> subject has authorized the access.
>
> It is a more complicated flow. The RP now acts as a client to the CP but
> at the time of the attribute request, it cannot know which CP it will be
> getting the data from. It will find it only when it receives the ID Token
> from the SIOP, in which the pair of the URL of the CP and the token that
> encodes the fact that the user has authorized the access is provided.
>
> A Globally unique client identifier, such as URL, is useful here. If it is
> adopted in the ecosystem, then the SIOP can specify it as the RP’s
> client_id and send it in the request. then, the CP creates an access
> token and binds it to the client_id provided.  The RP then uses it
> against the URL of the CP that was provided in the ID Token to obtain the
> desired claims.
>
> If the access token is a bearer token, this means that the SIOP (i.e., the
> data subject) can also obtain the same claims and it is good from the
> transparency purposes. However, there are times where the access of the
> data subject is undesirable. In this case, the access token needs to be
> sender constrained to the RP by such mechanism like MTLS. Using a URL as
> the client_id is handy here as well.
> 5. ENABLING KEY RECOVERY
>
> Individuals are notorious in managing his keys. There has to be layers of
> protection against it. Some of them are:
>
> 1.    Transform the JWKS of the SIOP by All-or-nothing-transform and
> split it into two, where one part is printed out as a QR code and the rest
> is stored in the cloud. The data subject can safely store the QR code
> off-line.
>
> 2.    Instead of storing the QR code off-line at his home, he can send it
> to the safe-keeping service.
>
> 3.    Identity proofing service: It is not a key-recovery service, but to
> assist the data subject to re-establish himself after having lost the keys,
> there can be a third party service that binds the data subject to the list
> of identifiers. When the user has lost all the keys that were bound
> together, then the service can declare that the newly generated keys are
> the successor of the previous identifiers after going through the identity
> re-proofing process, such as examining the identity documents, etc.
>
>
>
> --
>
> Nat Sakimura (=nat)
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnat.sakimura.org%2F&data=02%7C01%7Ctonynad%40microsoft.com%7C6211dc24a1a14b1a720908d661285835%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636803223259757225&sdata=c1COzsmPWzVBQoyT1cattL5i%2BugXZh2uQGOdr1Knf9Y%3D&reserved=0>
> @_nat_en
>
>
>
>
> --
>
> Nat Sakimura (=nat)
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnat.sakimura.org%2F&data=02%7C01%7Ctonynad%40microsoft.com%7C6211dc24a1a14b1a720908d661285835%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636803223259767235&sdata=eMtfyhLSVMR7W416Y8sF%2Fxpo%2Bkk9zfcYIFT0cQV5260%3D&reserved=0>
> @_nat_en
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&data=02%7C01%7Ctonynad%40microsoft.com%7C6211dc24a1a14b1a720908d661285835%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636803223259767235&sdata=GFmUWQmZ3TRmBwUBFgCpdb0h7a5FpAbTs%2FJXHoNaiSY%3D&reserved=0>
>
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20181214/f4920681/attachment-0001.html>


More information about the Openid-specs-ab mailing list