├── CODEOWNERS
├── CODE_OF_CONDUCT.md
├── CONTRIBUTING.md
├── LICENSE.md
├── README.md
├── common.js
├── index.html
├── terms.html
└── w3c.json


/CODEOWNERS:
--------------------------------------------------------------------------------
1 | # These owners will be the default owners for everything in
2 | # the repo. Unless a later match takes precedence,
3 | # they will be requested for review when someone opens a 
4 | # pull request.
5 | *       @msporny @dlongley @OR13
6 | 
7 | # See CODEOWNERS syntax here: https://help.github.com/articles/about-codeowners/#codeowners-syntax
8 | 


--------------------------------------------------------------------------------
/CODE_OF_CONDUCT.md:
--------------------------------------------------------------------------------
1 | # Code of Conduct
2 | 
3 | All documentation, code and communication under this repository are covered
4 | by the [W3C Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/).
5 | 


--------------------------------------------------------------------------------
/CONTRIBUTING.md:
--------------------------------------------------------------------------------
 1 | # Credentials Community Group
 2 | 
 3 | Contributions to this repository are intended to become part of
 4 | Recommendation-track documents governed by the
 5 | [W3C Patent Policy](https://www.w3.org/Consortium/Patent-Policy-20040205/) and
 6 | [Software and Document License](https://www.w3.org/Consortium/Legal/copyright-software).
 7 | To make substantive contributions to specifications, you must either
 8 | participate in the relevant W3C Working Group or make a non-member patent
 9 | licensing commitment.
10 | 
11 | If you are not the sole contributor to a contribution (pull request), please
12 | identify all contributors in the pull request comment.
13 | 
14 | To add a contributor (other than yourself, that's automatic), mark them one
15 | per line as follows:
16 | 
17 | ```
18 | +@github_username
19 | ```
20 | 
21 | If you added a contributor by mistake, you can remove them in a comment with:
22 | 
23 | ```
24 | -@github_username
25 | ```
26 | 
27 | If you are making a pull request on behalf of someone else but you had no part
28 | in designing the feature, you can remove yourself with the above syntax.
29 | 


--------------------------------------------------------------------------------
/LICENSE.md:
--------------------------------------------------------------------------------
1 | All Reports in this Repository are licensed by Contributors under the [W3C Software and Document
2 | License](https://www.w3.org/Consortium/Legal/2015/copyright-software-and-document).
3 | 
4 | Contributions to Specifications are made under the
5 | [W3C CLA](https://www.w3.org/community/about/agreements/cla/).
6 | 
7 | Contributions to Software, including sample implementations, are under the
8 | [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
9 | 


--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
 1 | ## WebKMS Specification
 2 | 
 3 | This specification describes a mechanism for performing remote cryptographic
 4 | key operations including key creation, signing, encryption, and decryption.
 5 | This technology is useful when securing communications using web-based,
 6 | hardware backed cryptographic systems.
 7 | 
 8 | We encourage contributions meeting the [Contribution
 9 | Guidelines](CONTRIBUTING.md).  While we prefer the creation of issues
10 | and Pull Requests in the GitHub repository, discussions often occur
11 | on the
12 | [public-credentials](http://lists.w3.org/Archives/Public/public-credentials/)
13 | mailing list as well.
14 | 
15 | ### Other useful links
16 | * [Public group email archive](https://lists.w3.org/Archives/Public/public-credentials/)
17 | 


--------------------------------------------------------------------------------
/common.js:
--------------------------------------------------------------------------------
  1 | /* globals omitTerms, respecConfig, $, require */
  2 | /* exported linkCrossReferences, restrictReferences, fixIncludes */
  3 | 
  4 | var ccg = {
  5 |   // Add as the respecConfig localBiblio variable
  6 |   // Extend or override global respec references
  7 |   localBiblio: {
  8 |     "REST": {
  9 |       title: "Architectural Styles and the Design of Network-based Software Architectures",
 10 |       date: "2000",
 11 |       href: "http://www.ics.uci.edu/~fielding/pubs/dissertation/",
 12 |       authors: [
 13 |         "Fielding, Roy Thomas"
 14 |       ],
 15 |       publisher: "University of California, Irvine."
 16 |     },
 17 |     "string-meta": {
 18 |       title: "Requirements for Language and Direction Metadata in Data Formats",
 19 |       href: "https://w3c.github.io/string-meta/",
 20 |       authors: [
 21 | 	"Addison Phillips",
 22 |         "Richard Ishida"
 23 |       ],
 24 |       status: "Editors-DRAFT",
 25 |       publisher: "Internationalization Working Group"
 26 |     },
 27 |     "LD-PROOFS": {
 28 |       title: "Linked Data Proofs",
 29 |       href: "https://w3c-dvcg.github.io/ld-proofs/",
 30 |       authors: [
 31 |         "Manu Sporny",
 32 |         "Dave Longley"
 33 |       ],
 34 |       status: "CG-DRAFT",
 35 |       publisher: "Digital Verification Community Group"
 36 |     },
 37 |     "LD-SIGNATURES": {
 38 |       title: "Linked Data Signatures",
 39 |       href: "https://w3c-dvcg.github.io/ld-signatures/",
 40 |       authors: [
 41 |         "Manu Sporny",
 42 |         "Dave Longley"
 43 |       ],
 44 |       status: "CG-DRAFT",
 45 |       publisher: "Digital Verification Community Group"
 46 |     },
 47 |     "LDS-RSA2018": {
 48 |       title: "The 2018 RSA Linked Data Signature Suite",
 49 |       href: "https://w3c-dvcg.github.io/lds-rsa2018/",
 50 |       authors: [
 51 |         "Manu Sporny",
 52 |         "Dave Longley"
 53 |       ],
 54 |       status: "CG-DRAFT",
 55 |       publisher: "Digital Verification Community Group"
 56 |     },
 57 |     // aliases to known references
 58 |     "HTTP-SIGNATURES": {
 59 |       aliasOf: "http-signatures"
 60 |     },
 61 |     'HASHLINK': {
 62 |       title: 'Cryptographic Hyperlinks',
 63 |       href: 'https://tools.ietf.org/html/draft-sporny-hashlink',
 64 |       authors: ['Manu Sporny'],
 65 |       status: 'Internet-Draft',
 66 |       publisher: 'Internet Engineering Task Force (IETF)'
 67 |     },
 68 |     'IPFS': {
 69 |       title: 'InterPlanetary File System (IPFS)',
 70 |       href: 'https://en.wikipedia.org/wiki/InterPlanetary_File_System',
 71 |       publisher: 'Wikipedia'
 72 |     }
 73 |   }
 74 | };
 75 | 
 76 | 
 77 | 
 78 | // We should be able to remove terms that are not actually
 79 | // referenced from the common definitions
 80 | //
 81 | // the termlist is in a block of class "termlist", so make sure that
 82 | // has an ID and put that ID into the termLists array so we can
 83 | // interrogate all of the included termlists later.
 84 | var termNames = [] ;
 85 | var termLists = [] ;
 86 | var termsReferencedByTerms = [] ;
 87 | 
 88 | function restrictReferences(utils, content) {
 89 |     "use strict";
 90 |     var base = document.createElement("div");
 91 |     base.innerHTML = content;
 92 | 
 93 |     // New new logic:
 94 |     //
 95 |     // 1. build a list of all term-internal references
 96 |     // 2. When ready to process, for each reference INTO the terms,
 97 |     // remove any terms they reference from the termNames array too.
 98 |     $.each(base.querySelectorAll("dfn"), function(i, item) {
 99 |         var $t = $(item) ;
100 |         var titles = $t.getDfnTitles();
101 |         var dropit = false;
102 |         // do we have an omitTerms
103 |         if (window.hasOwnProperty("omitTerms")) {
104 |             // search for a match
105 |             $.each(omitTerms, function(j, term) {
106 |                 if (titles.indexOf(term) !== -1) {
107 |                     dropit = true;
108 |                 }
109 |             });
110 |         }
111 |         // do we have an includeTerms
112 |         if (window.hasOwnProperty("includeTerms")) {
113 |             var found = false;
114 |             // search for a match
115 |             $.each(includeTerms, function(j, term) {
116 |                 if (titles.indexOf(term) !== -1) {
117 |                     found = true;
118 |                 }
119 |             });
120 |             if (!found) {
121 |                 dropit = true;
122 |             }
123 |         }
124 |         if (dropit) {
125 |             $t.parent().next().remove();
126 |             $t.parent().remove();
127 |         } else {
128 |             var n = $t.makeID("dfn", titles[0]);
129 |             if (n) {
130 |                 termNames[n] = $t.parent() ;
131 |             }
132 |         }
133 |     });
134 | 
135 |     var $container = $(".termlist",base) ;
136 |     var containerID = $container.makeID("", "terms") ;
137 |     termLists.push(containerID) ;
138 | 
139 |     return (base.innerHTML);
140 | }
141 | // add a handler to come in after all the definitions are resolved
142 | //
143 | // New logic: If the reference is within a 'dl' element of
144 | // class 'termlist', and if the target of that reference is
145 | // also within a 'dl' element of class 'termlist', then
146 | // consider it an internal reference and ignore it.
147 | 
148 | require(["core/pubsubhub"], function(respecEvents) {
149 |     "use strict";
150 |     respecEvents.sub('end', function(message) {
151 |         if (message === 'core/link-to-dfn') {
152 |             // all definitions are linked; find any internal references
153 |             $(".termlist a.internalDFN").each(function() {
154 |                 var $r = $(this);
155 |                 var id = $r.attr('href');
156 |                 var idref = id.replace(/^#/,"") ;
157 |                 if (termNames[idref]) {
158 |                     // this is a reference to another term
159 |                     // what is the idref of THIS term?
160 |                     var $def = $r.closest('dd') ;
161 |                     if ($def.length) {
162 |                         var $p = $def.prev('dt').find('dfn') ;
163 |                         var tid = $p.attr('id') ;
164 |                         if (tid) {
165 |                             if (termsReferencedByTerms[tid]) {
166 |                                 termsReferencedByTerms[tid].push(idref);
167 |                             } else {
168 |                                 termsReferencedByTerms[tid] = [] ;
169 |                                 termsReferencedByTerms[tid].push(idref);
170 |                             }
171 |                         }
172 |                     }
173 |                 }
174 |             }) ;
175 | 
176 |             // clearRefs is recursive.  Walk down the tree of
177 |             // references to ensure that all references are resolved.
178 |             var clearRefs = function(theTerm) {
179 |                 if ( termsReferencedByTerms[theTerm] ) {
180 |                     $.each(termsReferencedByTerms[theTerm], function(i, item) {
181 |                         if (termNames[item]) {
182 |                             delete termNames[item];
183 |                             clearRefs(item);
184 |                         }
185 |                     });
186 |                 }
187 |                 // make sure this term doesn't get removed
188 |                 if (termNames[theTerm]) {
189 |                     delete termNames[theTerm];
190 |                 }
191 |             };
192 | 
193 |             // now termsReferencedByTerms has ALL terms that
194 |             // reference other terms, and a list of the
195 |             // terms that they reference
196 |             $("a.internalDFN").each(function () {
197 |                 var $item = $(this) ;
198 |                 var t = $item.attr('href');
199 |                 var r = t.replace(/^#/,"") ;
200 |                 // if the item is outside the term list
201 |                 if ( ! $item.closest('dl.termlist').length ) {
202 |                     clearRefs(r);
203 |                 }
204 |             });
205 | 
206 |             // delete any terms that were not referenced.
207 |             /*
208 |             Object.keys(termNames).forEach(function(term) {
209 |                 var $p = $("#"+term) ;
210 |                 if ($p) {
211 |                     var tList = $p.getDfnTitles();
212 |                     $p.parent().next().remove();
213 |                     $p.parent().remove() ;
214 |                     tList.forEach(function( item ) {
215 |                       console.log("CHECKING ITEM", item, respecConfig);
216 |                         if (respecConfig.definitionMap[item]) {
217 |                             delete respecConfig.definitionMap[item];
218 |                         }
219 |                     });
220 |                 }
221 |             });*/
222 |         }
223 |     });
224 | });
225 | 


--------------------------------------------------------------------------------
/index.html:
--------------------------------------------------------------------------------
  1 | <!DOCTYPE html>
  2 | <html>
  3 |   <head>
  4 |     <title>WebKMS v0.7</title>
  5 |     <meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
  6 |     <!--
  7 |       === NOTA BENE ===
  8 |       For the three scripts below, if your spec resides on dev.w3 you can check them
  9 |       out in the same tree and use relative links so that they'll work offline,
 10 |      -->
 11 |     <script src='https://www.w3.org/Tools/respec/respec-w3c' class='remove'></script>
 12 |     <script src="./common.js" class="remove"></script>
 13 |     <script type="text/javascript" class="remove">
 14 |       var respecConfig = {
 15 |         // specification status (e.g., WD, LCWD, NOTE, etc.). If in doubt use ED.
 16 |         specStatus: "CG-DRAFT",
 17 | 
 18 |         // the specification's short name, as in http://www.w3.org/TR/short-name/
 19 |         shortName: "webkms",
 20 | 
 21 |         // subtitle for the spec
 22 |         subtitle: "Cryptographic Key Management Systems for the Web",
 23 | 
 24 |         // if you wish the publication date to be other than today, set this
 25 |         //publishDate: "2019-03-26",
 26 |         //crEnd: "2019-04-23",
 27 |         //implementationReportURI: "https://w3c.github.io/sdh-test-suite",
 28 |         previousMaturity: "UNOFFICIAL",
 29 |         previousPublishDate: "2020-12-29",
 30 | 
 31 |         // extend the bibliography entries
 32 |         localBiblio: ccg.localBiblio,
 33 |         doJsonLd: true,
 34 | 
 35 |         github: "https://github.com/w3c-ccg/webkms/",
 36 |         includePermalinks: false,
 37 | 
 38 |         // if there a publicly available Editor's Draft, this is the link
 39 |         edDraftURI: "https://w3c-ccg.github.io/webkms/",
 40 | 
 41 |         // if this is a LCWD, uncomment and set the end of its review period
 42 |         // lcEnd: "2009-08-05",
 43 | 
 44 |         // editors, add as many as you like
 45 |         // only "name" is required
 46 |         editors: [
 47 |           { name: "Manu Sporny", url: "http://manu.sporny.org/",
 48 |             company: "Digital Bazaar", companyURL: "https://digitalbazaar.com/"},
 49 |           { name: "Dave Longley", url: "https://github.com/dlongley",
 50 |             company: "Digital Bazaar", companyURL: "https://digitalbazaar.com/"}
 51 |         ],
 52 |         // authors, add as many as you like.
 53 |         // This is optional, uncomment if you have authors as well as editors.
 54 |         // only "name" is required. Same format as editors.
 55 |         authors:
 56 |         [
 57 |           { name: "Dave Longley", url: "https://digitalbazaar.com/",
 58 |             company: "Digital Bazaar", companyURL: "https://digitalbazaar.com/"},
 59 |           { name: "Manu Sporny", url: "https://digitalbazaar.com/",
 60 |             company: "Digital Bazaar", companyURL: "https://digitalbazaar.com/" }
 61 |         ],
 62 |         // name of the WG
 63 |         group: "credentials",
 64 |         maxTocLevel: 2,
 65 |         inlineCSS: true
 66 |       };
 67 |     </script>
 68 |     <style>
 69 | pre .highlight {
 70 |   font-weight: bold;
 71 |   color: green;
 72 | }
 73 | pre .comment {
 74 |   font-weight: bold;
 75 |   color: Gray;
 76 | }
 77 | .color-text {
 78 |   font-weight: bold;
 79 |   text-shadow: -1px 0 black, 0 1px black, 1px 0 black, 0 -1px black;
 80 | }
 81 |     </style>
 82 |   </head>
 83 |   <body>
 84 |     <section id='abstract'>
 85 |       <p>
 86 | Cryptographic authentication systems enable more secure interactions among
 87 | machines, individuals, and organizations. These systems often use public-private
 88 | key cryptography or encryption mechanisms to manage both cryptographic material
 89 | and operations utilizing that material. This specification provides a common data
 90 | model and interface for interacting with these systems enabling one to perform
 91 | secure cryptographic operations on keypairs such as creating, wrapping, unwrapping,
 92 | signing, encrypting, and decrypting.
 93 |       </p>
 94 |     </section>
 95 | 
 96 |     <section id='sotd'>
 97 |       <!--p>
 98 | Comments regarding all aspects of this document are welcome.
 99 | Please file issues
100 | directly on <a href="https://github.com/w3c-ccg/webkms/issues/">GitHub</a>,
101 | or send them to
102 | <a href="mailto:public-credentials@w3.org">public-credentials@w3.org</a>
103 | (<a href="mailto:public-credentials-request@w3.org?subject=subscribe">subscribe</a>,
104 | <a href="https://lists.w3.org/Archives/Public/public-credentials/">archives</a>).
105 | </p-->
106 | 
107 |     </section>
108 | 
109 |     <section class="informative">
110 |       <h2>Introduction</h2>
111 | 
112 |       <p>
113 | Cryptographic authentication systems enable machines, individuals, and
114 | organizations to more securely interact with one another. These systems often
115 | use public-private key cryptography or encryption mechanisms in order to  manage
116 | cryptographic material as well as operations utilizing that material. There are
117 | a variety of these sorts of cryptographic systems in use today, sometimes
118 | referred to as Key Management Systems. While many of these sorts of systems
119 | exist, there is no common interface for accessing and using these systems.
120 |       </p>
121 |       <p>
122 | The creation of a common interface for accessing Key Management Systems would
123 | enable software to be written once to interact with these systems such that
124 | systems with different implementations and properties could be switched
125 | without affecting the client software that utilizes such systems. A common API
126 | would shift the burden of interacting with each implementation to the vendors
127 | of those systems, while eliminating the burden for application developers.
128 |       </p>
129 |       <p>
130 | While there are a variety of proprietary enterprise grade Key Management Systems today
131 | that would benefit from a common interface, personal Key Management Systems
132 | such as those created through the Fast Identity Online (FIDO) initiative could
133 | also benefit.
134 |       </p>
135 |       <p>
136 | If the interface is provided as a Web-based interface, then Web-based
137 | applications could be written against such an API. Similarly, Web-based
138 | applications could provide choice in Key Management Systems -- potentially
139 | allowing customers to bring their own Key Management Systems with them just as
140 | they bring their own devices today.
141 |       </p>
142 | 
143 |       <section class="informative">
144 |         <h3>Ecosystem Overview</h3>
145 | 
146 |         <p>
147 | This section describes the roles of the core actors and the relationships
148 | between them in an ecosystem where this specification is expected
149 | to be useful. A role is an abstraction that might be implemented in many
150 | different ways. The separation of roles suggests likely interfaces and
151 | protocols for standardization. The following roles are introduced in this
152 | specification:
153 |         </p>
154 | 
155 |         <dl>
156 |           <dt>controller</dt>
157 |           <dd>
158 | A role an <a>entity</a> might perform by demonstrating control of
159 | cryptographic key material in order to authenticate itself with a system.
160 |           </dd>
161 |           <dt>key management client</dt>
162 |           <dd>
163 | A role an <a>entity</a> might perform by communicating with a Key Management
164 | System.
165 |           </dd>
166 |           <dt>key management system</dt>
167 |           <dd>
168 | A role an <a>entity</a> might perform by providing an interface to
169 | the management of cryptographic material and the execution of cryptographic
170 | operations.
171 |           </dd>
172 |         </dl>
173 | 
174 |       </section>
175 | 
176 |       <section class="informative">
177 |         <h3>Use Cases and Requirements</h3>
178 | 
179 |         <p>
180 | The following use cases outline a number of key scenarios that readers might
181 | find useful:
182 |         </p>
183 | 
184 |         <ul>
185 |           <li>
186 | Manage Keystore - Edwin would like to enable his application to create
187 | and delete keystores. Each keystore will have one or more controllers that
188 | are capable of controlling the keystore, and keys within the keystore.
189 | Controllers of the individual keys might not be the same as the controllers
190 | for the keystore.
191 |           </li>
192 |           <li>
193 | Sign Data - Padthmini instructs her application to digitally sign a document
194 | using a hardware-backed cryptographic key. Her application forwards the
195 | authorized request to a hardware-backed key management system that performs the
196 | operation and returns the digital signature.
197 |           </li>
198 |           <li>
199 | Verify Data - Haneda has received a document with a digital signature. He
200 | uses an application to verify the digital signature. The application provides
201 | the signed cryptographic hash, the public key used to sign the hash, and
202 | the digital signature to verify. The key management system responds to the
203 | request noting the status of the verification.
204 |           </li>
205 |           <li>
206 | Wrap and Unwrap Key - Mimi would like to exchange messages with BanPo without
207 | worrying about people that might intercept the messages. Mimi uses her
208 | application to set up a secure communication link to BanPo. The application
209 | requests the creation of an encryption key that is then wrapped and encrypted
210 | in a way that only BanPo can extract. The wrapped encryption key is sent to
211 | BanPo's application, which then unwraps and stores the encryption key. The
212 | exchange is done in such a way where neither Mimi, nor BanPo, nor any
213 | intermediaries have access to the encryption key (only the keystores can
214 | see and use the encryption key).
215 |           </li>
216 |           <li>
217 | Encrypt and Decrypt Data - Mimi would like to exchange messages with BanPo
218 | without worrying about people that might intercept the messages. They have
219 | already exchanged symmetric encryption keys. Mimi uses her application to
220 | encrypt a message, which is then sent to BanPo. BanPo uses his application
221 | to decrypt the message. This is done without BanPo having access to the
222 | decryption key, only the keystore has access to the decryption key.
223 |           </li>
224 |           <li>
225 | Bring Your Own Keystore - Kuwele would like to write his application to use a
226 | variety of 3rd party key management systems without having to manage drivers for
227 | each key management system. He finds a set of keystores using a common API and
228 | writes his application to use the common API. As new key management systems
229 | support the common API, he is able to easily integrate these new systems.
230 |           </li>
231 |         </ul>
232 | 
233 |         <p>
234 | As a result of documenting and analyzing the use cases, the following
235 | desirable ecosystem characteristics were identified for this specification:
236 |         </p>
237 | 
238 |         <ul>
239 |           <li>
240 | A standard data model for Web-based Key Management Systems MUST be defined.
241 |           </li>
242 |           <li>
243 | A standard HTTP API MUST be defined.
244 |           </li>
245 |           <li>
246 | Common key operations such as create, sign, verify, wrap, unwrap, encrypt,
247 | and decrypt MUST be supported.
248 |           </li>
249 |           <li>
250 | Utilizing private key material MUST be supported without the need to
251 | exfiltrate the key.
252 |           </li>
253 |           <li>
254 | Executing cryptographic functions MUST be delegatable on a per-key basis.
255 |           </li>
256 |           <li>
257 | Each keystore MUST be able to support one or more controller.
258 |           </li>
259 |         </ul>
260 |       </section>
261 | 
262 |       <section id="conformance" class="normative">
263 |         <p>
264 | TBD
265 |         </p>
266 |       </section>
267 | 
268 |     </section>
269 | 
270 |     <section class="informative">
271 |       <h2>Terminology</h2>
272 | 
273 |       <div data-include="./terms.html">
274 |       </div>
275 |     </section>
276 | 
277 |     <section class="informative">
278 |       <h2>Core Concepts</h2>
279 | 
280 |       <p>
281 | There is a relatively small set of common cryptographic operations that Key
282 | Management Systems provide. These operations include: generate, wrap, unwrap,
283 | sign, verify, encrypt, and decrypt. These cryptographic operations can be
284 | thought of as <em>functions</em> that operate on <em>objects</em>, in this case
285 | cryptographic keys, in a remote execution environment.
286 |       </p>
287 |       <p class="issue">
288 | Ensure that the list is updated from
289 | <a href="https://github.com/digitalbazaar/web-kms-switch/tree/master/lib/schemas">here</a>.
290 |       </p>
291 |       <p>
292 | The Authorization Capabilities for Linked Data [ZCAP-LD] specification,  also
293 | know as ZCAPs, outlines how remote execution environments can be  manipulated by
294 | demonstrating cryptographic control of  <em>functions</em> and <em>objects</em>.
295 | The  ZCAP-LD specification enables one to grant authority to remote clients to
296 | call functions on specific objects. This technology enables a Key Management
297 | System to provide a Web-based API that enables clients to create keys and
298 | execute cryptographic operations using those keys by invoking ZCAPs.
299 |       </p>
300 |       <p>
301 | The WebKMS API enables clients to create keystores, a type of <em>object</em>,
302 | that they control. That is, the client is the controller of the keystore.
303 | The client may also generate a key, another type of <em>object</em>, and
304 | associate it with a keystore. Each keystore is identified by a URI. In
305 | addition, the controller of a keystore can be changed to enable the transfer
306 | of keys without requiring the exfiltration of the key. Other entities can
307 | also be added as controllers of the keystore such that multiple parties might
308 | control the keystore without having access to the raw key material.
309 |       </p>
310 |       <p>
311 | Each key in the keystore has an associated set of <em>functions</em> according
312 | to the type of key that it is. Examples of key types include keys used for
313 | performing asymmetric cryptographic operations such as digital signatures and
314 | keys used for performing symmetric cryptographic operations such as
315 | encryption and decryption. These <em>functions</em> can be remotely executed
316 | via the use of ZCAPs such that the cryptographic key material never
317 | needs to be exfiltrated in order to use the key. In many hardware-backed
318 | cryptographic key management systems, the exfiltration of keys is not
319 | supported and the system itself is hardened against tampering with the
320 | intent to exfiltrate the keys.
321 |       </p>
322 |       <p>
323 | In order to execute a <em>function</em> on a key, a <code>KmsOperation</code>
324 | of a specific type can be applied to the key, including a ZCAP that
325 | invokes the capability that demonstrates the authorization to perform the
326 | operation. For example, a KmsOperation might be constructed and POSTed to
327 | the key URL with an invocation of a ZCAP performed via HTTP Signatures.
328 |       </p>
329 | 
330 |     </section>
331 | 
332 |     <section>
333 |       <h2>HTTP API</h2>
334 | 
335 |       <dl>
336 |         <dt><a href="#webkms_generateKey">generateKey(options)</a> ⇒ <code>&lt;map&gt;</code></dt>
337 |         <dd>
338 |           <p>Generates a new cryptographic key in the keystore.</p>
339 |         </dd>
340 |         <dt><a href="#webkms_getKeyDescription">getKeyDescription(options)</a> ⇒ <code>&lt;map&gt;</code></dt>
341 |         <dd>
342 |           <p>Gets the key description for the given key ID.</p>
343 |         </dd>
344 |         <dt><a href="#webkms_revokeCapability">revokeCapability(options)</a> ⇒ <code>&lt;map&gt;</code></dt>
345 |         <dd>
346 |           <p>Store a capability revocation.</p>
347 |         </dd>
348 |         <dt><a href="#webkms_wrapKey">wrapKey(options)</a> ⇒ <code>&lt;string&gt;</code></dt>
349 |         <dd>
350 |           <p>Wraps a cryptographic key using a key encryption key (KEK).</p>
351 |         </dd>
352 |         <dt><a href="#webkms_unwrapKey">unwrapKey(options)</a> ⇒ <code>&lt;(Uint8Array|null)&gt;</code></dt>
353 |         <dd>
354 |           <p>Unwraps a cryptographic key using a key encryption key (KEK).</p>
355 |         </dd>
356 |         <dt><a href="#webkms_sign">sign(options)</a> ⇒ <code>&lt;string&gt;</code></dt>
357 |         <dd>
358 |           <p>Signs some data. Note that the data will be sent to the server, so if
359 |             this data is intended to be secret it should be hashed first. However,
360 |             hashing the data first may present interoperability issues so choose
361 |             wisely.
362 |           </p>
363 |         </dd>
364 |         <dt><a href="#webkms_verify">verify(options)</a> ⇒ <code>&lt;boolean&gt;</code></dt>
365 |         <dd>
366 |           <p>Verifies some data. Note that the data will be sent to the server, so if
367 |             this data is intended to be secret it should be hashed first. However,
368 |             hashing the data first may present interoperability issues so choose
369 |             wisely.
370 |           </p>
371 |         </dd>
372 |         <dt><a href="#webkms_deriveSecret">deriveSecret(options)</a> ⇒ <code>&lt;Uint8Array&gt;</code></dt>
373 |         <dd>
374 |           <p>Derives a shared secret via the given peer public key, typically for use
375 |             as one parameter for computing a shared key. It should not be used as
376 |             a shared key itself, but rather input into a key derivation function (KDF)
377 |             to produce a shared key.
378 |           </p>
379 |         </dd>
380 |         <dt><a href="#webkms_enableCapability">enableCapability(options)</a> ⇒ <code>&lt;map&gt;</code></dt>
381 |         <dd>
382 |           <p>Stores a delegated authorization capability, enabling it to be invoked by
383 |             its designated invoker.
384 |           </p>
385 |         </dd>
386 |         <dt><a href="#webkms_disableCapability">disableCapability(options)</a> ⇒ <code>&lt;boolean&gt;</code></dt>
387 |         <dd>
388 |           <p>Removes a previously stored delegated authorization capability, preventing
389 |             it from being invoked by its designated invoker.
390 |           </p>
391 |         </dd>
392 |         <dt><a href="#webkms_createKeystore">createKeystore(options)</a> ⇒ <code>&lt;map&gt;</code></dt>
393 |         <dd>
394 |           <p>Creates a new keystore using the given configuration.</p>
395 |         </dd>
396 |         <dt><a href="#webkms_getKeystore">getKeystore(options)</a> ⇒ <code>&lt;map&gt;</code></dt>
397 |         <dd>
398 |           <p>Gets the configuration for a keystore by its ID.</p>
399 |         </dd>
400 |         <dt><a href="#webkms_findKeystore">findKeystore(options)</a> ⇒ <code>&lt;map&gt;</code></dt>
401 |         <dd>
402 |           <p>Finds the configuration for a keystore by its controller and reference ID.</p>
403 |         </dd>
404 |       </dl>
405 | 
406 |       <section><h3 name="webkms_generateKey">generateKey(options) ⇒ <code>&lt;map&gt;</code></h3>
407 |       <p>Generates a new cryptographic key in the keystore.</p>
408 |       <p><strong>Response</strong>: HTTP 200 -  <code>&lt;map&gt;</code> - The key description for the key.</p>
409 |       <table class="simple">
410 |         <thead>
411 |           <tr>
412 |             <th>Param</th>
413 |             <th>Type</th>
414 |             <th>Description</th>
415 |           </tr>
416 |         </thead>
417 |         <tbody>
418 |           <tr>
419 |             <td>options.kmsModule</td>
420 |             <td><code>string</code></td>
421 |             <td>The KMS module to use.</td>
422 |           </tr>
423 |           <tr>
424 |             <td>options.type</td>
425 |             <td><code>string</code></td>
426 |             <td>The key type (e.g. &#39;AesKeyWrappingKey2019&#39;).</td>
427 |           </tr>
428 |           <tr>
429 |             <td>[options.capability]</td>
430 |             <td><code>string</code></td>
431 |             <td>The zCAP-LD authorization   capability to use to authorize the invocation of this operation.</td>
432 |           </tr>
433 |           <tr>
434 |             <td>options.invocationSigner</td>
435 |             <td><code>map</code></td>
436 |             <td>An API with an   <code>id</code> property and a <code>sign</code> function for signing a capability invocation.</td>
437 |           </tr>
438 |         </tbody>
439 |       </table>
440 |       <p><a name="webkms_getKeyDescription"></a></p>
441 |       </section><section><h3 id="getkeydescription-options-code-lt-map-gt-code-">getKeyDescription(options) ⇒ <code>&lt;map&gt;</code></h3>
442 |       <p>Gets the key description for the given key ID.</p>
443 |       <p><strong>Response</strong>: HTTP 200 -  <code>&lt;map&gt;</code> - The key description.</p>
444 |       <table class="simple">
445 |         <thead>
446 |           <tr>
447 |             <th>Param</th>
448 |             <th>Type</th>
449 |             <th>Description</th>
450 |           </tr>
451 |         </thead>
452 |         <tbody>
453 |           <tr>
454 |             <td>[options.keyId]</td>
455 |             <td><code>string</code></td>
456 |             <td>The ID of the key.</td>
457 |           </tr>
458 |           <tr>
459 |             <td>[options.capability]</td>
460 |             <td><code>string</code></td>
461 |             <td>The zCAP-LD authorization   capability to use to authorize the invocation of this operation.</td>
462 |           </tr>
463 |           <tr>
464 |             <td>options.invocationSigner</td>
465 |             <td><code>map</code></td>
466 |             <td>An API with an   <code>id</code> property and a <code>sign</code> function for signing a capability invocation.</td>
467 |           </tr>
468 |         </tbody>
469 |       </table>
470 |       <p><a name="webkms_revokeCapability"></a></p>
471 |       </section><section><h3 id="revokecapability-options-code-lt-map-gt-code-">revokeCapability(options) ⇒ <code>&lt;map&gt;</code></h3>
472 |       <p>Store a capability revocation.</p>
473 |       <p><strong>Response</strong>: HTTP 200 -  <code>&lt;map&gt;</code> - Resolves once the operation completes.</p>
474 |       <table class="simple">
475 |         <thead>
476 |           <tr>
477 |             <th>Param</th>
478 |             <th>Type</th>
479 |             <th>Description</th>
480 |           </tr>
481 |         </thead>
482 |         <tbody>
483 |           <tr>
484 |             <td>options.capabilityToRevoke</td>
485 |             <td><code>map</code></td>
486 |             <td>The capability to enable.</td>
487 |           </tr>
488 |           <tr>
489 |             <td>[options.capability]</td>
490 |             <td><code>string</code></td>
491 |             <td>The zcap authorization   capability to use to authorize the invocation of this operation.</td>
492 |           </tr>
493 |           <tr>
494 |             <td>options.invocationSigner</td>
495 |             <td><code>map</code></td>
496 |             <td>An API with an   <code>id</code> property and a <code>sign</code> function for signing a capability invocation.</td>
497 |           </tr>
498 |         </tbody>
499 |       </table>
500 |       <p><a name="webkms_wrapKey"></a></p>
501 |       </section><section><h3 id="wrapkey-options-code-lt-string-gt-code-">wrapKey(options) ⇒ <code>&lt;string&gt;</code></h3>
502 |       <p>Wraps a cryptographic key using a key encryption key (KEK).</p>
503 |       <p><strong>Response</strong>: HTTP 200 -  <code>&lt;string&gt;</code> - The base64url-encoded wrapped key bytes.</p>
504 |       <table class="simple">
505 |         <thead>
506 |           <tr>
507 |             <th>Param</th>
508 |             <th>Type</th>
509 |             <th>Description</th>
510 |           </tr>
511 |         </thead>
512 |         <tbody>
513 |           <tr>
514 |             <td>options.kekId</td>
515 |             <td><code>string</code></td>
516 |             <td>The ID of the wrapping key to use.</td>
517 |           </tr>
518 |           <tr>
519 |             <td>options.unwrappedKey</td>
520 |             <td><code>Uint8Array</code></td>
521 |             <td>The unwrapped key material as   a Uint8Array.</td>
522 |           </tr>
523 |           <tr>
524 |             <td>[options.capability]</td>
525 |             <td><code>string</code></td>
526 |             <td>The zCAP-LD authorization   capability to use to authorize the invocation of this operation.</td>
527 |           </tr>
528 |           <tr>
529 |             <td>options.invocationSigner</td>
530 |             <td><code>map</code></td>
531 |             <td>An API with an   <code>id</code> property and a <code>sign</code> function for signing a capability invocation.</td>
532 |           </tr>
533 |         </tbody>
534 |       </table>
535 |       <p><a name="webkms_unwrapKey"></a></p>
536 |       </section><section><h3 id="unwrapkey-options-code-lt-uint8array-null-gt-code-">unwrapKey(options) ⇒ <code>&lt;(Uint8Array|null)&gt;</code></h3>
537 |       <p>Unwraps a cryptographic key using a key encryption key (KEK).</p>
538 |       <p><strong>Response</strong>: HTTP 200 -  <code>&lt;(Uint8Array|null)&gt;</code> - Resolves to the unwrapped key material
539 |         or null if the unwrapping failed because the key did not match.
540 |       </p>
541 |       <table class="simple">
542 |         <thead>
543 |           <tr>
544 |             <th>Param</th>
545 |             <th>Type</th>
546 |             <th>Description</th>
547 |           </tr>
548 |         </thead>
549 |         <tbody>
550 |           <tr>
551 |             <td>options.kekId</td>
552 |             <td><code>string</code></td>
553 |             <td>The ID of the unwrapping key to use.</td>
554 |           </tr>
555 |           <tr>
556 |             <td>options.wrappedKey</td>
557 |             <td><code>string</code></td>
558 |             <td>The wrapped key material as a   base64url-encoded string.</td>
559 |           </tr>
560 |           <tr>
561 |             <td>[options.capability]</td>
562 |             <td><code>string</code></td>
563 |             <td>The zCAP-LD authorization   capability to use to authorize the invocation of this operation.</td>
564 |           </tr>
565 |           <tr>
566 |             <td>options.invocationSigner</td>
567 |             <td><code>map</code></td>
568 |             <td>An API with an   <code>id</code> property and a <code>sign</code> function for signing a capability invocation.</td>
569 |           </tr>
570 |         </tbody>
571 |       </table>
572 |       <p><a name="webkms_sign"></a></p>
573 |       </section><section><h3 id="sign-options-code-lt-string-gt-code-">sign(options) ⇒ <code>&lt;string&gt;</code></h3>
574 |       <p>Signs some data. Note that the data will be sent to the server, so if
575 |         this data is intended to be secret it should be hashed first. However,
576 |         hashing the data first may present interoperability issues so choose
577 |         wisely.
578 |       </p>
579 |       <p><strong>Response</strong>: HTTP 200 -  <code>&lt;string&gt;</code> - The base64url-encoded signature.</p>
580 |       <table class="simple">
581 |         <thead>
582 |           <tr>
583 |             <th>Param</th>
584 |             <th>Type</th>
585 |             <th>Description</th>
586 |           </tr>
587 |         </thead>
588 |         <tbody>
589 |           <tr>
590 |             <td>options.keyId</td>
591 |             <td><code>string</code></td>
592 |             <td>The ID of the signing key to use.</td>
593 |           </tr>
594 |           <tr>
595 |             <td>options.data</td>
596 |             <td><code>Uint8Array</code></td>
597 |             <td>The data to sign as a Uint8Array.</td>
598 |           </tr>
599 |           <tr>
600 |             <td>[options.capability]</td>
601 |             <td><code>string</code></td>
602 |             <td>The zCAP-LD authorization   capability to use to authorize the invocation of this operation.</td>
603 |           </tr>
604 |           <tr>
605 |             <td>options.invocationSigner</td>
606 |             <td><code>map</code></td>
607 |             <td>An API with an   <code>id</code> property and a <code>sign</code> function for signing a capability invocation.</td>
608 |           </tr>
609 |         </tbody>
610 |       </table>
611 |       <p><a name="webkms_verify"></a></p>
612 |       </section><section><h3 id="verify-options-code-lt-boolean-gt-code-">verify(options) ⇒ <code>&lt;boolean&gt;</code></h3>
613 |       <p>Verifies some data. Note that the data will be sent to the server, so if
614 |         this data is intended to be secret it should be hashed first. However,
615 |         hashing the data first may present interoperability issues so choose
616 |         wisely.
617 |       </p>
618 |       <p><strong>Response</strong>: HTTP 200 -  <code>&lt;boolean&gt;</code> - <code>true</code> if verified, <code>false</code> if not.</p>
619 |       <table class="simple">
620 |         <thead>
621 |           <tr>
622 |             <th>Param</th>
623 |             <th>Type</th>
624 |             <th>Description</th>
625 |           </tr>
626 |         </thead>
627 |         <tbody>
628 |           <tr>
629 |             <td>options.keyId</td>
630 |             <td><code>string</code></td>
631 |             <td>The ID of the signing key to use.</td>
632 |           </tr>
633 |           <tr>
634 |             <td>options.data</td>
635 |             <td><code>Uint8Array</code></td>
636 |             <td>The data to verify as a Uint8Array.</td>
637 |           </tr>
638 |           <tr>
639 |             <td>options.signature</td>
640 |             <td><code>string</code></td>
641 |             <td>The base64url-encoded signature to   verify.</td>
642 |           </tr>
643 |           <tr>
644 |             <td>[options.capability]</td>
645 |             <td><code>string</code></td>
646 |             <td>The zCAP-LD authorization   capability to use to authorize the invocation of this operation.</td>
647 |           </tr>
648 |           <tr>
649 |             <td>options.invocationSigner</td>
650 |             <td><code>map</code></td>
651 |             <td>An API with an   <code>id</code> property and a <code>sign</code> function for signing a capability invocation.</td>
652 |           </tr>
653 |         </tbody>
654 |       </table>
655 |       <p><a name="webkms_deriveSecret"></a></p>
656 |       </section><section><h3 id="derivesecret-options-code-lt-uint8array-gt-code-">deriveSecret(options) ⇒ <code>&lt;Uint8Array&gt;</code></h3>
657 |       <p>Derives a shared secret via the given peer public key, typically for use
658 |         as one parameter for computing a shared key. It should not be used as
659 |         a shared key itself, but rather input into a key derivation function (KDF)
660 |         to produce a shared key.
661 |       </p>
662 |       <p><strong>Response</strong>: HTTP 200 -  <code>&lt;Uint8Array&gt;</code> - The shared secret bytes.</p>
663 |       <table class="simple">
664 |         <thead>
665 |           <tr>
666 |             <th>Param</th>
667 |             <th>Type</th>
668 |             <th>Description</th>
669 |           </tr>
670 |         </thead>
671 |         <tbody>
672 |           <tr>
673 |             <td>options.keyId</td>
674 |             <td><code>string</code></td>
675 |             <td>The ID of the key agreement key to use.</td>
676 |           </tr>
677 |           <tr>
678 |             <td>options.publicKey</td>
679 |             <td><code>map</code></td>
680 |             <td>The public key to compute the shared   secret against; the public key type must match the key agreement key&#39;s   type.</td>
681 |           </tr>
682 |           <tr>
683 |             <td>[options.capability]</td>
684 |             <td><code>string</code></td>
685 |             <td>The zCAP-LD authorization   capability to use to authorize the invocation of this operation.</td>
686 |           </tr>
687 |           <tr>
688 |             <td>options.invocationSigner</td>
689 |             <td><code>map</code></td>
690 |             <td>An API with an   <code>id</code> property and a <code>sign</code> function for signing a capability invocation.</td>
691 |           </tr>
692 |         </tbody>
693 |       </table>
694 |       <p><a name="webkms_enableCapability"></a></p>
695 |       </section><section><h3 id="enablecapability-options-code-lt-map-gt-code-">enableCapability(options) ⇒ <code>&lt;map&gt;</code></h3>
696 |       <p>Stores a delegated authorization capability, enabling it to be invoked by
697 |         its designated invoker.
698 |       </p>
699 |       <p><strong>Response</strong>: HTTP 200 -  <code>&lt;map&gt;</code> - Resolves once the operation completes.</p>
700 |       <table class="simple">
701 |         <thead>
702 |           <tr>
703 |             <th>Param</th>
704 |             <th>Type</th>
705 |             <th>Description</th>
706 |           </tr>
707 |         </thead>
708 |         <tbody>
709 |           <tr>
710 |             <td>options.capabilityToEnable</td>
711 |             <td><code>map</code></td>
712 |             <td>The capability to enable.</td>
713 |           </tr>
714 |           <tr>
715 |             <td>[options.capability]</td>
716 |             <td><code>string</code></td>
717 |             <td>The zCAP-LD authorization   capability to use to authorize the invocation of this operation.</td>
718 |           </tr>
719 |           <tr>
720 |             <td>options.invocationSigner</td>
721 |             <td><code>map</code></td>
722 |             <td>An API with an   <code>id</code> property and a <code>sign</code> function for signing a capability invocation.</td>
723 |           </tr>
724 |         </tbody>
725 |       </table>
726 |       <p><a name="webkms_disableCapability"></a></p>
727 |       </section><section><h3 id="disablecapability-options-code-lt-boolean-gt-code-">disableCapability(options) ⇒ <code>&lt;boolean&gt;</code></h3>
728 |       <p>Removes a previously stored delegated authorization capability, preventing
729 |         it from being invoked by its designated invoker.
730 |       </p>
731 |       <p><strong>Response</strong>: HTTP 200 -  <code>&lt;boolean&gt;</code> - Resolves to <code>true</code> if the document was deleted
732 |         and <code>false</code> if it did not exist.
733 |       </p>
734 |       <table class="simple">
735 |         <thead>
736 |           <tr>
737 |             <th>Param</th>
738 |             <th>Type</th>
739 |             <th>Description</th>
740 |           </tr>
741 |         </thead>
742 |         <tbody>
743 |           <tr>
744 |             <td>options.id</td>
745 |             <td><code>map</code></td>
746 |             <td>The ID of the capability to revoke.</td>
747 |           </tr>
748 |           <tr>
749 |             <td>[options.capability]</td>
750 |             <td><code>string</code></td>
751 |             <td>The zCAP-LD authorization   capability to use to authorize the invocation of this operation.</td>
752 |           </tr>
753 |           <tr>
754 |             <td>options.invocationSigner</td>
755 |             <td><code>map</code></td>
756 |             <td>An API with an   <code>id</code> property and a <code>sign</code> function for signing a capability invocation.</td>
757 |           </tr>
758 |         </tbody>
759 |       </table>
760 |       <p><a name="webkms_createKeystore"></a></p>
761 |       </section><section><h3 id="createkeystore-options-code-lt-map-gt-code-">createKeystore(options) ⇒ <code>&lt;map&gt;</code></h3>
762 |       <p>Creates a new keystore using the given configuration.</p>
763 |       <p><strong>Response</strong>: HTTP 200 -  <code>&lt;map&gt;</code> - Resolves to the configuration for the newly
764 |         created keystore.
765 |       </p>
766 |       <table class="simple">
767 |         <thead>
768 |           <tr>
769 |             <th>Param</th>
770 |             <th>Type</th>
771 |             <th>Description</th>
772 |           </tr>
773 |         </thead>
774 |         <tbody>
775 |           <tr>
776 |             <td>options.url</td>
777 |             <td><code>string</code></td>
778 |             <td>The url to post the configuration to.</td>
779 |           </tr>
780 |           <tr>
781 |             <td>options.config</td>
782 |             <td><code>string</code></td>
783 |             <td>The keystore&#39;s configuration.</td>
784 |           </tr>
785 |         </tbody>
786 |       </table>
787 |       <p><a name="webkms_getKeystore"></a></p>
788 |       </section><section><h3 id="getkeystore-options-code-lt-map-gt-code-">getKeystore(options) ⇒ <code>&lt;map&gt;</code></h3>
789 |       <p>Gets the configuration for a keystore by its ID.</p>
790 |       <p><strong>Response</strong>: HTTP 200 -  <code>&lt;map&gt;</code> - Resolves to the configuration for the keystore.</p>
791 |       <table class="simple">
792 |         <thead>
793 |           <tr>
794 |             <th>Param</th>
795 |             <th>Type</th>
796 |             <th>Description</th>
797 |           </tr>
798 |         </thead>
799 |         <tbody>
800 |           <tr>
801 |             <td>options.id</td>
802 |             <td><code>string</code></td>
803 |             <td>The keystore&#39;s ID.</td>
804 |           </tr>
805 |         </tbody>
806 |       </table>
807 |       <p><a name="webkms_findKeystore"></a></p>
808 |       </section><section><h3 id="findkeystore-options-code-lt-map-gt-code-">findKeystore(options) ⇒ <code>&lt;map&gt;</code></h3>
809 |       <p>Finds the configuration for a keystore by its controller and reference ID.</p>
810 |       <p><strong>Response</strong>: HTTP 200 -  <code>&lt;map&gt;</code> - Resolves to the configuration for the keystore.</p>
811 |       <table class="simple">
812 |         <thead>
813 |           <tr>
814 |             <th>Param</th>
815 |             <th>Type</th>
816 |             <th>Description</th>
817 |           </tr>
818 |         </thead>
819 |         <tbody>
820 |           <tr>
821 |             <td>[options.url]</td>
822 |             <td><code>string</code></td>
823 |             <td>The url to query.</td>
824 |           </tr>
825 |           <tr>
826 |             <td>options.controller</td>
827 |             <td><code>string</code></td>
828 |             <td>The keystore&#39;s controller.</td>
829 |           </tr>
830 |           <tr>
831 |             <td>options.referenceId</td>
832 |             <td><code>string</code></td>
833 |             <td>The keystore&#39;s reference ID.</td>
834 |           </tr>
835 |         </tbody>
836 |       </table>
837 | 
838 |     </section>
839 |   </section>
840 | 
841 |   <section class="informative">
842 |     <h2>Privacy Considerations</h2>
843 | 
844 |     <p>
845 | This section details the general privacy considerations and specific privacy
846 | implications of deploying this specification into production environments.
847 |     </p>
848 | 
849 |   </section>
850 | 
851 |   <section class="informative">
852 |     <h2>Security Considerations</h2>
853 | 
854 |     <p>
855 | There are a number of security considerations that implementers should be
856 | aware of when processing data described by this specification. Ignoring or
857 | not understanding the implications of this section can result in
858 | security vulnerabilities.
859 |     </p>
860 | 
861 |     <p>
862 | While this section attempts to highlight a broad set of security
863 | considerations, it is not a complete list. Implementers are urged to seek the
864 | advice of security and cryptography professionals when implementing mission
865 | critical systems using the technology outlined in this specification.
866 |     </p>
867 | 
868 |   </section>
869 | 
870 |   <section class="informative">
871 |     <h2>Accessibility Considerations</h2>
872 | 
873 |     <p>
874 | There are a number of accessibility considerations implementers should be
875 | aware of when processing data described in this specification. As with any web
876 | standards or protocols implementation, ignoring accessibility issues makes
877 | this information unusable to a large subset of the population. It is important
878 | to follow accessibility guidelines and standards, such as [[WCAG21]], to ensure
879 | all people, regardless of ability, can make use of this data. This is
880 | especially important when establishing systems utilizing cryptography, which
881 | have historically created problems for assistive technologies.
882 |     </p>
883 | 
884 |     <p>
885 | This section details the general accessibility considerations to take into
886 | account when utilizing this data model.
887 |     </p>
888 | 
889 |   </section>
890 | 
891 |   <section class="informative">
892 |     <h2>Internationalization Considerations</h2>
893 | 
894 |     <p>
895 | There are a number of internationalization considerations implementers should be
896 | aware of when publishing data described in this specification. As with any web
897 | standards or protocols implementation, ignoring internationalization makes it
898 | difficult for data to be produced and consumed across a disparate set of
899 | languages and societies, which would limit the applicability of the
900 | specification and significantly diminish its value as a standard.
901 |     </p>
902 | 
903 |     <p>
904 | This section outlines general internationalization considerations to take into
905 | account when utilizing this data model.
906 |     </p>
907 | 
908 |   </section>
909 | 
910 |   </body>
911 | </html>
912 | 


--------------------------------------------------------------------------------
/terms.html:
--------------------------------------------------------------------------------
 1 | <p>
 2 | The following terms are used to describe concepts in this specification.
 3 | </p>
 4 | 
 5 | <dl class="termlist">
 6 |   <dt><dfn data-lt="entities|entity's">entity</dfn></dt>
 7 |   <dd>
 8 | A thing with distinct and independent existence, such as a person,
 9 | organization, or device that performs one or more roles in the ecosystem.
10 |   </dd>
11 |   <dt><dfn>user agent</dfn></dt>
12 |   <dd>
13 | A program, such as a browser or other Web client, that mediates the
14 | communication between the various roles in this specification.
15 |   </dd>
16 |   <dt><dfn data-lt="URI|URIs">URI</dfn></dt>
17 |   <dd>
18 | An identifier as defined by [[RFC3986]].
19 |   </dd>
20 | </dl>
21 | 


--------------------------------------------------------------------------------
/w3c.json:
--------------------------------------------------------------------------------
 1 | {
 2 |   "group": [
 3 |     "credentials"
 4 |   ],
 5 |   "contacts": [
 6 |     "msporny", "dlongley"
 7 |   ],
 8 |   "shortName": "data-hubs",
 9 |   "repo-type": "cg-report"
10 | }
11 | 


--------------------------------------------------------------------------------