Skip to content

Commit

Permalink
Merge branch 'main' into ask/checksum
Browse files Browse the repository at this point in the history
  • Loading branch information
andorsk authored Dec 14, 2023
2 parents 81c8375 + f172dad commit 66c51b4
Show file tree
Hide file tree
Showing 4 changed files with 103 additions and 52 deletions.
63 changes: 63 additions & 0 deletions LICENSE
Original file line number Diff line number Diff line change
@@ -0,0 +1,63 @@
Open Web Foundation

Final Specification Agreement (OWFa 1.0)

(Patent and Copyright Grants)

1. The Purpose of this Agreement. This Agreement sets forth the terms under which I make certain copyright and patent rights available to you for your Permitted Uses of the Specification. Capitalized terms are defined in the Agreement’s last section.

2. Copyrights.

2.1. Copyright Grant. I grant to you a perpetual (for the duration of the applicable copyright), worldwide, non-exclusive, no-charge, royalty-free, copyright license, without any obligation for accounting to me, to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, distribute, and implement the Specification to the full extent of my copyright interest in the Specification.

2.2. Attribution. As a condition of the copyright grant, you must include an attribution to the Specification in any derivative work you make based on the Specification. That attribution must include, at minimum, the Specification name and version number.

3. Patents.

3.1. Patent Non-Assert.

3.1.1. The Promise. I, on behalf of myself and my successors in interest and assigns, irrevocably promise not to assert my Granted Claims against you for your Permitted Uses, subject to the terms and conditions of Section 3.1. This is a personal promise directly from me to you, and you acknowledge as a condition of benefiting from it that no rights from me are received from suppliers, distributors, or otherwise in connection with this promise. This promise also applies to your Permitted Uses of any other specifications incorporating all required portions of the Specification.

3.1.2. Termination.

3.1.2.1. As a Result of Claims by You. All rights, grants, and promises made by me to you under this Agreement are terminated if you file, maintain, or voluntarily participate in a lawsuit against me or any person or entity asserting that its Permitted Uses infringe any Granted Claims you would have had the right to enforce had you signed this Agreement, unless that suit was in response to a corresponding suit first brought against you.

3.1.2.2. As a Result of Claims by a Related Entity of Mine. If a Related Entity of mine files, maintains, or voluntarily participates in a lawsuit asserting that a Permitted Use infringes any Granted Claims it would have had the right to enforce had it signed this Agreement, then I relinquish any rights, grants, and promises I have received for the Specification from other signatories of this Agreement, unless a) my promise to you was terminated pursuant to section 3.1.2.1, or b) that suit was in response to a corresponding suit first brought by you against the Related Entity.

3.1.3. Additional Conditions. This promise is not an assurance (i) that any of my copyrights or issued patent claims cover an implementation of the Specification or are enforceable or (ii) that an implementation of the Specification would not infringe intellectual property rights of any third party. Notwithstanding the personal nature of my promise, this promise is intended to be binding on any future owner, assignee or exclusive licensee to whom has been given the right to enforce any Granted Claims against third parties.

3.1.4. Bankruptcy. Solely for purposes of Section 365(n) of Title 11, United States Bankruptcy Code and any equivalent law in any foreign jurisdiction, this promise will be treated as if it were a license and you may elect to retain your rights under this promise if I (or any owner of any patents or patent applications referenced herein), as a debtor in possession, or a bankruptcy trustee, reject this non-assert.

3.2. Patent License Commitment. In addition to rights granted in 3.1, on behalf of me and my successors in interest and assigns, I agree to grant to you a no charge, royalty free license to my Granted Claims on reasonable and non-discriminatory terms, where such license applies only to those Granted Claims infringed by the implementation of the Specification, solely for your Permitted Uses.

4. No Other Rights. Except as specifically set forth in this Agreement, no other express or implied patent, trademark, copyright, or other property rights are granted under this Agreement, including by implication, waiver, or estoppel.

5. Antitrust Compliance. I acknowledge that I may compete with other participants, that I am under no obligation to implement the Specification, that each participant is free to develop competing technologies and standards, and that each party is free to license its patent rights to third parties, including for the purpose of enabling competing technologies and standards.

