Difference between revisions of "API"

From MgmtWiki
Jump to: navigation, search
(→‎Authentication)
(→‎Granting Consent)
(34 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
==Full Title or Meme==
 
==Full Title or Meme==
−
An Application Program Interface [[API]] in the area of [[Identity]] and [[Information Sharing]].
+
An Application Program Interface [[API]] in the area of [[Identity]] and [[Information Sharing]] that can be accessed over the internet.
  
 
==Context==
 
==Context==
 +
[[API]]s on the internet can provide all manner of functionality. This wiki is dedicated to [[Identity Management]] and [[Information Sharing]].
 +
 
Within the context of establishing and maintaining a [[Trusted Identity in Cyberspace]] different digital entities will need to exchange information in a machine readable format. These exchanges can be represented as a [[Network Protocol]] on the way that the data flows among the various entities, or as an Application Program Interface for how one entity exposes the protocol to the network. This page is about the later.
 
Within the context of establishing and maintaining a [[Trusted Identity in Cyberspace]] different digital entities will need to exchange information in a machine readable format. These exchanges can be represented as a [[Network Protocol]] on the way that the data flows among the various entities, or as an Application Program Interface for how one entity exposes the protocol to the network. This page is about the later.
 +
 +
Here is the way the VA described an api:<ref>Mike Miliard, ''FHIR and Open APIs are here to stay - but are they ready for prime time?'' (2018-03-20) Healthcare IT News https://www.healthcareitnews.com/news/fhir-and-open-apis-are-here-stay-are-they-ready-prime-time</ref>
 +
<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,
+
# Federation or credential sharing and [[Verification]] among web providers,
 
# Authentication or credential sharing and [[Assurance]] from an individual.
 
# 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.
Line 15: Line 20:
  
 
==Solutions==
 
==Solutions==
 +
While an API can be accessed over a variety of protocols on the internet, the dominate protocol is HTTP(S) and so that will be focus of this page.
  
 
===Federation===
 
===Federation===
  
 
# [https://kantarainitiative.org/groups/federation-interoperability-work-group/ Kantara Federation Interoperability Work Group] has published a SAML version of metadata exchange.
 
# [https://kantarainitiative.org/groups/federation-interoperability-work-group/ Kantara Federation Interoperability Work Group] has published a SAML version of metadata exchange.
−
# RFC
+
# Kantara [https://kantarainitiative.org/category/otto/ 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].
 +
# 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===
 
===Authentication===
  
−
# SAML
+
# [[SAML 2.0]] was the first Single Sign On standard.
−
# OpenID Connect
+
# [[OpenID Connect]] is the current most popular standard.
−
# NIST 800-63-3
+
# [https://pages.nist.gov/800-63-3/sp800-63-3.html New version of SP 800-63-3]
  
 
===Granting Consent===
 
===Granting Consent===
  
 +
This effort requires a taxonomy of types of information to be shared, which is now available from several sources.
 +
 +
# 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.
  
 
===Information Sharing===
 
===Information Sharing===
 +
 +
[[Information Sharing]] includes the broad list of all sort of information about a [[Subject]] that is collected by a web site; and not just [[User Information]] that is securely shared with user consent, but also the user behaviors like web site visits, searches and purchases as well.
 +
 +
This area would require a taxonomy of data types to be shared; for example the diagnostic codes used in health care.
  
 
==References==
 
==References==

Revision as of 11:34, 26 January 2021

Full Title or Meme

An Application Program Interface API in the area of Identity and Information Sharing that can be accessed over the internet.

Context

APIs on the internet can provide all manner of functionality. This wiki is dedicated to Identity Management and Information Sharing.

Within the context of establishing and maintaining a Trusted Identity in Cyberspace different digital entities will need to exchange information in a machine readable format. These exchanges can be represented as a Network Protocol on the way that the data flows among the various entities, or as an Application Program Interface for how one entity exposes the protocol to the network. This page is about the later.

Here is the way the VA described an api:[1]

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.

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:

  1. Federation or credential sharing and Verification among web providers,
  2. Authentication or credential sharing and Assurance from an individual.
  3. Granting of consent by a Subject to a web site to act in its behalf, or as a fiduciary of the subject's property.
  4. Information Sharing including the reporting of information held by a web site on behalf of a Subject.

Problems

How can a Subject trust a web site with only that part of its personal information as is required to acquire access to the resources of the web site.

Solutions

While an API can be accessed over a variety of protocols on the internet, the dominate protocol is HTTP(S) and so that will be focus of this page.

Federation

  1. Kantara Federation Interoperability Work Group has published a SAML version of metadata exchange.
  2. Kantara Open Trust Taxonomy for OAuth 2.0 or OTTO for authorization federations.
  3. ONC (The Office of the National Coordinator for Health Information Technology) FHIR API guidance.
  4. UK Open Banking web page and standards.
  5. OAuth 2.0 Authorization Server Metadata is now RFC 8414 (2018-06-26) [2]

Authentication

  1. SAML 2.0 was the first Single Sign On standard.
  2. OpenID Connect is the current most popular standard.
  3. New version of SP 800-63-3

Granting Consent

This effort requires a taxonomy of types of information to be shared, which is now available from several sources.

  1. No work is currently (2020-12-01) underway in granting consent beyond that buried in the Open ID Connect specification.
  2. Kantara Consent Receipt is now available in an implementer's draft.

Information Sharing

Information Sharing includes the broad list of all sort of information about a Subject that is collected by a web site; and not just User Information that is securely shared with user consent, but also the user behaviors like web site visits, searches and purchases as well.

This area would require a taxonomy of data types to be shared; for example the diagnostic codes used in health care.

References

  1. ↑ Mike Miliard, FHIR and Open APIs are here to stay - but are they ready for prime time? (2018-03-20) Healthcare IT News https://www.healthcareitnews.com/news/fhir-and-open-apis-are-here-stay-are-they-ready-prime-time
  2. ↑ Mike Jones, OAuth 2.0 Authorization Server Metadata is now RFC 8414. http://self-issued.info/?p=1883
Retrieved from "http://tcwiki.azurewebsites.net/index.php?title=API&oldid=9262"