WIP: Identities #79

milux · 2022-11-03T08:50:01Z

Work in progress.
Definition of requirements and properties of connector identities.

Fixed typo and added missing changelog entry for changes in CONTRIBUTING.md

Adding the Structure for the communication guide and moving the infomodel to a new location.

tidy up formatting

…ation Add more foundational standards

* Adding prelimmary figure and source Adding entities and realtionship of dataspaces as png and draw.io source * Linking the entity model to the Communication Guide * Add Catalog section to the CommunicationGuide * Add Catalog section to the CommunicationGuide Co-authored-by: Sebastian Bader <[email protected]> Co-authored-by: Anil Turkmayali <[email protected]>

* Issue 46: Bugfix adding necessary JSON-LD context elements (#49) * Bugfix adding necessary JSON-LD context elements Co-authored-by: Sebastian Steinbuss <[email protected]> * Add specification input documents * Remove uneccessary restrictions * Add numbering * Fix cardinality typo * Add mapping section Co-authored-by: sebbader-sap <[email protected]> Co-authored-by: Jim Marino <[email protected]>

…n-guide-identities

Communication/Identities/README.md

mokamhuber · 2022-11-18T15:09:42Z

isn't this pull request obsolete since the respective changes have been merged to another branch by: #83?

gbrost · 2022-11-18T15:12:39Z

Communication/Identities/README.md

+# Identities
+
+Connector identities according to this specification are typically represented by some sort of token.
+This token contains statements about properties of the connector ("claims"), like its membership in one or more data spaces.


and it's trust level as well as it's assurance level (e.g., trust level 1 for base connector with assurance level 1 for a self-assessment).

Please tell the exact claim names for the token.

gbrost · 2022-11-18T15:14:41Z

Communication/Identities/README.md

+In order to establish trust via these tokens, two requirements have to be met:
+
+- Security-relevant claims within the token, or the entire token as a whole, MUST be signed by one or more trusted entities.
+- There MUST exist a sound mechanism that enables a connector to proof ownership over the tokens or claims issued for this particular connector.


So this means, the token belongs to the connector that is trying to establish a connection? Should we mention binding the base identity/certificate to the token?

We would also have to somehow signal the used version of a DAT to the other connector. This is facilitated by the version encoded in the issuer URL at the moment. Should we consider requirements for that?

Suggestions welcome. (:

TODO: Talk with @bellebaum about versioning schema and whether this makes sense.

So this means, the token belongs to the connector that is trying to establish a connection? Should we mention binding the base identity/certificate to the token?

I think the point right below this one is supposed to express exactly this, but making the channel binding (That's what some authentication mechanisms call it) explicit may be less subtle.

We would also have to somehow signal the used version of a DAT to the other connector. This is facilitated by the version encoded in the issuer URL at the moment. Should we consider requirements for that?

As far as I am aware, there is as of now no versioning scheme for the DAT, just for the DAPS. I feel like the more appropriate thing to do is to ensure the DAT claims stay backwards compatible, and update the verification routines to include checks on newer included information.

If applicable, some sort of critical array can also be defined marking certain keys in the DAT as critical. The idea here would be that any connector MUST reject DATs for which it does not know how to handle/check a certain claim. This should of course only be done with claims adding additional proofs of applicability to the connector (like new forms of binding). C.t. https://www.rfc-editor.org/rfc/rfc5280#section-4.2

If applicable, some sort of critical array can also be defined marking certain keys in the DAT as critical. The idea here would be that any connector MUST reject DATs for which it does not know how to handle/check a certain claim. This should of course only be done with claims adding additional proofs of applicability to the connector (like new forms of binding). C.t. https://www.rfc-editor.org/rfc/rfc5280#section-4.2

Interesting idea. This is however not yet part of any existing OAuth-related standard, is it? If we do this, should we explain it here in the IDS-G as well?

Communication/Identities/README.md

gbrost · 2022-11-18T15:17:41Z

Communication/Identities/README.md

+Each implementation of identity tokens MUST at least implement the following claims:
+
+- `securityProfile`: Reflects the `SecurityProfile` of the owning connector according to IDS certification criteria.
+Valid values are `idsc:BASE_SECURITY_PROFILE`, `idsc:TRUST_SECURITY_PROFILE` and `idsc:TRUST_PLUS_SECURITY_PROFILE` as given by the members of https://international-data-spaces-association.github.io/InformationModel/docs/index.html#SecurityProfile.


See comment above, potentially also still not reflected in the info model.

Introduce trustLevel instead to be consistent with certification.

gbrost · 2022-11-18T15:22:55Z

Communication/Identities/README.md

+The claim MUST NOT contain any property that reflects a security level lower than the requirements of the stated `SecurityProfile`.
+The claim MAY contain one or more values represented by members of `SecurityGuarantee` subclasses.
+For a comprehensive list, see https://international-data-spaces-association.github.io/InformationModel/docs/index.html#SecurityGuarantee.
+


The info model will have to be updated in a number of ways to comply with the current certification proceedings.

Should we continue maintaining this opportunity for security guarantees extending the trustLevel?
@mokamhuber Do will still have such an extension concept?

The "official" certification levels for components:
https://github.com/International-Data-Spaces-Association/IDS-RAM_4_0/blob/main/documentation/4_Perspectives_of_the_Reference_Architecture_Model/4_2_Certification_Perspective/4_2_4_Component_Certification.md

So we have trust level 1-3 and assurance Level 1-3.
We can just keep the security profile as an option for future use.

Communication/Identities/README.md

milux · 2023-01-02T06:48:44Z

isn't this pull request obsolete since the respective changes have been merged to another branch by: #83?

No, according to @ssteinbuss it is still relevant.

milux · 2023-08-17T06:28:22Z

@ssteinbuss How can we proceed from here? This has been stale for a while now.

ssteinbuss · 2023-08-30T08:18:34Z

We will discuss in the next Working Group meeting in September

sebbader and others added 11 commits September 23, 2022 08:49

fix outdated references in the contribution.md (#51)

436628a

Update CHANGELOG.md

f7d182e

Fixed typo and added missing changelog entry for changes in CONTRIBUTING.md

Changing structure of Communication package

702143f

Adding the Structure for the communication guide and moving the infomodel to a new location.

Update CommunicationGuide.md

cd16a2a

tidy up formatting

add more foundational standards

6a45b74

Merge pull request #68 from sebbader-sap/55-update-strcuture-communic…

d42f16e

…ation Add more foundational standards

First identity token draft

082dcbe

Added mandatory claims section

5b97d9e

Merge branch '55-update-strcuture-communication' into 63-communicatio…

693207e

…n-guide-identities

gbrost reviewed Nov 18, 2022

View reviewed changes

Communication/Identities/README.md Outdated Show resolved Hide resolved

gbrost reviewed Nov 18, 2022

View reviewed changes

milux mentioned this pull request Mar 2, 2023

docs: Fix unclear security properties of "security tokens" International-Data-Spaces-Association/ids-specification#52

Closed

Changes based on comments

fdf6836

milux requested a review from ssteinbuss August 17, 2023 06:28

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

WIP: Identities #79

WIP: Identities #79

milux commented Nov 3, 2022

mokamhuber commented Nov 18, 2022

gbrost Nov 18, 2022

milux Jun 19, 2023

gbrost Nov 18, 2022

gbrost Nov 18, 2022

milux Jun 19, 2023

milux Jun 19, 2023

bellebaum Jun 19, 2023

milux Jun 19, 2023

gbrost Nov 18, 2022

milux Jun 19, 2023

gbrost Nov 18, 2022

milux Jun 19, 2023 •

edited

Loading

gbrost Jun 21, 2023

milux commented Jan 2, 2023 •

edited

Loading

milux commented Aug 17, 2023

ssteinbuss commented Aug 30, 2023

WIP: Identities #79

Are you sure you want to change the base?

WIP: Identities #79

Conversation

milux commented Nov 3, 2022

mokamhuber commented Nov 18, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

milux Jun 19, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

milux commented Jan 2, 2023 • edited Loading

milux commented Aug 17, 2023

ssteinbuss commented Aug 30, 2023

milux Jun 19, 2023 •

edited

Loading

milux commented Jan 2, 2023 •

edited

Loading