6. Non-Circumvention. I agree that I will not intentionally take or willfully assist any third party to take any action for the purpose of circumventing my obligations under this Agreement.

7. Representations, Warranties and Disclaimers. I represent and warrant that I am legally entitled to grant the rights and promises set forth in this Agreement. IN ALL OTHER RESPECTS THE SPECIFICATION IS PROVIDED "AS IS." The entire risk as to implementing or otherwise using the Specification is assumed by the implementer and user. Except as stated herein, I expressly disclaim any warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to the Specification. IN NO EVENT WILL ANY PARTY BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THIS AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. All of my obligations under Section 3 regarding the transfer, successors in interest, or assignment of Granted Claims will be satisfied if I notify the transferee or assignee of any patent that I know contains Granted Claims of the obligations under Section 3. Nothing in this Agreement requires me to undertake a patent search.

8. Definitions.

8.1. Agreement. “Agreement” means this OWFa document, which sets forth the rights, grants, promises, limitations, conditions, obligations, and disclaimers made available for the particular Specification.

8.2. Bound Entities. “Bound Entities” means the entity listed below and any entities that the Bound Entity Controls.

8.3. Control. “Control” means direct or indirect control of more than 50% of the voting power to elect directors of that corporation, or for any other entity, the power to direct management of such entity.

8.4. Granted Claims. "Granted Claims" are those patent claims that I own or control, including those patent claims I acquire or control after the Date below, that are infringed by Permitted Uses. Granted Claims include only those patent claims that are infringed by the implementation of any portions of the Specification where the Specification describes the functionality causing the infringement in detail and does not merely reference the functionality causing the infringement.

8.5. I, Me, or My. “I,” “me,” or “my” refers to the signatory below and its Bound Entities, if applicable.

8.6. Permitted Uses. “Permitted Uses” means making, using, selling, offering for sale, importing or distributing any implementation of the Specification 1) only to the extent it implements the Specification and 2) so long as all required portions of the Specification are implemented. Permitted Uses do not extend to any portion of an implementation that is not included in the Specification.

8.7. Related Entities. “Related Entities” means 1) any entity that Controls the Bound Entity (“Upstream Entity”), and 2) any other entity that is Controlled by an Upstream Entity that is not itself a Bound Entity.

8.8. Specification. “Specification” means the Specification identified below

8.9. You or Your. “You,” “you,” or “your” means any person or entity who exercises copyright or patent rights granted under this Agreement, and any person or entity you Control.

Identify the Specification and version number here:

trust-registry-service-profile. All Versions.
19 changes: 14 additions & 5 deletions docs/index.html
Original file line number Diff line number Diff line change
Expand Up @@ -9,19 +9,19 @@

<body>

