Write a Self-issued IdP (SI-IdP) Best Practice document

Issue #1027 open
Nat Sakimura created an issue

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.)
  2. Android intent and claimed URI (in addition to the custom URI scheme that we have in the spec.)
  3. How the SI-IdP gets introduced to the Claims providers for the use in Aggregated claims.
  4. 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.)
  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.

Comments (9)

  1. Nat Sakimura reporter
    • changed status to open
    • DID WG was talking about it this morning.
    • Apple and Google is adding software backup using keychain. It could change the security posture that is to be evaluated yet.
    • Second key is bound to the context
  2. Kristina Yasuda

    Regarding 1, we may want to add text to clarify it in SIOP V2 draft. @Nat, could you draft a PR, maybe?

    Regarding 2, I am not sure what “Android intent and claimed URI“ is, but this seems related to SIOP Chooser issue.

    Regarding 3, communicating SIOP metadata to the Client is being tackled in “hard-coded policy switch“ - iss=self-issued.me conversation related to SIOP Properties discussion - I believe it is also applicable to Aggregated Claims context - @Nat, @Edmund what do you think?

    Regarding 4, I think this is not being dealt anywhere even in Claims Aggregation draft. Do we still want to address it?

    Regarding 5, per discussion during 06-21-2021 call, people commented that this is being discussed in WebAuthn WG. This would not be in a normative text in SIOP V2, but we could mention it in security considerations.

    Regarding 6, Not sure we are talking about this. Should we open an issue in SIOP?

    Regarding 7, this has been a theme in variuos discussions, but there is no one consoludated issue around it - should we open one?

  3. Tom Jones

    Some issues like key recover may still belong in a best practice doc. What do others think? We had a long chat in the meeting about changes coming from Android and Apple in that space.

  4. Michael Jones

    This 2018 issue seems to have been overtaken by events, as we are now writing the SIOP V2 draft. As such, I believe this should be closed on that basis. If there are aspects of this issue that you believe should be reflected in the SIOP V2 draft, please identify them in new issues. Thanks.

  5. Log in to comment