Difference between revisions of "Entity Statement"

From MgmtWiki
Jump to: navigation, search
(→‎Solutions)
(→‎Solutions)
 
(42 intermediate revisions by the same user not shown)
Line 6: Line 6:
  
 
==Problems==
 
==Problems==
 +
There have been several attempts to get information from web sites to users. These have diverged in unexpected ways based on the approach taken.
  
 
==Solutions==
 
==Solutions==
Line 13: Line 14:
 
| Entity Statement ||HL7 capability|| X.509 certificate||DID Document || Notes
 
| Entity Statement ||HL7 capability|| X.509 certificate||DID Document || Notes
 
|-
 
|-
−
| n/a || unique URI|| version 3|| || Document ID - may include url to this or current version of doc
+
|End Points||End Points||DNS range||one key instance|| collection of scopes
 
|-
 
|-
−
| iss || || || || The entity identifier of the issuer of the statement.
+
| n/a || persistent URI|| ver 3, Serial No.||@context || Document ID - may include status & url to this or current version of doc
 
|-
 
|-
−
| sub|| || || ||The entity identifier of the subject
+
| n/a ||s/w app name || || ||may include status & a human readable description of function
 
|-
 
|-
−
| iat  || || || || The time the statement was issued.  
+
| || software || || || very specific software version (GUID?) incl. trade name, release date
 
|-
 
|-
−
| exp || || || || Expiration time when the statement MUST NOT be used for new signatures
+
| iss || publisher|| Issuer|| controller|| The entity identifier of the issuer of the statement may incl. contact
 
|-
 
|-
−
| jwks || || || || public part of the subject entity's signing keys
+
|scope?||use context|| || ||
 
|-
 
|-
−
| authority_hints|| || || ||entities that may issue an entity statement about the issuer entity
+
|grant_types?||purpose ||EKU || ||
 +
|-
 +
| || jurisdiction || || || who's laws apply?
 +
|-
 +
| sub|| ||Subject DN || id||The entity identifier of the subject
 +
|-
 +
| || || ||authn method||
 +
|-
 +
| iat  ||date published  ||Not Before || || The time the statement was issued or start validity
 +
|-
 +
| exp || ||Not After|| ||Expiration time when the statement MUST NOT be used for new signatures
 +
|-
 +
| jwks || ||public key || publicKeyPem || public part of the subject entity's signing keys
 +
|-
 +
| authority_hints|| imports||chain ||blockchain ||entities that may issue an entity statement about the issuer entity
 
|-
 
|-
 
| metadata || || || || protocol specific metadata claims
 
| metadata || || || || protocol specific metadata claims
Line 31: Line 46:
 
| metadata_policy|| || || ||type followed by organization information
 
| metadata_policy|| || || ||type followed by organization information
 
|-
 
|-
−
| sub_is_leaf|| || || ||is the subject considered a leaf entity
+
|constraints || || || || trust chain contraints
 +
|-
 +
|crit || || || || claims that MUST be understood and processed.
 +
|-
 +
| metadata type|| kind of app || || ||overall purpose of this type of installation
 +
|-
 +
|policy ||instantiates || || || uri of detailed description (level confusion)
 +
|-
 +
| sub_is_leaf|| || || ||is the subject considered a leaf entity or [[Leaf Node]]
 +
|-
 +
| organization_name|| implementation ||Legal entity || || incl contact, uri. not very exact correspondence (level confusion)
 +
|-
 +
| response mode||rest ||  || ||How the request & response are put into http incl. security choices
 +
|-
 +
|errors ||messaging || || || needs to be part of good implementation support
 +
|-
 +
| || documentation || || || seems out-of-place?
 +
|-
 +
| federation||s/w app  ||PKI || self ID||context
 +
|-
 +
|trust_marks || || || || image
 
|-
 
|-
−
| Legal entity || || || || not part of openid statement
+
|trust_anchor_id || || || ||  
 
|-
 
|-
−
| b|| || || ||
+
|aud || || || || audience = the entity that is specifically targeted by this statement.
 
|-
 
|-
−
| c|| || || ||
+
| signature || || || || singed by the issuer of the statement
 
|}
 
|}
  
 
===HL7 FHIR Capability Statement===
 
===HL7 FHIR Capability Statement===
−
The FHIR spec include a definition of a [https://hl7.org/fhir/R4/capabilitystatement.html Resource Capability Statement]. Which is similar in purpose to the [[Entity Statement]] but includes FHIR specific fields. To quote the spec "A Capability Statement documents a set of capabilities (behaviors) of a FHIR Server for a particular version of FHIR that may be used as a statement of actual server functionality or a statement of required or desired server implementation.".
+
The FHIR spec includes a definition of a [https://hl7.org/fhir/R4/capabilitystatement.html Resource Capability Statement]. Which is similar in purpose to the [[Entity Statement]] but includes FHIR specific fields. To quote the spec "A Capability Statement documents a set of capabilities (behaviors) of a FHIR Server for a particular version of FHIR that may be used as a statement of actual server functionality or a statement of required or desired server implementation.".
  
 
==References==
 
==References==

Latest revision as of 16:39, 11 January 2024

Full Title or Meme

A digital document that describes a digital Entity typically signed by a trusted issuer or Authority.

Context

On the Identity Management page different roles are defined for Entities.

Problems

There have been several attempts to get information from web sites to users. These have diverged in unexpected ways based on the approach taken.

Solutions

Quite a few structures have been defined to describe entities. The Entity Statement created in the OpenID Connect Federation document is taken as be base for comparison with several others in the table below.

Entity Statement HL7 capability X.509 certificate DID Document Notes
End Points End Points DNS range one key instance collection of scopes
n/a persistent URI ver 3, Serial No. @context Document ID - may include status & url to this or current version of doc
n/a s/w app name may include status & a human readable description of function
software very specific software version (GUID?) incl. trade name, release date
iss publisher Issuer controller The entity identifier of the issuer of the statement may incl. contact
scope? use context
grant_types? purpose EKU
jurisdiction who's laws apply?
sub Subject DN id The entity identifier of the subject
authn method
iat date published Not Before The time the statement was issued or start validity
exp Not After Expiration time when the statement MUST NOT be used for new signatures
jwks public key publicKeyPem public part of the subject entity's signing keys
authority_hints imports chain blockchain entities that may issue an entity statement about the issuer entity
metadata protocol specific metadata claims
metadata_policy type followed by organization information
constraints trust chain contraints
crit claims that MUST be understood and processed.
metadata type kind of app overall purpose of this type of installation
policy instantiates uri of detailed description (level confusion)
sub_is_leaf is the subject considered a leaf entity or Leaf Node
organization_name implementation Legal entity incl contact, uri. not very exact correspondence (level confusion)
response mode rest How the request & response are put into http incl. security choices
errors messaging needs to be part of good implementation support
documentation seems out-of-place?
federation s/w app PKI self ID context
trust_marks image
trust_anchor_id
aud audience = the entity that is specifically targeted by this statement.
signature singed by the issuer of the statement

HL7 FHIR Capability Statement

The FHIR spec includes a definition of a Resource Capability Statement. Which is similar in purpose to the Entity Statement but includes FHIR specific fields. To quote the spec "A Capability Statement documents a set of capabilities (behaviors) of a FHIR Server for a particular version of FHIR that may be used as a statement of actual server functionality or a statement of required or desired server implementation.".

References

Retrieved from "http://tcwiki.azurewebsites.net/index.php?title=Entity_Statement&oldid=19552"