[Openid-specs-ab] Issue #1027: Write a Self-issued IdP (SI-IdP) Best Practice document (openid/connect)

[Nat Sakimura]

New issue 1027: Write a Self-issued IdP (SI-IdP) Best Practice document
https://bitbucket.org/openid/connect/issues/1027/write-a-self-issued-idp-si-idp-best

Nat Sakimura:

Dear Connectors:

Mike and I talked this over at #EIC18, but it seems it is a good idea to document about Self-Issued IdP. Current documentation seems to be a bit too dry and you have to jump implicitly to many locations in the spec. As the result, people do not get it. In addition, it probably should include some of the operational considerations such as Key backup etc. as well.

Some of the “non-spec” (potentially it can be spec’ed out later) items that come into my mind are documentation on:

1. Clearly tell that we are not using URL to identify a user. (It is the hash of the generated key.)
1. Android intent and claimed URI (in addition to the custom URI scheme that we have in the spec.)
1. How the SI-IdP gets introduced to the Claims providers for the use in Aggregated claims.
1. How the SI-IdP gets the authorization delegation from the Claims providers for the Distributed claims case. (UMA resource registration comes in mind as one of the methods.)
1. How the keys and tokens to be backed up and transferred to other devices. (e.g., encrypting with a CEK based on the user-supplied pass-phrase and storing it on a cloud-based storage.)
1. Recommendation on Claims revocation/expiration.
1. Privacy consideration. 

I also had an opportunity to talk with Kim Cameron: He wanted to have SS-IdP that is even closer to a regular IdP. E.g., returning ‘code’ or ‘access_token’ from the SS-IdP so that they can be used against the cloud-hosted token endpoint and userinfo endpoint, that probably maps to the “Hub API” in his slide found at 17min12sec at https://www.identityblog.com/wp-content/resources/2018/eic2018_06_cameron.mp4.

Responsible: Nat