Self-issued OpenID Provider - Revision history

Tom: /* Contents */

2022-01-19T23:45:20Z

‎Contents

Tom at 23:52, 23 March 2021

2021-03-23T23:52:48Z

Tom: /* Other Material */

2020-12-08T18:13:53Z

‎Other Material

Tom: /* Contents */

2020-12-07T18:47:48Z

‎Contents

Tom: /* Contents */

2020-12-07T18:47:24Z

‎Contents

Tom: /* Context */

2020-12-07T18:46:39Z

‎Context

Tom: /* Informative references */

2020-12-05T01:15:05Z

‎Informative references

Tom: /* UX Considerations */

2020-10-25T22:57:12Z

‎UX Considerations

Tom: /* Security Considerations */

2020-10-25T22:56:04Z

‎Security Considerations

Tom: /* Context */

2020-10-25T22:53:53Z

‎Context

@@ Line 6: / Line 6: @@
 ==Contents==
 * This is from a 2020-10 version of a DIF doc.
-This specification defines the "SIOP DID Profile" (SIOP DID) that is a DID AuthN flavor to use OpenID Connect (OIDC) together with the strong decentralization, privacy and security guarantees of Decentralized Identifiers (DID) for everyone who wants to have a generic way to integrate Identity Wallets into their web applications.
+This specification defines the "SIOP DID Profile" (SIOP DID) that is a DID AuthN flavor to use OpenID Connect (OIDC) together with the strong [[Decentralization]], [[Privacy]] and [[Security]] guarantees of Decentralized Identifiers (DID) for everyone who wants to have a generic way to integrate Identity Wallets into their web applications.
 Status of This Document

@@ Line 421: / Line 421: @@
 * [https://bitbucket.org/openid/connect/src/master/SIOP/draft-jones-self_issued_identifier.md Alternative version on OpenID] from Tom Jones
 * [https://bitbucket.org/openid/connect/src/master/SIOP/ parent folder for SIOP docs on OpenID.net]
 [[Category:Standard]]
 [[Category:Identity]]
 [[Category:Security]]

@@ Line 420: / Line 420: @@
 ===Other Material===
 * [https://bitbucket.org/openid/connect/src/master/SIOP/draft-jones-self_issued_identifier.md Alternative version on OpenID] from Tom Jones
 [[Category:Standard]]
 [[Category:Identity]]
 [[Category:Security]]

@@ Line 5: / Line 5: @@
 ==Contents==
-* This is a 2020-10 versions of a DIF doc.
+* This is from a 2020-10 version of a DIF doc.
 This specification defines the "SIOP DID Profile" (SIOP DID) that is a DID AuthN flavor to use OpenID Connect (OIDC) together with the strong decentralization, privacy and security guarantees of Decentralized Identifiers (DID) for everyone who wants to have a generic way to integrate Identity Wallets into their web applications.

← Older revision		Revision as of 18:47, 7 December 2020
Line 5:		Line 5:

	==Contents==		==Contents==
		+	* This is a 2020-10 versions of a DIF doc.
	This specification defines the "SIOP DID Profile" (SIOP DID) that is a DID AuthN flavor to use OpenID Connect (OIDC) together with the strong decentralization, privacy and security guarantees of Decentralized Identifiers (DID) for everyone who wants to have a generic way to integrate Identity Wallets into their web applications.		This specification defines the "SIOP DID Profile" (SIOP DID) that is a DID AuthN flavor to use OpenID Connect (OIDC) together with the strong decentralization, privacy and security guarantees of Decentralized Identifiers (DID) for everyone who wants to have a generic way to integrate Identity Wallets into their web applications.

@@ Line 2: / Line 2: @@
 Self-issued Identifiers in an OpenID Connect Context.
 ==Context==
 This specification defines the "SIOP DID Profile" (SIOP DID) that is a DID AuthN flavor to use OpenID Connect (OIDC) together with the strong decentralization, privacy and security guarantees of Decentralized Identifiers (DID) for everyone who wants to have a generic way to integrate Identity Wallets into their web applications.

@@ Line 375: / Line 375: @@
 * For Native apps the URL Schema redirect can be overridden the the last app to request access.
 * For PWA (web apps) the URL is bound to the web site that installed the PWA, leading to exacerbations of the NASCAR logo problem.
 ===OIDC Considerations===

@@ Line 372: / Line 372: @@
 The OWASP Foundation maintains a set of security recommendations and best practices for web applications, and it is RECOMMENDED to follow these best practices when creating an SIOP or RP based on this specification.
+===UX Considerations===
 ===OIDC Considerations===

@@ Line 8: / Line 8: @@
 Table of Contents
-.Terminology
+#Terminology
-.Introduction
+# Introduction
-.1Purpose
+## Purpose
-.2Goals
+## Goals
-.Protocol Flow
+# Protocol Flow
-.1Generate SIOP Request
+## Generate SIOP Request
-.1.1Request (Regular-device Flow)
+## Request (Regular-device Flow)
-.1.2Request Validation (Regular-device Flow)
+### Request Validation (Regular-device Flow)
-.1.3SIOP Request Validation
+### SIOP Request Validation
-.1.4Generate SIOP Response
+### Generate SIOP Response
-.1.5SIOP Response Validation
+### SIOP Response Validation
-.1.6SIOP Discovery
+### SIOP Discovery
-.2UX Considerations
+## UX Considerations
-.3Security Considerations
+## Security Considerations
-.4IANA Considerations
+## IANA Considerations
-.5OIDC Considerations
+## OIDC Considerations
-A.References
+#.References
-A.1Normative references
+## Normative references
-A.2Informative references
+## Informative references
-. Terminology
+# Terminology
 This section is non-normative.
@@ Line 342: / Line 342: @@
 On Android, the user can choose which app should open if multiple apps registered the same custom URL scheme. On iOS, the behavior is undefined. One approach would be to check if the user is on an iOS device and then, won't render the button if this is a concern. A fallback on iOS could be the use of custom mime types, but unusual UX has to be considered. Note, this issue is not specific to SIOP only but affects all apps using custom URL schemes. In case a QR Code is used where the user has to open the app first and has to scan the QR Code, this issue is mitigated.
-.3 Security Considerations
+===Security Considerations===
 This section is non-normative.
@@ Line 372: / Line 372: @@
 The OWASP Foundation maintains a set of security recommendations and best practices for web applications, and it is RECOMMENDED to follow these best practices when creating an SIOP or RP based on this specification.
 ===OIDC Considerations===