Presentation I gave on Self-Issued OpenID Provider during the second OpenID Foundation Virtual Workshop covering:
1. What is Self-Issued OpenID Provider (SIOP) ?
2. SIOP Requirements (draft)
3. Initial discussion points deep-dive
Self-Issued OpenID Providers are personal OpenID Providers that issue self-signed ID Tokens, enabling portability of the identities among providers
Understanding Discord NSFW Servers A Guide for Responsible Users.pdf
Self-issued OpenID Provider_OpenID Foundation Virtual Workshop
1. Self-Issued OpenID
Provider
~Chapter 7 of OpenID Connect~
Kristina Yasuda
Identity Standards, Microsoft Corp.
Liaison Officer between OpenID Foundation and Decentralized Identity
Foundation
2. A session with a lot of open questions
1. What is Self-Issued OpenID Provider (SIOP) ?
2. SIOP Requirements (draft)
3. Initial discussion points deep-dive
3. 1. What is Self-Issued OpenID Provider (SIOP) ?
- Self-Issued OpenID Providers are personal OpenID Providers that issue self-signed ID Tokens,
enabling portability of the identities among providers.
- User holds its own OpenID Provider(OP) <> No Central OP
1. SIOP holds Claims
issued by Claims
Provider
2. SIOP can directly issue
self-signed ID Tokens
upon RP request
End-user
4. 2. SIOP Requirements draft (1/4)
openid/connect/src/master/SIOP/siop-requirements.md
A. SIOP request
B. SIOP response
C. Key recovery and key rotation
D. Trust model between RP and SIOP
E. Issuance of the claims
F. Privacy protection
G. Claims binding
H. Various OpenID providers deployment architectures
I. Use-case specific requirements
5. 2. SIOP Requirements draft (2/4)
A. SIOP request
1. OpenID Provider’s capability to issue self-issued responses is an extension of
the core OpenID Connect protocol => redirect_uri
2. SIOP can be used both for logins and for transmitting identity characteristics.
3. SIOP should support best practices of flow types.
B. SIOP response
4. SIOP should be able to return Verifiable Credentials and Verifiable
Presentations in the response
C. Derivation of Key information (cryptography itself is out of scope)
5. Key information should be derived either by using Decentralized Identifiers
resolved into DID documents, or sub_jwks with URNs (-> deep-dive)
6. 2. SIOP Requirements draft (3/4)
D. Trust model between RP and SIOP (accounting for a special use-case where RP and
SIOP are on the same device?)
6. SIOP must be able to advertise that it is a SIOP-enabled OP => Invocation (->
deep-dive)
7. SIOP must be able to advertise configuration information to the RP => Discovery
8. RP must be able to register with SIOP => Registration parameter
E. Issuance of the claims (SIOP - Claims Provider)
9. SIOP providers can be registered with the Claims provider (Unique to SIOP)
F. Privacy protection
10.RPs should understand the security/privacy posture of SIOP
11.SIOP should support pairwise, omnidirectional, and ephemeral identifiers
12. Attestations made in the past should remain valid
13.RP must be able to receive the claims when the end-user is offline without
colluding with the Claims Provider
7. 2. SIOP Requirements draft (4/4)
G. Claims Binding (relation with Aggregated and Distributed Claims Draft?) (OpenId
Connect Credential Provider draft?)
H. Various OpenID providers deployment architectures (Authentication flows?)
14. Support PWA-based SIOP implementations
15. SIOP should support browser flow path, device flow path and combination of
both
I. Use-case specific requirements
16.SIOP could support rich identity information sharing with RP (optional)
17.SIOP should allow for selective disclosure of claims in claim sets
18.SIOP should allow offline authentication
8. 3. Discussion points deep-dive
1. Finding the SIOP address (Issue #1199) re: NASCAR Problem
If there are several SIOP wallets on my mobile device (or in a web browser), which one
gets invoked when SIOP request is received?
Currently, SIOP wallets would register custom schema openid://. However, there are
certain dependencies on the OS that does not allow to choose among wallets registered
under the same custom schema.
Is there a way to make this work without OS support (ideal), or should the conversation
with OS vendors be initiated (hard)? One idea was to have a “capability broker“ that
registers a list of SIOP wallets and the identifier methods they support (jwk thumb or did
methods)
From a user experience perspective, leaving current openid:// schema mechanism
could work fine – no user confusion over existence of several wallets.
9. 3. Discussion points deep-dive
2. Conduit to Decentralized Identifiers
- “Decentralized Identifiers (DIDs) allow DID controller(end-user) to prove control over
an identifier without requiring permission from any other party”
- Advertising support for DIDs?
- Extension to `subject_types`? New parameter `identifier_type`?
- Where to best represent DIDs – key pair controlled by you?
- Introducing indirection to `sub` claim allowing it to be a URN allowing both jwk
thumbprint and DIDs
- `iss` is self-issued.me and has to be a URL per OpenID Connect Specification
- Updating verification methods when DIDs are included in `sub`?
- Additional cryptography mechanisms required (ES256K/EdDSA)
Collaboration with Decentralized Identity Foundation (DIDAuthn WG)
10. Discussions during OIDC AB/Connect WG
calls:
- Weekly Pacific time-zone calls and
- Bi-weekly Atlantic time-zone calls
+ Bitbucket issues, drafts
Hinweis der Redaktion
From the beginning of this year, OpenID Connect Working Group has decided to revise Chapter 7 of OpenID Connect specification;
Protocol as a conduit between OIDC and decentralized identity
Can be used when
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;
to identify himself that he is the PII principal that the identity relates to;
Also sometimes called SSI
This document enumerates requirements for SIOP to help define the scope of a new version of SIOP specification - what will and will not be included.
Combins todo lists/laundry lists, and various work
4 players:
Data Subject: that is “me”;
Claims Providers (CPs) that provides attested claims;
Relying Parties (RPs) that consumes the attested claims in order to provide services to the data subject;
Self-issued OPs (SIOPs) that provide the authenticated identity to the
the Data subject can ask the CP to provide the attested and includes it in the ID Token that he provides through the SIOP to the RP
SIOP operates on behalf of a human or non-human subject to share information contained in a SIOP store by including it in an ID Token signed using an identifier and keys controlled by the subject.
Self-Issued identifier draft
A. SIOP an extension of the core OpenID Connect Protocol rather than an alternative flow
5. adding layer of indirection, with ‘sub’ value being URN -> 2 types
DIDs a resolvable identifier to a set of statements about the did subject including a set of cryptographic material (e.g public keys). Using this cryptographic material, a decentralized identifier can be used as an authenticatable identifier in a credential.
D6: SIOP and OP since the key retrieval and security checks work differently
OP: iss value -> openid-configuration -> jwks_uri -> signing key for id token
SIOP: just the key as represented in the Id token or DID based resolution, etc.
E. how SIOP verified credential issuers deliver credentials to wallets controlled by credential holders.
a credential is defined as an assertion about the End-User which is bound to the Client in an authenticatable manner based on public/private key cryptography. This feature then enables the Client to onward present the credential to other relying parties whilst authenticating the established binding to the assertion.
To make a user assertion to be suitable as a credential, feature some form of binding to the Client that requested it
the subject identifier for the end-user a “cryptographically verifiable” identifier