<h2 class='ui medium header' id="discoveryadditionalservicediscoveryusingprofiledefinitionsonadiddocument">Discovery: Additional Service Discovery Using Profile Definitions on a DID Document</h2>
<h2 class='ui medium header' id="toipserviceprofilespecification">ToIP Service Profile Specification</h2>
<p><strong>Status:</strong> Pre-Draft 0.0.1<br />
<strong>Latest Draft</strong>:<br />
<strong>Previous Draft:</strong><br />
<strong>History:</strong> <a href="https://github.com/trustoverip/tswg-trust-registry-service-profile">Commit History</a><br />
<strong>Task Force:</strong> Trust Registry Task Force<br />
<strong>Organization:</strong> Trust Over IP<br />
<strong>Editors</strong> // TODO<br />
<strong>Editors</strong> Andor Kesselman, Sam Curren
<strong>Chairs:</strong> Andor Kesselman, Darrell o' Donnell, Antti Kettunen<br />
<strong>Authors:</strong> Andor Kesselman<br />
<strong>Contributors:</strong> // TODO<br />
<strong>Contributors:</strong> Darrel o' Donnell, Antti Kettunen, Sankarshan Mukhopadhyay, Dan Bachenheimer, Mathieu Glaude, Drummund Reed, Alex Tweeddale, Tim Bouma
<strong>Feedback:</strong> <a href="https://github.com/trustoverip/tswg-trust-registry-service-profile/issues">Github Issues</a><br />
<strong>Related Documents:</strong> <a href="https://github.com/darrellodonnell/tswg-trust-registry-tf/tree/main/v2">Trust Registry Protocol</a> </p>
<p><strong>Status Description</strong>: This document is a preliminary draft and should not be regarded as a finalized version. It is subject to ongoing revisions and modifications, and its content may change significantly before reaching a final form. Please note that the information presented herein is not binding and is provided for reference and discussion purposes only. Your feedback and input are essential in shaping the final version of this document. We intend to add additional supporting material before the specification is finalized. </p>
<h3 class='ui small header' id="introduction">Introduction</h3>
<p>This specification outlines the structure and requirements for enabling
additional service discovery through profile definitions within a Decentralized
Expand Down Expand Up @@ -259,13 +259,21 @@ <h4 class='ui smallest header' id="profiledocumentsample">Profile Document Samp
}
}
</code></pre>
<h3 class='ui small header' id="securityconsiderations">Security Considerations</h3>
<p>This section describe a non-normative, non-exhaustive list of security considerations. </p>
<h4 class='ui smallest header' id="cryptographysuitesandlibraries">Cryptography Suites and Libraries</h4>
<p><em>This section is non-normative.</em></p>
<p>Some aspects of the profile model described in this specification can be protected through the use of cryptography. It is important for implementers to understand the cryptography suites and libraries used to create and process credentials and presentations. Implementing and auditing cryptography systems generally requires substantial experience. Effective red teaming can also help remove bias from security reviews.</p>
<h4 class='ui smallest header' id="unsignedprofiledocuments">Unsigned Profile Documents</h4>
<p><em>This section is non-normative.</em></p>
<p>This specification allows profiles to be produced that do not contain signatures or proofs of any kind. These types of profiles are often useful for cases where users may not have the ability to take advantage of the cryptographic proof mechanisms. Endpoint systems should be aware that these types of profiles are not verifiable because the authorship either is not known or cannot be trusted.</p>
<h3 class='ui small header' id="futurework">Future Work</h3>
<p><strong>Service Descriptors and Capability Declarations</strong> We intentionally excluded a
feature from this specification that we are eager to explore in future versions.
This pertains to defining the capabilities or services associated with the
profile data. By outlining the functions embodied by the profile, this section
provides clarity on the profile's purpose and its role within the DID ecosystem.</p>
<h3 class='ui small header' id="references">References</h3>
<h3 class='ui small header' id="referencesandacknowledgements">References and Acknowledgements</h3>
<ul class='ui list' >
<li class='ui item' >Initial Proposal: https://github.com/trustoverip/tswg-trust-registry-tf/discussions/96</li>
<li class='ui item' >DID Linked Resources :
Expand All @@ -274,6 +282,7 @@ <h3 class='ui small header' id="references">References</h3>
<li class='ui item' >DID Core: https://www.w3.org/TR/did-core/ - Referenced mainly the DID Core spec.</li>
<li class='ui item' >DIDComm Messaging: https://identity.foundation/didcomm-messaging/spec/ - used
for understanding how to update the service endpoint of the DID Document.</li>
<li class='ui item' >https://www.w3.org/TR/vc-data-model/ : For the securtiy considerations and guidance on the profile document structure. </li>
</ul>

</body>
Expand Down
47 changes: 5 additions & 42 deletions readme.md
Original file line number Diff line number Diff line change
@@ -1,45 +1,8 @@
# Trust over IP Specification Template
# ToIP Service Profile Specification

A base template.
This specification outlines the structure and requirements for enabling additional service discovery through profile definitions within a Decentralized Identifier (DID) document. By integrating service endpoints and profile information, this approach enhances the capabilities of DIDs for decentralized and self-sovereign identity systems. Some of the possible advantages include:

### How to use this template
- service and profile crawlers become possible, enabling better service discovery and interoperability across services.
- better descriptive power for individual services composibility of capabilities for succinct representation of capabilities.

The contents of this template can be used to create a ToIP specification.

### Getting Started

