Q2 2021 release from IDS-G-pre (International-Data-Spaces-Association#20

)

* Q2 2021 release from IDS-G-pre

Release Q2 2021 of IDS-G based on IDS-G-pre see changelog for details

CHANGELOG.md

@@ -0,0 +1,52 @@
+# Changelog
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## [Unreleased]
+
+### Added
+- Connector interaction, IDS-REST, IDSCP
+
+### Changed
+- none
+- 
+### Removed
+- none
+
+### Deprecated 
+- none
+
+### Fixed
+- none
+
+### Security
+- none
+
+## Q2/2021 2021-08-23
+### Added
+
+- IDS Meta Data Broker Specification
+- DAPS Specification
+- ParIS Specification
+- License, CONTRIBUTING.MD, CHANGELOG.MD, CODE_OF_CONDUCT.MD
+- Handbook
+
+
+
+### Changed
+- New structure for IDS-G and IDS-G-pre
+- Readme.md provides overview on active developments and approvals
+
+### Removed
+- Participant description
+
+### Deprecated 
+- none
+
+### Fixed
+- none
+
+### Security
+- none

CODE_OF_CONDUCT.md

@@ -0,0 +1,71 @@
+## Code of Conduct
+
+### Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, gender identity and expression, level of experience,
+nationality, personal appearance, race, religion, or sexual identity and
+orientation.
+
+### Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+### Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+### Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+### Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+### Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant](http://contributor-covenant.org),
+version 1.4, available at http://contributor-covenant.org/version/1/4.

CONTRIBUTING.md

