[Openid-specs-ab] Self-issued IdP Best Practice document

n-sakimura n-sakimura at nri.co.jp
Mon May 28 03:28:47 UTC 2018

Dear Connecters:

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 comes 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.)
  2.  Android intent and claimed URI (in addition to the custom URI scheme that we have in the spec.)
  3.  How the SS-IdP gets introduced to the Claims providers for the use in Aggregated claims.
  4.  How the SS-IdP gets the authorization delegation from the Claims providers for the Distributed claims case. (UMA resource registration comes in mind as one of the method.)
  5.  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.)
  6.  Recommendation on Claims revocation/expiration.
  7.  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.

Perhaps we should talk about it in the next AB/C call.


Nat Sakimura <n-sakimura at nri.co.jp<mailto:n-sakimura at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180528/6c3b294a/attachment-0001.html>

More information about the Openid-specs-ab mailing list