API - Revision history

Tom: /* Attestation */

2024-11-29T05:08:56Z

‎Attestation

2024-11-29T05:08:42Z

‎Federation

2024-11-29T05:08:24Z

‎Authentication

2024-11-29T05:03:49Z

‎Federation

2024-09-13T23:16:38Z

‎Context

2024-01-12T00:54:13Z

‎Context

2021-04-14T00:15:24Z

‎Authentication

2021-01-26T18:34:48Z

‎Granting Consent

2021-01-26T18:34:27Z

‎Granting Consent

2021-01-26T18:33:44Z

‎Context

@@ Line 32: / Line 32: @@
 ===Attestation===
 #some standards in the IETF (like RFC 9334) use the term [[Verifier]] for an [[Entity]] that is a remote service providing information about the source of a API.
 ===Authentication===

@@ Line 29: / Line 29: @@
 # UK Open Banking [https://www.openbanking.org.uk/providers/standards/#request web page] and [https://bitbucket.org/openid/obuk/src/8aec1c5808f6a22c39f669bb31de9f424cac19d7/uk-openbanking-registration-profile.md?at=master&fileviewer=file-view-default standards].
 # OAuth 2.0 Authorization Server Metadata is now RFC 8414 (2018-06-26) <ref>Mike Jones, OAuth 2.0 ''Authorization Server Metadata is now RFC 8414.'' http://self-issued.info/?p=1883</ref>
 ===Attestation===

@@ Line 29: / Line 29: @@
 # UK Open Banking [https://www.openbanking.org.uk/providers/standards/#request web page] and [https://bitbucket.org/openid/obuk/src/8aec1c5808f6a22c39f669bb31de9f424cac19d7/uk-openbanking-registration-profile.md?at=master&fileviewer=file-view-default standards].
 # OAuth 2.0 Authorization Server Metadata is now RFC 8414 (2018-06-26) <ref>Mike Jones, OAuth 2.0 ''Authorization Server Metadata is now RFC 8414.'' http://self-issued.info/?p=1883</ref>
 ===Authentication===

@@ Line 25: / Line 25: @@
 # [https://kantarainitiative.org/groups/federation-interoperability-work-group/ Kantara Federation Interoperability Work Group] has published a SAML version of metadata exchange.
-# Kantara [https://kantarainitiative.org/category/otto/ Open Trust Taxonomy for OAuth 2.0] or OTTO for authorization federations.
+# Kantara [https://kantarainitiative.org/ottowgformation/ Open Trust Taxonomy for OAuth 2.0] or OTTO for authorization federations.
 # ONC (The Office of the National Coordinator for Health Information Technology) [https://nhsconnect.github.io/gpconnect/development_fhir_api_guidance.html FHIR API guidance].
 # UK Open Banking [https://www.openbanking.org.uk/providers/standards/#request web page] and [https://bitbucket.org/openid/obuk/src/8aec1c5808f6a22c39f669bb31de9f424cac19d7/uk-openbanking-registration-profile.md?at=master&fileviewer=file-view-default standards].

@@ Line 13: / Line 13: @@
 # Federation or credential sharing and [[Verification]] among web providers,
 # Authentication or credential sharing and [[Assurance]] from an individual.
-# Granting of consent by a [[Subject]] to a web site to act in its behalf, or as a fiduciary of the subject's property.
+# Granting of consent by a [[Subject]] to a web site to act in its behalf, or as a [[Fiduciary]] of the subject's property.
 # [[Information Sharing]] including the reporting of information held by a web site on behalf of a [[Subject]].

@@ Line 10: / Line 10: @@
 <blockquote>Think of an API as a server in a restaurant. Imagine you are sitting at a table with a menu of choices to order from, and the kitchen is the part of the system that will prepare the order. What’s missing is the critical link to communicate your order to the kitchen and deliver your food back to your table. That’s where the server, or API, comes in.</blockquote>
-There are three broad areas of sharing that occur in the maintenance of an [[Identity]] Ecosystem: credentials, grants and [[Information Sharing]]. In the case of credentialing, there is a huge asymmetry between the manner in which a web provider is expected to share credential versus an individual [[Subject]], that teaches us to separate the types of [[API]] into these four categories:
+There are three broad areas of sharing that occur in the maintenance of an [[Identity Ecosystem]]: credentials, grants and [[Information Sharing]]. In the case of credentialing, there is a huge asymmetry between the manner in which a web provider is expected to share credential versus an individual [[Subject]], that teaches us to separate the types of [[API]] into these four categories:
 # Federation or credential sharing and [[Verification]] among web providers,
 # Authentication or credential sharing and [[Assurance]] from an individual.

@@ Line 32: / Line 32: @@
 ===Authentication===
-# [[SAML 2.0]] was the first Single Sign On standard.
+# [[SAML 2.0]] was the first [[Single Sign-On]] standard.
 # [[OpenID Connect]] is the current most popular standard.
 # [https://pages.nist.gov/800-63-3/sp800-63-3.html New version of SP 800-63-3]

@@ Line 40: / Line 40: @@
 This effort requires a taxonomy of types of information to be shared, which is now available from several sources.
-# No work is currently (20-20-12-01) underway in granting consent beyond that buried in the Open ID Connect specification.
+# No work is currently (2020-12-01) underway in granting consent beyond that buried in the Open ID Connect specification.
 # Kantara [[Consent Receipt]] is now available in an implementer's draft.