You need a [GitHub](https://github.com) account.

When creating a new specification, you can select 'trustoverip/toip-spec-template' from the Repository template list.

#### Set up GitHub pages

1. Under your repository name, click Settings.
2. In the "Code and automation" section of the sidebar, click Pages.
3. Under "GitHub Pages", use the drop-down menu and select 'main' as the publishing source.
4. Use the drop-down menu to select '/docs' for your publishing source.
5. Click save

### Editing

1. Edit the [specification](spec.md) using markdown.
2. Commit and push your changes

A HTML version of the spec is automatically generated and available at https://trustoverip.github.io/your-spec-name


#### Previewing locally

This requires [node.js](https://nodejs.dev) to be installed.

Install development dependencies:

```shell
npm install
```

To generate and preview the specification run:

```shell
npm run preview
```
The specification can be found [here](./spec.md).
26 changes: 21 additions & 5 deletions spec.md
Original file line number Diff line number Diff line change
@@ -1,18 +1,19 @@
## Discovery: Additional Service Discovery Using Profile Definitions on a DID Document
## ToIP Service Profile Specification

**Status:** Pre-Draft 0.0.1
**Latest Draft**:
**Previous Draft:**
**History:** [Commit History](https://github.com/trustoverip/tswg-trust-registry-service-profile)
**Task Force:** Trust Registry Task Force
**Organization:** Trust Over IP
**Editors** // TODO
**Editors** Andor Kesselman, Sam Curren
**Chairs:** Andor Kesselman, Darrell o' Donnell, Antti Kettunen
**Authors:** Andor Kesselman
**Contributors:** // TODO
**Contributors:** Darrel o' Donnell, Antti Kettunen, Sankarshan Mukhopadhyay, Dan Bachenheimer, Mathieu Glaude, Drummund Reed, Alex Tweeddale, Tim Bouma
**Feedback:** [Github Issues](https://github.com/trustoverip/tswg-trust-registry-service-profile/issues)
**Related Documents:** [Trust Registry Protocol](https://github.com/darrellodonnell/tswg-trust-registry-tf/tree/main/v2)

**Status Description**: This document is a preliminary draft and should not be regarded as a finalized version. It is subject to ongoing revisions and modifications, and its content may change significantly before reaching a final form. Please note that the information presented herein is not binding and is provided for reference and discussion purposes only. Your feedback and input are essential in shaping the final version of this document. We intend to add additional supporting material before the specification is finalized.

### Introduction

This specification outlines the structure and requirements for enabling
Expand Down Expand Up @@ -286,6 +287,20 @@ The following describes a sample profile document.
}
}
```
### Security Considerations

This section describe a non-normative, non-exhaustive list of security considerations.

#### Cryptography Suites and Libraries
_This section is non-normative._

Some aspects of the profile model described in this specification can be protected through the use of cryptography. It is important for implementers to understand the cryptography suites and libraries used to create and process credentials and presentations. Implementing and auditing cryptography systems generally requires substantial experience. Effective red teaming can also help remove bias from security reviews.

#### Unsigned Profile Documents

_This section is non-normative._

This specification allows profiles to be produced that do not contain signatures or proofs of any kind. These types of profiles are often useful for cases where users may not have the ability to take advantage of the cryptographic proof mechanisms. Endpoint systems should be aware that these types of profiles are not verifiable because the authorship either is not known or cannot be trusted.

### Future Work

Expand All @@ -295,7 +310,7 @@ This pertains to defining the capabilities or services associated with the
profile data. By outlining the functions embodied by the profile, this section
provides clarity on the profile's purpose and its role within the DID ecosystem.

### References
### References and Acknowledgements

- Initial Proposal: https://github.com/trustoverip/tswg-trust-registry-tf/discussions/96
- DID Linked Resources :
Expand All @@ -305,3 +320,4 @@ provides clarity on the profile's purpose and its role within the DID ecosystem.
- DIDComm Messaging: https://identity.foundation/didcomm-messaging/spec/ - used
for understanding how to update the service endpoint of the DID Document.
- [MultiHash](https://multiformats.io/multihash/): Used for integrity field.
- https://www.w3.org/TR/vc-data-model/ : For the securtiy considerations and guidance on the profile document structure.

0 comments on commit 66c51b4

Please sign in to comment.