@@ -0,0 +1,78 @@
+# Contributing to IDS-G-pre
+
+IDS-G is the official repository of [IDSA](https://www.internationaldataspaces.org) to publish the [IDS-RAM]() and the subsequent specifications.
+
+All content published here is approved by the IDSA Technical Steering Committee and the ISDA Working Groups. Detailed information on the contribution process can be found in the [IDS-G Handbook](Handbook/README.md). Nevertheless, you are very welcome to contribute
+to this project when you find a bug, want to suggest an improvement, or have an idea for a useful
+feature. For this, always create an issue and a corresponding branch, and follow our style
+guides as described below.
+
+Please note that we have a [code of conduct](CODE_OF_CONDUCT.md) that all contributors should stick to.
+
+## Changelog
+
+We document changes in the [CHANGELOG.md](CHANGELOG.md) on root level which is formatted and
+maintained according to the rules documented on http://keepachangelog.com.
+
+## Issues
+
+You always have to create an issue if you want to propose or integrate a bugfix, improvement, or feature.
+Briefly and clearly describe the purpose of your contribution in the corresponding issue.
+The pre-defined [labels](#labels) improve the understanding of your intentions and help to follow
+the scope of your changes.
+
+**Bug Report**: As mentioned above, bug reports should be submitted as an issue. To give others
+the chance to reproduce the error in order to find a solution as quickly as possible, the report
+should at least include the following information:
+* Description: What did you expect and what happened instead?
+* Steps to reproduce (system specs included)
+* Relevant logs and/or media (optional): e.g. an image
+
+## Labels
+
+The [labels](https://github.com/International-Data-Spaces-Association/ids-g/labels) are listed at the
+[issues](https://github.com/International-Data-Spaces-Association/IDS-G/issues).
+There are two types of labels: one describes the content of the issue and should be used by the
+developer that creates the issue. The other one, starting with `status`, will be added from the
+developer that takes on the issue. New issues should be initially marked with `status:open`.
+*  Basic labels: `bug`, `enhancement`, `suggestion`, `documentation` `outdated`, `question`, `discussion`
+*  `status:closed`: issue is closed (after successful approval by issuer and QA)
+*  `status:duplicate`: issue is a duplicate of another linked issue and therefore discontinued
+*  `status:in-progress`: issue has been assigned and is currently being worked on
+*  `status:on-hold`: issue may be implemented at a later date
+*  `status:open`: issue has been submitted or re-opened recently
+*  `status:out-of-scope`: issue is considered out of the project's scope and therefore not further considered
+*  `status:resolved`: issue has been implemented and tested by a developer
+*  `status:wont-fix`: issue is in scope but considered impossible or too expensive to deal with
+
+## Branches
+
+After creating an issue yourself or if you want to address an existing issue, you have to create a
+branch with a unique number and name that assigns it to an issue. Therefore, follow the guidelines
+at https://deepsource.io/blog/git-branch-naming-conventions/. After your changes, update the
+`README.md`, Wiki, and `CHANGELOG.md` with necessary details. Then, create a pull request and note
+that **committing to the main branch is not allowed**. Please use the feature `linked issues` to
+link issues and pull requests.
+
+Pull requests have to be approved by the IDSA TSC and the IDSA Working Groups.
+
+## Commits
+
+We encourage all contributors to stick to the commit convention following the specification on
+[Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/). In general, use  the
+imperative in the present tense. A quick overview of the schema:
+```
+<type>[optional scope]: <description>
+[optional body]
+[optional footer(s)]
+```
+
+Types: `fix`, `feat`, `chore`, `test`, `refactor`, `docs`, `release`. Append `!` for breaking
+changes to a type.
+
+An example of a very good commit might look like this: `feat![login]: add awesome breaking feature`
+
+
+## Versioning
+IDS-G-pre uses the [SemVer](https://semver.org/) for versioning. The release versions
+are tagged with their respective version.

Communication/README.md

@@ -0,0 +1,3 @@
+# Communication
+
+The content in this folder will specify the communication between different IDS components.

Components/AppStore/README.md

@@ -0,0 +1,5 @@
+# IDS App Store (IDS-CH)
+
+- [Glossary "App Store"](../../Glossary/README.md#app-store)
+
+---

Components/ClearingHouse/README.md

@@ -0,0 +1,6 @@
+# IDS Clearing House (IDS-CH)
+
+- [Glossary "Clearing House"](../../Glossary/README.md#clearing-house)
+- Shortcut: `IDS-CH`
+
+---

Components/Connector/README.md

@@ -0,0 +1,5 @@
+# IDS Connector
+
+- [Glossary "Connector"](../../Glossary/README.md#connector)
+
+---

Components/IdentityProvider/CA/README.md

@@ -0,0 +1,9 @@
+# Certificate Authority (CA)
+
+See also:
+
+- [Glossary "Certificate Authority"](../../../Glossary/README.md#certification-authority)
+
+- Shortcut: `CA`
+
+---

core/DAPS/README.md → Components/IdentityProvider/DAPS/README.md

@@ -1,39 +1,41 @@
 # Dynamic Attribute Provisioning Service (DAPS)
 
-The infrastructure component "Digital Attribute Provisioning Service" (DAPS)
+The infrastructure component "Dynamic Attribute Provisioning Service" (DAPS)
  in a given IDS ecosystem enables enrichment of identities of organisations
  and connectors with additional attributes.
-
-DAPS can be understood (like the [Certification Authority](../CA/README.md), too) as building block of the construct of an
- [IDS Identity Provider](../../glossary/README.md#identity-provider). 
+
+DAPS can be understood (like the [Certificate Authority](../CA/README.md), too) as building block of the construct of an
+ [IDS Identity Provider](../../glossary/README.md#identity-provider).
+
+
 
 These attributes are embedded by the DAPS into a [Dynamic Attribute Token (DAT)]().
  The advantages of this technique of *dynamic attribute provisioning* instead
  of embedding them into [X.509 certificates](https://en.wikipedia.org/wiki/X.509)
  are:
 
 - Attribute revocation does not enforce certificate revocation and re-issuance.
- This is also true if new attributes are added. 
+ This is also true if new attributes are added.
 - By defining scopes or attribute sets, only the needed attributes can be
  included in the DAT. This limits information leakage, so only needed
  attributes are communicated.
 - Baseline certificates can be issued to enable connector deployment
  in uncomplicated manner.
 - More complex scenarios can be created as soon as attributes are
- assigned later on. 
+ assigned later on.
 
 See also:
-- [Glossary "Dynamic Attribute Provisioning Service"](../../glossary/README.md#dynamic-attribute-provisioning-service)
+- [Glossary "Dynamic Attribute Provisioning Service"](../../../Glossary/README.md#dynamic-attribute-provisioning-service)
 - Shortcut: `DAPS`
 
 ---
 
 ## Unique Identifier
 
-Each (TODO: COMPONENT/entry) connector in the IDS needs a valid, outlasting and unique
+Each connector in the IDS needs a valid, outlasting and unique
  identifier, never be re-used for any other resource inside the IDS ecosystem.
 
-The architecture aims to be open to multiple [Certification Authorities](../CA/README.md)
+The architecture aims to be open to multiple [Certificate Authorities](../CA/README.md)
  (CAs) issuing certificates. This means, a truly unique identifier needs to consist of
   the issuer of the certificate and the subject identifier. For an easy machine readable
   identifier, two ´X.509v3´ extensions will be used:
@@ -48,17 +50,15 @@ EXAMPLE (snippet from a X.509 certificate):
 
 ```
 ...
-
 X509v3 extensions:
     X509v3 Subject Key Identifier:
         DD:CB:FD:0B:93:84:33:01:11:EB:5D:94:94:88:BE:78:7D:57:FC:4A
     X509v3 Authority Key Identifier:
         keyid:CB:8C:C7:B6:85:79:A8:23:A6:CB:15:AB:17:50:2F:E6:65:43:5D:E8
-
 ...
 ```
 
-... leads to a [connectors](../Connector/README.md) `unique identifier`:
+... leads to a [connectors](../../Connector/README.md) `unique identifier`:
 
 ```
 DD:CB:FD:0B:93:84:33:01:11:EB:5D:94:94:88:BE:78:7D:57:FC:4A:keyid:CB:8C:C7:B6:85:79:A8:23:A6:CB:15:AB:17:50:2F:E6:65:43:5D:E8
@@ -71,11 +71,11 @@ SKI:AKI
 ```
 
 See also:
-- [Glossary "Dynamic Attribute Token"](../../glossary/README.md#dynamic-attribute-token)
+- [Glossary "Dynamic Attribute Token"](../../../Glossary/README.md#dynamic-attribute-token)
 - Shortcut: `DAT`
 - [X.509 certificates](https://en.wikipedia.org/wiki/X.509)
 
---- 
+---
 
 
 ## Request token that is handed in at DAPS side
@@ -101,7 +101,7 @@ See also:
 
 |**FormBody Attribute**|**content**
 |:---|:---|
-|**`grant_type`**  | OAuth based grant type. See [TODO : client_credentials grant](TODO). |
+|**`grant_type`**  | OAuth based grant type. Always uses client_credentials grant. |
 |**`client_assertion_type`**  | See [JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants](https://tools.ietf.org/html/rfc7523). |
 |**`client_assertion`**  | The signed and base64 encoded request token. Paste the example to jwt.io to see the decoded JWT. The token is signed with the connectors private key belonging to the public key contained in the X.509 certificate. |
 
@@ -112,16 +112,14 @@ See also:
 POST /
 Host: https://daps.example.com
 Content-Type: application/x-www-form-urlencoded
-
 "grant_type=client_credentials
  &client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
  &client_assertion=eyJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJkZW1vY29ubmVjdG9yMSIsInN1YiI6ImRlbW9jb25uZWN0b3IxIiwiZXhwIjoxNTQ4Nzg1Mzg2LCJuYmYiOjE1NDg3ODE3ODYsImlhdCI6MTU0ODc4MTc4NiwiYXVkIjoiaHR0cHM6Ly9hcGkubG9jYWxob3N0In0.JSQuMf-9Fd7DNna_-s-sR7eXgcSYNCau5WgurrGJTuCSLKqhZe3odXfunN2vRFgUhU21ADFlEq96mlbQDueBlMtaXrcHFPSpIUtvuIMIVqQcGYkDdSJr_VmDuAykCYpyTCkLa7a8DTV-N3sECp-AxUgmEzYIfh8jW0WS6ehgUzrnpH6t_h_GWXKkNSAg3ERakDc4NY02pBGmiN7bmtLZNt5b4LWALiiFiduC7JbIpx4awOU6skMApmzgLnZmmTG20JlJRg6hAqyHEz5Cd4rUgrt0twmpC0Us_CG23KdUF5fWI55dcO2qAVvhNQXpqz7IiPcF7-jgkrx4oukYNY6eHA"
  &scope=ids_connector_attributes"
-  
+
 ```
-
-> **!!!** REMARK: NO line breaks in front of '&', done for better readability only **!!!**
 
+> **!!!** REMARK: NO line breaks in front of '&', done for better readability only **!!!**
 
 See also:
 - [JSON-LD](https://en.wikipedia.org/wiki/JSON-LD)
@@ -147,7 +145,7 @@ The DAT has these payload fields:
 |**Field name**|**mandantory**|**cardinality**|**content**
 |:---|:---|:---|:---|
 |**`@context`**             | yes    | 1    | The JSON-LD context containing the IDS classes, properties and instances. Must be "https://w3id.org/idsa/contexts/context.jsonld". |
-|**`@type`**                | yes    | 1    | In the context of the IDS, the request payload is an RDF instance and therefore must state that it has "@type" : "ids:DatRequestToken". TODO: @SBA: We need a type def for this... |
+|**`@type`**                | yes    | 1    | In the context of the IDS, the request payload is an RDF instance and therefore must state that it has "@type" : "ids:DatRequestToken".
 |**`iss`**                  | yes    | 1    | According to RFC 7519 Sec. 4.1.1, the issuer is the component which created and signed the JWT. In the context of the IDS, this must be a valid DAPS. The "iss" value must be a valid URL for the DAPS such as "https://daps.aisec.fraunhofer.de".  |
 |**`sub`**                  | yes    |      | Subject the requesting connector the token is created for. This is the connector requesting the [DAT](#dynamic-attribute-token-dat). The `sub` value must be the  combined entry of the `SKI` and `AKI` of the IDS X509 as presented in Sec. 4.2.1.  In this context, this is identical to `iss`. |
 |**`exp`**                  | yes    | 1    | Expiration date of the token. Can be chosen freely but should be limited to a short period of time (e.g., one minute).  |
@@ -178,7 +176,7 @@ An example of a complete DAT, including header and payload is shown below:
     "iss": "https://daps.aisec.fraunhofer.de",
     "sub": "DD:CB:FD:0B:93:84:33:01:11:EB:5D:94:94:88:BE:78:7D:57:FC:4A:keyid:CB:8C:C7:B6:85:79:A8:23:A6:CB:15:AB:17:50:2F:E6:65:43:5D:E8",
     "referringConnector": "http://some-connector-uri.com",
-    "securityProfile": "idsc:BASE_CONNECTOR_SECURITY_PROFILE",
+    "securityProfile": "idsc:BASE_SECURITY_PROFILE",
     "extendedGuarantee": "idsc:USAGE_CONTROL_POLICY_ENFORCEMENT",
     "transportCertsSha256": ["bacb879575730bb083f283fd5b67a8cb..." ],
     "iat": 1516239022,
@@ -189,12 +187,11 @@ An example of a complete DAT, including header and payload is shown below:
 }
 .
 <signature>
-
 ```
 
 See also:
 - [Info Model : idsc:USAGE_CONTROL_POLICY_ENFORCEMENT](https://github.com/International-Data-Spaces-Association/InformationModel/blob/develop/codes/SecurityGuarantee.ttl)
-- [Glossary "Dynamic Attribute Token"](../../glossary/README.md#dynamic-attribute-token)
+- [Glossary "Dynamic Attribute Token"](../../../Glossary/README.md#dynamic-attribute-token)
 - Shortcut: `DAT`
 
 ---
@@ -209,4 +206,3 @@ REST API description can be found
  [here](https://app.swaggerhub.com/apis/IDS_Association/DynamicAttributeProvisioningService).
 
 ---
-

core/DAPS/requests/README.md → Components/IdentityProvider/DAPS/requests/README.md

@@ -1,4 +1,4 @@
-# DAPS requests
+ DAPS requests
 
 |**request**|**example**|**summary**|
 |:---|:---|:---|